团队线上故障处理模板（SRE必收藏）

如果对于生产环境的故障没有一个提前的准备，出现故障时，团队必定手忙脚乱。前段时间，笔者设计了一个线上故障处理的流程模板。当出现故障时，根据这个模板创建一个故障单，然后团队的人各司其职，将自己的那部分信息填到故障单中。方便排查人排查故障的根因。

当然，这个故障单应该是可以自动化生成的，但是，并不是每个团队一开始就有这样的能力去建设。所以，小团队时，手工创建这个故障单也是可以的。

同时，你也会发现，这个故障处理模板很大程度上，其实是一个初级的AIOps。

以下是故障单的内容：

事故业务现象

<由谁在什么时间点报什么问题，尽量详细，比如设备id，用户id等>

事件发生频率

偶发 or 必现

事故复现方法

方便大家复现。

事件时间流记录

以事件时间流的方式记录出现事故前，事故中的操作记录

注：时间能精确就精确

时间	事件	备注
2021/09/28 12:20:20	将LB带宽从10Mb到20Mb

事故排查

最近一次生产环境发布信息

可以包括最后一次发布的系统的commitId，时间，人员等。

测试反馈

测试人员对本次故障处理的反馈。方便开发人员查问题。

时间	测试用例	结果	备注
9/28 11点左右	在APP上登录	成功	张三
9/28 11点左右	在设备上登录	失败	李四

服务情况

在团队每个服务都应该有相应的owner。在出现线上故障，每个owner负责检查自己负责的服务的情况。检查过程的证件必须保留证据。

时间	服务名	检查内容及结果	检查人	备注
9/28 10:30	echo	values配置正确 应用的版本：v2.1 cpu，内存 同比环比正常  应用配置正确  ERROR级别从9/28 7点突增。	张三

基础设施情况

基础设施的排查由基础设施团队负责。

时间	组件	检查内容	检查人	备注
9/28 10:00	LB	带宽 包流速
9/28 10:00	NAT
9/28 10:00	Redis
9/28 10:00	PostgreSQL
9/28 11:00	域名解析

事件排查记录

“假设”指的是排查人员对于故障原因的假设。

此表的作用是避免不同的人重复排查同一个假设。同时，也方便其他人验证。

时间	假设	排查方法	结果	排查人	备注
9/28 10:00	登录环节出现业务逻辑错误

事后总结

事后Action

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

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