别再拿无法实现零故障当借口摆烂

我们在昨天的文章中，借用IBM的大型机之父Frederick Brooks在《人月神话》一书中阐述的理论，解释了为什么一个软件系统无法实现零故障的原因。

但作为一个拥有不（jia）断（guan）进（jin）取（jue）之心的技术团队成员，相信还是会想要规避故障，今天就和大家来聊聊这方面的内容。

任何的生产故障，当其发生时都会带来一定量的伤害和损失。故障虽然不能杜绝，但我们可以通过一系列的手段去及时发现故障、预判故障发生的可能性、在故障发生时能够及时合理预估可能的损失，从而做出正确的动作判断。我们可以通过如下手段和方法去逐步完善。

• 故障处理制度

这个部分是非常重要的工作规范，是属于在前人踩坑经验的基础上总结提炼出来的内容，是每个技术管理者需要在技术团队内不断强化和要求准确执行的内容。

故障处理制度要包含几个部分：故障等级、处理流程、分析要求、处罚说明。

故障等级：是用来描述故障严重等级定义内容，约定了不同的服务类型及其出现故障后可能产生的影响面及损失大小，整体用“S”（Sensitive 严重级别）或“P”（Priority 优先级别）叠加从小到大的数字来表示。

比如用户登录服务，属于核心服务。根据业务规模情况，如果是停止服务15分钟，就可以定义为P1（或S1）级故障。在这个部分还有一个重要的关键内容是服务升级情况，需要根据服务等级不同，约定故障在多长时间内没有恢复。则需要进行升级，以强化技术团队整体对故障发生时的快速响应和处理。

处理流程：用来约定技术团队整体对故障的处理过程。比如发现故障后，需要召唤哪些人组成临时的处理小组，什么场景要通知谁、运维要做什么配合、要对哪些内容进行操作处理等等，是对整个故障现场工作处置的细节描述。

同时，作为一个完整的处置流程，必须要关注的还有故障处理完成的标志。比如针对该故障的所有后续任务处置完毕等，也是工作闭环的重要内容。正如之前文章提到的《计划清单》一书中所描述一样，详尽细致的清单，可以在压力巨大的场景下提供更安全高效的工作处理过程，带来更好的结果。

分析要求：每一个故障其实都是团队的一次技术训练和教育，通过故障的深入分析还原故障的本质原因，找到最核心的解决方法，能够帮助技术团队快速提升。在分析要求中，需要明确列明故障分析报告的构成元素、数据详细程度、处理过程细节要求、处置结果描述及后续任务安排及跟进结果等内容。

处罚说明：这个部分的内容根据技术团队的实际情况来定义，可以是针对故障等级，对相关故障的主要责任人和次要责任人进行适度的处罚建议。这里需要关注的内容在于处罚本身不是故障处理的重要内容，而前面几项内容才是核心。但作为一个制度，没有相应的责罚内容说明，就会让这个制度失去威严，会让大家不重视该制度的落地执行。

• 日常CodeReview

CodeReview并不能带来直接的工作绩效，是属于需要长期坚持且见效很慢的工作。但坦率讲，Code Review除了能带来系统质量上的提升，还能带来工作效率和团队整体技术战斗力的提升。

我在阿里所负责的一个团队中，PLA（Product Line Architect，业务线架构师）有 3、4 位，分别负责各自的一块业务。PLA 之间 CodeReview 很少，代码质量的意识交流似乎也不多。但团队的普通开发同学在这些 PLA 之间轮流被 CodeReview，代码质量的评比标准差异较大。

这可能会导致 2 种现象：开发倾向 Review 宽松的同学，因为宽松 Review 发现问题（不仅仅是 bug）较少，变动成本不大。不会有改动造成的故障风险，不会影响项目进度，但后续的维护和沟通成本会明显增加；另一种现象，开发向不同的 PLA 提出疑义，PLA 之间统一代码质量标准，在团队内达成共识并形成文档，以作为后续参考。

所以这个团队的代码质量主要取决于团队几位 PLA，最后在一次故障的复盘工作中，我们重新提出这个问题，要求PLA们能够帮助团队统一代码质量意识和规范。例如：先由 1-2 位 PLA 对整个团队开发做 Review，这个 Review 工作量初期会很大，并且团队工作效率不高。但后期的 Review 工作量应该会明显减小，代码质量也会明显提高， 团队的工作效率也会明显提升。

可能你会说，这例子能被执行是因为大厂有更多的冗余资源足以可以落地推行，中小团队没有太多的空闲该如何处理？答案只能从为质量埋单的人这里来寻找，只有他痛，他才会推进这些工作得以落地。即便团队中没有更多的PLA来落地推进，也可以依靠各个模块的技术负责人，在日常工作过程中立即开展这项工作以使代码质量得到改善。

• 监控系统

