SRE体系07----紧急故障处理

应急原则

尽最大可能让业务系统恢复服务，故障定位和排除是次要目标。例如采取一些应急措施：将用户流量导入到功能正常的集群；抛弃部分流量以降低负载；或者屏蔽部分故障节点等临时措施，等到用户使用率较低时，再处理故障或变更。

这一点可能让很多技术达人或强迫症难以接受，往往心里会认为无法定位故障或查清根本原因是自己能力问题，增添不必要的焦虑。更有甚者，在处理紧急故障时钻牛角尖，耗在现场不停的尝试，也不向上升级和求助，把问题长时间的压在自己手里，导致了更严重的后果。他们往往执着于技术问题，而忘记或者没有精力去思考如何缓解当前的服务故障

我们需要注意，SRE职责是保障系统稳定运行，出现故障要及时让系统恢复正常，降低MTTR, 确保系统持续产生商业价值。故障定位和排除，根因分析在发生事故时并不能产生商业价值，要排在次优先级。

故障响应

事先要制定一套故障响应流程，并培训相关的SRE和运维工程师。如果没有流程，那遇到故障心里必然非常慌乱不知所措。

试想一下，你正在家休息，突然手机收到了监控系统的故障报警信息。于是你立刻打开电脑，发现系统出现了大量报错，几千行的错误日志让你头昏眼花。你决定重启服务，结果服务没起来，引发了更多报错，并产生了二次事故！这时候公司boss给你的leader打电话，愤怒质问发生了什么？ 你的leader一头雾水，啥都不知道，无法和老板解释周旋，年底绩效估计不会太好看。。。。 你继续处理故障，可是开发组的同事不停的询问你：出了什么问题？ 为什么会出这个问题？ 谁搞的？ 什么时候能恢复？ 你一边工作，一边回答同事的询问，心里越来越慌张和烦躁。。。

从上面的例子可以看出，无流程的紧急故障处理事倍功半，效果太差，那么如何建立流程呢？ 有以下几个要素大家可以酌情考虑：

团队角色

制定团队角色是为了分离职责，让每个人专注一个方向不受打扰，提高效率。

角色	职责
故障总负责人	一般由接收故障工单的SRE担任，职责是组建故障处理团队，协调各个团队之间的工作。建议组建两个工作群，一个群为技术团队，另一个为leader群，主要是业务相关方，非技术人员。这样做是为了让技术团队专注于处理故障，不受外界因素干扰
故障处理团队	主要由技术人员组成，负责分析，决策，执行相关操作。技术团队是唯一能够对系统做变更的团队，这样可以防止未经审核的方案或操作引起的二次事故
发言人	向所有关心业务系统的人员发出统一的公告或通知，安抚相关人员，维护当前的故障处理状态信息，缓解焦虑

控制中心

可以通过远程视频会议建立一个实时沟通平台，当然如果有条件，建议组建一个临时应急响应中心，把所有的人员集中在一个办公室。因为面对面的交流远比视频，语音，电话效率高，更容易达成共识，尤其是在处理生产事故时。同时确保令出一门，不被多头领导指挥。

故障状态维护

维护实时的故障处理状态，有助于缓解相关人员的焦虑，同时可以同步大家的工作状态，让跨团队的工作保持协调