软件架构治理也是一样，既需要解决现在的问题，也要为未来的扩展留有可能性。软件架构治理并不是一项单纯的技术工作，治理工作需要考虑到现在的问题，也需要考虑到未来的业务发展，单纯的从技术角度来思考软件的架构治理无疑是在雪上加霜。即便是倡导技术驱动的公司，本质上也是通过创新技术创造了新的业务，改变了人们的生活方式，从而用技术改变了世界。只有找到真实的业务价值，才能把技术的价值发挥到最大，因此 软件架构治理一定是问题或价值驱动的 。
架构师在实际做架构治理的过程中，一个难点是当系统复杂度高到超出个体认知上限时，就很难看清系统问题全貌，只能从已知问题入手。然而，已知问题往往只是冰山一角，随着系统复杂度上升，很多随机的、不可预测的问题经常发生，这种问题有些是很难重现的，每次表现也不完全一样，在这种场景下，如何能有效发现系统根本的脆弱点，防患于未然，就是一个很大的挑战。
混沌工程
为了解决软件系统复杂后的稳定性问题，近几年，混沌工程作为一种以实验来提升软件系统韧性的学科，开始逐渐在众多大企业中开始实践起来。混沌工程的概念由来已久，为什么最近几年才被大家越来越多地提及，才开始变得流行呢？我觉得原因有以下几个：
- 开源工具的发展和完善，让大家应用混沌工程实验的成本降低。
- 最近几年因为互联网业务的发展，微服务架构等技术的流行，软件系统的复杂度在不断提升，已远远超出人类能够记忆和认知的范围，定位问题成本越来越高，而混沌工程通过实验的方式能够快速帮助架构师找到架构上的问题。
- 提升了研发团队对软件系统的理解，道长在他的文章《混沌工程赋能：规模化地应对上云后的未知暗债》中提出混沌工程是一种赋能活动，可以帮助开发团队理解复杂系统是如何运行和如何失效的。
那么混沌工程到底是怎样一种实验？是不是我们把各种猴子扔到生产环境中，让它们随机的搞一些破坏，看哪里出问题就修哪里？答案显然是否定的，试想如果随便扔几只搞破坏的猴子在生产环境，不可预知到底会发生什么问题，这无疑是一种自杀式的实验，任谁也不会放心大胆地去进行这样一种实验。
混沌工程实验并不是盲目的，也不是试探性的，它一定是有目的的，可控的一种实验。在混沌工程原则的网站上，定义了应用混沌工程的几个高级原则：
- 建立一个围绕稳定状态行为的假说
- 多样化真实世界的事件
- 在生产环境中运行实验
- 持续自动化运行实验
- 最小化爆炸半径
在第1个原则中，首先要定义一种可测量的稳定状态，并依据团队对系统的理解，定义一个假说：在某种故障发生时，系统依然能保持这种稳定状态。这里的关键点在于稳态假说，如果已经确定当故障发生时，系统一定无法保持稳态，那就没有必要进行实验了，而需要针对当前的问题去想对策。
接下来的4个原则描述了如何具体实施混沌工程实验：
- 要模拟真实的事件，以确保实验结果的可靠性
- 要尽量在生产环境中实验，以避免不同环境的差异（数据量，数据多样性，网络环境，并发请求数量等等）产生的影响
- 要把实验过程自动化并持续执行，自动化以降低每次执行的成本，持续运行以便能够在有问题时及时发现
- 要做到最小化爆炸半径，确保每次实验的影响范围都是可控的，而且是最小的
在软件架构治理中应用混沌工程
回到软件架构治理的话题上，既然混沌工程可以帮助架构师以及开发团队更好地理解系统，发现系统的弱点，那么应该如何应用混沌工程，提高研发团队对架构的掌控力，找到架构设计的问题，并加以治理？
首先 ， 要对软件系统进行一次整体的盘点：有哪些组件（比如微服务、数据库、缓存等），运行环境如何（网络，VM/主机，存储等），三方依赖等等。
其次， 针对系统中的这些组件，进行优先级的排序，通常可以按下面的方式定义优先级：
- 基础设施环境相关，基础设施出问题，往往都是大问题
- 三方集成系统相关，集成系统不可控，一旦出问题，处理不好影响非常大
- 自研的各个组件，自研组件受控性最强，往往问题发生后修复起来更快
基于以上的优先级，可以再根据业务的影响范围，在每个层级里进行进一步的优先级定义。
最后 ，根据上面定义好的优先级，逐一定义稳定状态假说，并判断是否需要进行混沌工程实验，如果有必要，需要设计完整的实验过程和恢复方案，控制好实施范围，如果前期信心不足，可以先在非生产环境尝试，等信心足够时，再放到生产环境自动执行。
