来自于 PagerDuty 的 Doug Barth 在伦敦的 DevOps 日上谈论了他们是如何在前期没有投入大量自动化努力的情况下开始弹性化测试自己的系统的。他们的目标是快速地了解错误点，然后每周拿出一个小时的时间公开讨论如何解决这些错误。
在 PagerDuty，自动化错误测试要实现和 Netflix 著名的 Simian Army 同样的覆盖范围是不可能的，原因是他们的多云环境以及自己所投资的内部自动化工具对最初结果的延迟。因此他们选择了人工的失败测试方法，绰号为“失败的周五（Failure Friday）”。该方法的内容就是每周五拿出一个小时的时间来设法制定一个“攻击（attacks，引发失败的问题）”列表，同时检查“受害者（victim，被测试的系统）”是如何反应的。
在攻击期间，系统会被恢复到正常的工作状态。如果系统被破坏的很严重，那么攻击就会停止，例如在失败之后发送给受害者的请求不会被其他的服务实例获得。在这种情况下，会话会被停止同时系统会被人工地恢复。下一个周五会对永久性的修复进行测试。否则的话攻击就会持续，直到长达一个小时的会话结束。
攻击策略很多，从快速失败的模拟（例如停止一个 Cassandra 数据库实例或者重新启动一个服务器实例）到更复杂的网络隔离（配置错误的 IP 表丢失进入一个特定端口的包）或者运行缓慢节点（使用 netem 的网络仿真）的模拟。
解决系统中的问题同时提高大家需要对错误进行处理和测试的意识是这样做的一些可预期的好处。但是 Doug 还强调了一些意想不到的好处，例如在发现了暴露的问题并理解了引发失败的原因之后，我们就能够减轻增加新的随叫随到的人（开发或者运维人员）的压力，这与等到不会引发错误的那些很有可能会过时或者不精确的理论知识截然相反。另一个计划之外的收益是，这样能够揭露模拟组件失败的困难，进而导致系统架构产生提高整体可测试性的变化。
Doug 提到，在实际的组织中保持日志和操作时间、发现和跟踪问题以及分享仪表盘和指标的重要性。他还推荐大家在会话期间不要关闭警报，因为这样不仅能够检查监控是否在按照预期正常运行；同时还能够将攻击会话通知所有人，避免引发的错误导致警报升级。
查看英文原文： Testing Resiliency at PagerDuty Without a Simian Army
暂无签名
Java 避坑指南：Java 高手笔记代码篇
本迷你书包括 86 个业务开发中常见踩坑点。每一个知识点都相当的实用，是程序员业务开发中的必备避坑指南...
评论