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

第三次也是最后一次尝试，我们使用了完整的iptables规则库，并成功地将网络分区故障注入到25％的信道服务器。 Consul迅速检测到故障，并立即采取替代行动。最重要的是，这种大规模自动重新配置的工作，给Slack API带来的负荷完全在该系统的能力范围内。
漫漫长路的尽头，最后都是积极的成果！
3、看似不可能的结果
演练也会有负面的结果。事件响应，通常涉及使用自研系统Confabulator进行配置更改。
在一次特别严重的事件中， Confabulator未能按预期运行，因此我们不得不手动进行配置更改的部署。
因此，我们认为这个事件值得进一步调查。系统维护人员和我们计划进行一次演练，直接模仿我们之前遇到的状况，这将会导致Confabulator的网络分区，其他的系统都运行正常，我们也不会尝试手动更改配置。

本文插图
重现了这个问题很容易，然后我们开始跟踪代码，很快就发现了问题。该系统的作者发现问题出在Slack本身宕机的情况下。
当提交的配置更改无法验证进而无法部署时，系统就会应用一种紧急模式，直接跳过了验证过程。但是，在正常模式和紧急模式中，系统都会试图将配置更改的通知发布到Slack通道。该操作恰恰没有设置超时，尽管配置API是有超时的。
因此，即使在紧急模式下，如果Slack本身处于关闭状态，该请求也永远无法进行配置更改的部署。
这个演练之后，我们对代码和配置部署进行了很多的改进，并审核了这些关键系统中的超时和重试策略。
未来展望
灾难剧院演练，已对Slack关键系统的容错能力进行了定期且安全的验证，帮助我们了解和提高了Slack服务的可靠性。
在我们拓展和迭代产品时，这是赢得并保持客户信任度的最重要因素之一。

本文插图
上面提到的三个演练，增强了Slack服务的健壮性，并建立或纠正了我们对系统容错能力的信心。
我们的韧性工程团队会一直不断地拓展和迭代这个过程。当然，我们计划进行更多的灾难剧院演练。
作者：Richard Crowley 译者：龙坞道长
【史上增长最快的SaaS公司-Slack的混沌工程实践 | IDCF】＋“CH050791”可入qun交流~

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