故障管理杂谈

随着系统复杂度、团队规模的增加，需要一个套方法来应对系统中的各种"黑天鹅",以下为整理的故障应对方法。

主要为分为以下阶段：

• 预备
• 故障预警
• 故障处理
• 复盘
• 改善与优化

一 预备

• 文化
• 组织准备
• 定义故障等级
• 资源清单
• 版本发布机制

1. 文化

一个企业的"文化"或者大家更熟悉的"基因"决定了一个企业思考、决策和执行逻辑，以下为个人思考在成熟的故障体系下，需要具备的条件。

"抗"事的领导

个人认为领导的主要能力是能"成"事和能"抗"事。一般来讲流程角色和定义中需要管理层参与统筹和协调，在此过程中需要领导具备"抗"事的素质，应首先考虑是协调解决问题，而不是划清责任，对于下属不能平时"小甜甜"，出事"牛夫人"。

文化的体现不应挂在墙上、印在书上，应体现在需要抉择时的行为上。

design for failure

作为系统设计的一个维度考虑，尤其由大量服务组成的复杂系统。往往出现很多"不讲道理"的"灵异"现象，需要设计时考虑如何系统的假设条件得以成立，如系统的假设遭到挑战时应如何处理

系统的质量(可用性)是有代价的

需要为质量、故障应对分配资源。

故障处理方式可以有多样，比如通过技术手段或者通过增加人员监控等。其实手段没有绝对的优劣，采用最适合的即可。

心态开放

对事不对人，谨慎追责。比如当时受限于资源和工期的因素妥协的功能，不能一股脑否认当时的限制，只对故障追责，否则会造成团队做事畏首畏尾，人才流失、掩盖小故障造成大故障等问题。

2.组织准备

是否有完善的 oncall 机制,人员协作流程和方式。

主要解决的问题是故障发生"谁"可以处理，在处理的过程中需要如何协作, 故障升级流程、以及附加流程上的"资源"是否可用,各团队的角色、预期是否一致。

3.定义故障等级

一 级是全站不可用；

二 级是某功能不可用，且无替代方案；

三 级是某功能不可用，但有替代方案；

四 级是非功能性故障，或是用户不关心的故障。

或按照"致命/高/中/低"划分，此处根据需要即可。

主要是为了确定该故障要牵扯进多大规模的人员来处理。设定该等级故障可用的资源；避免一人救火,大家观望。

4.资源清单

• 以用户功能为索引的服务和资源全视图

需要一个系统来记录前端用户操作界面和后端服务，以及服务使用到的硬件资源之间的关联关系。以应用角度关联的CMDB(配置管理数据库),确认应用与基础服务的关系，要同时固化下来，从应用创建之初，就将应用与各类基础服务的生命周期进行挂钩，同时确保信息可以更新。信息固化不是目的，也没有价值，只有信息动态流转起来才有价值。

然后，把后端的服务、服务的调用关系，以及服务使用到的资源都关联起来做成一个视图。这个视图最好是由相应的自动化监控系统生成。有了这个资源图后，我们就可以很容易地找到处理故障的路径了。这就好像一张地图，如果没有地图，很容易定位错问题，或者增加定位的时间。

如以下信息:

基础服务

• 主机
• 数据库
• redis
• 其他中间件

应用层面的信息

• 应用元信息
• 应用调用关系
• 代码信息
• 部署信息
• 脚本信息
• 日志信息
• 设计时的妥协点

系统是各种资源受限的情况下做出来的，因此在可用性或者质量方面的妥协点需要整理出来，方便知道哪些是需要重点维护的，故障是否与妥协点有关。

• 容易造成系统波动的清单

大的变更如功能升级导致的用户完成某一功能路径变更；用户考核规则引起的使用频率的大幅度变化。

市场活动、市场曝光或运营大促等造成的流量波动。

定时任务运行的时间是否合理，包括计划中的和非计划的中的。比如数据库维护期间是否有其他任务处理重要的定时任务，对定时任务的依赖也要有相应的梳理。

批量导入导出以及其他容易造成的数据库或中间件波动操作等。

5.版本发布机制

很多故障是由于版本升级引入的，因此需要对版本更新和功能发布有充足的管理，需重点关注此过程执行需要时间、比如有无良好的工具支持回退操作等。

如配置管理、自动化测试、回退机制、灰度/蓝绿发布等。

二 故障预警

• 完善监控
• 预警指标优化
• 预警分发

墨菲定律：事情往往会向你所想到的不好的方向发展，只要有这个可能性。

前段时间考虑优化缓存，结果还没来得及处理，线上就出了一个缓存项过多，引起的响应时间过长的bug...

此领域主要解决如何把真正影响系统稳定的指标通过合适的渠道及时发送给合适的相关人。如果不期望一个事情发生（包括业务层面如数据一致和完整性等），就要有确保它不发生的机制。

