互联网故障管理指南

什么是故障

业界故障管理均基于ITIL演化而来，根据实际情况精简流程以适配互联网的精益迭代。

1、ITIL中的定义

故障：①非计划性的IT服务中断，或者IT服务性能的下降。②配置项的失效，即便没有影响到服务。故障管理：对所有故障进行处理的流程。

故障管理的目标：尽快恢复服务到正常运行，并且最小化对业务运营的不利影响，从而尽可能地保证服务质量和可用性的水平。

为什么要做故障管理

无论是理论还是实践，均证明故障只要有发生的可能，它总会发生。所以为了保障业务稳定性，需提前发现、解决风险，及时发现、定位原因、快速恢复故障，同时要确保改进措施有效落地、避免故障重复发生，我们需要建立一个规范可遵循、闭环的故障管理体系。

系统正常只是无数异常情况的一种特例

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

系统正常只是无数异常情况的一种特例

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

• 大型网站也经常发生故障，但是我们感觉微乎其微，究其原因是因为这些公司的的故障隔离和故障处理机制十分完备.

• Design for Failure，我们无法杜绝故障，但是我们能让系统更加健壮，恢复更加快速

  • 防御性设计（Defensive Design）
  • 边界情况（Edge Case）
  • 防误措施（Mistake Proofing）
  • 解耦（Decoupling）
  • 舱壁模式（Bulkhead）
  • 冗余（Redundancy）
  • 重试（Retry）
  • 撤销（Undo）
  • 冷备（Cold Standby）
  • 熔断（Derating）
  • 容错（Error Tolerance）
  • 失效安全（Fail safe）
  • 优雅降级（Graceful Degradation）
  • 监控（Monitorng）
  • 耐用性（Durability）
  • 回弹性（Resilience）

国内大型网站为保证业务稳定性和连续性，容量评估，限流降级，开关预案，故障隔离，快速恢复，容灾切换等方面做足了功夫.故障演练为这些能力提供了实践场地，为故障处理提供了强有力的组织赋能

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

• 永远不要将注意力放在故障本身上，一定要将注意力放到故障背后的技术和管理问题上去。技术和管理上的问题，积累到一定量通过故障的形式爆发出来，所以故障是现象，是在给我们严重提醒。有时我们过分关注故障本身，就容易揪着跟故障相关的责任人不放，这样会给责任人造成很大的负面压力，进而导致一些负面效应
• 问题改进往往以杜绝故障为命题，改进措施往往容易输出一些无法落地，无法量化的措施

所以，想要更好地应对和管理故障，当故障发生后，我们需要考虑的问题应该是其背后存在的技术和管理问题。这里和你分享我自己在故障后的复盘中，经常会反思和提出的几个问题

0. 为什么会频繁出故障？是不是人员技术不过硬？人为操作太多，自动化平台不完善，操作没有闭环？代码发布后的快速回滚措施不到位？
1. 为什么一个小问题或者某个部件失效，会导致全站宕机？进一步考虑，是不是业务高速发展，技术架构上耦合太紧，任何一个小动作都可能是最后一根稻草？是不是容量评估靠拍脑袋，系统扛不住才知道容量出问题了？是不是限流降级等保障手段缺失，或者有技术方案，但是落地效果不好？
2. 为什么发生了故障没法快速知道并且快速恢复？进一步考虑，是不是监控不完善？告警太多人员麻木？定位问题效率低，迟迟找不到原因？故障隔离还不够完善？故障预案纸上谈兵？
3. 管理上，团队成员线上敬畏意识不够？还是我们宣传强调不到位？Oncall机制是否还需要完善？故障应对时的组织协作是不是还有待提升？

总结下来，任何一个故障的原因都可以归结到具体的技术和管理问题上，在故障复盘过程中，通常会聚焦在某个故障个例上，归纳出来的是一个个非常具体的改进措施。

