史上增长最快的SaaS公司-Slack的混沌工程实践 | IDCF

来源：混沌工程实践   首发：slack.engineering

作者：Richard Crowley  译者：龙坞道长 

标题：Disasterpiece Theater: Slack’s process for approachable Chaos Engineering

堪称史上增长最快的SaaS产品: Slack。这是一家特别神奇的SaaS公司，号称在没有销售团队和营销预算的情况下，成立3年营收增长10倍，一度被誉为“历史上增长最快的SaaS公司”。今天，我们来看看他们的混沌工程实践。

引 子

在过去的五年中，Slack的日活用户数超过了1000万，快速的迭代和重大的架构调整支撑了Slack更多的功能。目前，Slack服务已经变成了一个庞然大物。对于这个庞然大物的测试，我们遵循假设验证的科学方法和流程。

每当启用新的功能或对其进行修改时，我们都会测试新代码的容错能力。不幸的是，尽管服务依赖的环境在发生变化，我们也很少重复这些测试。

最初，我们对关键系统的韧性和可靠性充满信心，但随着时间的推移，这些最初的测试结果就会失效，这种信心就没有充分的依据了。

靠运气？不！我们必须有所改变。

当然，如果这是一个从0到1的新产品，我们一开始就会实践混沌工程。毕竟，测试故障路径的最佳方法就是永远不要正常关闭服务。

但是，我们并不是从零开始，我们经营着对业务至关重要且规模庞大的服务，我们现在最需要的是什么呢？

Slack服务保持尽可能的健壮性：

• 开发环境成为一个对容错测试更有信心的地方 ；
• 测试所有系统（不仅仅是新系统） ；
• 不能造成影响用户的事件，所做的测试都必须安全 ；
• 不要虚假的信心，所做的一切都需要在生产中进行 。

在2018年1月，我们启动了一个严格的流程：

• 识别可能发生的故障；
• 确保服务能够容忍这些故障；
• 故意在生产中引入这些故障。

这还不是Netflix实践和宣传的混沌工程。这是混沌工程的第一步，我们称之为灾难剧院。

演练准备

每次灾难剧院的演练过程都旨在最大程度地学习，同时最大程度地降低生产事故的风险。每次演练都在一个确定且通知到位的时间和地点进行，所有相关的专家都在同一房间或同一视频会议中。

这一阶段，我们尚未试图在这些演练中测试监控的部分。在演练之前，主持者们要编写一份详细的计划并广泛分享收集反馈，因为该计划对演练的安全性至关重要。

不过这份计划里面更多是演练的内容，不会提供服务的容错原理。

主持者们负责分享他们的电脑桌面，讲出整个计划背后的思考逻辑。同时，还要精细地记录如何引发故障，将要运行的命令，以及如何选择涉及的EC2实例（我们将其称为“贡品”）。

我们还要求主持者继续记录，用开发环境的容错状况去预测生产中的容错能力，他们有多少信心。此外还包括需要监控的所有日志、指标和告警，以及在此演练过程中需要的运行手册。

最重要的是，他们需要在计划中，提出一个具体的假设，用来描述上下游系统以及Slack客户端经历故障的过程。

例如，“MySQL主服务器的终止，将导致依赖于该数据库的请求，延迟增加20秒，而其它请求的延迟不会增加，失败的API请求数少于1000个，所有这些都是由于客户端重试造成的。”

灾难来袭

在开始演练之前，我们会审核演练计划，将Grafana中定义好的仪表板和Kibana中预置的实时搜索结果，投到幕布上或分享出来。现在我们准备注入故障。

我们先在Slack拥有700多人的运维频道，宣布了这项演练的开始。

在演练过程中，我们不会停止部署或其他任何正常活动，但会让相关的人提前知晓我们的演练计划。

在整个演练过程中，我们会在运维频道中提供一些粗略的状态更新，而在灾难剧场的频道中提供每一步的结果。

演练总是先在开发环境中注入故障。

之后，我们检查日志和指标，以确认故障以我们期望的方式表现出来。碰到问题想要修复是一种常见的本能，但在这里我们必须控制自己，作为旁观者，监视系统的自行维护。

我们通过使用负载平衡和流量管理的方式进行故障转移或更换容量。极少的情况，我们会按照运行手册来恢复服务。

在开发环境中注入故障后，我们会暂停，决定是否在生产上进行同样的操作。很多时候，我们都觉得，如果不在生产上进行，这个演练就是失败的或者浪费大家的时间。

但实际上，往往最有价值的一些经验教训反倒是来自开发环境。

如果系统的自动补救措施不起作用，或者不能按预期见效，亦或者花费的时间太长，更重要的是，如果故障会导致更多的破坏，而不是客户端延迟短暂且轻微的增加，我们会认真考虑中止。

如果我们决定终止，就会在运维频道中宣布。

幸运的是，我们对开发环境的结果感到满意，准备在生产环境中注入故障。我们把Grafana中定义好的仪表板和Kibana中预置的实时搜索，投到幕布上或分享出来，并在运维频道中宣布我们即将在生产注入故障。

