Files
devops/guzhangchuli.md
2025-09-17 16:08:16 +08:00

73 lines
3.9 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

## 故障处理
故障报告:
- 用户申告
- 监控告警
接到故障报告时应该做什么?
- 支撑作为入口,统一组织故障处理小组,可以调动运维、研发资源。
- 快速建立故障状态报告。在线文档注意权限范围。每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 事后总结: 总结原因,解决问题
事后总结->事故处理小组: 输出会议总结,故障报告
```
**事故反馈**
一般要求以团队为单位,每隔 1015 分钟做一次反馈反馈当前处理进展以及下一步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)