## 故障处理

故障报告：
- 用户申告
- 监控告警

接到故障报告时应该做什么？
- 支撑作为入口，统一组织故障处理小组，可以调动运维、研发资源。
- 快速建立故障状态报告。在线文档，注意权限范围。每15分钟更新。
  - 故障摘要
  - 故障状态
  - 故障处理人
     - 牵头人、运维负责人、研发负责人
  - 待办列表
     - 切换备用资源（已完成）
     - 执行xxx脚本（已完成）
     - 借用一些紧急资源提高xxx容量（进行中）
- 故障时间线

如果从故障服务来看，运维恢复业务最重要的三个方法是： 重启，隔离和降级。

以今天的 RabbitMQ 故障为例：当已经知道 RabbitMQ 发送消息失败的时候，那么就要对它进行重启，如果还没生效，那么则对他上游（消息生产者）进行重启，还不行就对下游，消息消费方进行重启。

这里需要注意的是，千万千万不要想着去定位，比如发现重启的对象指标都正常，则不进行重启，时刻谨记，是在恢复业务，不是在定位故障。

基本原则： 在故障处理过程中采取的所有手段和行动，一切以恢复业务为最高优先级。
1. 故障发现后，On-Call 的 SRE 或 运维，故障指挥官有权召集相应的业务开发或其它必要资源，快速组织事故处理小组。
1. 如果问题和恢复过程非常明确，故障指挥官 仍然是 SRE 或 运维，就不做转移，由他来指挥每个人要做的具体事情，以优先恢复业务优先。
1. 如果问题疑难，影响范围很大，这时 SRE 可以要求更高级别的主管介入，比如 SRE 主管或总监等，一般的原则是谁的业务受影响最大，谁来牵头组织。这时 SRE 要将 故障指挥官 的职责转移给更高级别的主管，如果是全站范围的影响，必要时技术 VP 或 CTO 也可以承担 故障指挥官 职责，或者授权给某位总监承担。
1. 问题解决后，需要进行功能验证。

```sequence
OnCall运维->故障:发现故障
OnCall运维->OnCall运维: 初步分析故障原因
OnCall运维->事故处理小组: 召集业务开发或其它必要资源
事故处理小组->事故处理小组: 事故反馈(10-15分钟一次)
事故处理小组->事故处理: 事故排查
OnCall运维-->高管: 问题疑难，影响范围很大，事故升级
高管-->事故处理小组: 全权管理，进行下一步协商处理
事故处理->事故处理: 最近发布情况
事故处理->事故处理: 服务和基础设施情况
事故处理->事故处理: 解决故障
事故处理->事故处理小组: 排查记录
故障->事故恢复: 进行恢复验证
事故恢复->事故处理小组: 恢复结果通知
OnCall运维->事后总结: 组织故障复盘会议
Note right of 事后总结: 总结原因，解决问题
事后总结->事故处理小组: 输出会议总结,故障报告
```

**事故反馈**
一般要求以团队为单位，每隔 10～15 分钟做一次反馈，反馈当前处理进展以及下一步Action，如果中途有需要马上执行什么操作，也要事先通报，并且要求通报的内容包括对业务和系统的影响是什么，最后由 故障指挥官 决策后再执行，避免忙中出错。没有进展也是进展，也要及时反馈。


事后Action
事后action可以和看板系统结合，方便跟踪。action必须是可执行的，准确的。

Action|执行人|验证人|计划完成时间|完成时间
--| --| --| --| --
||||



### reference
- [运维的线上系统故障总结](https://segmentfault.com/a/1190000041205903)
- [一份十分完整的故障演练指南](http://www.yunweipai.com/28352.html)
- [史上最长最全！围绕故障管理谈SRE体系建设](https://blog.51cto.com/u_5646435/3153364)
- [一文吃透SRE故障预案6把刀](https://zhuanlan.zhihu.com/p/362842387)
- [团队线上故障处理模板（SRE必收藏）](https://blog.csdn.net/apl359/article/details/120775746)