预防为主，何以为辅？——《混沌工程》译者序

在敏捷软件开发领域，质量内建是一个广受欢迎的实践。这种将质量意识贯彻到软件开发各个环节，从而节省返工成本的做法，其本质就是”预防为主“。

但片面强调“预防为主”，会给人一个错觉，那就是软件系统的任何故障，都可以通过“预防”来解决。

基于这个错觉，一旦出现了线上事故，那么人们首先就会责备开发、测试和运维人员，因为他们“不能也不该出现失误”（https://developer.aliyun.com/article/603866）。

像“绝不能将任何风险引入生产环境”这样的口号，只是人们美好的愿望。“暗债本固有”的客观事实，大家则都心知肚明。

在云原生和微服务这些复杂系统大行其道的年代，必须承认，一个人的大脑，无法承载分布式系统的全部细节；每个人对系统的理解，也会存在差异；加上沟通时所发生的信息损耗，当他们合作开发软件时，就必然会产生不可预知的“暗债”。

我们虽然能凭借”软件测试“和”故障演练“来提升软件质量，但这种经常采用固定测试用例和相同演练流程的手段，却让软件系统在生产环境上，无法应对来自外界”不按常理出牌“的种种”恶毒“考验，比如本应通畅的网络出现了延迟，本应能正常写入的磁盘被写满了，本应理智的用户不知为何开始疯狂地反复点击提交按钮……

我们就生活在这种充满了非线性和不确定性的世界中。

“预防为主”固然很好，但因为”人无完人“，所以“暗债”必然会产生。而其不可预知的特点，导致无法做到“预防暗债”。

让我们重温一下“面向恢复的计算“（https://pages.cs.wisc.edu/~remzi/Classes/838/Fall2001/Papers/hpts01.pdf ）所信奉的观点：

• 无论在硬件方面还是软件方面，系统失效都是不可避免的。

• 建模和分析永远都不会足够完备，用推导的方法预测所有系统失效方式是不可能的。

• 人的行为是系统失效的主要原因。 

这种论断是不是太悲观了。面对复杂系统中无法预知和“预防”的“暗债”，我们还能做什么？

我们可以做下面三件事：

• 承认“暗债”本就固有

• 故障发现修复要快

• 随时树立起警示牌

下次云平台发生故障，我期望能看到这样的故障说明：“我们要为该故障树立起警示牌，并提升故障的发现和修复速度，最终达到在用户尚未察觉的情况下，快速发现并修复故障。”

在承认暗债本固有的前提下，设计安全的方法来做“不按常理出牌”的实验，以考验软件系统的稳定性，以促进“快速发现和修复故障”，从而有效地对“预防为主“的质量内建进行补充。

这种工程实践，就是混沌工程。