作为故障管理者，需要不断的反问，下次出现类似问题，怎么才能更快地发现问题，更快地恢复业务？即使这一次的故障应对已经做得非常 好了，下次是否可以有更进一步的改进？比如，是不是应该考虑有更加完善的发布系统，减少人为操作；是不是应该有整体的稳定性平台 建设，包括限流降级、开关预案、强弱依赖、容量评估、全链路跟踪等子系统，以及建设完成后，应该如何一步步的落地；还有，故障预 案和演练应该如何有效的组织起来，毕竟这些是从全局考虑，自上而下的一个过程。

对事不对人＆管理者责任

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

强调技术解决问题

强调技术解决问题，而不是单纯地靠增加管理流程和检查环节来解决问题，技术手段暂时无法满足的，可以靠管理手段来辅助。比如我上 面提到的就基本都是技术手段，但是要建设一个完善的体系肯定要有一个过程，特别是对于创业公司。这时可以辅以一些管理措施，比如 靠宣传学习，提升人员的线上安全稳定意识，必要的Double Check，复杂操作的Checklist等，但是这些只能作为辅助手段，一定不能是 常态，必须尽快将这些人为动作转化到技术平台中去。

怎么做好故障管理

故障管理就是围绕故障全生命周期管理，形成体系闭环、持续改进。

无论是理论还是实践，均证明故障只要有发生的可能，它总会发生。所以为了保障业务稳定性，需提前发现、解决风险，及时发现、定位 原因、快速恢复故障，同时要确保改进措施有效落地、避免故障重复发生，我们需要建立一个规范可遵循、闭环的故障管理体系。

定义故障

• 故障命名

  故障管理部门（例如质量部门、NOC、运维管理部门等）可根据实际情况定义故障序列，以下为目前业界可参考的序列，一类序列一般分 为4级，级别数字越小严重程度越高。

  • P（PRIORITY）序列：技术基础序列，为故障处理的综合优先级。
  • D （DATA）序列：数据质量序列，综合数据资产等级与数据影响因素。
  • R（RISK）序列：舆情风险序列。
  • S（SLA）序列：衡量影响SLA严重程度。 故障定级

标准概述

以P序列举例：

• 明确故障等级，一般PO～P5数值越小越严重
• 故障定级建议分为通用型和业务型两类，业务线型故障定级标准不得低于通用型故障定级标准。
• 通用型故障等级由故障管理部门定义，可包含受影响用户数、受影响商家数、客诉增量、资金损失等通用指标。通用型故障场景在业务线 型故障场景未覆盖情况下兜底。
• 业务型故障等级由故障管理部门联合业务团队基于用户视角共同定义，以下为业务型故障定级举例。公司内部工具也可按照此模板定义故 障级别以纳入故障管理。

故障分级(参考,每个公司不同业务定义都有差异)

级别定义	具体定义	备注
P0	1、数据丢失无法追回的，且损失无法回补 2、阻塞主流程4小时以上 3、直接或间接资损30W以上 4、客诉超过50 5、阻碍客户正常操作，阻碍用户数＞1000 6、服务宕机	严重性问题，导致系统不可用，大规模用户出现资损，或者品牌严重受损
P1	1、功能不符合用户需求数据，计算错误，业务流程错误，且百分百复现 2、程序接口错误 因错误操作迫使程序中断100％出现 3、系统可被执行，但操作功能无法执行（含指令） 4、功能项的某些项目（选项）使用无效（对系统非致命的） ＜br/＞ 5、功能实现不完整，导致流程无法进行，需要重新开发测试发布的＜br／＞ 6、直接或者间接经济损失10～30W	一般严重性问题，导致系统部分不可用，问题可以百分百重现，且出现在主流程上
P2	1、出现设计未预料的异常，不阻断正常主流程＜br／＞ 2、户体验影响有限的问题1% 3、分支流程阻断，不影响业务完整性，概率低于50％ 4、功能实现不完整，但是系统可以提供完整服务＜br／＞ 5、直接或者间接经济损失10W以内	中等性问题，导致系统概率不可用，或者系统性能明显降低，影响用2、主流程出现概率性问题，阻断正常操作，阻断比例小于
P3	1、分支链路异常，且异常没有透出终端，不影响业务开展 2、无直接经济损失 3、较大的影响用户产品体验	一般性问题，不影响用户，错误没有直接透出.服务可用展
P4	1、概率性影响用户体验	体验性问题

