云软件中无处不在的可用性风险
我利用这篇帖子整理了一些我在阅读关于重大云软件事件的文章后注意到的一些共同线索。作者云软件我指的是软件即服务（SaaS）（现在还有人说这个吗？在云端。这不仅适用于云服务提供商，但也适用于他们。
以下是本文主题的概述：
- 问题领域
- 饱和度
- 示例：数据库
- 网络（流量路由故障）
- 示例：DNS
- 安全性（拒绝有效访问）
- 示例：SSL 证书
- 饱和度
- 非标准的必要变更
- 缓解操作问题
- 迁徙
- 本质复杂度的必增
- 可靠性子系统
- 迁徙
我把这些都认为是无处不在的可用性风险我认为这些问题从根本上是不可避免的，并且会在软件事故中持续到永远;或者至少，直到我自己在软件领域的职业生涯结束。
大多数重大事件大致归入三个领域：饱和、网络和安全。那么，我们先从这些开始。
饱和度
饱和度这大概是我最常谈论的话题，两者都是在这个博客里以及其他地方（例如：该饱和柱我为软件韧性基金会撰稿，我的饱和演讲在“软件应当可工作”会议上）。
该系统变为饱和当它达到极限时。这描述很普通，但极限其实很多！
数据库
许多重大事件都涉及系统组件以某种形式出现饱和。我个人最担心的是数据库饱和。这是因为从过载的生产数据库中恢复非常困难。此外，由于数据库系统极其复杂，甚至很难确定具体的性能问题是什么。
这就是为什么拥有内部数据库运营专业知识至关重要。
饱和是一个无处不在的风险，因为资源的有限性是我们所生活的世界里的一个硬性限制。最终，你系统中的某些资源会耗尽。
人脉网络
虽然我不停地谈论饱和，但并非所有重大事件都涉及过于拥堵。你可能会遇到所有内部子系统报告健康，但从客户角度看，你的网站瘫痪了：他们无法使用。
一种情况是用户甚至无法访问你的网站，这正是网络问题的体现。
网络问题可能导致数据包被错误路由。这些请求可能包括黑洞（即无声丢弃），或者它们可能被错误路由到无法响应所有这些请求的服务上，这种情况下你会同时遇到网络路由问题和饱和问题。
DNS
DNS 问题就是这种网络相关故障模式的一个例子。如果客户端连发送到哪个 IP 地址都无法确定数据包，数据包根本不可能到达目的地。
当 DNS 出问题时，事情就是这样发生的。
我提DNS是因为它已经让很多人吃过不少次，甚至有一句著名的俳句：
更广泛地说，网络是一个无处不在的风险，因为云软件本质上是分布式的，所以网络始终是关键服务。我不从事网络工作，但从外部看，网络在进行运营工作时感觉像是一个危险的领域。
网络问题的爆炸半径可能非常大。而且，由于网络行为本质上是分布式的，推理操作变化的行为本身就很困难。说实话，这大概也是我不从事网络工作的原因。
因此，我预测我们将继续看到网络问题导致大规模事件。
安全性
可用性和安全之间存在一个根本性的权衡：可用性是确保好人能够访问系统。安全则是确保坏人无法访问系统。这意味着总存在一个风险，一个设计用来防止恶意行为者访问系统的安全系统，可能导致好人也被屏蔽。
考虑这样一个场景：有一个内部安全子系统出现了不健康状态（可能是由于过于饱和）。当该子系统出现错误时，你的策略是关闭失败还是关闭？
回答这个问题需要在可用性和安全之间做出权衡。
SSL证书过期
另一个反复困扰我们行业的失败模式例子是SSL证书过期。这里有安全系统的行为，因为它阻止了合法访问，因为证书没有被续期。
所以，我的观点是，涉及安全子系统的可用性事件将永远存在。
本质的非常见变更
你的系统一直在不断变化。说实话，如果你停止做改动，系统最终也会无法正常工作。现在，有些改动是你们组织非常频繁的。希望你们经常部署，频繁切换功能标志等等。
但有些变更你的组织经验较少，因为它们发生频率要低得多。这意味着支持这类变更的工具投资不够多，也意味着做这些改动的人没有像处理常见改动那样的专业水平。
这让这类改动更危险：工具不够成熟，人员经验也不够。
缓解操作问题
几年前，我写过一篇标题为关于可靠系统为何失败的猜想我推测了两个共同导致重大事件的因素。其中一个因素是这是一项旨在减轻小事故的人工干预.当然，你可能经常需要手动干预来缓解系统问题，这时你会有很多这类干预的经验。
但你也会更有动力投入工程努力，自动化解决这些常见问题。
正是不常见需要人工操作员介入以缓解的问题是危险的，因为它们并不常见。但它们是必不可少的：系统中存在问题，你需要解决它！但是因为所有从业者的行为都是赌博手动缓解存在问题变得更严重的风险。
最终，这种情况会发生在你身上。
迁徙
如果你在科技公司，除非是初创公司，否则你会遇到迁移，因为旧技术会被更适合你组织当前问题的新技术取代。虽然迁移作为一个普遍类别非常常见，但每次迁移本身就是一个“雪花”。
这意味着迁移工作的具体细节是不寻常的变化.迁移的工作涉及对系统进行前所未有的改变。
更糟糕的是，迁移的一个危险是，随着进展，你开始建立起对更改安全的信心，但系统中实际上潜藏着下一次迁移的潜在风险。对工作安全的信心超过了实际安全。
我的意思是，你在迁移过程中做了n-1的更改，这些更改都没有产生负面后果。很自然地会假设同样的结果会发生在第N改变。
本质复杂度的本质增加
已故的美国计算机科学家弗雷德·布鲁克斯写过一篇著名的软件工程论文，题为没有银弹他区分了以下两项偶然复杂性以及本质复杂性。总体思想是，软件系统中存在一定程度的复杂性，这些复杂性并非必须存在（偶然复杂性），同时也存在于问题空间和解决方案空间的本质中固有的复杂性，因此无法被消除（本质复杂性）。
可靠性子系统
我们开发了多种技术来提升软件系统的可靠性，包括重试、并发限制、自动扩展、自动故障切换、断路器、健康检查、金丝雀、异常值检测，等等。
这些技术有一个共同点：它们增加了整个系统的复杂性！它们之所以这样做，是因为它们必须增加复杂度才能完成任务。这是阿什比定律该规则指出，如果你想构建一个能处理更多场景的控制系统，就必须提高控制器本身的复杂度。
这意味着可靠性子系统带来了复杂度的权衡。一方面，我们的系统现在可以自动从以前需要人工干预的故障模式中恢复。另一方面，众所周知，复杂度的增加本身就是危险的，因为它可能引入之前不存在的全新故障模式。
回到我的猜想我提出的第二个贡献者是：一个主要目的是提升可靠性的子系统的意外行为.这正是原因所在。增加可靠性子系统可以提升鲁棒性但这会为我们的系统带来本质性的复杂性，可能导致新的事件。
迁徙
像所有工程师一样，如果有人问我该做X还是Y，我很喜欢回答“这要看情况”。然而，如果有人走过来对我说：“Lorin，我正在准备公司做一次迁移，正在考虑是做一次大规模迁移还是增量迁移”，那么我几乎肯定会说：“看在上帝的份上，请做一次增量迁移！”有时候大规模迁移是不可避免的，但当有选择时，我会选择增量迁移，因为它是更安全的选择。
然而，当你进行增量迁移时，意味着在迁移过程中，你需要同时支持旧系统和新系统。这意味着即使新系统整体复杂度相较于旧系统净降低，迁移过程中你仍会看到增加在系统复杂性方面。
这意味着你会看到事故作为复杂性增加的副产品产生。
意外难免，你最好做好准备
再强调一次，我认为这里提到的所有风险都是无处不在它们是云软件本质的基础。我认为这些风险都无法被消除。这就是为什么我坚信提升事件响应能力的价值。
因为只要你做好准备，就能更好地应对由此带来的问题。
点赞
收藏
点踩
分享