云软件中的普遍可用性风险

# 云软件中无处不在的可用性风险 来源：https://surfingcomplexity.blog/2026/08/29/omnipresent-availability-risks-in-cloud-software/ 我撰写本文，旨在整合阅读多起重大云软件事故报告后所发现的一些共同脉络。此处*云软件*特指软件即服务（SaaS）（人们现在还这么说吗？就是在云端运行的软件。虽然这并不仅限于云服务提供商，但他们同样适用。 以下是本文的主题纲要： - 问题领域 - 饱和 - 举例：数据库 - 网络（流量路由故障） - 举例：DNS - 安全（阻止合法访问） - 举例：SSL证书 - 必要的非常规变更 - 缓解运维问题 - 迁移 - 必要复杂性之必要增长 - 可靠性子系统 - 迁移 我认为这些都属于*无处不在的可用性风险*：我认为这些风险从根本上是不可避免的，在可预见的未来，甚至直到我的软件生涯终结之前，它们都将持续导致软件事故。 大多数重大事故似乎都涉及三个通用领域：饱和、网络和安全。那么，让我们从这些开始探讨。 ## 饱和 *饱和*可能是我讨论最频繁的话题，无论是在本博客（https://surfingcomplexity.blog/?s=saturation）还是在其他场合（例如：我为Resilience in Software Foundation撰写的饱和文章（https://resilienceinsoftware.org/news/11475336），以及我在Software Should Work会议上的饱和主题演讲（https://youtu.be/PHYCRubnmSM））。当系统达到某个限制时，它就变得*饱和*。这是一个相当笼统的描述，但限制的种类繁多！ ### 数据库 许多重大事故都涉及某个系统组件以某种形式饱和。我个人最担心数据库饱和。这是因为生产数据库过载后很难恢复。此外，由于数据库系统本身极其复杂，确定具体性能问题的根源可能相当困难。这就是为什么拥有内部的数据库运维专业知识至关重要。 饱和是一种无处不在的风险，因为在我们所处的世界中，资源的有限性是一个硬约束。最终，你系统中的某些资源会耗尽。 示例：GitHub 事故，2026年8月26日（https://www.githubstatus.com/history） ## 网络 虽然我喋喋不休地谈论饱和，但并非每起重大事故都涉及饱和。你可能会遇到这样的情况：你所有的内部子系统都报告正常，但从客户的角度看，你的网站宕机了：他们无法使用。一种可能的原因是用户甚至无法访问你的网站，这就引出了网络问题领域。 网络问题可能导致数据包被错误路由。这些请求可能被*黑洞化*（即被静默丢弃），或者被错误地路由到一个没有足够容量响应所有请求的服务上，这样你就同时面临网络路由问题和饱和问题。 [](https://surfingcomplexity.blog/wp-content/uploads/2026/08/image-3.png)真实黑洞的可视化描绘。图片来源：NASA (https://science.nasa.gov/resource/black-hole/) ### DNS DNS问题就是此类网络相关故障模式的一个例子。如果客户端甚至无法确定将数据包发送到哪个IP地址，那么这些数据包就绝无可能到达目的地。当DNS故障时，情况正是如此。 我提到DNS，是因为它已经给人们带来了足够多次的麻烦，以至于有一首著名的俳句： [](https://surfingcomplexity.blog/wp-content/uploads/2026/08/image-1.png) 更普遍地说，网络是一种无处不在的风险，因为云软件本质上是分布式的，因此网络始终是一项关键服务。虽然我不从事网络工作，但从外部来看，网络领域进行运维操作似乎总是充满风险。网络问题的影响范围（爆炸半径）可能非常大。并且，由于网络行为本质上是分布式的，推理运维变更的行为本来就困难重重。老实说，这可能就是我不从事网络工作的原因。 因此，我预测我们将继续看到网络问题导致大规模事故。 示例：Buildkite 事故，2026年8月25日（https://www.buildkitestatus.com/incidents/tm6746k61p73） ## 安全 可用性和安全性之间存在根本性的权衡：可用性关乎确保合法用户能访问系统，而安全性则关乎确保恶意用户无法访问系统。这意味着，旨在阻止恶意行为者访问系统的安全系统，始终存在同时阻止合法用户的风险。考虑这个场景：一个内部安全子系统变得不健康（可能是由于饱和）。当该子系统报错时，你的策略是“默认拒绝”（fail closed）还是“默认允许”（fail open）？回答这个问题需要进行可用性-安全性的权衡。 ### SSL证书过期 这种故障模式的另一个例子，反复困扰着我们的行业，就是SSL证书过期。这里，一个安全系统因证书未续期而阻止了合法访问，其行为本身成为了故障源。 Bazel过期证书 (https://surfingcomplexity.blog/wp-content/uploads/2025/12/image-4.png) 即使是强大的Google也会遇到SSL证书过期问题。此图来自Bazel事故 因此，我的论点是：涉及安全子系统的可用性事故将永远存在。 示例：Bazel 事故，2025年9月27日（https://surfingcomplexity.blog/2025/12/27/the-dangers-of-ssl-certificates/） ## 必要的非常规变更 你的系统在不断变化。说真的，如果你停止变更，系统最终将无法正常运行。当然，有些变更你的组织进行得非常频繁。希望你经常部署、频繁切换功能开关等等。但也有其他一些变更，你的组织经验较少，因为它们发生的频率低得多。这意味着，支持这类变更的工具投入不足，执行这些变更的人员也缺乏进行常见变更时的专业知识。这使得这类变更更加危险：工具不成熟，人员经验不足。 ### 缓解运维问题 几年前，我写了一篇题为《可靠系统为何失效之猜想》（https://surfingcomplexity.blog/2017/06/24/a-conjecture-on-why-reliable-systems-fail/）的文章，推测了导致重大事故的两个常见因素。其中一个因素是***旨在缓解小规模事故的手动干预***。当然，你可能经常需要通过手动干预来缓解系统问题，在这种情况下，你对这类干预会有丰富的经验。但你也更有动力投入工程努力，将这类常见问题自动化。 正是那些*非常规*问题，需要人工操作员干预来解决，才尤为危险，因为它们不常见。但它们又是必要的：系统出了问题，你需要修复它！但由于所有实践者的操作都是赌博（https://www.adaptivecapacitylabs.com/HowComplexSystemsFail.pdf），手动缓解存在风险，你可能让问题变得更糟。最终，这种情况总会发生。 示例：Azure 区域性中断，2026年7月23日（https://surfingcomplexity.blog/2026/08/16/quick-thoughts-on-azure-regional-outage-from-july-23-26/） ### 迁移 如果你在科技公司工作，除非是初创公司，否则你都会处理迁移工作，用更新、更适合当前组织所面临问题的技术来替代旧技术。虽然迁移作为一个类别极其常见，但每次迁移本身都是独一无二的。这意味着迁移工作的具体细节是一项*非常规变更*。迁移工作涉及对你的系统进行一种你之前未曾做过的变更。 更糟糕的是，迁移的一个危险之处在于，随着进程推进，你会开始相信你的变更是安全的，但系统中实际上潜伏着下一次迁移的隐藏危险。对工作安全性的信心超过了实际的安全水平。我的意思是，你在迁移过程中进行了n-1次变更，没有一次变更带来负面后果。人们自然会假设第n次变更也会产生同样的结果。 示例：Rogers网络中断，2022年7月8日（https://surfingcomplexity.blog/2024/07/06/quick-takes-on-rogers-network-outage-executive-summary/） ## 必要复杂性之必要增长 已故的美国计算机科学家弗雷德·布鲁克斯写过一篇著名的软件工程文章，题为《没有银弹》（https://worrydream.com/refs/Brooks_1986_-_No_Silver_Bullet.pdf），其中区分了*偶然复杂性*和*必然复杂性*。其核心思想是，软件系统中存在一部分不必要的复杂性（偶然复杂性），以及一部分由问题空间和解决方案空间本质所决定、因而无法消除的复杂性（必然复杂性）。 ### 可靠性子系统 我们已经开发出多种技术来提高软件系统的可靠性，包括重试、并发限制、自动扩缩、自动故障转移、熔断器、健康检查、金丝雀发布、异常点检测等等，不一而足。所有这些技术有一个共同点：它们都增加了整体系统的复杂性！它们必须增加复杂性才能履行其职责。这是阿什比定律（https://surfingcomplexity.blog/2026/01/31/ashby-taught-us-we-have-to-fight-fire-with-fire/）的一个结果，该定律指出，如果你想构建一个能处理更多场景的控制系统，你必须增加控制器本身的复杂性。 这意味着可靠性子系统会导致复杂性的权衡。一方面，我们的系统现在可以自动从以前需要手动干预的故障模式中恢复。另一方面，众所周知，复杂性的增长本身就很危险，因为它可能引入以前不存在的全新故障模式。 回到我的*猜想*博文，我提出的第二个因素是：***以提升可靠性为主要目的的子系统的意外行为***。这正是其原因。添加可靠性子系统提升了我们系统的*鲁棒性*，但也为系统增加了必然复杂性，这可能导致新的事故。 示例：OpenAI 事故，2024年12月11日（https://surfingcomplexity.blog/2024/12/14/quick-takes-on-the-recent-openai-public-incident-write-up/） ### 迁移 和所有工程师一样，当有人问我是否应该做X或Y时，我非常喜欢给出“视情况而定”这个答案。然而，如果有人走到我面前说：“Lorin，我正准备在公司做一次迁移，我在考虑是做一次性迁移还是增量迁移”，那么我几乎肯定会说：“看在上帝的份上，请做增量迁移！”有时候一次性迁移不可避免，但如果有选择，我会选择增量迁移，因为它更安全。 但是，当你进行增量迁移时，意味着在迁移过程中，你需要同时支持旧系统和新系统。这意味着即使新系统相比旧系统最终能降低总体复杂性，在迁移期间，你也会看到系统复杂性的*增加*。而这就意味着，作为复杂性增长的副产品，事故将会出现。 示例：Cloudflare 事故，2025年7月14日（https://surfingcomplexity.blog/2025/07/21/cloudflare-and-the-infinite-sadness-of-migrations/） ## 事故不可避免，你最好做好准备 重申一下，我认为这里提到的所有风险都是*无处不在*的：它们是云软件本质固有的。我不认为这些风险中的任何一个可以被消除。这就是为什么我如此坚信提升事故响应能力的价值。因为，如果你做好了准备，你就能更好地应对由这些风险引发的问题。