云服务性能下降事件分析：高可用架构与可用区疏散实践

10 月 22 日星期一，某海外云服务商发生了一次服务故障。由于该故障导致多个热门网站宕机数小时，事件引发了广泛关注。某海外流媒体服务提供方也受到了一定影响，但对终端用户造成的实际影响较小。

从高可用架构、故障隔离和可用区疏散的角度来看，这次事件具有较强的参考价值。回顾此次事件，我们有一些应对措施做得比较到位，也有一些地方本可以做得更好。本文将从我们的视角梳理此次云服务性能下降事件的时间线，并分享我们在降低用户影响、提升系统韧性方面采用的一些实践方法。

事件时间线：从性能下降到可用区疏散

周一上午 8:30 刚过，我们注意到几个托管在某海外云服务商平台上的大型网站开始出现问题，并陆续返回错误。随后，我们检查了自身的监控系统，发现我们的服务尚未受到影响。

上午 10:40，该云服务商更新了状态页，显示其块存储服务出现性能下降。由于我们一直重视服务在单个实例故障下的容错能力，并且尽量避免依赖块存储服务进行持久化数据存储，因此当时我们的服务仍然保持正常。

大约上午 11 点，部分用户开始遇到间歇性问题。由于我们的大多数客户端软件都针对间歇性服务端故障进行了韧性设计，因此绝大多数用户并未察觉异常。上午 11:15，问题开始变得更加严重，我们随即触发内部告警，并开始排查原因。

当时，问题表现得更像是网络故障，而不是块存储系统故障，这在初期造成了一定混淆。事后来看，我们本应更早触发告警。这样一来，我们就能更快缩小问题范围，并更早采取修复措施。

在将网络问题定位到单个可用区之后，该云服务商也确认网络性能下降仅限于该可用区。得知影响范围只局限在一个可用区后，我们立即开始将用户流量从受影响的可用区疏散出去。

由于此前曾经历过单可用区故障，我们会定期开展可用区疏散演练。基于这些演练经验，以及我们从以往故障中吸取的教训，我们毫不犹豫地决定疏散故障可用区。我们预期此次疏散会像以往演练一样迅速而顺利，因此立即采取了行动。

过去的经验表明，可用区疏散是应对单个可用区局部故障的有效方法。因此，我们在内部云管理平台中对这一流程进行了工具化支持，只需点击几下鼠标即可完成可用区疏散。此次事件中，这项准备发挥了重要作用：我们仅用 20 分钟就完成了故障可用区的疏散，并为所有用户全面恢复了服务。

如何构建高可用系统

结合过去的故障经验，以及我们从一开始就坚持的韧性设计理念，我们总结出了一些构建高可用系统的实践模式。这些实践不仅适用于云服务故障应对，也适用于大规模分布式系统的稳定性建设。

冗余：跨可用区部署是高可用架构的基础

最重要的实践之一，是确保所有软件都能够跨三个可用区运行。同时，我们还确保每个应用都能够承受单个实例故障。正是这两点，使可用区迁移变得更加容易：当我们停止向受影响可用区发送流量时，所有服务仍能继续运行。

在某些情况下，我们需要将实例从该可用区中移除，但这只需通过几次点击重新配置自动伸缩组即可完成。

我们对分布式数据库集群也采用了同样的三可用区冗余模型。所有集群都配置为复制因子为 3，并确保每个副本位于不同的可用区。这样的设计让数据库集群能够很好地应对故障。当单个可用区不可用时，我们无需进行人工干预。系统会将请求路由到其他可用区，并在故障可用区恢复后自动修复整个副本环。

故障演练工具体系：持续验证系统韧性

每个人在开发软件时都有良好的初衷。优秀的开发者和架构师会考虑错误处理、边界情况，并努力构建具备韧性的系统。然而，仅仅“考虑到”这些还远远不够。为了持续确保系统具备韧性，我们必须不断测试系统的功能，以及它在罕见异常事件下的应对能力。

这正是我们构建故障演练工具体系的原因：

实例故障演练工具用于测试系统对单个实例故障的韧性；延迟故障演练工具用于测试系统对网络延迟和服务降级的韧性；可用区故障演练工具用于测试系统对单可用区中断的韧性。

未来，我们计划进一步扩展可用区故障演练能力，使其能够通过一次点击完成可用区疏散，从而简化故障处置过程中的决策流程。随着能力的持续提升，我们还计划建设更大范围的故障演练能力，用于测试系统在整个云服务地域中断时的韧性。

简易工具与自动化：降低故障处置成本

让可用区迁移决策变得简单的关键之一，是我们的内部云管理平台。借助这一平台，服务负责人只需点击几下，就可以按需停止向某些实例发送流量，或直接删除相关实例。

在故障发生时，复杂、依赖人工判断且步骤繁琐的操作往往会放大风险。相反，如果关键操作已经被工具化、自动化，并且在日常演练中反复验证，团队就能在压力环境下更快、更稳地完成处置。

除了底层技术工具，跨团队协作工具同样重要。例如在故障响应过程中，团队可以借助 Worktile 这类通用项目协作系统，将任务、文档、日历、审批和项目进度统一管理，减少信息分散带来的沟通成本。

接受错误：通过故障复盘持续改进

每次故障发生后，我们都会进行事件复盘。这些复盘的目的并不是追究个人责任，而是找出系统和流程中可以改进的地方。

每次故障后，我们都会整理一份详细的时间线，然后追问自己：

我们有哪些地方本可以做得更好？
下一次怎样才能进一步降低影响？
怎样才能更早发现问题？
怎样才能更快定位问题并采取行动？

随后，我们会根据这些问题的答案，尝试解决一类问题，而不是只修复最近一次故障中暴露出来的个别问题。正是通过这种方式，我们逐步沉淀出了一套高可用系统建设的实践方法。

对于研发团队来说，故障复盘不应停留在会议纪要层面，而应沉淀为可复用的研发管理资产。借助 PingCode 这类智能化研发管理工具，团队可以将目标、需求、开发、测试、发布和复盘知识串联起来，让故障经验沉淀到 Wiki，并与研发流程中的数据形成闭环，从而持续提升研发效能。

结论：系统韧性建设没有终点

在此次云服务中断事件中，我们成功控制了影响范围，并从中获得了新的经验教训。每次服务中断后，我们都会寻找机会，持续优化系统构建方式，完善故障检测和响应机制。

虽然我们认为自己已经构建了一套高可用、高可靠的服务体系，但我们也始终清楚：系统韧性的建设没有终点。无论当前系统表现如何，都仍然存在持续改进和提升的空间。