使用混沌工程增强API的可恢复性

语言开发

摘要： Gremlin团队在博客上给出了一种简单的混沌实验，可用做验证一个组织的API是否具有可恢复性的方法。与适当地使用此领域中涌现的商业和开源工具一样，使用混沌工程的原则以及运行“游戏日”（可看成是IT系统和人员的消防演练）等技术同样可体现出自身的价值。

作者： Daniel Bryant

正文：

Gremlin团队在博客上给出了一种简单的混沌实验，可用做验证一个组织的API是否具有可恢复性的方法。与适当地使用此领域中涌现的商业和开源工具一样，使用混沌工程的原则以及运行“游戏日”（可看成是IT系统和人员的消防演练）等技术同样可体现出自身的价值。

在这篇由Gremlin首席站点可靠性工程师Tammy Butow撰写的博客帖子中，一开篇就指出，尽管很多组织通过基于Web的API提供自身的服务（以及提供核心商业价值），但是从作者的经验看，这些API及相关的架构常被看成是“二等公民”。随着组织规模的扩张，这种方式存在着一些风险，例如可导致用户体验降级的API层失败，甚至是非常严重的事故。在与之相关的运行模式中，增加API的使用将会增大相关后台系统的压力，并且由请求数量增加而产生的负载可能并非与性能和可靠性呈线性关系。因此，工程师应该制定并运行一些试验，了解负荷增加、系统退化和基础设施失效的影响情况，并最终设计出可降低风险的系统。

Butow建议，使用“混沌工程”原则和“游戏日”是形成上述理解并设计实验的最好方式。对于不熟悉“游戏日”概念的读者，Adrian Cockcroft在QCon旧金山大会将其比喻为“IT领域的消防演练”。出乎意料的应用行为或架构失败，常会导致工程师的人为介入，这会使情况变得更糟。在日常生活中，消防演习可训练人们接受如何应对火灾，进而在真正发生火灾的情况下挽救生命，IT游戏日发挥了同样的作用。

该Gremlin博客帖子中，给出了一个针对典型API网关重度负载情况的例子脚本，并介绍了如何使用Gremlin的“可恢复服务”SaaS商业平台实现在运行API网关的计算实例上注入失败（例如，高CPU或内存使用率，或者完全终止）。Butow在博客帖子中强调指出（她同样也曾在先前的QCon伦敦大会演讲中提及），在开始运行混沌实验之前，对监控和可观察性的需求是至关重要的。

“在着手测定API可恢复性之前，你应该做的一件事情就是在一致的基础上运行混沌实验。确保你具有良好的可见性（监控），并增加回退覆盖率，所有这些将有助于强化你的系统。”

混沌工程原则正逐渐被主流大众所采纳。这一方面是在Gremlin等商业混沌工具和服务业务的驱动下，另一方面的驱动力也来自于一些该领域的先驱者（例如Netflix，早期chaos monkey的创立者）、一些由社区牵头的工作（例如Chaos Toolkit）以及一些企业组织（例如Expedia和Bloomberg。后者发布了专用于Kubernetes的开源混沌工具“PowerfulSeal”）。

随着混沌工程日渐广为采用，这正引导组织考虑是否应构建或购买相关工具，Gremlin团队推荐工程师应在一些权衡上做出考虑，包括：构建自身混沌实验平台的TCO（总体拥有成本，Total Cost of Ownership）、将内部系统暴露给外部SaaS平台的能力（以及可取性），以及团队当前技能集及团队在平台路线图方面对控制的需求。一些领域引领者，例如Adaptive Capacity Labs的联合创始人John Alspaw，也提醒说不应忽视可恢复工程中人的因素，这事实上要比相关的工具更为重要。

更多信息，提供在Gremlin官方网站上，首届混沌大会将于2018年9月28日在旧金山举行。

查看英文原文： Increasing the Resilience of APIs with Chaos Engineering