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

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

1.对故障的认识

ITIL的10个重要的IT管理关键模块之一就是故障管理。
故障永远只是表面现象，其背后技术和管理上的问题才是根因

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

• 管理者要先自我反省:员工只是执行者，管理者的责任永远大于执行者
• 强调用技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题
  • 短期可以辅以一些管理措施，比如靠宣传学习必要的Double Check/制定复杂操作的Checklist等。但是这些只能作为辅助手段，一定不能是常态
  • 随着系统复杂度越来越高，迟早有一天会超出单纯人力的认知范围和掌控能力，各种人力的管理成本也会随之上升，所以最终必须将这些人为动作转化到技术平台中去

2.故障的定级

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

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

• 制定故障定级定责标准
• 对线上故障做出定级和定责
• 跟踪线上故障处理
• 组织故障复盘

故障应急小组需要有个负责人。在部分公司，这个负责人属于研发效率团队。
定级定责标准等同于法律条款，而这个角色等同于法官。法官依法办事，做到公平公正。
现实情况中，因为各方受到故障的影响不同，对故障影响的理解也不同，所以复盘过程中经常会出现下面这两种争执场景：

• 技术支持判定故障很严重，但是责任方认为没什么大不了的，不应该把故障等级判定到如此之高
• 技术支持认为故障影响较小，但是受影响方却认为十分严重，不应该将故障等级判定得这么低

所以需要有严格而明确的判定标准。故障定级标准的目标是要判定故障的影响程度，使各相关利益方能够基于统一的标准判断和评估。
故障等级常见可以分为PO-P4共5个级别。PO最高P4最低。定级主要看3点：功能的核心程度，影响面，以及影响时间。核心程度有一些共通的标准（例如登录），也有各系统独有的业务衡量标准，所以需要基于每个系统与业务部门分别制定。影响时间是包含故障发生到完全解决的总时间。根据实际况，也可以调整为只计算工作时间的时间长度。如果影响时间超过一定时长，要进行故障升级。
P故障通常是两个或以上P1故障的叠加造成。

2.1 故障定级范例

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

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

再次强调一下，为了避免日后引起争执，需要将定级标准在业务部门、产品团队、开发团队、测试团队和运维团队之间进行逐点的细节讨论，并达成最终一致的认可。
这个标准可能覆盖不到有些特例，这个时候需要由应急小组的负责人根据已达成一致的标准＋自己的经验进行独立裁量。同时，在每季度或半年对标准进行一轮修订。需要注意的是要对故障应急小组，特别是应急小组的负责人树立绝对的话语权和决策权的制度。

3.故障应急处理

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

3.1 故障应急的原则

在故障应急状态下，坚守的第一原则是：优先恢复业务而非定位问题。
这需要事先有充足的预案准备以及故障模拟演练，也涉及各种稳定性保障措施，例如扩容，开关，限流降级等。

3.2 故障应急流程

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

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

• 确认故障的有效性
• 登记生产缺陷
• 将故障上报到可用性保障群里
  • 故障的原因排查和讨论在该群里或者单独拉一个独立的故障处理群处理。如果相关人员比较集中在一个办公场所，则集中到会议室
• 对于处理时间比较长的故障，应急处理小组每隔15-30分钟对相关业务部门同步一次故障处理进程，并判断是否需要升级故障
• 确定故障处理方案，包括:正常业务流程处理提交数据修改单/修改配置/回滚/紧急版本/放到大版本
• 在故障确认处理完成后，关闭生产缺陷
• 组织故障复盘，产出故障分析报告，将问题记录到事件管理。故障分析报告需要同步给技术副总监、PMO，以及其他的产品、开发、测试和运维，以便后续吸取教训
• 根据事件管理的记录，进行故障数据分析
  • 分析角度包括:每月故障数对比、每月故障处理时间对比近两月故障等级占比分布、近两月故障类别占比分布、近两月故障来源对比和近两月各业务组故障数对比

3.3 故障的信息通报

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

• P0/P1：技术总监/PMO
• P2：技术副总监/PMO/测试主管/运维主管
• P3/P4：技术经理/产品经理

4.故障的复盘

首先要明确复盘的目的。复盘的目的是为了从故障中学习我到我们技术和管理上的不足，然后不断改进。切总将复盘过程和目的搞成追究责任或实施惩罚，这对于团队氛围和员工积极性的打击是非常大的。
在复盘过程中，故障应急小组要起到关键作用，组织复盘会议。
对于低级别的生产事故，在晨会夕会之后顺带进行；对于高级别的生产事故，需要专门安排时间进行。