最后的时刻到了，在生产中注入故障，和我们在开发环境中所做的一样，我们检查日志和指标，以验证我们的假设。同时，我们也为系统预留了自动修复所需的时间。

另外，这个理论上令人恐惧的时刻，实际上是相当平静的。所有的一切完成后，我们在运维频道中宣布故障全部清除。

然后，我们开始总结和持续跟进:

• 找到问题根源和解决问题的时间点；
• 是否有用户已经注意到这个问题； 
• 是否需要人工干预这个问题； 
• 这个问题的严重程度； 
• 演练计划的文档是否有差错； 
• Grafana中的仪表板是否已过时。 

演练结果

我们在Slack进行了数十次灾难剧院的演练。其中大多数能按计划进行，增强了我们对现有系统的信心，并验证了新功能的容错能力。当然，有些时候我们还是会发现Slack可用性的严重问题，并在影响客户之前找到提前修复的机会。

以下是三个特别成功的演练：

1、避免缓存不一致

第一次的灾难剧院演练，我们把注意力投向了memcached，用于证明在生产中自动实例替换能正常工作。

这个演练很简单，选择将memcached的实例断开网络连接，观察备用实例是否能正常替换。最后，我们恢复了网络连接并终止了备用实例。

演练计划审核时，我们发现了实例替换算法中的一个漏洞，并很快在开发环境确认了它的存在。

根据最初的设计，如果实例在一组缓存键上丢失了租约，然后又获得相同的租约，则该实例不会刷新其缓存项。但是，在这种情况下，备用实例在此期间已使用了该组缓存键，这意味着原始实例中的数据已过时而且可能不准确了。

在演练中，我们通过选定适当时间段手动刷新缓存，在演练完成后立即更改算法，并再次进行测试来解决此问题。

没有演练发现的这个问题，我们很可能不会察觉缓存损坏的问题。

2、为了安全反复尝试

在2019年初，我们计划进行十次演练，用来证明Slack对AWS中的区域故障和网络分区的容错能力。其中一个演练涉及信道服务器(Channel Server)，负责将新发送的消息和元数据，广播到所有关联Slack客户端的WebSocket中。

这次演练的目标是将25％的信道服务器受到网络分区的故障，并观察是否能检测到对应的故障点，系统是否自动会将原实例替换为备用实例。

创建网络分区故障的第一次尝试失败了，问题出在提供透明传输加密的overlay网络。实际上，我们对信道服务器的隔离远超出了预期，与网络分区相比，这是断开网络连接。我们提早停下使信道服务器重新加入集群，恢复网络故障。

第二次尝试好了很多，但在投入生产前就结束了。但这次演练提供了积极的结果，我们发现Consul适合管理网络分区上的路由。这个结果给了我们更多的信息，但还是结束了这次演练，因为虽然做了很多工作，最终还是没有产生任何信道服务器的故障。

第三次也是最后一次尝试，我们使用了完整的iptables规则库，并成功地将网络分区故障注入到25％的信道服务器。Consul迅速检测到故障，并立即采取替代行动。最重要的是，这种大规模自动重新配置的工作，给Slack API带来的负荷完全在该系统的能力范围内。

漫漫长路的尽头，最后都是积极的成果！

3、看似不可能的结果

演练也会有负面的结果。事件响应，通常涉及使用自研系统Confabulator进行配置更改。

在一次特别严重的事件中，Confabulator未能按预期运行，因此我们不得不手动进行配置更改的部署。

因此，我们认为这个事件值得进一步调查。系统维护人员和我们计划进行一次演练，直接模仿我们之前遇到的状况，这将会导致Confabulator的网络分区，其他的系统都运行正常，我们也不会尝试手动更改配置。

重现了这个问题很容易，然后我们开始跟踪代码，很快就发现了问题。该系统的作者发现问题出在Slack本身宕机的情况下。

当提交的配置更改无法验证进而无法部署时，系统就会应用一种紧急模式，直接跳过了验证过程。但是，在正常模式和紧急模式中，系统都会试图将配置更改的通知发布到Slack通道。该操作恰恰没有设置超时，尽管配置API是有超时的。

因此，即使在紧急模式下，如果Slack本身处于关闭状态，该请求也永远无法进行配置更改的部署。

这个演练之后，我们对代码和配置部署进行了很多的改进，并审核了这些关键系统中的超时和重试策略。

未来展望

灾难剧院演练，已对Slack关键系统的容错能力进行了定期且安全的验证，帮助我们了解和提高了Slack服务的可靠性。

在我们拓展和迭代产品时，这是赢得并保持客户信任度的最重要因素之一。

上面提到的三个演练，增强了Slack服务的健壮性，并建立或纠正了我们对系统容错能力的信心。

我们的韧性工程团队会一直不断地拓展和迭代这个过程。当然，我们计划进行更多的灾难剧院演练。

2021 IDCF 公开课招生ing

王立杰老师授课《端到端DevOps持续交付（5P）工作坊》第一期课程本周四开播啦，限时拼团优惠，快识别下图二维码报名吧~