不能用断言检查运行时错误_健康检查，运行时断言和猴子军

不能用断言检查运行时错误

上线后，我们开始在系统中进行运行状况检查–运行时检查操作依存关系和状态，以确保系统已正确设置并运行。 随着时间的流逝，当我们遇到问题时，我们继续添加更多的运行时检查和测试，以确保这些问题不会再次发生。

这不仅仅是ping和Nagios警报。 这是在测试我们是否在系统之间安装了正确的代码和配置。 检查代码构建版本号和数据库架构版本。 检查文件上的签名和校验和。 应该打开或关闭的标志和开关实际上是打开或关闭的。 提前检查许可证，密钥和证书的有效期。

通过系统发送测试消息。 检查警报和通知服务，确保它们正在运行，并且应该运行的其他服务正在运行，并且应该运行的服务没有运行。 应该打开的端口是打开的，应该关闭的端口是关闭的。 检查以确保应有的文件和目录在那里，应有的文件和目录没有，应为空的表为空。 在控制文件和目录上正确设置了该权限。 检查数据库状态和配置。

检查以确保生产和测试设置为生产和测试，而非测试和生产。 检查诊断和调试代码是否已禁用。 检查开始和结束记录计数和序列号。 检查“作业”中的伪像-结果文件，控制记录，日志文件条目-并确保清理和设置任务成功完成。 检查运行时存储空间。

我们在启动时（或有时在启动前的早期，发行或升级后，故障转移后）运行这些运行状况检查，以发现错误，操作问题和环境问题。 这些测试需要快速运行并返回明确的结果（一切正常或不正常）。 它们可以是在生产环境中运行的简单脚本，也可以是在应用程序代码中进行内部检查和诊断的脚本，尽管脚本更易于适应和扩展。 有些需要将挂钩添加到应用程序中，例如JMX 。

运行时断言

像Etsy这样的其他公司也使用运行时断言来做类似的事情，使用单元测试方法来检查系统正常运行所必须具备的条件。

这些测试也可以（并且应该）在开发和测试系统上运行，以确保运行时环境正确。 这样做的目的是摆脱手工检查，操作检查表，日历提醒和手动测试的麻烦。 任何具有依赖项的东西，任何需要手动检查或测试的东西，操作清单中的任何东西都应该具有自动运行时检查。

猴子军队

相同的想法是在Netflix过度宣传（尽管并非总是由Netflix推出 ） Simian Army的背后， Simian Army一套机器人不仅检查运行时条件，而且有时在违反运行时条件时甚至会自动采取行动-甚至违反运行时条件以测试系统仍将正常运行。

军队包括Security Monkey ，它检查配置不当的安全组，防火墙规则，过期的证书等。 漏洞利用猴子（Exploit Monkey），在启动新实例时会自动扫描这些漏洞。 Conformity Monkey将运行时检查发挥到了极致，关闭了不符合既定策略的服务，而著名的
Chaos Monkey ，它会在测试和生产中自动强制系统出现随机故障。

令人惊讶的是，Chaos Monkey获得了如此多的关注-也许这是一个很酷的名字，或者是因为Netflix与其他猴子一起开源了它 。 确保通过在白天实际杀死系统来测试生产中的故障转移，即使它们是无状态的VM实例，这些实例在设计上应该无故障地进行故障转移（尽管这是关键，以确保它们确实进行了无故障的虚拟机转移，例如它们应该是）。

Netflix的成功不仅仅在于运行时故障注入和其他猴子。 尽管如此，在工程驱动，快速变化的Devops或Noops环境中 ，开发人员将代码投入生产的速度太快而无法正确地事先理解和验证，在运行时尽可能多地自动检查仍然是非常重要的。 但是，无论您是否继续将更改（例如Etsy和Netflix）部署到生产中，让开发人员，操作人员和Infosec在一起编写自动化的运行状况检查和运行时测试是控制系统中实际发生的事情的重要组成部分，保持其可靠运行。

参考： Building Real Software博客上来自JCG合作伙伴 Jim Bird的健康检查，运行时断言和Monkey Armies 。

翻译自: https://www.javacodegeeks.com/2012/11/health-checks-run-time-asserts-and-monkey-armies.html

不能用断言检查运行时错误