那些可爱的人儿叫技术支持
1、前言
提到运维部，你最先想到什么？
老妹儿的回答虽好，但运维部远不止以上几种兵种，今天就让我们走近科学...啊调错频道了...走近运维部神秘兵种之一 —— 运行支持中心。
各位镖友想必看过刘大掌柜亲自执笔的《故障管理与吉吝凶悔》，文中有云：运维如人生，充满吉吝凶悔。
吉：平稳运行期
吝：隐患积累期
凶：故障发生期
悔：复盘反思期
而伴随运行支持的，往往是一个“凶”字和一个“悔”字。
运行支持中心，顾名思义，对线上系统的稳定运行提供支持、保障。
我们提供线上7*24小时监控、故障应急响应及总结、应急预案制定、应急演练组织协调、大促支撑等一系列服务，所以我们的户口本上永远有个曾用名——运维监控服务台。
说到这各位镖友一定迫不及待想知道我们的日常了吧，今儿我们就来聊聊运行支持部技术支持的日常。
镖友：（扔鸡蛋）不想听！
航仔：扑通...
2、技术支持的日常
2.1 故障管理
旁友们
您是否会因漏看了一条告警，错过故障最佳解决时间
是否会为一时激动，忘记上次相同故障如何解决
是否因系统庞杂，不知故障找谁处理
那么...
您一定是遇到了假技术支持
我们提供全方位的故障管理服务，包括线上7*24小时监控、故障通知、故障分诊、故障联查、故障记录、故障复盘、改进项制定、故障归档等一系列故障排查处理机制，还有技术支持小管家定期询问您改进项进度哦
做故障管理，我们是认真的
2.2 应急预案
据不完全统计，技术支持小管家平均每月跟踪故障达116起，其中约10%（12起）为高等级紧急故障，这么多故障，我们是怎样有秩序地跟进并给出解决建议的呢，这就要提到技术支持的法宝--应急预案。
应急预案，即根据各故障场景，给出的完善的、联动的、可执行性的故障解决方案。
应急预案的来源主要有两方面，一是各系统负责人根据已知故障场景，给出的可能的解决方案；二是根据故障中前人经（cai）验（keng）的积累，将前人智慧的结晶总结至应急预案中。你可能会问，相同故障怎么会重复出现？这位镖友一定听过这样一句话：
说了这么多，好的应急预案应该是什么样的呢？大致有以下几点：
① 场景覆盖 好的应急预案会尽可能多地覆盖故障隐患点，给相同或相似场景的故障提供处理建议和指导；
② 可执行性 好的应急预案一定是友好的、可执行的，一个模糊的故障处理方法不能称之为应急预案；
③ 千锤百炼 好的应急预案需经历故障处理或应急演练的考验，这样的应急预案才能有效指导故障管理。
2.3 应急演练
为保障系统稳定、验证应急预案可执行性，我们会有计划地进行应急演练、变更。
整体来看，一套完整的演练流程包含如下部分：
① 演练需求收集及排期
我们会以半年度为单位，定期收集演练、变更需求，技术支持结合需求方意愿及实际情况进行月度演练排期，月度演练负责人将计划具体到各周、各天
② 演练前期准备
风险评估：同执行人确认（或凭借经验积累）操作层面的影响，同相关方（业务方、PE等或凭经验）确认到具体对业务层面的影响（如涉及定时任务需错峰操作）。
操作计划确认：需同相关方确认操作范围、操作时间、影响范围（受影响业务、人员）、影响时长、操作步骤、风险防范措施等，当然还包含一些待确认事项，如数据库相关操作需确认应用到数据库的网络权限是否已全部开通、应用有无ip直连数据库的、应用是否有自动重连机制、数据库是否有其它使用方等；而网络操作需确认有无旁路环境、“瞬断”的时长等等。
验证人员确认：需同操作人确认验证方式，技术支持提前协调相关人员支持验证
操作周知：将如上确认内容行程操作计划书，并将操作通知发送到各相关方（研发群组、客服、监控、运营等）。
操作流程周知：操作前需将操作流程周知相关人员，确认所有人了解操作顺序及各自负责的内容，做到有条不紊，常用的方式有拉群、邮件周知计划书、组会当面沟通等。
总结起来就是，要想演练做得好，前期准备少不了。
③ 过程跟进
演练过程中要注意演练节奏的掌控，做好演练过程的记录，必要时需针对突发情况进行应急故障响应，一律遵循故障处理原则，视排查情况决定是否继续操作
④ 演练总结
当日演练总结：技术支持会针对每个演练进行总结，包含操作起止时间、操作步骤概述、演练是否符合预期等，针对演练中存在的问题，需重点总结并跟进，并周知相关方
每周演练总结：针对当周进行的演练进行总结汇总，并周知运维部全员
月度演练总结：针对当月演练进行月度演练总结，分享心得体会，形成演练报告并上传至wiki
半年度/年度演练总结：技术支持每半年进行一次半年度演练总结，出具数据报表周知运维部
应急演练/变更流程
虽然我们前期会尽可能地考虑到各种情况，但毕竟涉及到线上变更，有一定的风险，所以我们的操作一般都在凌晨，也因为这样，我们有了一大拨一起熬夜的兄弟。
DBA和网络兄弟是我们的大客户，据统计，2016年度全年技术支持协调演练共计227次，数据库及网络相关操作共计192次，约占全年的85%。
说到这儿，您一定很好奇，我们都有哪些操作呢？
直接上图！
2.4 大促支撑
相信对于大促，各位镖友定是又爱又恨，敢问各位镖友，大促既过，双手安在否？
每年618、双十一，都是金融人的节日，技术支持如约来到这里，组织金融运维、金融主干业务线研发进行大促值班，为了这一天，我们往往提前两到三个月就开始准备。
关于大促，您看得到的是系统稳定，看不到的是我们的彻夜坚守。
二零一六年双十一，金融运维、主干业务线研发值班会场之一
二零一七年618
下面就让我们来了解下，技术支持小管家在大促中是怎样带节奏的吧。
2.4.1 大促前
关键词：大促启动会
我们会提前两到三个月组织大促启动会，针对以往大促的改进项完成进度进行说明汇报，并针对系统评估、资源备份等准备工作进行事项说明，并确认人员分工、工期评估，之后技术支持每周会组织大促前期准备会，确认好各项事宜进度及遇到的问题，在会上统一进行汇报。
大促前置准备工作
2.4.1.1 系统评估
系统评估是每年大促前期准备工作的重头戏，包含系统架构优化、银行通道容量评估、系统/数据库容量评估等，而核心系统压测及扩容可以说是重中之重。
提到压测、扩容，可能各位镖友随口就能说出，不就是对系统逐渐施加压力，看看系统瓶颈在哪嘛。
这些大家都了解，今天我们说点儿不一样的。
关键词：交易支付全链路压测
2016年双十一大促，由运维部牵头，首次实现了交易支付全链路压测。即采用虚拟银行、虚拟商户和测试用户方式，介由入口流量压测的方式，找到各分支系统瓶颈点，并分析是否进行扩容，以达到系统评估优化的目的。
本次交易支付全链路压测，主要针对收单和支付接口，共执行五轮单机房线上压测，其中收单两轮、支付三轮，经验证基本能满足双十一需求。2016年双十一大促高峰期，无高等级故障发生，全链路压测功不可没。
关键词：核心系统压测、秒杀数据分析
之前提到了全链路压测，但是有些核心系统不在交易支付主链路里，我们要怎样分析这些系统的性能呢。
机智的大大们提出让技术支持分析分析数据。首先去谛听、SGM（两个超棒的系统）捞取CPU、LOAD、内存、磁盘IO、TPS、TP99等指标，然后按大大们要求排序、出表、制图。
先来个整体指标，压测的、秒杀的，各来一份儿，应用占用的所有IP列出来，每个IP对应的各项基础指标也列出来。整体指标抓不住重点怎么办，按应用维度统计指标，并展示应用占用机器总数。
还不清晰？那按业务线统计吧，再画个图，这样很清晰就能看出，哪些应用使用率不高，但是占了好多机器，而哪些应用机器太少，CPU使用率已经常年99.99%+了；
不想按业务线统计，想单独看哪些应用机器冗余度高？那来个（CPU占用量<50%）∩（机器占用量>100台）统计可好？
您想问这么多数据分析复杂吗？其实我们真的没分析几次，也就五六次吧（汪的一声哭出来）…
不过这一套流程下来，小妹儿基本从Excel基本靠瞅，进阶为能用公式能画图的入门级选手了...
2.4.1.2 资源备份
这部分包含系统/IDC服务器准备、网络准备、安全准备等，涉及到服务器资源池准备、硬件巡检、备件准备，IDC设备巡检、网络流量评估、出口带宽调整、网络优化，以及安全相关应急响应措施等。因该部分技术支持以跟进进度及问题为主，不详细展开啦。
2.4.1.3 监控应急
这部分是技术支持的主战场了，主要包含应急预案管理、应急演练实施、监控系统整合、改进项落实等部分。
我们常说：大促是一面“照妖镜”，系统是否稳定，预案是否完善，演练是否到位，故障改进项是否落地，一验便知。
关键词：应急预案
应急预案作为故障管理的知识库，其重要程度不言而喻，大促对于故障解决时效的要求较平时更高，常规的应急预案不能满足需求，所以我们每年针对大促会出具《XX年XX大促应急预案》，具体而有效地指导大促应急工作开展。
关键词：应急演练/压测
说到应急预案就不得不提应急演练了，我们大促前三个月左右就开始组织大促相关应急演练及压测，临近大促的月份尤甚，每年5月、10月的操作数量几乎是其它月份的两倍，当然同样的情况也出现在3月份，我们只能理解为，刚刚过年回来，大家热情比较高涨 ~
关键词：改进项落地
大促马上要开始了，上次大促的改进项都落地了吗？没有当然是不行的，这也是技术支持的常规工作之一，每周统计上次大促遗留改进项的进度，并以周报的形式周知全员（此处呼应“吉吝凶悔”之“悔”）。
关键词：监控系统整合
此项主要针对大促期间，监控大屏展示哪些内容，监控及技术支持需关注哪些监控及指标，需要记录哪些数据等，做到有条不紊。
2.4.1.4 信息收集
关键词：营销活动收集
作为技术支持汪，需要对大促期间，包括大促前期的所有营销活动了如指掌，包括活动内容、活动时间、可能的影响，都要提前收集了解，做到有备无患。
关键词：值班安排收集
各主干业务线值班人员也需要重点了解，包括值班场地有多少席位，哪个业务线能分到几个座位，这个业务线集中坐在哪，都需要了解清楚，以便出现问题能第一时间协调研发排查。
以上工作都做好了，就可以等待大促来临啦。
2.4.2 大促进行时
终于到紧张又鸡冻的大促当天了，技术支持当然要第一拨到达值班场地，把座位图贴在显眼的位置，检查检查桌子上名牌是否正确等等，一切都准备好就可以等研发及运维小伙伴入场啦。
大概9点钟，就会有小伙伴陆续入场了，这是熟悉研发的好机会，技术支持需要引导研发入场及签到，并强行尬聊（捂脸），记住各业务线研发坐在哪个位置，以便应对突发状况。待值班人员全部就坐后，就可以稍稍舒口气了，整理整理资料，熟悉熟悉研发，当然如果白天遇到故障了，也需要按照大促标准紧急处理，提高时效，避免影响大促高峰期秒杀。如果有惊无险到了饭点儿，技术支持小管家会提醒忙碌的大大们吃饭，人是铁饭是钢嘛。
基本上到了23点，大家都需要停下手头的工作，专心应急了。这时候可以检查检查故障模板准备情况，确认确认技术支持分工情况，将各个应急群置顶，确认主干业务研发值班在现场。
23:59 大家都集中到了大屏前面，是的这时候就发现之前的座位图已经不管用了...
五、四、三、二、一！
什么？！XX银行TP99红了？XX业务成功率跌了？XX接口可用率告警了？
稳住，这时候我们会优先跟进非银行类业务故障（后面会提到原因），如果故障并发太多，将由全体技术支持分头行动，第一时间找到故障相关方处理，时间允许情况下，记录现象、开始时间恢复时间、排查人，有原因更好没有先跳过，如时间紧急，只记录故障现象和处理人即可，后续可详细了解；
银行类问题只记录有问题的银行名称即可，这时候就要感谢沈大镖头的SGM系统了，只要有银行名称，后续完全能够反查到故障起止时间，甚至期间失败原因占比排序都能清晰看到，简直神器！
整个场地一定是混乱的，肯定有无数人跟你汇总故障，但一定要稳住，默念hold住hold住，撑过去的才是英雄。
大概到00:30，秒杀量逐渐回落，心也可以回落了...理论上可以让各位值班人回家或酒店休息了，当然如果有问题需要确认的话，可以请求值班人晚走一会儿。此时技术支持需要专心跟进未解决的故障，刚刚有啥没查清楚的也需要再行确认，想问的该问的都可以放心大胆问了，尽量把能拿到的信息都拿到，因为下面还有重头戏。
是的，大促当天除了秒杀问题处理跟进，另一个重头戏就是大促日报整理了。
技术支持整体协调人，需要汇总各方记录的故障，合并去重，统一整理成Excel文档。就这样整理到天蒙蒙亮，终于完成初稿了，可以给辛苦陪通宵的老大过目了，针对改进意见再行修改，就可以发送啦。
大促第一天值班就圆满落幕啦！
第二天继续，确认遗留的问题，记录新增的问题，过了零点发送大促第二天日报，大概就是这样啦。
然后就可以安心等待庆功会啦，有好吃的有好吃的有好吃的！
半夜码文馋得不行的小妹儿一怒之下冲了杯蜂蜜水
不过再多美味也比不上我大运维部收到的这个蛋糕
致敬 双11卫士！
2.4.3 大促后
关键词：复盘准备
作为一个认真负责的部门，我们做事向来有始有终，大促后当然要复盘啦。
我们一般选择大促后一周进行复盘，前期会进行一些准备工作。
关键词：PPT
技术支持会收集各组大大制作的大促复盘PPT，并整合各组信息（运行支持部分需要技术支持完成），形成《XX年XX大促汇报》PPT，交由老大审阅，并结合老大意见进行修改。
关键词：数据分析
同压测数据分析类似，大促各系统数据是衡量系统性能难得的标准，我们按照之前的方法，对大促数据进行分析，并按照各维度进行统计、分析、制表、制图，并展示在复盘PPT中
关键词：复盘会议
准备妥当之后，技术支持会择期组织大促复盘会议，针对大促前期准备、大促期间整体运行情况、大促期间异常情况分析、事件与问题分析、优化目标五个部分进行汇报，结合大大们的建议，以及各组的优化目标，形成《XX年XX大促改进项汇总》表格，供后续跟进。
关键词：改进项跟进
其实复盘会议之后，大促整体过程就结束了，但是后续需要定期跟进改进项完成进度，并以周报形式进行汇报，确保下次大促前改进项稳步落实。
3、后记
在今年年初的运维表彰会中，运维大当家特别提到：“技术支持组织大促不容易，感谢监控服务台！”
其实，技术支持们想说：感谢大大们的支持和信任，感谢所有伙伴的理解和配合，技术支持汪们会继续坚持和努力的！