混沌工程：让云原生工程师更贴近用户

云原生技术的演进以及工程规模扩张的需求都在促使组织重组他们的团队，并拥抱新的架构方式，如微服务。这些变化使团队能够对他们交付的内容具备端到端的所有权，并增强了他们的敏捷性。

这种演进带来的一个结果就是，现在的工程师能够更接近产品和客户需求，但是依然还有很长的路要走，公司依然在想法设法让工程师更靠近客户，深入了解他们所带来的业务影响是什么：他们解决了什么问题，给客户带来了什么样的影响以及对产品有什么影响？工程师的思维发生正在发生变化，他们逐渐意识到：我们交付的是产品，而不仅仅是代码。

更大的权力伴随着巨大的责任

我们乐于见到这种转变，这会给采用这种方式的公司带来许多好处。另一方面，随着团队和系统规模的扩大，编写新特性以解决特定的业务问题变得更具挑战性，显然，要理解服务的行为也变得更为复杂。

当讨论微服务面临的挑战以及如何转换至该架构时，我通常会参考一个很棒的演讲，也就是 Aviran Mordo（Wix）在 GOTO 2016 会议上做的题为“Journey from Monolith to Microservices & DevOps”的演讲。

这种先进的方式带来了巨大的价值，但是作为工程师，我们所编写的应用是一个更广阔的服务集合的一部分，这些服务建立在云端的某个平台之上。正如 Ben Sigelman 在其最近的博客文章和演讲中，将其称为“深度系统”，一图胜千言，下图展示了它的全貌。

随着不断转换至更加云原生、分布式的架构并且越来越依赖编排器（如Kubernetes），工程师们面临越来越多的挑战。仅举一例，当待命（on-call）过程中遇到某种事件时，我们必须要迅速识别出根本原因，或至少要快速修复，这通常需要一套不同的专业知识（例如，由于集群中缺乏可用的节点，我们的部署有 33%的可能性无法重新调度）。

工程师演进概览

作为一名云原生工程师是非常有趣的，但也很有挑战性。如今，工程师们不仅需要编写代码和构建软件包：按照期望，他们需要知道如何编写相关Kubernetes资源的YAML文件、使用HELM、容器化应用并将其交付到各种环境。但是，知道这些依然是不够的。作为云原生工程师，还需要不断调整对所依赖的云原生技术的认识和理解。除了正在使用的工具集，构建云原生应用还涉及到很多不断变化的组件，比如我们所依赖的平台、所使用的数据库等等。显然，有一些很优秀的工具和框架，它们能够帮助工程师抽象出一些的复杂的东西，但是对它们视而不见可能会让你在某一天（或某一个深夜）付出代价。如果你还没有听说过“分布式计算的谬误”，那么我真心建议你进一步了解相关的内容。如今这些问题依然存在，我们需要注意它们并为此做好充分的准备。

我们采取了哪些举措来应对这些挑战呢？

我们使用混沌工程来达成这一目的，并创建了一系列名叫“像国王一样待命（On-call like a king）”（猜测该名字的灵感来源于一款名为“LIKE A KING”的塔防游戏——译者注）的工作坊。我们发现这种方法非常有用，我认为分享一下我们的实践是一件不错的事情。

混沌工程的主要目标在于：混沌工程是在系统上进行实验的学科, 目的是建立对系统抵御生产环境中失控条件的能力以及信心。

混沌工程的理念就是识别在构建分布式系统时的弱点并减少不确定性。正如我在前文所述，构建大规模的分布式系统是很有挑战性的，因为这种系统通常会由很多不断变动的组件组成，利用混沌工程能够减少这种失败的爆炸半径，这种办法已经被证明行之有效。

我们利用混沌工程还实现了其主要目标之外的收益。“像国王一样待命”工作坊计划同时实现两个目标：（1）向工程师培训最近遇到的生产环境故障；（2）培训工程师掌握云原生实践和工具，并成为更好的云原生工程师！

工作坊的课程是由哪些内容组成的？

1. 课程首先会快速介绍一下动机，明确我们为什么需要这个课程，这次我们需要做些什么，并且确保所有的听众在流程上保持一致。

