经验分享：故障管理中的涅槃重生

2017 年 9 月 13 日 EGONetworks 赵成

对于任何一个技术团队，如果要问大家，让大家最痛苦、最不愿面对的事情是什么？我想答案只有一个，那就是：故障。

作者介绍：

赵成（谦益），EGO 杭州分会会员、美丽联合集团技术服务经理，负责美丽联合集团（原蘑菇街、美丽说）技术服务团队管理及运维体系建设工作。拥有近10年研发和运维经验，拥有非常丰富的电信级和互联网业务研发和运维经验。目前专注于运维创造价值，以及云计算和 AI 时代运维技术转型和突破。

动态针分割线写故障相关的文章比较痛苦，着实感觉有点费力。因为故障这个事情，跟技术、管理、团队、人员息息相关，是需要一整套体系来保障的。后来想想， Google 为了介绍稳定性和 SRE 的职责，可以出厚厚一本书，就能明白稳定性和故障管理这项系统工程的复杂度了。

所以，这篇文章还是聚焦一下，聚焦在：故障的事后阶段。作为一个经历了无数故障的技术管理者，把我在经历了煎熬和痛苦之后的一点点体会总结出来的，共勉。也希望我们每一个人和团队都能够在故障的涅槃重生中达到升华。

一、接受下面这个现实

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

然而系统正常，只是该系统无数异常情况下的一种特例。( From SRE , by John Allspaw )

可能有人会问：“ 那也没见到这些大型网站整天出问题或不可访问啊？”，其实这反而说明了这些公司的技术非常牛，他们在故障隔离、快速恢复、容灾切换这些方面做的实在太好了，以至于一般的问题和故障，根本不会影响到业务访问和体验。

对于故障的态度上面：要接受现实，拥抱风险。所以我们的目标和注意力不应该是消除故障，或者不允许故障发生上，而是应该考虑 Design for Failure ，也就是怎么让我们系统更健壮，在小打小闹的问题面前，仍然可以岿然不动，甚至是出现了故障，怎么能够让业务更快恢复起来。

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

再用另外一个意思表达一下：永远不要将主要注意力放在故障本身上，一定要将注意力放到解决技术和管理的问题上去。

这个逻辑一定是技术和管理上的问题，积累到一定量通过故障的形式爆发出来，所以故障是现象，是在给我们严重提醒了。对于故障的理解更深入一下，应该转化成考虑下面几个问题才对：

1.为什么会频繁出故障？

是不是人员技术不过硬？人为操作太多，自动化平台不完善？线上敬畏意识不够？

2. 为什么一个小问题或者某个部件失效，会导致全站宕机？

是不是业务高速发展，技术架构上是不是耦合太紧，任何一个小动作可能都是最后一根稻草？是不是容量评估靠拍脑袋，系统扛不住才知道容量出问题了？是不是限流降级等保障手段缺失，或者有技术方案，但是落地效果不好？

3. 为什么发生了故障没法快速知道并且快速恢复？

监控是不是不完善？告警是不是太多人员麻木？定位问题效率低，迟迟找不到原因？故障隔离是不是还不够完善？故障预案是不是纸上谈兵？

4. ……

总结下来，任何一个故障的原因都可以归结到具体的技术和管理问题点上，在故障复盘过程中，通常会聚焦在某个故障个例上，归纳出来的是一个个非常具体的改进措施。但是这个时候对于管理者来说，要能够关注到更全局的关键点上。比如：

1. 是不是应该考虑有更加完善的发布系统，减少人为操作？

2. 是不是应该有整体的稳定性平台建设？

包括限流降级、开关预案、强弱依赖、容量评估、全链路跟踪等子系统，以及建设完成后，应该如何一步步的落地；

3. 故障预案和演练应该如何有效的组织起来？

毕竟这些是从全局考虑，自上而下的一个过程。

这里还想表达两个观点：

1. 出问题，管理者要先自我反省看问题出在哪儿

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

2.强调技术解决问题，而不是单纯靠增加管理流程和检查环节来解决问题

技术手段暂时无法满足的，可以靠管理手段来辅助。比如我上面提到的基本就都是技术手段，但是要建设完善肯定是要有一个过程，特别是对于创业公司，不可能一下就有完善的自动化体系，这时可以辅以一些管理措施。

再比如靠宣传学习，提升人员的线上安全稳定意识，必要的 double check ，复杂操作的 checklist 等，但是这些只能作为辅助手段，一定不能是常态，必须尽快的将这些人为动作转化到技术平台中去。单纯的管理手段还是靠人，跟之前没有本质区别，同时效果上很难被量化评估，同时还增加了管理成本。

