故障管理三部曲

故障前

既然是故障前，说明故障还未发生，那故障前的关键工作包含以下几点：

• 隐患分析及修复；
• 故障预警；
• 预警响应。

• 隐患分析目的：分析清楚自身系统的隐患，才能知道可能的风险以及如何应对；
• 隐患分析方法及工具：FMEA方法，排除架构可用性隐患的利器，引用自《从零开始学习架构》；[https://time.geekbang.org/article/9391?code=4cnn4UWjC67wg8UpB2w86l0zY34bjpIIo5sc7zIEiO0%3D]
• 结合自身实际情况梳理隐患表，以下是我们结合实际情况，针对技术基础设施redis，输出的隐患分析demo。

•     隐患修复：
• 目的：修复隐患，提高系统的可用性、可扩展性、可维护性；
• 方法及工具：
• 根据优先级安排修复任务排期；
• 持续跟进任务进度，形成闭环。

故障预警的核心工作是完善监控告警体系，这也是一个专题工作及实践；

这里提出2个问题及思考：
• 思考1：故障前，说明故障还未发生，但是为啥最终故障发生了（针对缓慢触发型告警）？
  缓慢触发型告警：告警不是突发性触发的告警，告警对应指标的值是缓慢增长到告警阈值，触发的故障时可以避免的；
• 故障原因：

• 监控告警有没有配置：覆盖率是否100%？监控告警覆盖对象有没有被自动化添加到告警对象中？

• 监控告警覆盖维度是否全面？常见的维度（指标、日志、trace），需要整个业务研发团队一起完善，需要对自己负责的系统做好监控告警；

• 告警触发方式是否完善？阈值告警（count）、斜率告警（pdiff）等；

• 监控告警有无触发验证？配置了告警，但没有验证过，往往会失效；

• 故障处理是否闭环？星星之火，可以燎原，故障处理要像灭火一样处理干净。
• 优化措施：

  完善监控告警体系。

• 思考2：完善了监控告警，就不会有故障了？
突发型触发告警：告警是突发性触发的告警，告警对应指标的值是一下子增长到告警阈值，触发的故障较难避免；

• 故障原因：

• 有变更：有发布或重启服务、有变更配置、外部依赖有变更、有服务被关闭或下线等；
• 有突发流量：有推广活动、受到外部或自身原因引起的DDOS攻击等。

• 优化措施：

• 不要轻视线上变更（有可能触发研发高压线及严重事故）；
• 完善操作sop及应急预案。

预警响应有两个关键点：

• 告警方式能否有效通知到处理人？
• 故障处理是否及时？如果不及时处理，故障可能升级成事故；

告警方式怎么有效通知到处理人？

• 确保重要告警，使用电话告警，电话、短信、邮件的通知到人的有效性不一样，电话最高；
• 确保告警接受人能正常接收到告警（手机需要保持非静音、有电、有信号）；
• 确保告警有升级策略，避免因为一个人没响应，告警没有备份处理人处理的情况；

故障怎么能被及时处理？

• 处理故障处理流程，按SOP操作；
• 梳理故障应急预案，做好演练；
• 保障工具良好运行，避免一到处理故障，就出现各种异常情况（无网络、vpn失效、电脑死机、家用电脑和工作电脑环境不一致等）；
• 设定告警响应OKR，比如一个OKR周期内，0.3分标准为告警未及时响应次数《2（根据团队具体人数及情况而定）。

故障中

• 故障信息同步：
• 找人、确认所有影响、服务恢复方案和预计恢复时间；
• 故障处理方案同步；
• 故障处理：
• 止损、保留现场；
• 恢复服务；
• 故障恢复信息同步；
• 故障升级。

故障后

• 故障报告
• 事故描述
• 事故解决方案
• 事故原因分析
• 事故影响
• 后续如何避免

• 事故收尾工作

• 问题是否切底解决

• 未解决，有解决方案：追踪和解决问题（建任务），形成闭环。
• 未解决，没有根治方案：完善预防监控措施。

故障处理流程图

根据以上的“故障前、故障中、故障后”总结出微鲤故障处理流程图，SOP如下图，具体情况，还需具体分析。

• 故障处理流程图中的关键角色：
• 报警人：反馈故障的人；
• 接警人：接到故障反馈的人；
• 指挥员：故障处理全局协调人；
• 快恢负责人：能够快速恢复故障，止损的人；
• 诊断负责人：诊断故障原因，给出解决方案的人。

事故管理制度

目的：出了故障后，我们需要上报故障，看故障是否升级为事故，并进行事故管理，所以需要建立对应的事故管理制度。

事故管理制度关键工作包含以下几点：

• 确定事故管理负责人：
• 跟进事故记录；
• 跟进事故定级和定责；
• 跟进事故处理和总结；
• 每月发送事故月报到部门负责人；
• 事故定级，根据对业务影响情况定级；
• 事故定责，根据需要改进的地方定责；
• 制定事故记录模板：
• 事故等级；
• 事故时间以及发现人；
• 事故现象；
• 事故影响；
• 事故解决方案；
• 事故原因；
• 后续改进；
• 制定事故处理红线：出现事故后必须同步信息至业务负责人，为了避免扩大损失快速处理的同时，处理流程及事故信息需同步公开，不得私自修复后隐瞒；
• 制定研发高压线：需要定义清楚未经授权或确认，私自进行会触发事故的高危操作，根据企业具体情况制定。

可用率保障小组

• 从全方位提高每个业务的可用率；
• 基于微鲤事故管理机制，我们出了事故后，事故管理存在定责的环节，这中间可能存在定责不清的情况，为了优化这种情况，所以建立了可用率保障小组及机制。

机制：

• 每个业务团队，组建一个可用率保障小组；
• 可用率保障小组成员由研发、测试、运维共同组成；
• 业务可用率由可用率保障小组部分或全部成员保障；
• 故障定责机制：

• 责任方无异议，遵循事故管理机制责任划分；

• 业务方需要对业务可用率做好监控告警，因业务方不清楚自己负责业务的可用率导致的故障由业务方负主责（目的：推进业务方关注自己的业务可用性）；

• 每个业务方需要对自己负责的业务系统的可用性、可用率负责；
• 如果有支撑方，业务方需要告知支撑方隐患点以及需要支撑方做什么来保障可用性；
• 业务方需要给出自己的承诺及SLA；
• 需求方和支撑方都可以给对方提出高可用优化建议，如果技术委员会认定可执行但没有执行，引起的故障为未执行建议方主责；
• 引起故障的原因都不在双方的隐患分析里面，且故障定责有异议，则双方共同承担主责。