混沌工程在医疗保健领域应用：从敏感的工作负载入手

本文要点：

• 虽然混沌工程是一种已被证明可以提高系统弹性的技术，但当涉及到关键系统时，涉众通常不愿意引入这一实践。
• 对于关键系统，最好首先在开发/测试类的环境中进行实验，将实际风险和感知风险都降到最低。当你从这些早期实验中了解到新东西时，你可以向涉众解释说，生产环境是一个更大、更复杂的环境，可以进一步从这种实践中获益。
• 使用真实的生产流量，而不是合成作负载，可以提高这些在早期阶段进行的实验的有效性。
• 良好的混沌工程实践可以帮助你提高系统的弹性和事件发生时的可观测性。

近年来，人们对混沌工程越来越感兴趣。它定义了一种有价值的实践，通过接受系统将会失败的事实来提高系统的可靠性。虽然关于如何应用这种方法的文献和讨论比比皆是，但当系统被视为“关键”系统或太重要而不能失败时，人们往往就会产生犹豫。尽管在关键系统中应用此方法可能有更令人信服的理由，但是可以预见，这些系统的涉众对任何可能增加风险的新事物都很敏感。在本文中，我将分享我们Cerner公司（一家医疗保健信息技术公司）的团队在我们的系统中引入这一实践时找到的一种有效的方法。

组织工作

在你开始尝试开展这些类型的实验之前，你希望确保系统涉众就这个方法达成了共识。这在早期阶段是很重要的，因为你的一些发现可能会改变你的软件交付时间表。你希望确保他们理解这个开发过程中新增加的部分，并且这些发现可能比其他计划好的开发工作具有更高的优先级。这就像在生产事件中发现的可靠性问题优先于其他计划好的特性。你通过混沌测试发现的问题可能同样重要，但你是主动发现它们，而不是在实际的事件中被动地发现它们。

在准备引入这些类型的实验时，你需要确定最初关注哪些系统组件。为了尽量减少涉众之间的沟通成本，让这些组件的所有者参加最初的会议是很有帮助的，这样他们就可以理解要实验什么以及为什么要做这些实验，这样你就可以得到他们的全力支持。就像任何新事物一样，最简单的做法可能是同意在第一次实验中与他们合作，这样他们就可以密切参与其中，从而看到其中的价值，并就如何继续参与最好提供反馈。这通常是有价值的，因为他们可以立即就观察到的系统行为提供信息，而不是必须记录这些基本的细节并提供最初的反馈。让他们参与实验，他们就能够在发现问题的时候更深入地分析他们的组件，这个时候收集额外的细节最有效。

识别引入混沌工程实践的安全点

对于关键系统，最好首先在开发 / 测试类的环境中进行实验，将实际风险和感知风险都降到最低。当你从这些早期实验中了解到新东西时，你可以向涉众解释说，生产环境是一个更大、更复杂的环境，可以进一步从这种实践中获益。同样，在将类似这样的东西引入生产环境之前，你需要确信你有一种安全的方法可以使用，这种方法允许存在令人惊讶的新发现，而且不会引入额外的风险。

下一步，考虑在一个新的生产环境中运行混沌实验，在处理实时流量之前使用生成的合成负载。这样做的好处是可以在生产配置下开始测试系统的一些边界，有利于其他利益相关者理解这将如何被应用，它不会增加客户的风险，因为还没有处理实时流量。

要开始引入比从合成流量获得的负载更真实的工作负载，下一步可能是利用现有的生产流量。在 Cerner，我们构建了一个流量管理功能，可以将传入的请求回放给另一个系统，生成一种“影子流量”。这种能力被内置到了我们的 API 网关中，用来处理进入我们系统的流量。在考虑影子流量的候选时，你希望确保请求能够安全地重放。你可能会想到只读类型的请求，它们是很好的候选，但对于敏感的工作负载，即使是读取操作也可能有副作用。例如，从服务发出事件以支持报警系统。在确定候选流量时，你需要了解如何控制系统中有问题的副作用。

将流量标注为影子流量的能力会有助于稍后的实验。例如，如果系统中的一个影子请求失败了，你不一定希望将其添加到服务的总体生产指标中（如故障率），因为在这些实验期间，当影子请求失败时，你可以向该服务的所有者发出告警，这些请求失败也许是可以接受的。能够标注和控制单个请求，可以为你提供合适的粒度级别来管理这些副作用并度量它们的行为。而且，在应用影子流量方法时，在流量上有统一的相关标识符（例如 Correlation-Id HTTP 头）是很有价值的，因为它为你提供了一种可靠的方法，让你可以通过比较处理实时流量的系统和处理影子流量的系统来比较两个系统的执行情况。因为你可能只能安全地向其他系统重放一组特定的请求，所以在不知道应该比较哪些流量的情况下，你无法准确地应用行为的聚合比较（例如，故障率或 99 百分位响应时间）。通过使用相关标识符并知道哪个请求针对哪个系统，你可以比较系统的行为。

使用影子流量，你可以开始向另一个系统重放流量，该请求可以失败，但又不影响请求源。这样的设置是开展这类实验的有效方法。这让你在系统上线后可以继续进行这种类型的测试，因为通过控制系统中的流量流，你就能够控制这些实验的风险。

开展实验

