我以前很崇拜那些能修复各种软件缺陷的“救火”高手。很多年前，我还是一个维护遗留系统的团队的普通开发人员。那时，团队的每个开发人员，都轮流带一个7x24小时开机的手机，处理用户问题。团队里有一位英雄。他戴眼镜，经常身穿一件白大褂。我们要是有搞不定的生产事故的各种疑难杂症，就会找他。
只有他能搞定我们这些普通开发人员搞不定的问题。所以过去了十多年，我依然很佩服他，觉得他是英雄。但当我后来读了《第五项修炼》中描述的“负担转移”系统基本模式后，醒悟到团队有这样的“英雄”，看起来值得“庆幸”，但会带来一个意想不到的后果——团队不再想花时间和精力，提升普通开发人员解决生产事故的能力，因为“英雄”出马，以一当十。当年团队所维护的遗留系统火情不断，但我们这些普通水平的开发人员，一直救不了火。
真英雄，要么能赋能团队成员，提升他们处理生产事故的“救火”的能力，而不仅仅靠他一人；要么能把需要半夜爬起来抢修的生产事故，化解成一个个小任务，在白天上班时间给解决了。
有人会问，作为开发人员，如何才能把生产事故化解成一个个小任务呢?
首先，可以在自己日常开发新代码，或解决软件缺陷时，时时思考面前的代码，是否出现了以下分布式计算的8个谬误：
- 网络是可靠的
- 延迟为零
- 带宽无限大
- 网络很安全
- 网络拓扑不会改变
- 只有一名网管
- 传输成本为零
- 网络是同质的
比如你发现要修改的代码，存在“网络是可靠的”这样的谬误，接下来就可以借助“复杂系统稳定性的12个反模式”(每个反模式的详细描述，参见《发布!》第2版第4章)列表，来思考哪里会存在“暗债”。
- 集成点
- 同层连累反应
- 层叠失效
- 用户
- 线程阻塞
- 自黑式攻击
- 放大效应
- 失衡的系统容量
- 一窝蜂
- 做出误判的机器
- 缓慢的响应
- 无限长的结果集
将思考产生的所有“暗债”集中起来，并按照“暗债”爆发的“影响度”和“可能性”这两个维度，把这些“暗债”进行排序，然后选择其中“影响度”最高且“可能性”最大的一个“暗债”，优先处理。
假如你发现代码中存在一个“集成点”的“暗债”需要优先处理，那么就可以借助下面“复杂系统稳定性的12个模式”(每个模式的详细描述，参见《发布!》第2版第5章)列表，来寻找偿还“暗债”的思路。
- 超时
- 断路器
- 舱壁
- 稳态
- 快速失败
- 任其崩溃并替换
- 握手
- 考验机
- 中间件解耦
- 卸下负载
- 背压机制
- 调速器
比如上面那个“集成点”的“暗债”，可以使用“快速失败”的思路来解决，那么就可以根据修复工作量的大小，要么顺手修复，要么将其加入迭代开发待办列表中，纳入日常开发活动中。如果每位开发人员都能在日常开发过程中，持续进行如上的思考，那么就能在白天上班时，将生产事故的相关“暗债”，逐一解决，让自己能睡个好觉。
当然你可以把上面那套方法及其成效，分享给你的队友。但更有效的方法，是设法影响你的技术领导，请他参考2021年6月中文版新上市的《混沌工程》关注与该书同名的这一新实践。
早在2008年，Netflix公司在把数据中心迁往亚马逊云平台的时候，踩了一个大坑，经常会出现生产事故。为了能在白天上班时间解决生产环境的事故，而不是半夜爬起来解决，他们摸索出一套行之有效的方法——混沌工程。
该如何做混沌工程?
借鉴Netflix的实例，可以从“摆正心态、人员主动和试点业务”三方面入手，来启动混沌工程。
摆正心态
承认暗债为复杂系统所固有，而不是一味要求工程师“不能也不该出现失误”。否则在故障面前，大家就只会花大量时间相互甩锅，而忽视了提升团队发现更多暗债和快速修复生产故障的能力。
人员主动
根据Ashby的必要多样性法则(用于控制系统B的系统A，需要和系统B同样复杂)，要建立对系统能够承受生产环境的动荡的信心，需要针对生产环境“丰富多彩”的暗债，设计同样“丰富多彩”的防范手段。而技术骨干一个人，是发现不了那么多暗债，并找到那么多的防范手段的。所以，就需要发挥各位工程师的主动性。此时，领导者要创造能调动工程师主动性和创造性的企业文化，来促进工程师更安全地发现与修复更多“花样”的暗债。在修复暗债的过程中，就可以使用上述8大谬误、反模式和模式列表。
试点业务
- 选择一个出现生产事故频率较高的业务系统，尝试混沌工程。因为事故的反复，出现会让发现与解决暗债的动力更大
- 基于能反映用户体验的业务稳态行为建立假设，而不是先聚焦于在系统内寻找弱点。因为这样能更利于进行全局优化，让成效更大
- 为了让暗债浮现出来，设计引入足够多样化的现实世界可能发生的事件，而不是设计那些易于生成但在现实中不大可能出现的事件，以便切中要害。针对每一个所引入的事件，参考上述模式列表，来进行稳定性设计
- 可以先从准生产环境入手进行混沌实验，等条件成熟后，再逐渐过渡到生产环境
- 自动化地持续进行混沌实验，以起到回归实验的效果，持续发现并解决暗债，避免系统随着时间的推移，在韧性方面逐渐“掉队”
- 设计更安全的实验方式，以最小化爆炸半径，让实验所导致的业务损失降到最低，而不是明知故障难以控制，还要贸然进行实验。如果实验的假设被证伪，那么就遇到了发现新的暗债的好机会。在寻找暗债的过程中，可以参考上述反模式列表，来启发寻找漏洞及修复
总结一下，真英雄最终都不会在半夜里爬起来抢修生产事故，因为他们会聪明地使用分布式系统稳定性设计，以及混沌工程，避免将自己陷入如此凄惨的境地。
作为一名开发人员，如何能让自己能逐渐减少在半夜爬起来抢修生产事故的次数?可以尝试使用本文要介绍的8个谬误、12个反模式和12个模式。
如何让队友不会半夜把你喊起来帮着抢修生产事故?影响领导，尝试使用混沌工程，来让团队成员都在上班时间，主动发现并修复分布式系统的漏洞，逐渐减少夜里喊你的次数。
【本文是51CTO专栏作者“ThoughtWorks”的原创稿件，微信公众号：思特沃克，转载请联系原作者】
