SRE体系17----复盘与定责

这是SRE或运维工程师在故障处理完毕后必然要面对的工作。也是比较棘手的环节

复盘

复盘环节要在故障处理完毕后尽快展开，因为大家对当时的故障细节和处理过程还能记住，时间久了就会遗忘。各个公司流程大体差不多，通常分为以下几步：

1. 回顾
   回顾整个故障处理的过程，包括故障的发生，报警，定位，处理，以及每个人在故障处理过程中做了哪些事。尽可能的把所有的细节信息收集起来。这一步收集的信息是下一步分析的基础

---

2. 分析
   1). 分析监测能力。报警是否属实和准确，是否有遗漏
   2). 分析协同能力。接到报警后，团队是如何应对的，沟通是否顺畅，跨部门的联合问题定位是否准确及时，如果有超时的问题是否有升级等
   3). 分析故障对业务的影响。
   4). 分析故障根本原因。
   5). 分析故障遗留问题。是否完全恢复，有没有在处理故障时造成二次伤害等。

---

3. 总结
   由复盘会议组织者汇总信息和结论。主要包含以下内容：
   1). 总结此次故障对业务带来的影响，损失和范围
   2). 总结故障总处理时间
   3). 总结可靠性运维保障能力，如监控，事件响应，问题定界定位等能力是否满足要求
   4). 总结设计问题，包括基础架构，系统架构，应用架构及部署架构是否有改进必要
   5). 总结协同能力，如部门间沟通合作，故障处理流程是否合理或有疏漏等
   6). 总结此次故障的定性定级定责任，即是什么类型的故障，故障的严重程度，该由谁来负责
   7). 总结整改措施及规划，防止此类故障再发生

---

4. 改进
   对前面步骤提出的整改措施进行落实。措施要具体，有具体的时间，具体的措施，具体的负责人。通过周会或月会持续跟踪整改行动，防止不了了之。

定责

出了故障必然是要追责的，否则大家会失去敬畏之心。但是一旦追责不当，就坏破坏团队信任与合作。定责的过程往往和一家公司的企业氛围和文化，主管的责任感与价值观联系密切。有的公司喜欢追究到个人，有的公司追究leader，有的公司把一整个项目组当成责任人。形式各异，各有各的道理。

如果老是追究个人责任，就会导致为了绩效好而逃避责任，能推就推，搞出一大堆的规范、限制和审批流程来免责，拖慢了整体效率。工作得过且过，不过再主动去优化。

定责的目的是减少故障，不是为了惩罚。

我们应当把责任人分为四类，责任由大到小：

1. 主体责任：
   由业务系统的负责人(有权决定业务的架构和技术方案)承担,位高权重，自然责任最大。例如架构设计方案等导致的事故以及管理责任
2. 系统责任：
   由业务系统的某个模块或组织的负责人承担。例如开发组导致的系统bug、测试组的遗漏测试，运维组的IT基础设施异常等事故
3. 个人责任：
   由直接造成事故的个人承担，属于直接责任人，例如误操作，违规变更，个人岗位失职
4. 不可抗力责任：
   无明显责任人，如天灾，地震洪水，长时间断电，封网等不可预测行为导致的事故

责任最终要和绩效挂钩，任何一家公司都是如此。但在定完责任处罚时，要根据不同的责任层级制定合理的奖惩。在没有违背法律和职业道德的前提下造成的故障，层级越低，责任越小，避免滥用处罚而毒化工作氛围和热情