1. 有时候，我们将课程作为一个很好的机会来交流最近架构、平台和流程的变化，例如对待命流程和更新或核心服务流程的调整。
2. 我们会对生产环境的两个事件进行模拟，整个课程不应该超过两个小时。我们发现，如果时间更长的话，工程师的注意力就会下降。如果是混合类型的工作的话，最好在同一个工作区域完成这些课程，我们发现这样会更加高效。

在进入具体的课程之前，我先介绍一下我们是如何待命的。

我们每周会有一次工程轮班并且 NOC 团队会 24/7 监控我们的系统。我们定义了三个告警的严重等级，分别是 SEV1、SEV2 和 SEV3（从紧急到监控状态）。如果是遇到 SEV1 级别的告警的话，首要任务是让系统回到正常状态。待命的工程师要领导事件的处理，理解高层次的业务影响并进行沟通，如果需要特定的专家才能将系统恢复至正常功能状态，工程师要确保相关的团队和服务所有者能够尽快就绪来解决问题。

我们的“像国王一样待命”工作坊课程通常会在某个环境中模拟真实的生产场景，尽可能接近真实的生产场景。这样真实的场景能够让工程师在处理真正的生产环境事件时有充分的信心。由于我们在这里使用了混沌工程，所以我建议执行一个真实的实验，我们使用一个负载测试的环境实现这一点。在这个过程中，我们使用LitmusChaos来运行混沌实验，但是你可以使用任意喜欢的工具，或者直接手动模拟事件。我们最开始的时候，就是手动的，不要迫不及待地使用特定的混沌工程工具。你要相信，当他们开始实践，而不仅仅是听别人解释时，课程才会变得非常高效。

在简介部分的幻灯片结束之后，我们的课程会继续以幻灯片的形式阐述要模拟的事件。我们通常会给出要发生事情的背景介绍，展示当前行为的一些指标以及刚刚触发的告警：

随后，我们会给工程师一些时间，让他们自行回顾这个事件。我们会不时地暂停他们的分析，并鼓励他们提出问题。我们发现，对事件的讨论是进行知识分享的绝佳地点。

如果这些人能够坐到一起，那么这非常好，因为你能够看到每个人都在做什么，然后你可以要求他们展示使用了哪些工具，以及是如何使用的。

在这些课程中，我非常喜欢的一点在于，它会引发对话，工程师们会告诉彼此在调试事件的过程中，都用到了哪些 CLI 或工具，从而使他们的生活更轻松。

我们可以通过提问来推进对话的进行，这能够让你分享一些想要培训的主题，比如，邀请工程师介绍要观察的指标仪表盘，邀请工程师分享他的日志查询，或者邀请其他的工程师介绍他的跟踪信息以及如何找到这样的跟踪信息。

有时候，你需要适当调整对话，因为时间过得非常快，需要把焦点及时拉回来。

在讨论的过程中，我们可以指出希望工程师了解的有趣的架构信息。鼓励工程师发言，就这些感兴趣的方面提出问题，使他们能够提出新的设计方式，或者分享他们最近在思考的挑战，并将它们添加到技术债务中。

在每项挑战的最后，邀请某位工程师介绍他们的端到端分析。这能够让那些在这种大型讨论中不能自如提问的人，如刚刚入职的工程师、或者只是想了解更多信息的初级工程师，对整个过程更加清晰。

请确保对整个会议进行记录，并在会议结束后立即分享会议记录。这是一个很好的资源，可以提醒人们都做了些什么，也可以作为入职培训过程的一个绝佳知识来源。

我们发现，对工程师来说，这些课程是一个很棒的游乐场。我必须承认，我一开始并没有想到使用混沌工程来进行这些模拟过程。最初，我们只是手动模拟事件，或者只是展示我们在故障发生时收集到的一些证据信息，以推进这些事件的对话。随着不断推进，我们开始利用混沌工具来达到这个目的。除了通过培训能够成为更好的云原生工程师之外，待命工程师们在轮班时也能够感到更加自如，并且熟悉了可用的工具，以便快速做出反应。

我认为这是很好的分享，因为我们总是在谈论借助混沌工程实验来实现更可靠的系统，但我们也可以利用这一点来投资工程团队的培训。

作者简介：

Eran Levy 是一位工程领导、问题解决者，乐于从事分布式系统研究，热爱技术，并在他的博客中与感兴趣的人分享他的知识。

原文链接：

How Do We Utilize Chaos Engineering to Become Better Cloud-Native Engineers?