Atlassian桌面灾备演练揭露依赖地狱烦恼，危机背后真相大白

澳大利亚协作软件公司 Atlassian 透露，它花了四年时间试图减少内部依赖关系的风险，虽然重建了其 PaaS，但仍然存在一些问题——不过他们认为这些问题现在是可以管理的……

正如高级工程经理 Andrew Ross 在周二的帖子中提到的：‘Atlassian 运行着一个大型基于服务的平台，拥有数千个不同的服务，大多数是通过我们的自定义编排系统‘Micros’来部署的。’

Micros 管理超过 2,000 个服务，每天进行超过 5,000 次部署，管理超过 40,000 个 DynamoDB 表和超过 80,000 个 Amazon 关系数据库服务 (RDS) 表。它还管理着三百万个 lambda 函数。

Atlassian 基础设施中的另一个重要部分是一个名为‘Artifactory’的私有 Docker 注册表。

在2021年，Atlassian 使用 Micros 部署了 Artifactory，而 Micros 平台在部署和运行时依赖于 Artifactory。这意味着如果其中任何一个工具失败，另一个也将无法恢复。

对于 Atlassian 来说，这对它很麻烦，因为它是一家 SaaS 公司，而在处理依赖关系时，正准备将客户从本地产品迁移到云端。

该公司创建了一个持续 PaaS 恢复 (CPR) 项目，以尽可能解决更多的依赖关系。

随着该项目的推进，Atlassian意识到依赖关系的数量和复杂性使得它无法消除所有依赖关系。因此，它优先处理那些使恢复服务变得困难的依赖关系纠缠。

在2023年，该公司进行了一个桌面演练以应对灾难恢复，模拟了6.5天的恢复过程，以帮助员工理解和识别风险。

罗斯的帖子展示了这次演练的结果，下面的图像显示了图中绿色表示已恢复的服务，红色则表示由于依赖关系纠缠而未能恢复的服务。在左侧的“之前”图中，有三个服务是正常运行的。在右侧的“之后”图中，由于依赖关系，数十个服务仍然处于停机状态。

Atlassian 现在已将其平台重新架构为罗斯所描述的“层级结构”。

“我们决定将云基础设施分为多个层次，最底层依赖最少，而上层依赖较多，”他写道。这个新结构并非没有依赖，因为 Atlassian 并不认为完全消除所有依赖是可能或实际的。相反，公司已经学会了与这些依赖共存的方式，并遵循以下原则：

公司还将 Artifactory 从 Micros 迁移到 Kubernetes，消除了一个关键的循环依赖关系，并构建了一个新的低依赖配置系统，称为 Atlassian Platform Deployer (APD)，该系统以 AWS CloudFormation 作为部署协调引擎。

APD 帮助公司创建并部署了其最近宣布的政府云服务。在经历了许多挑战后，Atlassian 将 Micros 自身迁移到了 APD。

他们仍然存在内部循环依赖，但消除了数百个，并且现在感觉运营的平台更可靠，更容易恢复。

它需要这样做，因为 Atlassian 最近宣布了一项计划，放弃其本地产品并将所有客户迁移到其云端。考虑到循环依赖是 Cloudflare 和 AWS 最近停机的重要因素，这些客户可能会对迁移到云端的这一举措感到谨慎。