运维-运维体系标准化之故障管理

本文是极客时间《赵成的运维体系管理课》的读后体会之二 。

1.对故障的认识

ITIL的10个重要的IT管理关键模块之一就是故障管理。

故障永远只是表面现象，其背后技术和管理上的问题才是根因

即当技术和管理上的问题积累到一定程度后，就会以故障的形式爆发出来。所以不能仅将眼光限于故障本身和直接责任人。

2.故障的定级

故障需要有标准化的流程来指导我们的处理过程。

这里有个关键组织:故障应急小组。这个组织有4个职责：

故障应急小组需要有个负责人。在部分公司，这个负责人属于研发效率团队。

定级定责标准等同于法律条款，而这个角色等同于法官。法官依法办事，做到公平公正。

现实情况中，因为各方受到故障的影响不同，对故障影响的理解也不同，所以复盘过程中经常会出现下面这两种争执场景：

所以需要有严格而明确的判定标准。故障定级标准的目标是要判定故障的影响程度，使各相关利益方能够基于统一的标准判断和评估。

故障等级常见可以分为PO-P4共5个级别。PO最高P4最低。定级主要看3点：功能的核心程度，影响面，以及影响时间。核心程度有一些共通的标准（例如登录），也有各系统独有的业务衡量标准，所以需要基于每个系统与业务部门分别制定。影响时间是包含故障发生到完全解决的总时间。根据实际况，也可以调整为只计算工作时间的时间长度。如果影响时间超过一定时长，要进行故障升级。

P故障通常是两个或以上P1故障的叠加造成。

2.1 故障定级范例

下面是两个定级参考范例。首先是交易系统，主要以钱为衡量指标。

另一个是IM即时通信App的故障定级标准。

再次强调一下，为了避免日后引起争执，需要将定级标准在业务部门、产品团队、开发团队、测试团队和运维团队之间进行逐点的细节讨论，并达成最终一致的认可。

这个标准可能覆盖不到有些特例，这个时候需要由应急小组的负责人根据已达成一致的标准＋自己的经验进行独立裁量。同时，在每季度或半年对标准进行一轮修订。需要注意的是要对故障应急小组，特别是应急小组的负责人树立绝对的话语权和决策权的制度。

3.故障应急处理

故障发生后可能会产生很大的外部压力，并传递到研发团队。如果没有很好的故障应对措施，很容易陷入慌乱。

3.1 故障应急的原则

在故障应急状态下，坚守的第一原则是：优先恢复业务而非定位问题。

这需要事先有充足的预案准备以及故障模拟演练，也涉及各种稳定性保障措施，例如扩容，开关，限流降级等。

3.2 故障应急流程

故障应急流程由故障应急小组来主导。对外同步信息，包括大致原因，影响面和预估恢复时长，同时屏蔽各方对故障处理人员的干扰；对内组织协调各团队相关人员集中处理。

故障的应急流程主要分为以下几个步骤：

对于处理时间比较长的故障，应急处理小组每隔15-30分钟对相关业务部门同步一次故障处理进程，并判断是否需要升级故障确定故障处理方案，包括:正常业务流程处理提交数据修改单/修改配置/回滚/紧急版本/放到大版本在故障确认处理完成后，关闭生产缺陷组织故障复盘，产出故障分析报告，将问题记录到事件管理。故障分析报告需要同步给技术副总监、PMO，以及其他的产品、开发、测试和运维，以便后续吸取教训根据事件管理的记录，进行故障数据分析3.3 故障的信息通报

对于每一级故障的知会人员的标准参考如下：

4.故障的复盘

首先要明确复盘的目的。复盘的目的是为了从故障中学习我到我们技术和管理上的不足，然后不断改进。切总将复盘过程和目的搞成追究责任或实施惩罚，这对于团队氛围和员工积极性的打击是非常大的。

在复盘过程中，故障应急小组要起到关键作用，组织复盘会议。

对于低级别的生产事故，在晨会夕会之后顺带进行；对于高级别的生产事故，需要专门安排时间进行。

复盘会议的环节包括：

故障处理时间线回顾针对时间线合理讨论确定故障根因故障定级定责产出故障分析报告将问题记录到事件管理

对故障根因的讨论可以诸如：

此外，按季度、半年和全年的周期，需要进行周期内的故障案例总结会。总结会的目的包括：

5.故障的定责

定责的目的是为了责任到人，并且使责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。

相比故障复盘的对事不对人，定责就是对人不对事了，所以不能一刀切，不能上纲上线，一定要慎重。

对于故障的定责方式，也要根据故障的类型来划分。

5.1 高压线规则

有一类是绝对不允许触碰的底线。对于这类高压线规则，需要让每个成员牢记在心，并经常重复提醒。例如：

通过高压线去加强安全稳定意识，目的是要让每一个人对线上都心存敬畏。从经验来看，绝大多数的严重故障都是因为无意识或意识薄弱导致的，并不是因为单纯的技术能力不足等技术因素。很多人事后复盘时候最常讲的话就是：“我以为是没问题的，我以为是没影响的。”其实恰恰就是因为这种“想当然”，导致了严重故障。

对于高压线问题，碰一次就要疼一次。

5.2 鼓励做事，而不是处罚错误

Google的专家有一句名言:理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。

每个人的技术能力提升，基本都是伴随着大大小小故障的发生、处理、复盘和改进。虽然我们不希望有故障发生，但是真的没有了故障，我们也就没有了真刀真枪实战成长的机会。我们对待故障一定要客观和辩证地理解，特别是对于管理者来说，对于故障，一定要有容忍度，一定要有耐心。

我们的团队和人员，在这样一次次痛苦的经历后，各方面的能力都得到了锻炼，素养也一定会有大幅度提升。所以，对故障有容忍度，有耐心，我们的团队就会变得越来越强，对于故障的应对也会变得更加游刃有余。而一出故障就劈头盖脸地把团队和责任人骂一通，并且还要严厉处罚的方式，最后的效果就是严重打击士气，适得其反。

特别是以下这些原因造成的故障：

何况，如果不出问题，可能很多主管压根都没有关注过员工在做的事情，过程中是否有困难，是否需要支持等等，这本身就是管理者的失责。

员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了而且想要再恢复起来也会非常困难，最终很大概率上会导致优秀人才流失。

5.3 定责和绩效非强挂钩

在故障后直接谈及处罚，员工的情绪很可能会消极和抵触。例如“反正都是我的错，你说咋样就咋样”，或“凭什么罚我却不罚别人，又不是我一个人的问题”。员工害怕、甚至拒绝承担责任，宁可少做不做，也不愿多做多错，团队沟通成本上升，运作效率自然下降。特别是一个故障如果是涉及多方的，扯皮推诿就开始了，都想着把责任撇干净，甚至当众相互指责，这个负面效应杀伤力极大。

所以可以考虑将定责放到季度、半年为维度，根据事件管理中的记录来整体判断。如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但如果是频繁出问题，这种情况就基于事实反馈，也会更加容易沟通。