监控系统的作用主要体现在故障发生前和发生中，如果一个团队拥有完善的监控系统，在面对故障发生的前后，会大幅度地缩短故障发生几率、降低故障带来的损失。这种监控分成几个方面：

业务层面监控：业务监控主要是针对日常的业务指标进行持续的数据跟踪，观察业务数据的变化区间情况，来判断当前的业务是否运转正常。

比如针对电商业务来说，一天24小时的用户登录、访问商品、下订单等业务动作都会有一个周期性的小幅波动。如果某天某个时段的业务数据产生异常波动，尤其是数据大幅下滑，则有可能是系统在这个业务流程处理过程中出现了风险，导致业务不能正常执行。

应用层面监控：是指对于业务系统进行内部的服务健康状态的监控。诸如：系统存活状态、性能响应、业务异常告警等等。

系统层面监控：这个部分一般是指系统的运行环境层面的监控，比如CPU、内存、磁盘、网络IO、网络连接等。针对系统运行环境内部的运行状态，如Java的JVM状态、GC次数和状态等等，都包含在这个部分之中。也都有相应的系统提供对应的服务，技术团队可以直接套用成熟的方案以节约时间。

这里还需要关注的一个内容就是监控系统中的告警机制，好的告警机制会规避掉告警的疲劳，避免因为频繁的小规模告警而让接受方产生思想上的懈怠。如果有一个重大的告警发生时，往往会出现没有及时关注告警情况而延误故障处置时间。

当然，针对这种情况，从告警的角度来讲，还可以通过告警升级的手段来加快处理效率。

比如一个告警在第一级处置人员手中没有及时响应，也没有及时对该告警内容进行后续的处置动作。那么可以在约定的时间内对该告警信息进行升级，交由上级处理，并在告警的形式上可以更换一种更加直接的方式处理。如：从短信告警升级为电话告警等等。

还有一种故障预防的方式越来越被许多技术团队采用，用来对系统健壮性和关键业务运行时间段中的故障发生状态下进行整体的故障处置演练，强化团队对故障处理的熟练度，提升处理效率，这就是时下比较流行的“混沌工程（Chaos Engineering）”。

Netflix工程师创建了Chaos Monkey，使用该工具可以在整个系统的随机位置引发故障。正如GitHub上的工具维护者所说，“Chaos Monkey会随机终止在生产环境中运行的虚拟机实例和容器。”通过Chaos Monkey，工程师可以快速了解他们正在构建的服务是否健壮，是否可以弹性扩容，是否可以处理计划外的故障。

2012年，Netflix开源了Chaos Monkey。今天，许多公司（包括谷歌，亚马逊，IBM，耐克等），都采用某种形式的混沌工程来提高现代架构的可靠性。Netflix甚至将其混沌工程工具集扩展到包括整个“Simian Army（中文可以译为猿军）”，用它攻击自己的系统。

混沌工程属于一门新兴的技术学科，行业认知和实践积累比较少，大多数IT团队对它的理解还没有上升到一个领域概念。阿里电商域在2010年左右开始尝试故障注入测试的工作，希望解决微服务架构带来的强弱依赖问题。

混沌工程通过一系列的实验来发现系统的弱点，整体过程分成如下几步：

1.定义并测量系统的“稳定状态”。

首先精确定义指标，表明您的系统按照应有的方式运行。Netflix使用客户点击视频流设备上播放按钮的速率作为指标，称为“每秒流量”。请注意，这更像是商业指标而非技术指标；事实上，在混沌工程中，业务指标通常比技术指标更有用，因为它们更适合衡量用户体验或运营。

2.创建假设。

与任何实验一样，您需要一个假设来进行测试。因为你试图破坏系统正常运行时的稳定状态，你的假设将是这样的：“当我们做X时，这个系统的稳定状态应该没有变化。”为什么用这种方式表达？如果你的期望是你的动作会破坏系统的稳定状态，那么你会做的第一件事是修复问题。混沌工程应该包括真正的实验，涉及真正的未知数。

3.模拟现实世界中可能发生的事情，目前有如下混沌工程实践方法：

模拟数据中心的故障、强制系统时钟不同步、在驱动程序代码中模拟I/O异常、模拟服务之间的延迟、随机引发函数抛异常。通常，您希望模拟可能导致系统不可用或导致其性能降低的场景。首先考虑可能出现什么问题，然后进行模拟。一定要优先考虑潜在的错误。

4.证明或反驳你的假设。

将稳态指标与干扰注入系统后收集的指标进行比较。如果您发现测量结果存在差异，那么您的混沌工程实验已经成功。您现在可以继续加固系统，以便现实世界中的类似事件不会导致大问题。或者，如果您发现稳定状态可以保持，那么你对该系统的稳定性大可放心。

混沌工程的目的是在将故障扼杀在襁褓之中，也就是在故障造成中断之前将它们识别出来。通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。

关注我们，防范线上故障