运维体系建设(稳定性保障体系7)

运维体系建设(稳定性保障体系7)

（本字共1706字，大约需要阅读5分钟）

故障管理

在说明故障管理的开始，我们要先树立正确的故障观。很多人对故障的发生非常抗拒，但故障是提高系统可用性的契机，比如从以下角度看待故障：

技术和管理上的问题，积累到一定量会通过故障的形式爆发出来，所以故障只是现象，是在对人进行提醒反馈。 理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。故障的处理过程也是对人磨练的过程，人是在外界压力下利用比较思维和统计学不断缓解问题的过程。

故障管理在各行各业都有使用，下面是各行业的常用管理手段，有些手段和信息系统行业的常规做法完全相反：

从组织架构层面对安全关注：常见于工业工程行业，通过整个组织从上至下严格遵守极为确定的流程确保不会出现意外事故。

关注日常操作细节：紧耦合结构机械操作行业的关注点，对日常操作每一步都进行规范化。 冗余容量：为了保证系统不中断，提供额外的容量进行应急部署。业务恢复演练：利用某种灾难情景可能导致的严重程度来决定演习是使用模拟方式还是线上方式。灾难的响应机制必须要经过不断练习才能确保不会忘记。培训与考核：在涉及人身安全的行业中极为重要，从业人员会不断的考核再考核，保证从业人员有足够的技能和反应能力。对详细的需求收集和系统设计的关注：对风险承受能力严重不足的行业，如医疗器械行业。这些行业的产品需要经常长时间的需求分析和系统设计，不然产品在交付后的使用情况或者维护情况与设计者的预想可能会有差别，设计的花费在产品中占比非常高，是与计算机软件行业最大化迭代速度截然相反的方式。 一些行业如军队的战略武器系统，这些行业的SLO要求必须为为100，所以自动化的bug是不能承受的，这些行业一般会通过一系列的人的操作而不是自动化完成一些工作，因为人的操作会发现自动化系统不会发现的问题，人的缓慢稳定的操作过程和人的反应速度是匹配的，形成了可以随时暂停的机制。计算机自动化的过程与人的反应速度不匹配，当人意识到问题时，自动化过程往往已经结束。而且在这种行业，使用“如果没有坏，就永远不要试着修复它”的理念进行决策，因为任何改动都可能带来新的问题，在行业演进较慢的行业里，故障场景不会因为系统升级而发生变化，或者故障修复操作者的操作水平不可预知，这种行业一般给操作者一本《万事通故障操作手册》或简单清淅的指令序列表，所有事前能想到的故障都写在一个手册上，当故障发生时，这些资料是进行操作的权威指南。 在数据为基础的行业里，决策的基本方向是事先决定的（不是事后得出的），决策时考虑的信息源是明确的，任何假设都应该明确说明原因，数据驱动决策方向优于情感、直觉、经验。决策的推理性决定决策往往不用考虑个人意见。

故障管理是需要管理流程支持的，无流程管理的紧急事故会造成：

没有缓解方案多人同时行动，但沟通不畅，导致效率降低或次生问题预想的解决办法实现不了，导致次生问题上下游服务人员的服务质量不匹配处理缓慢，客户投诉导致组织被动上级领导要求故障后立即承诺修复时间和确定事故原因缺乏信任：上级领导依据直觉经验对尝试的专业解决方案进行干预

故障域

故障管理中缓解故障的影响或制定故障管理流程一般通过确定故障域，然后对故障域进行隔离或替代实现的，并一定要对故障本身进行实时的处理。

故障域（failure domain）指系统中可能由于一个故障而同时不可用的一组组件。常见的故障域包括物理机器、数据中心中用同一个供电设计的机柜、数个机柜中使用同一个网络设备的网络、受单个网络出口影响的数据中心、可以被一个自然灾害所影响园区。

事后总结

事后总结是为了系统化的关注引起故障（或接近故障）的根源问题，回答发生了什么、响应的有效程度、是否有其他方案、如果确保下次故障不会再发生。

潜伏的事故：在任何事故和业务灾难发生之前，类似事故都曾经发生过好几次，只是没有造成任何后果，这些事故在发生的时候都被忽略了。潜伏的错误，加上某个适合的时机，就会导致事故的发生。潜伏的错误，加上自我纠正，就是一次学习和优化的机会。

---

今天就到这里吧，明天我们介绍一种通用的故障排查方法。晚安！