故意破坏系统：强化系统恢复能力

“复杂系统可能以无限多种方式失败。” —— John Gall《Systemantics》

事故压力重重但不可避免。即使为可用性设计的服务最终也会遇到故障。工程师们自然会对防御系统可能出错的“无限多种方式”感到畏惧。

当我们的内部仪表板服务宕机、恢复失败并丢失团队成员配置时，我们团队就陷入了这种境地。然而，凭借创造力和一点调皮精神，我们开发了一项练习，解决了问题根源，激发了团队活力，并为枯燥的系统维护工作带来了兴奋和乐趣。请跟随我们分享从事故恐慌到安心的旅程。

事故经过

Slack工程师使用Kibana和Elasticsearch保存自定义仪表盘和重要应用性能数据的可视化。2024年1月29日，由于磁盘空间不足，我们的Kibana集群及随后的仪表板开始故障。我们开始调查，意识到这是早期架构决策的不幸连锁反应。

您可以将Elasticsearch配置为Kibana使用的独立集群，从而将对象存储与Kibana应用程序本身解耦。然而，我们的Kibana集群配置为使用与Kibana应用程序相同主机上的Elasticsearch实例。这将存储和应用程序绑定在相同节点上，而这些节点现在正在故障。Slack工程师无法加载确保应用程序健康所需的数据。

最终，集群陷入无法挽救的糟糕状态，我们不得不从头开始重建。我们以为可以通过轮换新主机并从备份恢复Kibana对象来建立新集群。然而，我们震惊且失望地发现最近的备份几乎是两年前的。备份和恢复方法在首次配置后没有得到足够关注，并且没有警报告诉我们它是否运行不正确。除此之外，我们的运行手册已过时，旧备份在尝试恢复时失败。我们丢失了内部员工的链接和可视化，被迫手动重新创建索引和索引模式。

向团队成员解释我们的恢复程序失败且数据丢失并不有趣。我们直到为时已晚才注意到备份失败。

没有人能免于此类情况。除非您积极演练流程、程序和运行手册，否则它们将变得过时，并在您最需要时失败。事件响应是关于尽快恢复服务，但尘埃落定后的行动决定了它们最终是资产还是负债。

破坏系统很有趣

我们决心将这次事故转化为切实利益。事故后任务包括确保每个环境中的Elasticsearch集群都有计划备份脚本、根据经验修复运行手册，并检查Amazon S3保留策略是否正确设置。

我们想测试改进以确保它们有效。团队提出了一个非常规但激动人心的想法：我们将破坏一个开发Kibana集群并尝试新的备份和恢复过程。开发集群配置与生产集群相似，将为测试提供真实环境。为确保成功，我们仔细计划了要破坏哪个集群、如何破坏以及如何恢复服务。

执行演练

我们将测试活动安排在一个安静的周四早晨，并邀请整个团队参加。大家充满活力，对有机会在工作中故意破坏某些东西感到高兴。我们填满了Kibana节点的磁盘，实时观察它们故障，并成功触发了警报。我们按照新运行手册步骤操作，并将整个集群轮换到全新重建中。我们的系统从我们策划的事故中成功恢复。

尽管恢复成功，但我们未能在不到一小时内恢复的目标。运行手册中的许多命令在压力事件中难以理解。即使尝试从运行手册复制粘贴也因格式问题而具有挑战性。尽管存在这些粗糙边缘，备份最终完全恢复了集群状态。此外，我们发现一些防火墙规则需要添加到基础设施即代码中。这是运行演练的额外发现——我们没想到会发现防火墙问题，但修复它们避免了未来的麻烦。

在新恢复过程的最终测试中，我们将通用开发Kibana实例和Elasticsearch集群迁移到Kubernetes上运行。这是在高度使用的Kibana集群上测试改进备份脚本的绝佳机会。得益于我们对过程的改进理解和更新的配置脚本，我们以约30分钟停机时间成功完成了迁移。

在两次演练中，我们都遇到了新运行手册和恢复过程的小问题。我们花时间找出运行手册不足之处并加以改进。受演练启发，我们主动通过更新计划备份脚本工具为全功能CLI备份和恢复程序来自动化整个过程。现在我们能够通过单个命令从云存储完全恢复Kibana备份。“破坏系统”不仅有趣：这是对我们时间的极其宝贵投资，使我们免于未来的压力。

混乱无处不在——不妨利用它

“复杂系统通常在故障模式下运行。” —— John Gall

每个生产系统都以尚未发现的方式存在故障。是的，包括您的系统。花时间和精力在关键之前发现这些问题并计划如何从中恢复。在客户之前生成大量流量和负载测试服务。关闭服务以模拟意外中断。经常升级依赖项。软件中的例行维护经常被忽视，因为它可能枯燥无聊，但当事故不可避免地发生时，我们会为此付出代价。

我们发现可以通过战略性混乱使系统测试和维护变得激动人心和新鲜：计划性的破坏机会。这不仅是从通常修复工作中偏离的简单兴奋，还将我们置于如果以传统方式处理维护永远不会发现的独特而真实的情况中。

我们鼓励您花时间破坏自己的系统。恢复它们，然后再做一次。每次迭代都会使过程和工具在您不可避免地需要在压力情况下使用时变得更好。

最后，记得在每年3月31日庆祝世界备份日。我们知道我们会！

致谢

• Kyle Sammons——与我合作规划和执行恢复演练
• Mark Carey和Renning Bruns——使工具正常运行并自动化过程
• Emma Montross、Shelly Wu和Bryan Burkholder——在恢复演练期间的事件响应和支持
• George Luong和Ryan Katkov——给予我们自主权以改进事物

有兴趣承担有趣项目、让人们的工作生活更轻松，或只是构建一些很酷的表单吗？我们正在招聘！立即申请！