复盘会议的环节包括：

• 故障的回顾
  • 包括故障发生时间点，故障影响面，恢复时长，主要处理人或团队
• 故障处理时间线回顾
  • 故障应急小组在整个过程记录时间点，以便真实再现整个故障处理过程
• 针对时间线合理讨论
  • 比如为什么没有告警而是用户反馈的，响应时长是否符合规范，是否有预案和预案执行完成度，测试环节为什么没有发现等
  • 故障应急小组负责人注意控制场面，务必注意对事不对人，及时干预和警告，避免演变成批斗会
• 确定故障根因
• 故障定级定责
  • 对于高级别生产故障定责时可以仅少数相关人在场时进行，考虑责任人个人感受
• 产出故障分析报告
• 将问题记录到事件管理

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

• 是否是人员对业务不熟悉导致？
• 是否有人为操作导致？如果是的话，是否能改为自动化？
• 是否在代码静态扫描中包含但被忽略了？
• 为什么容量不足没有更早发现？
• 为什么没法快速定位？是监控不够，还是告警太多人员麻木？
• 管理上，人员的on call机制是否及时？应对故障的协作方式上是否还能改进？

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

• 分析故障趋势，观察是否需要进行人员安排的调整
• 发现共性的问题，贡献给整个研发团队

5.故障的定责

定责的目的是为了责任到人，并且使责任人能够真真切切地认识到自己的不足之处，能够主导改进措施的落地。
相比故障复盘的对事不对人，定责就是对人不对事了，所以不能一刀切，不能上纲上线，一定要慎重。
对于故障的定责方式，也要根据故障的类型来划分。

5.1 高压线规则

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

• 未经发布系统，私自变更线上代码和配置
• 未经授权、严格的方案准备和评审，私自在业务高峰期进行硬件和网络设备变更
• 未经授权，私自在生产环境进行调测性质的操作
• 未经授权，私自变更生产环境数据

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

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

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

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

每个人的技术能力提升，基本都是伴随着大大小小故障的发生、处理、复盘和改进。虽然我们不希望有故障发生，但是真的没有了故障，我们也就没有了真刀真枪实战成长的机会。我们对待故障一定要客观和辩证地理解，特别是对于管理者来说，对于故障，一定要有容忍度，一定要有耐心。
我们的团队和人员，在这样一次次痛苦的经历后，各方面的能力都得到了锻炼，素养也一定会有大幅度提升。所以，对故障有容忍度，有耐心，我们的团队就会变得越来越强，对于故障的应对也会变得更加游刃有余。而一出故障就劈头盖脸地把团队和责任人骂一通，并且还要严厉处罚的方式，最后的效果就是严重打击士气，适得其反。
特别是以下这些原因造成的故障：

• 员工积极主动地承担了一些极具挑战性的工作，需要尝试某个新技术或解决方案
• 业务高速发展时期，业务量成指数级增长时，团队人员能和经验水平整体上还没法很好地应对。这个时候可能任何一个小变动都是最后一根稻草

何况，如果不出问题，可能很多主管压根都没有关注过员工在做的事情，过程中是否有困难，是否需要支持等等，这本身就是管理者的失责。
员工努力做事的积极性一旦被打击，变得畏首畏尾起来，也就谈不上什么技术进步和突破了而且想要再恢复起来也会非常困难，最终很大概率上会导致优秀人才流失。

5.3 定责和绩效非强挂钩

在故障后直接谈及处罚，员工的情绪很可能会消极和抵触。例如“反正都是我的错，你说咋样就咋样”，或“凭什么罚我却不罚别人，又不是我一个人的问题”。员工害怕、甚至拒绝承担责任，宁可少做不做，也不愿多做多错，团队沟通成本上升，运作效率自然下降。特别是一个故障如果是涉及多方的，扯皮推诿就开始了，都想着把责任撇干净，甚至当众相互指责，这个负面效应杀伤力极大。
所以可以考虑将定责放到季度、半年为维度，根据事件管理中的记录来整体判断。如果员工整体的表现都是不错的，甚至是突出的，说明员工已经改正或者那件事情确实是偶尔的失误导致，这种情况下员工仍然会有好的绩效。但如果是频繁出问题，这种情况就基于事实反馈，也会更加容易沟通。

本文永久链接 [ https://galaxyyao.github.io/2020/07/30/运维-运维体系标准化之故障管理/ ]