故障升级

评定项	降级标准	升级标准
响应时间	第一时间响应，包括故障的通知，处理，善后等事宜	相关人员一再催促下，责任人仍没有及时对故障进行处理
准备度	对故障发生的原因已有充分的预防机制	对已有发生的问题，或低级错误没有进行预防或规避
处理态度与能力	在最快时间内处理故障，并积极配合其他相关人员的故障处理工作；遇到技术问题积极寻求解决办法和资源支持；	对故障不重视，态度怠慢，敷衍；或没有足够技能进行故障处理
处理结果	在最短时间内完全恢复正常运作，故障影响降到最低	故障没有完全解决；或由于处理过程不及时不妥善导致故障 影响（范围，金额，投诉量，恶性舆论等）有所扩大
改进措施	对故障发生的原因进行总结，制定同类故障的预防规避措施	拒绝对故障原因（除不可抗力因素以外）进行总结和制定预防／规避措施 故障定责原则

故障定责原则

• 避免扯皮推诿

  • 避免扯皮推诿，大概是很多团队都会遇到的非常头疼的问题，也是最令人生厌的问题，所以避免这样的问题，就必须得有相对清晰的定责标准。
  • 避免甩锅推诿，还有一个很重要的原则，就是对于所有问题定位到底，找到根因

• 正视问题严肃对待

不是为了处罚，但是作为责任方或责任团队一定要正视问题，找出自身不足，作为改进的主要责任者，来落地或推进改进措施。

• 高压线禁止触碰（出现故障，对故障进行加权）

  • 未经测试和发布系统，私自变更线上代码和配置，未知授权，私自在生产环境进行测试性质的操作
  • 未经授权，私自变更生产环境数据信息
  • 未经授权，私自承接需求
  • 代码未按标准合并
  • 未经授权，私自在业务高峰期进行硬件和网络设备变更未经授权，私自导出公司内部数据
  • 其他未按经授权或未按标准开发流程执行的情况

• 定责范围

  • 理者应当负连带责任，并思考管理改进办法
  • 产品设计不合理，运营不善带来的问题，运营和产品负主要责任未经许可擅自发布的代码，开发以及直属管理者全责
  • 中间件运维等外部因素导致的问题，由第三方主责，团队负连带责任
  • 触碰高压线，直接责任人和直属领导，从重处理
  • 通过代码review的需求，review负责人负连带责任

故障奖惩

• 故障等级以实际定责为准
• 责任人跟进复盘问题，并定期通报解决进度，直到结束故障级别

处罚措施(管理者需要提前公示)

略

故障应急

• 问题升级为故障后，由故障管理部门及时通告故障信息，拉起故障处理群／电话会议，协调、跟进、监督故障处理直至恢复。
• 由于故障管理部门需要7X24应急响应，有条件的公司可以参考google的SRE、阿里的GOC组建团队，成员分布不同时区，实现日出而作，日落而息。

故障确立

• 故障会通过监控、告警、业务反馈或用户商家投诉几个渠道反馈过来，这时技术支持会根据故障定级标准，快速做出初步判断，确认影响面，以及故障等级

故障传播＆应急

• 对于非紧急故障，由故障管理人员建立故障管理单，进行维护跟踪，直至解决

• 对于紧急故障，第一时间做故障上报，避免直接处理导致的次生危害

