3.9 KiB
3.9 KiB
故障处理
故障报告：
- 用户申告
- 监控告警
接到故障报告时应该做什么？
- 支撑作为入口，统一组织故障处理小组，可以调动运维、研发资源。
- 快速建立故障状态报告。在线文档，注意权限范围。每15分钟更新。
- 故障摘要
- 故障状态
- 故障处理人
- 牵头人、运维负责人、研发负责人
- 待办列表
- 切换备用资源（已完成）
- 执行xxx脚本（已完成）
- 借用一些紧急资源提高xxx容量（进行中）
- 故障时间线
如果从故障服务来看，运维恢复业务最重要的三个方法是： 重启，隔离和降级。
以今天的 RabbitMQ 故障为例：当已经知道 RabbitMQ 发送消息失败的时候，那么就要对它进行重启，如果还没生效，那么则对他上游（消息生产者）进行重启，还不行就对下游，消息消费方进行重启。
这里需要注意的是，千万千万不要想着去定位，比如发现重启的对象指标都正常，则不进行重启，时刻谨记，是在恢复业务，不是在定位故障。
基本原则： 在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级。
- 故障发现后，On-Call 的 SRE 或 运维，故障指挥官有权召集相应的业务开发或其它必要资源，快速组织事故处理小组。
- 如果问题和恢复过程非常明确，故障指挥官 仍然是 SRE 或 运维，就不做转移，由他来指挥每个人要做的具体事情，以优先恢复业务优先。
- 如果问题疑难，影响范围很大，这时 SRE 可以要求更高级别的主管介入，比如 SRE 主管或总监等，一般的原则是谁的业务受影响最大，谁来牵头组织。这时 SRE 要将 故障指挥官 的职责转移给更高级别的主管，如果是全站范围的影响，必要时技术 VP 或 CTO 也可以承担 故障指挥官 职责，或者授权给某位总监承担。
- 问题解决后，需要进行功能验证。
OnCall运维->故障:发现故障
OnCall运维->OnCall运维: 初步分析故障原因
OnCall运维->事故处理小组: 召集业务开发或其它必要资源
事故处理小组->事故处理小组: 事故反馈(10-15分钟一次)
事故处理小组->事故处理: 事故排查
OnCall运维-->高管: 问题疑难，影响范围很大，事故升级
高管-->事故处理小组: 全权管理，进行下一步协商处理
事故处理->事故处理: 最近发布情况
事故处理->事故处理: 服务和基础设施情况
事故处理->事故处理: 解决故障
事故处理->事故处理小组: 排查记录
故障->事故恢复: 进行恢复验证
事故恢复->事故处理小组: 恢复结果通知
OnCall运维->事后总结: 组织故障复盘会议
Note right of 事后总结: 总结原因，解决问题
事后总结->事故处理小组: 输出会议总结,故障报告
事故反馈 一般要求以团队为单位，每隔 10～15 分钟做一次反馈，反馈当前处理进展以及下一步Action，如果中途有需要马上执行什么操作，也要事先通报，并且要求通报的内容包括对业务和系统的影响是什么，最后由 故障指挥官 决策后再执行，避免忙中出错。没有进展也是进展，也要及时反馈。
事后Action 事后action可以和看板系统结合，方便跟踪。action必须是可执行的，准确的。
| Action | 执行人 | 验证人 | 计划完成时间 | 完成时间 |
|---|---|---|---|---|