在最简单的C/S模型当中，一次网络通讯会发生这样的过程：
1.客户端将消息发送到网络上。
2.网络向服务器发送消息。
3.服务器验证消息。
4.如果需要，服务器更新其状态。
5.服务器将回复发送到网络上。
6.网络向客户端发送回复。
7.客户端验证回复。
8.如果需要，客户端更新其状态。
在这个过程中可能发生的所有故障排列是令人难以置信的。例如，网络随时可能出现故障，数据存储可能出现故障或过载，或者验证逻辑可能失败导致应用程序崩溃。应对这一挑战的传统方法是测试。但是测试解决的问题常常是在有一个期望结果的前提下，通过断言来验证已知条件，例如结果是否是我们期待的，函数结果返回是否正确。
但随着分布式系统变得越来越复杂，测试已经达到极限。它通常无法解决生产环境的复杂性，例如发生在网络上的随机故障和其他奇怪的间歇性错误；配置限制和配置漂移；未知的呢？你怎么能测试你不知道的东西？
例如，在实例动态启动和停止的系统中，如果任何实例磁盘空间不足会发生什么情况？如果一个实例没有剩余空间来写入日志，它在大多数情况下会快速失败，这是一个真正的问题，因为快速失败会产生一个黑洞。因为它失败得很快，通常会欺骗负载均衡器，认为该实例可以自由地接收更多请求，而这反过来也会导致更多的失败。
如果我们能更早地发现这一点，我们就可以事先进行改进并避免中断。例如：
1 — 使用日志轮换。
2 — 使用集中式日志服务。
3 — 监控磁盘空间。
4 — 在每周运营会议上审查指标。
5 — 当设备上只剩下 10% 的磁盘空间时发出一些警报。
幸运的是，有一种实践可以帮助解决这种未知数——正如你可能猜到的，混沌工程。
......
查看更多精彩内容，请点击下载：
版权声明：本文出自《51测试天地》第六十四期。51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