• 对于重大故障由团队负责人（技术or质量）组织应急小组，统一指挥分工协作

  • 故障定位班，进行故障根因定位
  • 故障应急止损班，进行快速止损
  • 故障通告班，进行故障影响搜集和故障信息的及时播报
  • 故障决策小组，快速决策处理方案，避免问题扩大，快速消除问题影响

故障恢复

故障发生后的第一要务是恢复业务，预案、重启、降级、隔离、切流、饱和式应急等，都是可选的方案。 故障处理中执行的预案一定要在故障演练中真实执行过，避免未知预案导致次生灾害

监控告警

一旦线上出现问题，都要及时反思告警是否完备，核心是业务监控关联故障等级定义（故障要严格分级，区分处理）做到故障及时发现。 告警本身要做到智能告警以提升告警准确率，例如智能阈值、智能基线、根因算法等。

故障复盘（Postmortem 验尸）

复盘时效

为确保问题、风险能够得到足够重视，并及时制定改进措施，建议PO～P2级别故障3个工作日内完成复盘，P3～P4故障5个工作日完成复 盘，其他序列故障可参考P序列时效性。

复盘准备

为提升复盘会议效率，故障管理人（复盘会议主持人）应该在会议之前整理如下信息：

• 故障处理过程：必须包含故障注入、故障发生、故障发现、故障响应、初因定位、恢复执行、故障恢复、根因定位等核心时间点及操 作，其他关键时间点及操作视实际情况补充。
• 影响业务：具体到下跌时段、下跌比例，资金损失金额。 用户
• ／商家影响情况：理论影响量，来电、在线咨询量
• 故障根因及对应根因分类：设备故障、代码问题、流程规范、应急灾备、容量等。

故障复盘重要关注点

• 故障预防：是否变更触发
• 故障发现：发现时长，发现来源，监控优化
• 应急响应：响应时长
• 故障恢复：恢复时长，恢复措施沉淀，改进
• 改进措施：基于以上信息制定可验的证改进措施，完成时间点，负责人

复盘流程

• 故障简单回顾。主要针对故障发生时间点，故障影响面，恢复时长，主要处理人或团队做简要说明。
• 故障处理时间线回顾。技术支持在故障处理过程中会简要记录处理过程，比如每个操作的时间点，责任人，操作结果，甚至是中间的沟通和协作过程，比如几点几分给谁打了电话，多长时间上线的等等，这个过程要求客观真实即可。业务恢复后，会发给处理人进行核对和补充。这个时间线的作用非常关键，它可以相对真实地再现整个故障处理过程。
• 针对时间线进行讨论。回顾完上述时间线之后，我们会提出过程中存在的疑问，这一点会对主要处理人产生一定的压力，所以一定要保持对事不对人。通常我们会针对处理时长过长、不合理的环节提出质疑，比如为什么告警没有发现问题，而是用户投诉反馈的？为什么从发生故障，到有人上线响应拖了很长时间？为什么对应的场景没有限流、降级和开关等预案？为什么预案执行了没有生效？为什么没有做灰度发布和验证等等？通过这些问题和细节的讨论，我们会找出明显的不足，记录下过程中的改进点。
• 确定故障根因。通过讨论细节，我们对故障根因进行判断，并再次对故障根因的改进措施进行讨论。在这个环节和上个环节中，通常会有很多讨论甚至是争论，技术支持要发挥的作用就是控制好场面，就事论事，一定不要让讨论失控，演变成相互指责和批斗会，一旦有这种苗头，技术支持一定要及时干预并给出警告。
• 故障定级定责。根因确定后，结合前面已经确认的故障影响面，就可以对故障定级定责了，这里还要依赖前面我们介绍到的故障标准。不过，定责时，我们会让责任方团队和相关处理人员在场，小范围告知，这样做主要是考虑责任人的个人感受。如果无异议，就形成故障完结报告；如果有异议，则可以向上级主管反馈，直至技术团队负责人（CTO或技术VP）为止。
• 发出故障完结报告。故障完结报告的主要内容包括故障详细信息，如时间点、影响面、时间线、根因、责任团队（这里不暴露责任人）、后续改进措施，以及通过本次故障总结出来的共性问题和建议。这样做的主要目的是保证信息透明，同时引以为戒，期望其它团队也能够查漏补缺，不要犯同样的错误。