三、定标准，定原则

故障定级标准，这个标准主要为了判定影响程度，各方能够基于统一的标准判断。同时也是避免复盘过程中技术支持判定故障很严重，但是责任方认为没什么大不了的这种情况出现。

比如分 P0-P4 几个级别、比如电商，主要以交易下跌、支付下跌、广告收入这些跟钱相关的指标为衡量标准，根据具体数据对应到不同等级。关于可用性和可靠性，这个可以借鉴业界通用的 MTBF 、MTTR 、MTTF 这几个指标来衡量。

图片说明：名词解析

故障定责原则，主要目的是判定责任方，避免我认为是你的责任，你认为是我的责任，大家相互推脱的情况出现。举个简单的例子：接口变更，变更方要通知到对应的依赖方，如果未通知，变更方承担责任，如果已通知，依赖方未及时做出调整，依赖方承担责任，通知形式已公告和邮件为准。

这里面还有一个角色，我们称之为技术支持，也有的团队叫 NOC ，这个角色就是来跟踪故障处理和复盘的。运作模式上，技术支持有权对故障做出定级和定责，有点像法院法官的角色，而上面的两个标准就像是法律条款，法官依法办事，做到公平公正。

这里只简单介绍下原则，因为每个公司的业务形态和特点不一样，里面的具体内容可能也不一样，评判标准也不同，这里就不细说了，推荐 《Google SRE》 这本书，有很多很细致的执行层面的建议，可以参考下，有兴趣也可以线下交流。

四、出现故障到底要不要处罚？

这个也是上次在 EGO 会员交流群讨论的内容，当时群里引发讨论的原文如下（以下内容已经过当事人许可发布）：

“ 请教一下大家，如果由于技术原因对客户造成资损，公司做了赔付后，后续对相关人员有没有什么资金或绩效上的处罚吗？目前我这边定的是绩效分上会有扣减，也会影响绩效工资，大家还有啥更好的建议不？”

对于故障的事后处理，我的建议是：一定要区分好两个概念，定责和处罚，定责 ≠ 处罚。

定责

事情一定要有人承担责任，并且负责后续改进措施落地。定责一般是故障复盘的后来确定的，通过这个过程找到根因，制定改进措施，最终判定责任方，会议和公开场合只体现责任团队，故障系统上会记录到具体责任人，但是这个字段不公开。

这个过程，就一个原则：对事不对人。因为故障复盘这个事情，每个团队都会去做，具体的过程和方式方法没有太大差别，所以这里不讲具体过程和方法。

处罚

也就是是否跟薪资、奖金、绩效考核、晋升资格等等这些跟利益相关的事情挂钩？我的观点是：不能一刀切，不能上纲上线。

这里首先问一个问题，处罚的目的是什么？其实说的直白一点，目的就是想让责任人长记性，别再出纰漏。这个地方再提个问题，到底什么事情是长了记性，知道了痛之后，就可以有效降低再犯错误的概率的？

概括来讲就是，由于主观意识薄弱、低级且重复的失误造成严重后果的故障，解决的就是这个主观意识上的问题，这样讲可能不具有指导意义，建议设定高压线，比如：

未经发布系统，私自变更线上代码和配置；
未经授权，私自在业务高峰期进行硬件和网络设备变更；
未知授权，私自在生产环境进行测试性质的操作；
未经授权，私自变更生产环境数据信息；
……

通过高压线去加强安全稳定意识，目的要让每一个人对线上都有敬畏心理。因为有太多的严重故障都是因为无意识或意识薄弱导致，特别是那种自我感觉没问题，命令就噼里啪啦敲到线上去了。如果意识到位，绝大多数严重问题都是可以避免的。所以，意识提升一定要放在第一位。

高压线是什么？建议我们在宣传的时候，不要只讲高压线这个名词，最好形象地说明一下后果，“ 明确告知哪里是高压线，一定不要碰。如果还不注意，不管主观和还是客观，高压线碰上就是个死。这里面不管是非要尝试下电压刺激，还是出门打酱油不小心踩上了，还是高压线掉下来不小心被碰到了，只要触碰到，后果都是一样的 ”。（不寒而栗）

高压线就是要坚决杜绝，碰一次就要让责任人疼一次，这个时候，责任人敬畏意识和主观意识提升了，人为失误才会减少，这样的处罚才是有效果的。

五、处罚的“负”作用远超我们的想象

前面讲到，定责不是处罚，需要就事论事。员工哪些地方做的不到位，是能力不够？还是经验不足？这些东西主管可以基于事实，正式甚至严肃地表达出来，通常情况下员工也大都是可以接受的。

