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

堪称史上增长最快的SaaS产品: Slack 。这是一家特别神奇的SaaS公司，号称在没有销售团队和营销预算的情况下，成立3年营收增长10倍，一度被誉为“历史上增长最快的SaaS公司” 。今天，我们来看看他们的混沌工程实践。
引子
在过去的五年中， Slack的日活用户数超过了1000万，快速的迭代和重大的架构调整支撑了Slack更多的功能。目前， Slack服务已经变成了一个庞然大物。对于这个庞然大物的测试，我们遵循假设验证的科学方法和流程。
每当启用新的功能或对其进行修改时，我们都会测试新代码的容错能力。不幸的是，尽管服务依赖的环境在发生变化，我们也很少重复这些测试。
最初，我们对关键系统的韧性和可靠性充满信心，但随着时间的推移，这些最初的测试结果就会失效，这种信心就没有充分的依据了。
靠运气？不！我们必须有所改变。
当然，如果这是一个从0到1的新产品，我们一开始就会实践混沌工程。毕竟，测试故障路径的最佳方法就是永远不要正常关闭服务。
但是，我们并不是从零开始，我们经营着对业务至关重要且规模庞大的服务，我们现在最需要的是什么呢？

本文插图
Slack服务保持尽可能的健壮性：

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

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

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

这还不是Netflix实践和宣传的混沌工程。这是混沌工程的第一步，我们称之为灾难剧院。
演练准备
每次灾难剧院的演练过程都旨在最大程度地学习，同时最大程度地降低生产事故的风险。每次演练都在一个确定且通知到位的时间和地点进行，所有相关的专家都在同一房间或同一视频会议中。
这一阶段，我们尚未试图在这些演练中测试监控的部分。在演练之前，主持者们要编写一份详细的计划并广泛分享收集反馈，因为该计划对演练的安全性至关重要。
不过这份计划里面更多是演练的内容，不会提供服务的容错原理。

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

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