复盘报告案例

Case Study | 2019-09-11 XX bug事故报告 级别：Px作者：QX

（一）事故影响

摘要：9月11日凌晨崩溃率上升1.58％，陡增2000％；9月11日热修复后问题未到得解决崩溃率未降低 讲版.md

影响范围：每日涉及1000个用户

时间：2019／09／11 17：24～2019／09／12 19：00 损失：无

责任方：测试、研发部、产品

责任人：XXX XXX 感.md

（二）事故原因

诱因：中秋活动中频繁进出直播间导致崩溃 主因：

1．在研发和测试过程中没有落实到每一个细节，活动特殊情况需要在特定时间段触发逻辑，没有及时在测试过程反馈。 2．研发自测未考虑完善。

3．当天热修复发布后，未及时验证问题是否解决。

（三）事故过程

时间线：

2019／09／11 00：40 收到bugly预警，崩溃率超过预警阈值。 2019／09／11 10：00 研发同学定位的导致崩溃的原因

2019／09／11 11：00 研发修复问题

前期：安卓冒烟测试和核心模块回归测试缺失

发现、止损、解决、验证、恢复：发现问题到确认问题用了12个小时，二次修复未得到验证就发布 解决＆自测＆测试：崩溃一直持续到9／11下午2点半，第二天9／12热更新补丁修复 版本

(四）问题总结和优化点及计划

事项	责任人	完成时间	关联任务链接
崩溃类型总结文档	XXXXXX	XXXX年XX月XX日
每个迭代codereview	XXXXXX	持续工作
每次GIT MR bugly测试环境支持	XXXXXX	XXXX年X月XX日
每个迭代特殊功能测试点梳理组织	XXXXXX	每个迭代需求会议后
测试加强机型覆盖和意外操作测试	XXXXXX	XXXX年X月XX日
制定故障处理流程，修复流程文档	XXXXXX	XXXX年X月XX日
新的事故总结模板、故障评级、责任制度整理	XXXXXX	XXXX年X月XX日

(五）六问

Q：设计、编码层面，有哪些问题？

A:

Q：测试为什么没有发现？

A:

Q：监控是否第一时间发现，为什么没有？

A:

Q：为什么系统不能容错？

A:

Q：解决速度能否更快、损失能否更小，如何做到？

A:

Q：怎样避免类似情况发生？

A:

持续运营

持续运营是个广义的概念，除了故障数据各种维度晾晒、经验传承、文化宣导外，最主要的是通过故障数据分析，识别故障各个生命阶段 的薄弱点、风险点，针对薄弱点、风险点有专项改进。

比如多次未灰度直接发布引起重大故障，变更制度、变更平台是否可强管控；故障恢复主要依赖代码发布导致恢复慢，是否可打造及时恢 复文化，针对常见故障场景是否能沉淀快恢预案等。

故障管理Tips

故障管理路长且艰，以下给故障管理同学的建议，希望共勉。

1．积极主动、认真负责

• 风险、问题跟进不到位，演变成故障的数量会增多 故障跟进不到位，影响面会扩大
• 故障根因不明确，改进措施可能无效 改进措施无效，故障还会重复发生

2．敢于质疑

• 监控发现是否及时
• 故障处理过程是否可优化，有没有人为失误
• 业务影响面统计是否真实
• 故障原因是否是本次故障的根因
• 改进措施制定是否合理

3．自我提升

故障管理者不是统计、记录文员，要以架构师严格要求自己，能够指出故障各个阶段存在的问题，并能够独立承担对应优化专项