在进行实验时，你希望开始的时候可以保持简单，并额外预留出时间来有效应对任何未知的意外。例如，如果你认为做实验需要两个小时，那就安排整个下午。如果你用不完这么多时间，那没问题，但是你不想因为时间限制而被迫提前结束。如果有一个中心位置用于记录这些实验，以便其他人可以发现和学习，这会很有帮助。在这个中心位置上，你将在开展实验之前制定场景计划并预测行为。在观察行为之前获取到你所期望的内容是有价值的，因为你经常会对实际行为感到惊讶。

在早期，当向系统注入故障时，你可能没有实现多少自动化。常见的例子是手动关闭服务。这可能是物理基础设施，也可能是关闭运行系统的虚拟机。因此，当你有多个人协调实验中的任务时，确保沟通有一个中心位置是很重要的。这可能是让每个人都在同一个聊天中，并确保他们的日历已被屏蔽，这样他们的注意力就不会被吸引到别的地方。让每个人都参与到同一个聊天中来，也有助于捕捉实验事件的时间线。这有助于关联事件和重要发现，如系统从故障中恢复的总时间。利用可以向实际的使用者快速说明实验影响的工具是很有价值的。 Vegeta 是一个简单的 HTTP 负载测试工具，你可以使用它来生成合成流量，在你的控制台上通过实时图表快速显示客户端体验。捕获客户端指标很重要，因为只查看服务器端指标，可能会与总体体验存在差异。例如，如果你注入一个只影响客户端应用程序的网络故障，那么你可能会错过这样一个事实：特定的请求甚至没有到达你的系统。在做这些实验和评估影响时，能够轻松生成流量和可视化效果是很有帮助的。此外，这避免了生成错误率或延迟图表的任何额外工作，因为该工具可以在实验期间实时地提供这些。

改进系统

这些实验的结果往往不符合你的预期。有时候，其行为与你最初所认为的非常相似，实验的主要结果就是你获得了关于系统实际行为的知识。在其他情况下，你可能会发现一些你想要在进行其他实验之前解决的问题。如前所述，你要确保这些发现很容易添加到团队的待办事项尽快解决，而不是以后解决。原因是你希望在这些实验中提供快速反馈循环，否则它可能会导致不必要的冲突。

能够快速、轻松地更改在系统中构建可见性的方式是很有价值的，这样当遇到意外情况时，你就能够借助附加到给定组件的可见性重复实验。这样做的次数越多，你就越能更好地优化你的可观测性系统，捕获必要的上下文，最终达到不需要再更改的程度，因为你已经能够回答许多常见的初始问题集。在 Cerner，我们在很多产品中使用 New Relic 作为我们的可观测性平台，而 Splunk 用于日志聚合。配置调优可以通过公共容器构建流程集中完成。当我们发现可见性方面的改进时，比如在日志中添加上下文，就可以在一个可供系统其他部分利用的位置完成。

分享价值

当你开始发现问题并基于这些实验改进你的系统时，你希望确保其他人理解这是怎么产生效果的。通常，许多参与实验的主要涉众已经意识到了好处。他们看到了这些故障下的系统行为，我们学到了什么，以及如何应用改进。然而，对于没有参与实验的涉众来说，包括领导团队在内，他们可能看不到这项工作的价值。领导层经常能看到生产事故，但当事故得以避免，他们可能不总是能听说。

为了解决这个问题，把实验记录在一个故事中，把最新消息共享给领导层，比如发现了什么，如何发现的，对客户的影响是什么，以及采取了什么措施来解决。在通常情况下，这个故事被界定为一种主动性方法，当你准备系统并为意外的失败做好计划时，你已经降低了客户的风险（或者至少将其保持在最低水平上）。因此，当你能够分享团队如何在不影响客户的情况下学习和改进系统的故事时，继续使用这些方法就成为了一个明显的选择。在可能的情况下，可以将一项发现与过去的生产事件（可能更容易被涉众记住）进行比较，进一步增加这些故事的分量。通过主动寻找系统中的这些故障边界，分享如何发现和避免这些东西，通常，这会让更多的人对这些方法产生兴趣，因为主动性方法提供了一种控制感，胜过源于生产事件的被动性方法。这种方法提高了团队诊断和排除生产问题的能力。可观测性的提高和对系统的了解，为团队在未来处理不同的事件做好了准备。

总结

改变从来都不容易，特别是涉及到生产环境中敏感的工作负载时。通过为团队提供一种识别和解决系统可用性风险的主动性方法，混沌工程方法可以为你的系统带来显著的价值。通过早期与这些系统的涉众一起工作并分享这项实践的价值，你就可以获得良好的势头，帮助你将此方法从早期环境应用到实际的生产系统。

作者介绍：

Carl Chesser是 Cerner 公司的首席工程师，该公司是全球医疗保健信息技术的领导者。他职业生涯的大部分时间都专注于为 Cerner 核心电子病历平台 Millennium 改进和扩展服务基础设施。他热衷于在 Cerner 打造一种积极的工程文化，并且是黑客马拉松、聚会和技术演讲的组织者。在业余时间，他喜欢撰写工程方面的博文，分享他粗制滥造的插图。

原文链接：

Applying Chaos Engineering in Healthcare: Getting Started with Sensitive Workloads