同时，还能帮助员工进一步分析出现这些问题是哪些方面的不足导致的，应该怎么更好的提升，或者员工自身有什么求助诉求，主管要能够给到一些承诺去帮助改进。这种情况下，员工的感受是：“主管还是尊重我，他现在是在帮助我，并没有否认和放弃我。”

但是，话题和目的如果一旦转到处罚相关的事情，员工一般会有两种类型的反应，一种是消沉低落（反正都是我的错，你说咋样就咋样）；另外一种是极力地反抗和质疑，比如他会质疑你：“凭什么罚我不罚别人，又不是我一个人的问题？”等等。

这个时候，处罚我 = 否认我，员工的注意力也会从怎么改进这个点上转移到你为什么要处罚我这个点上来了，在这种消极情绪和氛围中再去沟通什么改进措施，就没有任何效果了。作为管理者，也就非常容易陷入到与被沟通者的反复解释中，他质疑一句，你就解释一堆，但是他压根就没听进去。

我们的经验：定责跟绩效强挂钩，团队就陷入这种恐慌、质疑、挑战以致最终相互不信任的局面。员工害怕或甚至拒绝承担责任，宁可少做不做，也不愿多做多错，团队沟通成本上升，运作效率自然下降。

特别是一个故障如果是涉及多方的，撕逼扯皮推脱就开始了，都想着把责任撇干净，甚至出现当众相互指责，背后议论纷纷的情况，破坏了整个团队的团结和信任，这个负面效应杀伤力极大，其实远比罚款带来那点损失大的多了。大家可以关注团队氛围，如果是撕逼扯皮多了，协作效率下降了，极有可能的原因之一就是处罚措施使用不当了。

后来我们取消挂钩，对于出现的故障有专门的系统记录，然后把这件事情放到员工一个 Q ，半年，甚至一年表现中整体进行判断，如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但是如果是频繁失误、频繁出问题，这种情况下也就没什么特别好说的了，用结果说话就好了。

我的团队中，就出现过有员工导致了线上严重故障，当个 Q 绩效较差，但是因为全年表现突出，年终仍然是优秀的情况；也有员工，因为连着两个 Q 连续触碰高压线，全年又无明显突出的表现，年终绩效也就不理想的情况。

六、目的是鼓励做事，而不是处罚错误

理解一个系统应该如何工作并不能使人成为专家，只能靠调查系统为何不能正常工作才行。（ From SRE ，by Brian Redman ）

这里还有几种情况要特别注意，当一个故障发生之后，主管一定要注意员工出问题的事情的背景是什么。比如我直接列举几个情况：

这件事情是不是本身就极具挑战性，需要尝试某个新技术或解决方案，而团队、业界和社区可能都没有可供直接借鉴的经验，结果在落地的过程中踩到了一些坑，导致出现问题。
（这种情况在成熟的技术和产品中出现也极其容易出现，比如开源产品有时候不翻源码都不知道某个地方埋着深坑，某些商业产品，在他的官方 bug 库里列着一堆已知 bug ，就是告诉你我是有问题的啊，你们用的时候自己小心着点别踩，踩了是你自己没注意，但是一般不出问题没人会去把整个 bug list 都去看一遍。）
业务高速发展时期，业务量成指数级增长时，团队人员技能和经验水平整体上还没法很好地应对时，这个时候可能任何一个小的动作都是那最后一根稻草。
员工在接受任务时，是不是团队中没有足够的人手，是员工发现了问题站出来主动承担的？

概括一点说：员工在主动承担别人做不了或不愿做的事情的情况下，只要不是涉及触碰高压线的或者造成什么不可挽回的损失的，一定要优先鼓励肯定，传递信任，而不是批评和处罚（定责该怎么定就怎么定，目的是改进）。何况，如果不出问题，可能很多主管压根都没有关注过员工在做的事情，过程中是否有困难，是否需要支持等等，这本身就是管理者的失责。

这样的员工大都是责任心和积极性很强的，一个事情没做好，其实内心里面都不知道自责了多少遍。作为管理者，这个时候没有任何必要再去批评他，甚至是处罚，而是要鼓励他、帮助他、支持他，这个时候反而会达到“知耻而后勇”的激励效果。

在当前这种新业务和新形态不断涌现，又要求快速迭代的形式下，软件开发这种技术工作很大程度上还是要依赖员工的创造性和创新性，所以在上面提到背景下，管理者一定要对故障有一定容忍度，员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了，而且想要再恢复起来就非常非常困难，最终极大概率地会导致优秀人才流失，为别人做了嫁衣。

所以，团队内部一定要营造出鼓励做事向前冲的氛围，而不是制造担心犯错误被处罚的恐慌氛围。