1.完善监控

可以回答谁、什么时候做了什么操作、操作结果如何？

2.预警指标优化

全面监控等于没有监控,太多的预警会导致"狼"来的效应，或因为关注大量的非核心预警浪费团队精力，需要评估哪些是核心指标，以及核心指标的覆盖率。如平均响应时长、最长响应时长、db长sql等。

优秀的监控系统可以做到故障抑制和故障衍生。故障抑制高级别的预警可以抑制由其导致的相关预警（常见的模式有关联分析、告警合并等），可以帮助故障处理人员快速定位问题，避免陷入预警风暴之中。比如数据库故障会导致响应时长、大量的功能可用性出问题；预警衍生，一般需要结合场景进行分析，比如再根据时间在接收层收到大量的低级别告警，此时可以衍生一条高级别告警；独立的事件A、B发生时，我们的目标C是否会受到影响等。

3.预警分发

此领域需要探讨的两个问题。

• 预警如何及时到达干系人 需要约定一个双方认可的通道，避免干系人屏蔽消息。最近把公司的群消息屏蔽了，很多事情后知后觉，被diss了几回。
• 预警消息上下文是否可以协助更快处理

三 故障处理

• 定位
• 隔离和清除
• 操作流程标准化
• 恢复

上述两个步骤的工作做好了，是不是发现此阶段也相对有序了。个人建议处理阶段优先是恢复故障，在此前提下尽量保护好现场，方便后续故障处理。

1.定位

需要结合响应清单和预警系统，以及之前的处理手册。

2.隔离和清除

是否可以通过降级和限流等防止故障蔓延。

3.操作流程标准化

此处主要是防止误操作引入更大的故障

• 保护好备份

保护好备份、让备份尽量远离操作现场 如有可能让备份存放在其他主机或独立快照，本地是否也可以保留一个备份；

记得有一次操作数据有一步操作操作了，请运维看看能否通过日志恢复还原到操作之前。结果运维上来先把原来的备份给删除了，还原操作也失败了...

• 做好配置管理

配置管理是误操作的"后悔药"。

4.恢复

• 重启

主要解决可用性问题，重启一般能解决很多问题；但要考虑重启是否会引入不一致、异常的数据等，后续的数据处理。

• 降级和限流
• 回滚
• 紧急更新

一般不建议，除非其他方式不能解决问题。此方案需要有发布系统支撑。

• 主动发布处理阶段

让相关人知道如何协作比如客户安抚等

• 积极、开放协作

需要帮助时及时求助

四 复盘

COE(Correction of Errors)

• 故障处理流程

就像一个 log 一样，需要详细地记录几点几分干了什么事，把故障从发生到解决的所有细节过程都记录下来。

• 故障原因分析

需要说明故障的原因和分析报告。

Ask 5 Whys：

需要反思并反问至少 5 个为什么，并为这些“为什么”找到答案，过程会很痛苦，会有反复被鞭尸的感觉。

• 故障后续整改计划

需要针对上述的“Ask 5 Whys”说明后续如何举一反三地从根本上解决所有的问题。

• 资源分配是否合理 五 改善与优化
• 故障演练

验证方案故障改善中的方案是否有效

• 优化故障获知和故障定位的时间

从故障发生到我们知道的时间是否可以优化得更短？

定位故障的时间是否可以更短？

有哪些地方可以做到自动化？

优化故障的处理方式。

故障处理时的判断和章法是否科学，是否正确？

故障处理时的信息是否全透明？

故障处理时人员是否安排得当？

优化开发过程中的问题

Code Review 和测试中的问题和优化点。

软件架构和设计是否可以更好？

对于技术欠债或是相关的隐患问题是否被记录下来，是否有风险计划？

优化团队能力

如何提高团队的技术能力？

如何让团队有严谨的工程意识？

• FMEA方法

(failure mode and effects analysis )全称为故障模式与影响分析,可帮助我们更好分析和应对故障。

整体思路：

给出初始的架构设计图。

假设架构中某个部件发生故障。

分析此故障对系统功能造成的影响。

根据分析结果，判断架构是否需要进行优化。

涉及到点:

1、功能点；

2、故障模式；

3、故障影响；

4、严重程度；

5、故障原因；

6、故障概率；

7、风险程度；

8、已有措施；

9、规避措施；

10、解决措施；

11、后续规划

总结

故障管理模型个人觉得就像一个金字塔，故障处理，就像塔的一个尖。功夫更多在下面。其他领域做的好，可以有效缩短故障时长，甚至避免故障;另外关于在信息领域车品觉 老师曾分享"存、管、晒；混、通、用"，让信息流通起来，最大化信息价值。

本文可以说是以下文章学习笔记整理。

https://time.geekbang.org/column/article/1059 https://time.geekbang.org/column/article/1064 陈浩老师

https://time.geekbang.org/column/article/9391 李运华老师