团队线上故障处理模板(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:30echovalues配置正确应用的版本:v2.1cpu,内存 同比环比正常 应用配置正确 ERROR级别从9/28 7点突增。张三

基础设施情况

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

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

事件排查记录

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

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

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

事后总结

事后Action

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

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

发表评论

登录后才能评论
服务中心
服务中心
联系客服
联系客服
返回顶部