故障管理里的小细节

故障，是一种常态，任何一个软件系统都避免不了，国内最牛的 BAT 避免不了，国外最牛的 Google、Amazon、Facebook、Twitter 等也避免不了。业务体量越大，系统越复杂，问题和故障就越多，出现故障是必然的。

这里有一个非常重要的体现，就是 Design for Failure 的理念。我们的目标和注意力不应该放在消除故障，或者不允许故障发生上，因为我们无法杜绝故障。所以，我们更应该考虑的是，怎么让系统更健壮，在一般的问题面前，仍然可以岿然不动，甚至是出现了故障，也能够让业务更快恢复起来。

简单表述一下，就是永远不要将注意力放在故障本身上，一定要将注意力放到故障背后的技术和管理问题上去。

想要更好地应对和管理故障，当故障发生后，我们需要考虑的问题应该是其背后存在的技术和管理问题。经常会反思和提出的几个问题。

1、为什么会频繁出故障？是不是人员技术不过硬？人为操作太多，自动化平台不完善，操作没有闭环？代码发布后的快速回滚措施不到位？

2、为什么一个小问题或者某个部件失效，会导致全站宕机？进一步考虑，是不是业务高速发展，技术架构上耦合太紧，任何一个小动作都可能是最后一根稻草？是不是容量评估靠拍脑袋，系统扛不住才知道容量出问题了？是不是限流降级等保障手段缺失，或者有技术方案，但是落地效果不好？

3、为什么发生了故障没法快速知道并且快速恢复？进一步考虑，是不是监控不完善？告警太多人员麻木？定位问题效率低，迟迟找不到原因？故障隔离还不够完善？故障预案纸上谈兵？

4、管理上，团队成员线上敬畏意识不够？还是我们宣传强调不到位？Oncall 机制是否还需要完善？故障应对时的组织协作是不是还有待提升？

第一，出问题，管理者要先自我反省。不能一味地揪着员工的错误不放，员工更多的是整个体系中的执行者，做得不到位，一定是体系上还存在不完善的地方或漏洞。在这一点上，管理者应该重点反思才对。

第二，强调技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题，技术手段暂时无法满足的，可以靠管理手段来辅助。要建设一个完善的体系肯定要有一个过程，特别是对于创业公司。这时可以辅以一些管理措施，比如靠宣传学习，提升人员的线上安全稳定意识，必要的 Double Check，复杂操作的 Checklist 等，但是这些只能作为辅助手段，一定不能是常态，必须尽快将这些人为动作转化到技术平台中去。

此文章为4月Day11 学习笔记，内容来源于极客时间《赵成的运维体系管理课》，推荐该课程。