主要观点：

• 未正确规划和设计时，使用云服务会带来很大风险，与本地数据中心实施中的挑战相似，如停电和网络问题等。
• 单一区域的云服务方法注定会失败，应设计利用多个可用区的云服务，以应对区域级中断，但仍存在风险。
• 引入“n + 2”规则，即增加两个区域以提高服务的弹性，避免因单个区域故障导致业务中断。
• 多区域设计可采用 Route 53 处理请求并导向最佳区域，同时引入可观测性层来监控和衡量服务性能。
• 设计多区域服务时要避免增加繁琐工作（toil），如自动创建变更请求并利用可观测性层监控部署。
• 可观测性平台通过度量指标、日志和追踪来测量系统状态，可用于创建合成 API 测试以监控服务性能。
• 实施多区域服务需要规划，包括理解持久层、采用基础设施即代码、使用容器化、减少部署时间、建立 SLO 和合成测试、自动化部署等。
• 应利用“n + 2”规则增加服务运行的区域数量，以更好地满足与客户的服务级别协议（SLA），提高服务弹性和团队生产力。

关键信息：

• AWS 有大规模区域中断记录，[danluu/post-mortems]仓库提供更全面的云视图。
• 单一区域服务易受区域级中断影响，多区域服务可通过多个可用区和 Route 53 处理请求。
• “n + 2”规则可增加服务的弹性和应对故障的能力。
• 可观测性平台可测量系统状态、创建合成测试并监控服务性能。
• 实施多区域服务需规划并采取一系列行动，如理解持久层、采用基础设施即代码等。

重要细节：

• 以图 1 展示基于 AWS 的 Kubernetes 平台的云服务利用多个可用区的设计，存在区域级中断风险及应对策略。
• 以图 2 展示多区域云服务设计，引入可观测性层并分别在区域和全球级别监控性能。
• 定义 toil 为手动、重复、可自动化、无持久价值且随服务增长线性增加的工作。
• 强调可观测性平台在 justify 手动变更批准需求方面的作用。
• 在图 3 中展示多区域服务实施在美国地图上的数据库连接及可观测性和云指标数据收集情况。
• 列出实施多区域服务的高层面行动项目，如理解持久层、采用基础设施即代码等。