崩后的B站，适合执行混沌工程实验

前天晚上，B站因为部分服务器机房发生故障，造成一段时间内无法访问。

虽然B站进行了“高可用架构”实践，但在充满“暗债”的非线性的分布式复杂系统面前，再次印证了“暗债本固有，不信有好事。”

好在几小时之后，服务恢复。这次故障再次印证了“虽然生产故障无法避免，但只要能提升快速修复的能力，那么就能增强我们对系统的信心。”

而对于那些对自己所开发和维护的系统，能否在生产环境长期稳定运行缺乏信心的团队，可以考虑实践混沌工程，以持续探索和快速修复未知生产故障，提升信心。

执行混沌工程实验（以下简称“混沌实验”）的团队，一般具有以下特点：

1. 软件开发团队（以下简称“团队”）所开发和维护的软件产品（以下简称“产品”），是一个具有分布式特点的复杂系统

2. 产品会依赖多个外部系统，这些外部系统可能由本公司其他团队开发和维护，或者由其他公司开发或维护

3. 团队的领导、业务、开发、测试、运维人员，以及本公司与该产品相关的其他团队，都能认同混沌工程的价值，即有助于持续探索和快速修复未知生产故障，并能抽出时间，投入必要的混沌工程学习与实践

4. 团队所在的公司，具有“积极对生产事故进行学习和分享，从而促进持续改进相关过程与工具，而非针对事故而相互指责人”的企业文化

5. 产品已经部署到生产环境，并已经发布给真实用户使用

6. 团队对产品能否在生产环境长期稳定运行缺乏信心

7. 产品具有与生产环境近似的，用于在上生产前验证产品的“准生产”环境（以便在生产环境的混沌实验之前，验证混沌实验过程本身）

8. 产品具有基础设施和业务应用层面的可观测性工具，可以方便地观测和记录产品的监控、日志、指标和链路追踪数据

9. 团队各相关角色，了解混沌实验全过程，并有主持人引导大家完成混沌实验

10. 团队在进行混沌实验前，已经基于分布式系统稳定性设计模式，对待实验的系统的相关模块，进行了稳定性设计和评审

11. 团队已经完成了混沌实验及其实验过程的设计和评审（邀请相关外部系统的专家），包括设计了“最小化爆炸半径”、“大红按钮”（以便在必要的情况下快速中止混沌实验）以及相关数据的清理和回滚，并具备基础的应对故障的能力

（感谢Thoughtworks公司同事乔桃利、赵瑞华、杨旭东、张薇薇、何耀文、余晟对本文提出建议）