不增加成本能更好应对生产系统稳定性意外故障的“开发测试运维三岗转为系统红蓝军”实验

系统红蓝军，不仅可以引导开发人员做好功能自测，更可以在不增加成本的情况下，引导企业有效应对生产系统稳定性意外故障。

1 基于观察

企业经常出现意料之外的软件系统生产环境稳定性故障。

2 问出问题

是什么原因导致企业经常出现意料之外的软件系统生产环境稳定性故障？

3 形成可验证的解释性假说

企业经常出现意料之外的软件系统生产环境稳定性故障，原因来源于管理者和工程师存在以下4种心理特点。

第一，过度自信(Overconfidence)。即人们经常高估自己的绝对能力，并高估与其他大部分人相比的相对能力。在判断和决策方面，没有什么问题比过度自信更容易发生，也更有可能造成灾难。

第二，确认性偏见(Confirmation bias)。即人们倾向于以证实自己先前信念的方式，搜索、处理、解释和回忆信息，同时也倾向于不考虑与自己先前信念不一致的信息。

第三，从众效应(Bandwagon effect)。人们在决策时倾向于 “从众"，而不是独立思考。

第四，注意力顾此失彼(Attention)。即人们在决策时，倾向于根据决策的重要性和与决策有关的信息的显著性，只处理可用信息的一个子集，而忽视其他可感知的信息。

企业所建立的蓝军行动机制，是克服上述心理特点的重要方法。蓝军行动（在国外叫红队行动 red teaming）是一个假装成敌人的团队，在企业相关部门的指导下，尝试对该企业进行物理或数字化的入侵，然后报告他们所发现的隐患，以便企业改进。企业要求蓝军跳出框框来思考问题，研究被认为不太合理的场景，开展蓝军行动。

4 基于假说做出预测

如果将开发人员的岗位改名为系统红军，即需要对所设计和编写的软件特性在整个系统的生产环境中正常运行负全责，而测试人员的岗位改名为系统蓝军，即从整个系统的角度，模拟现实世界生产环境各种刁钻的场景，来考验系统红军所设计和实现的软件特性，能否正常运行，并向企业汇报，助推红军进行改进。因为红蓝军都要使用生产环境，所以运维人员可以根据红蓝军的需要，分为两组，分别加入系统红蓝军。那么开发、测试和运维这这三个岗位之间的关系，就转变为红蓝军对抗。这样就能有效克服管理者和工程师的过度自信、确认性偏见、从众效应和注意力顾此失彼等心理特点所带来的负面影响，减少意料之外的软件系统生产环境稳定性故障，并提升故障的修复速度和质量。

为了更好地应对从众效应，系统蓝军应该相对独立于系统红军。由于企业的测试团队，一般都会独立于开发团队。所以测试团队转变为系统蓝军，具备天然优势。

作为企业IT部门某个开发团队负责人的你，该如何设计这个实验？

我在下面帮你列出这个实验具体实施方法。你可以根据团队具体情况，做适当的调整。

5 设计并执行有对照组的实验检验预测

你需要设法吸引IT部门负责人、运维团队和测试团队负责人对这个实验感兴趣，并获得他们的支持，比如帮助你找到另一个有同样多开发和测试人员并维护另一个生产系统的开发团队作为对照组，并获得那个开发团队负责人的支持。而你所在的团队，可以作为实验组。

由IT部门负责人、运维团队负责人、测试团队负责人和实验组与对照组这两个开发团队负责人，五人成立实验小组。

为了让实验结果不会因为实验组和对照组两个开发团队的开发和测试人员，因相互攀比而有损数据的准确性，该实验从始至终秘密进行。即实验的事情，只有实验小组的那五人知道。若其他人问起实验过程中一些事情的缘由，可以编一个理由。总之不要透露正在开展的实验和实验意图。

在实验开始前，两个开发团队的负责人，需要与运维团队负责人协作，保证可以观测两个团队各自所维护的生产系统的两个指标，即观测崩得少的平均停机间隔时长 (MTBF, Mean Time Between Failures)，以及观测修得快的平均停机恢复时长（MTTR, Mean Time To Recovery）。

对照组对于开发和测试人员的岗位名称保持不变。对照组团队负责人在实验开始前一天，召集所有开发、测试和运维人员，向他们明确一下三个团队的主要职责，即开发团队负责设计、编码和自测，测试团队负责功能性和非功能性测试，运维团队负责上线、监控、排障、升级、安全、备份。

实验组团队负责人，就是你，在实验开始前一天，召集所有开发、测试和运维人员，向他们宣布，针对本团队所维护的生产系统，开发和测试人员的岗位，分别改名为系统红军和系统蓝军。并告诉他们，系统红军需要对所设计和编写的软件特性在整个系统中正常运行负全责，而系统蓝军需要从整个系统的角度模拟现实生产环境各种刁钻的场景来考验系统红军所设计和实现的软件特性，能否正常运行。因为红蓝军都要使用生产环境，所以运维人员可以根据红蓝军的需要，分为两组，分别加入系统红蓝军。

设置一个开展实验时间段，比如半年。两个团队同时开展实验，并同时采集数据MTBF和MTTR。

每2个月作为一个迭代。实验小组在迭代末就开一次碰头会，分析和对比这2个月采集的观测数据。

6 根据实验结果可回到第3步不断迭代优化假说/预测/实验过程

到半年后结束，总结和对比这3个迭代实验组和对照组的数据。根据实验数据，看看是否支持第4步的预测，并决定是否回到第3步，改进假说、预测或实验过程。

如果在实验的设计和执行中遇到问题，欢迎在评论区留言，与我交流。非常欢迎你把实验的步骤、过程和结果分享给我，以便一起改进这个实验。我会在这个实验的将来的版本的致谢段落，署上你的名字和你所做的改进。

如果觉得本文对你有帮助，欢迎点赞，并转发给其他志同道合的小伙伴。你觉得更好地应对生产系统稳定性意外故障，还有什么其他好办法？你还希望我聊有关做软件的其他什么新话题？欢迎在评论区留言。我会仔细阅读每一条留言。期待听到你的声音。

企业生意好，系统运行稳。你所阅读的文章，来自“吾真本说混沌工程”知乎专栏。