在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级。这也是我们故障处理过程中的唯一目标，没有第二个。
但凡故障处理不好的，基本就是没有任何演练，这里又分为两种。
一种是我们前面讲的第一个原因，故障隔离手段缺失。要么缺失手段，不知从何入手，要么就是有限流降级等故障隔离策略，但是不敢尝试和演练。为什么呢？就是担心演练有可能也会影响正常业务，但这也侧面说明我们的技术方案仍然不够成熟和完善。因为如果在相对比较宽松的氛围下，都不敢演练不敢操作，那真正出问题的时候就更不敢乱动，或者动了系统会导致更多意想不到的状况。所以，我们应该借助演练的手段，来倒逼我们考虑得更完善才可以。
另一种就是整个应急流程基本跑不起来，要么是人凑不齐，要么是很多团队不愿意配合，只要是这种理由导致的无法演练，基本出现故障后，整个应急状态就是失控的。因为大家都是慌乱状态，平时都缺少配合和协作，在这种高压状态下，大家就更顾不上或者不知道该怎么配合了。
故障响应其实是两个方面，技术方面和流程机制方面。
这里，我们重点来讨论如何建立有效的故障应急响应机制。
如何建立有效的故障应急响应机制
当一个问题被定性为故障，这时我们就要成立 War Room，如果是在办公时间，大家可以聚集到同一个会议室，或者同一块办公区域集中处理；如果是非办公时间，可以是视频、电话或微信会议的方式，形成虚拟的 War Room。但无论是真实还是虚拟的 War Room，根本目的是快速同步信息，高效协作。
仅仅有 War Room 这样一个聚集形式还是不够的，既然我们把解决故障类比成战争，我们就一定要有一套相对应的指挥体系才可以，这个体系里面，我认为最重要的就是“关键角色分工”和“沟通机制”。
关键角色分工
Google 的故障指挥体系，是参考了美国消防员在处理 1968 年森林大火时建立的应急指挥体系，体系中有三个核心角色。
Incident Commander，故障指挥官，简称为 IC。这个角色是整个指挥体系的核心，他最重要的职责是组织和协调，而不是执行，下面所有的角色都要接受他的指令并严格执行。
Communication Lead，沟通引导，简称 CL。负责对内和对外的信息收集及通报，这个角色一般相对固定，由技术支持、QA 或者是某个 SRE 来承担都可以，但是要求沟通表达能力要比较好。
Operations Lead，运维指挥，简称 OL。负责指挥或指导各种故障预案的执行和业务恢复。
这里其实还有一类角色，虽然不在指挥体系内，但是也非常重要，我们也要做一下介绍：Incident Responders，简称 IR。就是所有需要参与到故障处理中的各类人员，真正的故障定位和业务恢复都是他们来完成的，比如具体执行的 SRE、网络和系统运维、业务开发、平台开发、网络或系统运维、DBA，甚至是 QA 等。
流程机制
在我自己团队的具体实践和场景中，我们按过程来分，会有如下的一个流程机制。
故障发现后，On-Call 的 SRE 或运维，最一开始就是 IC，有权召集相应的业务开发或其它必要资源，快速组织 War Room。
如果问题和恢复过程非常明确，IC 仍然是 SRE，就不做转移，由他来指挥每个人要做的具体事情，以优先恢复业务优先。
如果问题疑难，影响范围很大，这时 SRE 可以要求更高级别的主管介入，比如 SRE 主管或总监等，一般的原则是谁的业务受影响最大，谁来牵头组织。这时 SRE 要将 IC 的职责转移给更高级别的主管，如果是全站范围的影响，必要时技术 VP 或 CTO 也可以承担 IC 职责，或者授权给某位总监承担。
反馈机制
有了角色分工，也明确了流程，那整个故障响应是否高效的关键就是沟通机制了。
反馈的重要性是再怎么强调都不为过的。有时涉及的团队和人员比较多，很多具体执行的同事就只顾闷头定位和排查了，往往没有任何反馈，甚至做了很多的操作也是自行决定，不做通报。这时就会出现上面案例说的场景，极有可能衍生故障或者导致故障更大范围的蔓延，这是极为影响协作效率和决策的。
我们一般要求以团队为单位，每隔 10～15 分钟做一次反馈，反馈当前处理进展以及下一步 Action，如果中途有需要马上执行什么操作，也要事先通报，并且要求通报的内容包括对业务和系统的影响是什么，最后由 IC 决策后再执行，避免忙中出错。
这里我要强调一点，没有进展也是进展，也要及时反馈。很多团队和成员往往会抱怨，我专心定位问题还没结果呢，有什么好反馈的呢？但是没有进展也是进展，IC 会跟 OL 以及团队主管决策是否要采取更有效果的措施，比如 10 分钟之内还没定位结果，可能我们就会选择做有损的降级服务，不能让故障持续蔓延，这个时候，反馈就显得尤为重要。
故障处理过程中效率如何，其实取决于三个因素：技术层面的故障隔离手段是否完备；故障处理过程中的指挥体系是否完善，角色分工是否明确；故障处理机制保障是否经过足够的演练。
我们可以看到，想要高效地处理故障，并不是说我在技术层面做到完备就可以了，这是一个需要体系化建设和反复磨炼才能最终达成的目标。
