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

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

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

故障管理——故障的定责标准

图76故障定责模型

定责过程是找出根因，针对不足找出改进措施，落实责任人的过程。

定责目的：责任到人，避免扯皮推诿，并且责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。同时，也让整个团队认识到，对待故障要正视问题，严肃对待。定责不是为了处罚，但是作为责任方或责任团队一定要正视问题，找出自身不足，作为改进的主要责任者，来落地或推进改进措施。

避免运维背锅问题：严禁上游把责任推脱到下游的情况发生。作为受影响方，开发负责人有责任端到端地把问题定位清楚，只有当定位出来的问题确实是发生在运维的某个部件时，才允许将责任传递，否则不允许出现将自己的问题简单排除，就推断或者感觉应该是其他责任方的问题，然后终止后续排查或者指定下游责任方的情况出现。当然，在这个过程中，如果需要配合，是可以要求各方投入支持的，因为共同的目标还是要清晰定位问题，找到解决方案。

一定要区分定责和处罚。定责是对事不对人的，处罚是对人不对事。

涉及员工工作责任的，要确定是能力不足还是经验欠缺，可以基于事实，很正式、严肃地表达出来。帮助员工进一步分析应该怎么提升，或者聆听员工有什么求助或困难。

管理者除了关注故障本身之外，还要考虑得更加全面一些，要关注到人的感受，关注事情前因后果，只有这样，在管理执行过程中才会让员工感受到尊重和信任。

变更执行类

变更方没有及时通知到受影响方，或者事先没有进行充分的评估，出现问题，责任在变更方。

如果通知到位，受影响方没有做好准备措施导致出现问题，责任在受影响方。

变更操作的实际影响程度大大超出预期，导致受影响方准备不足出现故障，责任在变更方。

服务依赖类

私自调用接口，或者调用方式不符合约定规则，责任在调用方。

如果是服务方没有明确示例或说明，导致调用方出现问题，责任在服务方。

第三方责任类

机房电力故障、服务器故障、运营商网络故障等等，如果确实是不可抗力导致，责任在第三方。

第三方原因导致的故障，尽量只作为触发因素，不作为故障根因，便于自我改进。

管理方责任类

因自身的冗余或故障预案问题导致故障，责任在管理方

对于有明确底线，坚决不允许触碰的规则，如果因不遵守规则，故意触犯，导致了严重故障的出现，这种情况要处罚，这样的规则建议通过设定高压线的方式让团队成员牢记心中，但处罚不能一刀切，更不能上纲上线，一定要慎重。

通过处罚高压线去加强安全稳定意识，目的是要让每一个人对线上环境和系统都心存敬畏。绝大多数的严重故障都是因为无意识或意识薄弱导致的，并不是因为单纯的技术能力不足等技术因素。其实恰恰就是因为这种“想当然”，导致了严重故障。

鼓励做事

没有直接借鉴的经验，主动地承担一些极具挑战性的工作的不处罚。

业务高速发展时期，业务量成指数级增长时，团队人员技能和经验水平整体上还没法很好地应对，出现问题应群策群力而不是处罚。

如果定责跟绩效强挂钩，团队就陷入这种恐慌、质疑以致最终相互不信任的局面。取消绩效强挂钩是一个可选择的方法，对于出现的故障形成故障处理记录，然后把这件事情放到员工一个季度，半年，甚至一年表现中进行整体判断。如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但如果是频繁出问题，这种情况就基于事实反馈，也会更加容易沟通。

处罚高压线

下面是一些必须处罚的情况（参考）：

未经发布系统，私自变更线上代码和配置；未经授权，私自在业务高峰期进行硬件和网络设备变更；l  未经严格的方案准备和评审，直接进行线上高危设备操作，如交换机、路由器防火墙等；未经授权，私自在生产环境进行调测性质的操作；未经授权，私自变更生产环境数据信息。

故障管理——定期总结故障案例

定期总结是指按照一个季度、半年和全年的周期，对故障进行梳理和总结，这样可以更容易地发现一些共性问题，以便于研发团队在稳定性建设方面的规划。

文档管理

建立事后总结文件库，并定期评选最佳事后总结文档，成立事后总结阅读机制。

优秀的事后总结和事故处理应该在绩效考核、公开渠道中体现。

文档分析

反馈信息收集：事后总结流程是否合理的支持他们的工作？以及如何改进这种支持？书写事后总结是否引入了太多杂事？有什么书写事务总结的最佳实践可以分享？

趋势分析：事后总结要定期分析，建立趋势图

故障复盘的相关问题我们就聊到这里，我们了解了复盘的思路，怎么组织复盘会议，故障总结报告怎么编制，以及故障定责和处罚的处理，故障案例的定期梳理总结等问题，希望故障复盘成为你运维工作顺利开展的好助手。我们下一篇聊一聊故障的应急预案相关部分。