为什么要重新制定故障处理流程？
2020年写过一篇文章： 故障处理流程和规范，在过去的这三年内，故障处理流程输出了好几个版本，但都没有很好的落地，所以本次的目标是，制定一个简单、易操作，易落地的故障处理流程。
将全链路中的各个组件和服务责任到人，当出现故障时，各司其职，快速分析定位，快速反馈。
1、事前（故障规范）
| 步骤 | 补充说明 |
|---|---|
| 统一故障处理群 | - 创建线上故障的统一处理群，请提前置顶，方便快速定位本群 - 入群要求：产研中心各部门核心关键人员 - 入群职责： ??? ? - 群内成员都有责任排查问题，并反馈分析结果 ??? ? - 群内成员对群内反馈的问题有责任进行甄别，若反馈的问题很小，可提醒单独拉群进行处理，避免信息影响到过多人员 |
| 故障整体跟进人 | - 统一指挥，及时跟进，可以是指定的几个人 |
2、事中（故障处理）
| 步骤 | 步骤内容 | 补充说明 |
|---|---|---|
| 第一步 | 信息同步 | - @所有人，同步故障关键信息，以便其他人员快速了解故障情况 - 若1分钟内无人响应，则直接电话加急（自行判断是否需要） |
| 第二步 | 分析排查 | - 按责任分工，各司其职，快速分析排查，定位问题 - 说明：针对问题点明确的故障，精准分析并反馈即可 |
| 第三步 | 分析反馈 | - 按责任分工，各自快速反馈有无问题，以便快速定位问题 - 分析反馈时限：3-5分钟内反馈 |
| 第四步 | 故障处理 | - 核心原则：以最有效，最短时间恢复故障为第一目标 - 常用手段：扩容、回滚、重启、紧急更新、限流降级等 |
| 第五步 | 进度反馈 | - 由整体跟进人于群中，定期同步故障处理进度（内容清晰明了即可） - 故障处理进度同步频率：主链路故障：每15分钟同步一次；其他故障：每隔30分钟同步一次 - 故障修复后，务必通知反馈方，告知问题已解决 |
3、事后（故障复盘）
| 步骤 | 补充说明 |
|---|---|
| 故障复盘 | - 指定一名人员，牵头推动如下事项 ????- 输出故障报告：2个工作日内 ????- 组织故障复盘会：5个工作日内 |
制定明确的定责标准，有利于尽量减少争议。定责是是问题复盘中最棘手的部分，要做到公平公正、让各方心服口服是一项很大的挑战。
| 定责标准 | 描述 |
|---|---|
| 1.违反公司规章/制度/流程的承担主责 | - 比如公司规定必须要有灰度策略才能升级，某业务版本直接全量升级导致发生为。 |
| 2.出现重大纰漏的承担主责 | - 比如测试时漏测了某个常见的业务场景，导致上线后发生问题，测试承担主责，产品承担主责（因为上线前验收阶段没有发现问题），开发反而不一定承担责任（看具体的公司和团队要求）。 |
| 3.问题源头承担主责 | - 比如A系统磁盘故障，导致接口响应很慢且问题持续时间很长，从而进一步导致B系统对外响应也超时，这种情况下A系统应该承担主责，B系统承担次责。 |
| 4.问题放大者承担主责 | - 比如A系统磁盘故障，导致接口响应很慢但只持续了几分钟，结果诱发了B系统的设计缺陷，导致B系统瘫痪了1个小时，这种情况下B系统应该承担主责。 |