故障管理

故障发生 -> 故障发现 -> 故障处理 -> 故障复盘

故障场景

场景关联:实际场景 -> 故障结果 -> 故障原因 -> 引发行为

资损

解决:

设计缺陷

解决:

流量故障

解决:

环境故障

解决:

应用故障

数据故障

发现:

解决:

发布故障

解决:回滚

安全故障

解决:

研发故障

解决:

历史遗留故障

这种问题存在的比较久,所以容忍度一般比较高,先止血,然后慢慢修复

小概率故障

解决:

研发操作管理

风险定级

风险降级:

发布监管

通过系统记录相关操作,使用审批流程引入人来监控

发布前要有发布卡点,如代码扫描,自动化测试来保证基础质量

使用发布窗口限定时间,确保发布期间有人员值守

发布窗口

灰度发布

发布前测试

发布提交(自动化测试) -> 发布流程(QA审批) -> 发布成功(QA验收)

故障监控发现

系统监控

业务监控

舆情监控

故障分析定位

系统诊断

根据现场得到现象,从而描述问题

根据输入输出定位分析是上游问题还是当前模块问题

根据已有日志或者指标判断是否是被上游错误影响、还是本身问题,亦或者与发布有关联、是否跟历史问题有关联

业务诊断

确定是否真的有异常,确定业务是否有损失

日志诊断

故障恢复

预案设定与执行

设定预案,发现线上问题自动报警并根据场景执行预警,以达到快速止血恢复的目的

stateDiagram-v2
  预案维护 --> 指标沉淀
  预案维护 --> 问题发现
  指标沉淀 --> 预案执行
  问题发现 --> 预案执行
  预案执行 --> 风险预防
  预案执行 --> 止血情况
  止血情况 --> 效果评估
  风险预防 --> 效果评估
  效果评估 --> 预案维护

故障复盘

过程

结果

故障分级

根据场景、影响、持续的时间

等级上升:随着故障危害加大,也要进行等级上升

等级下降:故障产生的影响及时修复或者损失被追回

故障定责

主要目的是判定责任方,由责任方来落地或推进改进措施

  1. 变更执行:变更方没有及时通知到受影响方,或者事先没有进行充分的评估,出现问题,责任在变更方;如果通知到位,受影响方没有做好准备措施导致出现问题,责任在受影响方;变更操作的实际影响程度大大超出预期,导致受影响方准备不足出现故障,责任在变更方
  2. 服务依赖:私自调用接口,或者调用方式不符合约定规则,责任在调用方;如果是服务方没有明确示例或说明,导致调用方出现问题,责任在服务方
  3. 第三方责任:电力故障、服务器故障、运营商网络故障等不可抗力导致,责任在第三方,但因自身的冗余或故障预案问题导致故障,责任在应用方

后续

故障演练

突袭演练,多样化每次触发的故障类型,整个过程严格按照真实流程处理

面向处理时间提升的演练