Atlassian 如何管理客户数据
Atlassian 如何实现弹性
我们的产品在一个平台即服务 (PaaS) 环境中运行，该环境分为两组主要的基础架构，我们称之为 Micros 和非 Micros。Jira、Confluence、Statuspage、Access 和 Bitbucket 在 Micros 平台上运行，而 Jira Align、Opsgenie 和 Trello 在非 Micros 平台上运行。
为此，我们会尽可能减轻任何中断对客户所造成的影响。我们利用分布于不同地理位置的多个数据中心，制定了全面的备份计划，并通过定期测试灾难恢复和业务持续性计划来提供保障。
本页概述了我们如何管理客户数据管理的整个生命周期，包括利用 Amazon Web Services (AWS) 中的原生功能进行备份以确保服务可用性，定期测试灾难恢复计划，以及不断改进我们的灾难恢复和业务持续性计划。
如何管理备份
第一要务：基础设施和数据库
从宏观来说，Atlassian 运行我们产品的基础设施划分为两个主要组别：平台即服务 (PaaS) 环境（内部称为 Micros），以及 non-Micros。在我们的 Micros 平台上运行的产品包括 Jira、Confluence、Statuspage、Bitbucket 和 Atlassian Access，而在 non-Micros 环境中运行的产品则包括 Opsgenie 和 Trello。为简单起见，本文主要关注我们最大的产品：Jira、Confluence 和 Bitbucket。
Jira 和 Confluence Cloud 托管在多个 AWS 地区，使用 AWS 基础设施即服务 (IaaS) 产品（特别是美国东部、美国西部、爱尔兰、法兰克福、新加坡和悉尼，并计划根据需要扩展到其他地区）。Jira 和 Confluence Cloud 都针对每个产品实例使用逻辑上独立的关系数据库，而存储在 Jira 或 Confluence Cloud 中的附件则存储在我们的文档存储平台（“媒体平台”）中，而该平台最终会存储在 Amazon S3 中。
备份
Atlassian 意识到，无论您的业务是什么，它都会产生数据。毕竟，若无数据，何来业务？根据我们“真诚对待客户”的价值观，我们非常重视保护您的数据不会发生丢失，并且制定了全面的备份计划。
对于 Jira 和 Confluence Cloud，Atlassian 利用 Amazon RDS（Amazon 关系数据库服务）的快照功能为每一个 RDS 实例自动创建每日备份。Amazon RDS 快照会保留 30 天，同时支持时间点恢复，并使用 AES-256 加密技术进行加密。
请注意，对于 Jira Align，Amazon RDS 快照将保留 35 天。
Bitbucket 中的数据会复制到不同的 AWS 区域，并且每个区域每天都在进行独立备份。
Atlassian 每季度对备份进行恢复测试，并以 Jira 工作单形式提交这些测试中发现的所有问题，以确保其得到全程跟踪直至修复为止。
有关更多信息，请参见数据存储常见问题解答。
如何利用多个数据中心和可用区域实现高可用性
虽说飓风、地震和海啸风险颇为遥远，但并不是零风险，因此必须将数据备份（和复制）到不同的地理位置，以便无论发生什么情况都能恢复数据。
Atlassian 通过利用 AWS 在全球多个地区的高可用数据中心设施来实现此目标。每个 AWS 地区都是一个独立的地理位置，拥有多个被称为可用区 (AZ) 的隔离区域。例如，美国西部（美国西海岸）是一个地区，其中有两个可用区：us-west-1a（位于加利福尼亚北部）和 us-west-1b（位于俄勒冈州），两者属于同一个地区，但在地理上相互独立。
每个可用区都旨在与其他可用区的故障相隔离，并为同一地区的其他可用区提供成本低、延迟短的网络连接。这种多区域高可用性是第一道防线；换言之，在多可用区部署中运行的服务应能承受可用区故障。
Jira 和 Confluence 利用 Amazon RDS 的多可用区部署模式。在多可用区部署中，Amazon RDS 在同一地区的不同可用区中调配和维护同步备用副本，以提供冗余和故障转移功能。可用区故障转移是自动执行的，通常需要 60-120 秒，因此数据库操作可以在无需管理员干预的前提下尽快恢复。下图突出显示了这些地区、可用区和复制概念。Opsgenie、Statuspage、Trello 和 Jira Align 使用类似的部署策略，但在副本时间和故障转移时间上稍有差异。
如何确定恢复时间和恢复点目标
在理想的世界中，我们永远不会丢失任何重要的业务数据。但在现实中，数据丢失风险为零的系统不是空中楼阁，就是价值连城。虽然从 Atlassian 公司文化角度来看，我们的期望就是追求这种零数据丢失梦想和在可用区故障时自动幸免的能力，但对于业务持续性规划，我们有必要设置“恢复时间目标”和“恢复点目标”（分别简称为 RTO 和 RPO），从而寻求在成本、收益和风险之间实现适当的平衡。
RTO 是指业务流程（或系统）应该在事故发生之后多久复原并恢复正常运行。RPO 实际上是指恢复操作中可能丢失但可为组织所接受的数据量。举一个简单的例子，如果您每天进行备份，在当天结束时发生事故并通过备份（上一天的备份）进行恢复，那么您将丢失 1 天的数据。这便是 RPO。
业务影响和风险评估有助于我们的团队根据客户一端的用户需求和中断带来的潜在影响设定自定义 RTO 和 RPO 目标。
更具体地说，我们将服务拆分为易于理解的存储桶，我们称之为“级别”(tier)。我们为产品和面向客户的服务、Atlassian 业务系统和内部工具定义了三个级别（第 1、第 2 和第 3 级），底层级别（第 0 级）则为各方所依赖的关键组件提供更高的可用性标准。
对于每个层级，我们都会通过审查所构建服务的业务影响评估和典型使用情景等要素来定义强制性目标。我们的服务级别有助于确定可用性、可靠性、RTO 和 RPO 目标，如下表所示。
| 第 0 级 | 第 1 级 | 第 2 级 | 第 3 级 | |
|---|---|---|---|---|
| 关键基础设施和服务组件 | 第 0 级服务是构成所有其他服务的基础，对我们产品的交付至关重要。 | 第 1 级服务通常是我们的产品，或者直接与我们的产品交付相关。 | 第 2 级服务是非关键服务，或面向内部的服务。 | 第 3 级服务是非关键服务，或面向内部的服务。 |
| 示例服务： | 示例服务 · AWS 平台 · Micros 服务器 · 网络核心 | 示例服务 · Jira 和 Confluence Cloud · Bitbucket · Jira Align · Trello · Opsgenie | 示例服务 · Image Effects · CAC | 示例服务 · 接收分析和/或 BI 数据 |
| RPO* | < 1 小时 | < 1 小时 | < 8 小时 | < 24 小时 |
| RTO** | < 4 小时 | < 6 小时 | < 24 小时 | < 72 小时 |
*RPO – 恢复点目标 – 发生灾难导致的数据丢失
**RTO – 恢复时间目标 – 发生灾难导致的服务恢复
在 Atlassian，我们将责任指派给服务负责人，由他们负责确保相关服务达到其 RPO 和 RTO 目标。
如何进行灾难恢复测试
作为 Atlassian 灾难恢复 (DR) 计划的一部分，我们定期进行灾难恢复测试，并努力实现持续改进，力求确保客户数据与服务的可靠性和弹性。我们进行按计划测试和临时测试，其中包括以下要素：
文档 - 对于关键/面向客户的服务（包括第 0 和第 1 级），每个季度审查备份文档，以确保准确、完整并保持最新。识别的所有问题都会进行记录，问题会在内部生成 Jira 工作单，以便对问题进行全程跟踪直至补救完毕。
流程 - 对于关键/面向客户的服务（包括第 0 和第 1 级），每个季度还会测试实际的技术备份/恢复流程，以确定是否达成了 RTO 和 RPO 目标（基于服务级别分类）。从这些测试中发现的所有问题都会以 Jira 工作单形式提交，以便对其进行全程跟踪直至补救完毕。
弹性和故障转移 – 对跨可用区的恢复能力水平进行定期和临时测试，以确保 Atlassian 能够以最短的停机时间处理可用区故障。虽然我们知道全地区故障几乎不可能发生，但依然会定期测试地区故障转移，并继续提升我们的地区性弹性。
系统 - 现场可靠性工程 (SRE) 团队和产品工程团队持续监控服务中的各种指标，以协助确保为用户提供卓越的体验。配置自动警报，以在超过特定服务指标阈值时通知 SRE 团队成员，从而依据我们的事件响应流程立即采取措施。
灾难恢复仪表板 - 我们在内部维护有灾难恢复仪表板。如此一来，对于关键/面向客户的服务（包括第 0 和第 1 级），我们便可集中跟踪与监督、维护和测试相关的 Jira 工作单，确保准时完成对文档和备份/恢复流程的审查。
灾难恢复测试和模拟 – 灾难恢复测试每年执行一次，并根据需要临时执行。在灾难恢复测试过程中，我们会执行桌面训练，以帮助 DR 团队对潜在事件的各种场景进行演练。桌面训练可以测试不同的场景，并确定恢复流程中的欠缺。桌面训练的场景包括地震、火灾、自然灾害、恢复演习和测试。执行灾难恢复测试后，我们会采集、分析和讨论测试的输出，以确定后续步骤的范围，从而实现持续改进。改进工作将在 Jira 工作单中进行记录和跟踪，直到补救完毕。
尽管 Atlassian 的测试和流程在技术上非常严谨，但我们仍然设有相关标准，汇聚优秀的人才来一同实现这些目标。因此，Atlassian 在灾难恢复计划中纳入了以下人员要素：
现场可靠性工程师（“SRE”） – SRE 会定期举行灾难恢复会议，并充当所负责关键服务的代言人。他们与风险和合规团队一起确定灾难恢复缺口，并在必要时全力进行补救。
灾难恢复冠军 - 每个产品/服务团队（包括底层服务）都指派有灾难恢复冠军，负责监督和协助管理该产品/服务中灾难恢复的实施，从而确保其满足服务级别要求。
领导层 - 我们确保高管和高级管理层在灾难恢复流程中的参与和持续交流。在领导层的参与下，Atlassian 将业务和技术驱动因素纳入到其弹性战略中。
其他更为广泛的业务持续性措施和计划
Atlassian 致力于保持强健的业务持续性（“BC”）和灾难恢复能力，以确保在发生运营中断时，尽量减少对客户的影响。指导我们业务持续性和灾难恢复计划的关键原则包括：
持续改进 – Atlassian 凭借运营效率、自动化、新技术和行之有效的实践，努力确保提高弹性。
通过测试提供保障 – Atlassian 明白，借助定期安排的测试并运用不断取得的进步，我们就能实现最佳弹性。
专门的资源 – Atlassian 委派了专门的人员和团队，确保我们面向客户的产品得到所需的关注，让业务持续性和灾难恢复成为可实现的目标。Atlassian 上上下下皆有水平适当的资源，为我们的指导委员会、风险评估、业务影响分析测试以及现实中发生的事件提供支持。
总结
Atlassian 将一流的技术与持续的测试和验证相结合，确保客户数据具有高可用性、可靠性和弹性。我们运营着分布于不同地理位置的多个数据中心，制定了全面的备份计划，并通过定期测试灾难恢复和业务连续性计划来提供保障。在此基础上，我们还有杰出人才和专门资源将各种流程整合在一起。