互联网 P0 故障频发背后：云架构的 15 个致命陷阱

云计算改变了我们构建和运行系统的方式，为我们提供了可提高可靠性的托管服务。但这种灵活性也意味着小错误会迅速蔓延，一个错误的设置、缺失的标签策略或错误的扩展规则都可能同时影响多个环境。，这些问题很快就会变得代价高昂或风险巨大。

许多团队都会遇到“类似”的问题……不是因为他们粗心大意，而是因为云平台的运行方式与传统的本地系统不同。

本期内容将带您了解云环境中的 15 个常见陷阱。

每个部分包含：

• 陷阱——快速示例或模式

• 为什么会发生这种情况——是什么设计缺陷导致了它

• 架构影响——它会影响系统的哪些部分

• 如何预防——避免方法

目标很简单：设计能够适应变化而不是被变化击垮的系统，并构建即使出现问题也能保持可靠的系统。

孤立资源是指不再使用但仍在运行的云资产。

例如：

• 未连接的存储磁盘

• 未使用的公共IP地址

• 旧照片

随着时间的推移，它们会不断堆积，耗费“金钱”，并使仪表盘变得杂乱无章……从而使跟踪重要内容变得更加困难。

一个典型的例子是，在大型且昂贵的虚拟机上运行概念验证程序，却忘记将其关闭或删除。虚拟机持续运行，账单不断增长，直到有人注意到为止。

云平台让创建新资源变得轻而易举，但删除资源通常需要手动操作，而且人们很容易忘记。由于每项资源都有成本，即使是少量残留资源也会累积成一笔不小的开支。如果资源没有被追踪记录，就没有人知道哪些可以安全删除。

孤立资源会使资金流向难以追踪，也可能造成安全风险。例如：

• 被遗忘的测试虚拟机可能仍然保存着凭据

• 防火墙规则中可能仍然允许旧的IP地址通过

• 残留的快照可能包含敏感数据

• 使用标签：所有者、用途和到期日期

• 自动清理未使用的或过期的资源

• 按标签和资源使用年限分组，定期发送成本报告

• 在每个项目的“完成”清单中添加清理工作

• 安排自动扫描以查找并删除旧资源

被遗忘的资源会悄无声息地浪费钱，而配置错误则会迅速导致系统崩溃。

配置错误是云事故最常见的原因之一。

一个错误的设置或缺失的规则都可能影响可靠性、安全性或成本。而且，其影响往往会在人们察觉之前就已经扩散开来了。

例如：

• 自动扩缩容限制错误

• 存储未启用加密

• 一个存储桶意外被设置为公开状态

• 复制粘贴模板而不检查差异

当这些模式自动化时，一个错误就会在多个账户或地区被放大。

云服务提供数百种设置：权限、扩展规则、加密选项、网络控制等等。

团队经常依赖默认设置，或者在未进行审查的情况下在不同环境之间复制设置。当基础设施即代码( IaC )模板包含错误时，每次使用该模板时，这些错误都会传播。

快速的发布周期让情况变得更糟，几乎没有时间可供审核。

配置错误可能导致：

• 将敏感服务暴露给公众

• 性能不稳定

• 禁用加密

• 打破缩放逻辑

• 增加成本

由于云自动化会大规模推送变更，因此一个微小的错误就可能在几分钟内影响整个生产环境。

• 对配置进行版本控制，审查并测试每一次更改

• 使用策略即代码工具（Terraform Validate、AWS Config、Azure Policy）

• 检测配置偏差并自动强制执行合规性

• 为生产系统和非生产系统保持清晰的配置基线

• 持续监控异常情况或安全警报

强大的配置固然有用，但前提是团队必须有效沟通。下一个挑战不在于代码，而在于协调。

云系统依赖于开发、运营、安全、网络和财务团队之间的有效协调。

如果他们不清楚地分享信息，各种假设就会发生变化，所有权就会变得不明确，问题就会在生产后期才显现出来。

例如：

• 网络团队为了合规性更新了路由规则，但没有通知依赖该网络的数据工程师

• 第二天，管道就崩溃了——不是因为程序错误，而是因为一个团队不知道另一个团队做了哪些更改

云项目涉及多个专业领域：

• 开发者专注于功能

• 运营重点在于可靠性

• 安全工作的重点在于合规性

• 每个团队使用的工具不同，优先事项也不同

如果团队之间信息共享不清晰，关键细节就会丢失。团队可能不清楚哪些工作负载比较重要，或者具体变更会对成本或性能产生哪些影响。

沟通不畅会导致：

• 重复服务

• 架构不一致

• 未能整合的管道

• 未经完整说明就批准了安全例外情况

• 身份和访问管理 ( IAM ) 角色冲突

事故发生时，没有人知道哪些东西属于谁，这会减慢响应和恢复速度。

• 明确每个系统或账户的所有权和联系人

• 保留共享文档和架构决策记录 ( ADR )

• 对关键基础设施或成本变更进行跨团队评审

• 鼓励“自己建设，自己运营”的理念

• 使用一致的标签、命名和共享的沟通渠道（共享仪表板等）

沟通不畅常常导致团队走捷径，例如依赖单一工具解决所有问题，但这种做法可能会适得其反！

许多团队认为，单一的云平台、监控工具或自动化系统就能满足所有需求。

起初感觉效率很高：

但随着系统的发展，这种方法限制了灵活性……而且带来的问题比解决的问题还要多。

例子：

• 团队统一采用了一种部署工具，该工具适用于虚拟机（但不支持容器）

• 于是开发者开始编写自定义脚本来填补这些空白，环境也逐渐分离

• 因此，追踪变化变得困难

云工具发展迅速，许多云工具都以“一体化”解决方案的名义进行销售。

面临简化或降低成本压力的团队通常会选择单一工具来完成所有事情：可观测性 、CI/CD、安全、部署等等。

起初，在单一平台上管理和培训员工似乎更容易。但随着时间的推移，难度会逐渐增加：

• 该工具无法扩展到多个账户

• 它在混合云或多云环境中表现不佳

• 它缺乏新服务所需的功能

最初的“简单”最终变成了僵化。

过度依赖单一工具可能导致：

• 隐藏依赖项

• 对多云或混合云的支持不足

• 如果该工具失效，系统的大部分部件都会损坏

• 指标缺失，尤其是对于较新的工作负载而言

• 创新缓慢，团队等待着可能永远不会实现的功能

• 选择工具时，要考虑其是否合适，而不仅仅是是否标准化

• 随着架构的演进，定期审查工具使用情况

• 使用 API 和模块化管道进行互操作性设计

• 限制使用的工具数量。此外，按用途（监控、基础设施即代码、部署）对工具进行分组，并明确分配责任人

仅仅依赖单一工具是有风险的。然而，当人们对云计算的实际运作方式缺乏了解时，就会出现更深层次的问题。

许多云问题源于对云实际工作原理缺乏了解：从计费和扩展到数据传输和网络。

如果没有这些知识，即使是设计良好的系统也可能变得昂贵或不可靠。

例子：

• 一个团队构建了一个数据分析作业，每天在不同区域之间复制大型数据集

• 他们以为数据传输是免费的，就像在他们自己的数据中心一样

• 他们第一个月的账单显示，网络费用高于计算成本

云平台隐藏了许多基础设施细节。

虽然这简化了流程，但并不能免除责任。习惯了传统环境的团队期望的是固定成本和可预测的绩效。

但在云端，一切都是基于使用量的：

• 你存储了多少数据

• 你移动了多少数据

• 你处理多少数据

服务可以自动扩展，但并非总能如团队预期那样扩展。服务的描述与其在实际工作负载下的表现之间通常存在差距。

对云基数的理解不足会导致：

• 扩展速度过慢或过快的系统

• 存储使用效率低下（例如，将活跃数据存储在速度慢、价格低的存储层上）

• 数据传输和 API 调用中的隐性成本增长

• 对可靠性特征（例如区域冗余或最终一致性）的误解

• 这些问题可能导致高昂的成本、数据丢失或可用性风险

• 尽早使用成本计算器和负载测试

• 在扩大规模之前，先构建并测试小型原型

• 了解 SLA 、扩展机制和区域数据流

• 在入职培训和架构评审中加入平台培训

• 测试系统在故障或高负载情况下的运行情况

对平台的误解往往会导致在云端照搬旧的数据中心模式，这可能会限制使用云计算的优势。

一个常见且代价高昂的错误是将云视为传统的数据中心。

许多团队在迁移虚拟机、网络和防火墙时，并未更改其设计，这样做看似安全可靠，但却忽略了云的关键优势，例如弹性、自动化和托管服务。

例子：

• 一家公司将其数据中心虚拟机和网络直接复制到云端

• 成本增加，更新仍然需要手动操作，扩展能力有限

• 只有在迁移到托管数据库和自动扩展组之后，系统才变得高效

大多数迁移都是在时间紧迫的情况下发生的，团队将会选择最快的方法：将他们的本地环境迁移到云端，以避免重新设计工作（“迁移”策略 ）。

但如果这些旧习惯继续下去，如：

• 手动修补

• 固定大小的服务器

• 严格网络区域

就会给平台带来技术债务，而该平台会对单元使用的每个资源（时间/调用/执行）收费。

在云端重建本地环境可能会导致：

• 对托管服务的利用不足

• 固定规模基础设施成本高昂

• 由于需要人工维护，可扩展性有限

• 与云原生设计相比，其弹性较弱

• 过度依赖基于网络的安全而非基于身份的访问控制

这些问题使得系统更难扩展、运行成本更高、恢复速度更慢。

• 逐步实现现代化：从小处着手，慢慢迭代

• 在能够减少工作量的地方采用云原生服务

• 使用身份和角色作为主要安全边界

• 设计时要考虑灵活性和模块化，以便系统能够不断发展

• 开展试点项目，测试扩展、恢复和自动化模式

迁移到云端后，架构和可视性变得至关重要，如果没有妥善的管理，即使是小型部署也可能变得混乱不堪。

如果没有明确的治理，即使是构建良好的云环境也会很快变得混乱。

当资源名称不明确、缺少标签或未受到监控时，成本会增加，所有权也会变得不明确。

团队无法回答诸如此类的简单问题：

例子：

• 一家公司发现，其每月账单的一半是由于未跟踪的计算实例和未使用的存储空间造成的

• 它们都没有标签或有意义的名称

• 花了数周时间才查明所有权

• 只有在添加了标签规则和成本仪表盘之后，他们才能安全地移除不必要的资源

在云计算采用过程的早期阶段，团队更注重速度而不是结构。

它们快速创建资源，但没有标准标签或名称。随着环境扩展到各个项目和地区，这些缺失的细节就会成为一个问题：

• 监控和成本预警功能添加得太晚了

• 没人知道哪个虚拟机支持生产环境

• 或者哪个存储桶属于一个已停用的项目

因此，环境变得难以理解。

缺乏治理会导致：

• 信息不透明，所有权不明确

• 安全团队无法追踪暴露的资源

• 财务部门无法将成本与业主或项目联系起来

• 未追踪的资源堆积起来，造成资金浪费

• 由于缺少标签和名称，自动化工具运行失败

• 使用清晰一致的命名规则

• 将治理视为核心架构，而不是清理工作

• 集中管理所有账户的监控、成本报告和警报

• 使用治理工具（AWS Config、Azure Policy、GCP Organization Policies）

• 明确强制性标签标准：所有者、环境、用途、成本中心和有效期

良好的治理可以提高可见性，但并不能保证安全，尤其是在团队过度依赖网络边界而忽视身份和访问控制的情况下。

在传统数据中心中，网络边界通常是第一道防线：

但在云端，这种模式不再适用，身份和权限如今定义了真正的安全边界。然而，许多团队仍然主要依赖网络规则，而忽略了身份识别。

例子：

• 一家公司将工作负载隔离在私有子网中

• 但他们赋予了自动化工具广泛的权限

• 当 CI/CD 凭证泄露时，攻击者可以直接通过 API 访问数据

• 网络虽然保持关闭状态，但身份访问权限足以造成损害

来自本地环境的团队通常会将同样的基于边界的思维模式带到云端。

他们继续使用：

• VPN

• IP地址允许列表

• 紧密子网

这种方法或许适用于小型部署环境，但云环境瞬息万变，许多服务（例如无服务器函数和托管数据库），完全运行在固定网络之外。

过度依赖网络控制会导致：

• 安全盲点

• 严格的规则阻碍了有效的沟通

• 配置错误的防火墙暴露了内部系统

• 无法防范基于身份的攻击（最常见的安全漏洞类型）

• 将身份（IAM 角色、服务帐户、最小权限策略）视为第一道防线

• 将网络规则用作额外的保护层，而不是核心安全层

• 应用零信任原则：根据身份和上下文验证每个请求，而不是根据位置

• 定期审查访问路径并使用自动化策略验证工具

• 对于敏感服务，优先选择私有端点和托管连接，而不是自定义 VPN

稳固的安全基础固然重要，但韧性也需要灵活性。静态的设计一旦环境发生变化，就会失效。

云系统旨在适应各种变化：

但许多团队在设计架构时，仿佛一切都不会改变。静态、僵化的设计乍看之下可能很稳定……但一旦工作负载、连接或平台功能发生变化，它们就会失效。

例子：

• 一款采用固定虚拟机集群和手动扩展的应用程序

• 在季节性高峰期，性能急剧下降，因此工程师不得不手动增加容量

• 切换到自动扩展（有限制）和无服务器处理后，系统在空闲期间自动处理负载并“降低成本”

来自本地部署环境的团队通常秉持“设置好就不用管了”的心态，他们沿用旧有的模式：

• 硬编码限制

• 固定大小的集群

• 手动部署

有时，内部规则（例如审批流程过长或担心自动化出错）也会减缓变革。其结果是，系统虽然能够应对当前的流量，但却无法随着需求的增长而扩展。

静态设计会导致：

• 可扩展性差

• 交通高峰期的交通事故

• 事件发生期间恢复缓慢

• 低流量期间浪费了钱

• 随着服务的发展而逐渐过时的基础设施

他们也不鼓励测试和实验。

• 弹性设计：自动伸缩、无服务器和事件驱动模型

• 使用基础设施即代码实现灵活且可重复的部署

• 使用蓝绿发布或金丝雀发布进行版本配置和测试更改

• 随着使用情况和平台功能的演变，应定期审查架构

• 引入混沌测试来验证系统如何应对故障

系统无法适应环境变化是一个问题。但即使是灵活的系统，如果开发环境与生产环境过于相似，也会造成浪费。

当两个环境使用相同的实例大小、保留规则和权限时，结果不是更好的控制；而是不必要的成本和降低的灵活性。

开发环境应该是一个安全的测试想法的环境，而不是生产环境的完全复制品。

例子：

• 每个测试堆栈都使用相同的计算层、可观测性工具和存储

• 一家公司将其整个生产流程复制到开发流程中，以“保持流程一致”

• 几个月内，研发成本就达到了生产成本的近一半

为了避免意外情况，团队通常会将生产环境的设置复制到开发或测试环境中。但在云端：

• 广泛的权限

• 长期保留规则

• 严格的生产政策

而且相同的配置会减慢开发速度，增加成本，并限制实验。

对所有环境一视同仁会导致：

• 未使用的数据堆积

• 权限过大导致秘密泄露

• 昂贵的开发资源带来的高昂成本

• 严格的规定阻碍了快速测试或实验

• 缓慢而僵化的设置，在版本发布之间几乎没有增加任何价值

• 对于非生产环境，请使用较小、更便宜的实例类型

• 设置开发环境和生产环境不同的权限级别

• 制定单独的预算、数据保留规则和访问策略

• 使用匿名化或合成数据代替生产数据

• 根据每个环境的用途调整监控和警报设置

• 使用明确的参数为每个环境（开发、测试、生产）自动配置

随着业务规模的扩大，跨账户追踪成本变得越来越困难。缺乏透明度，支出就难以解释和控制。

只有当有人实际跟踪云成本时，云成本才会变得清晰可见。

许多团队几个月都不知道资金的去向。这会迅速削弱财务和领导层对团队的信任。

例子：

• 一个项目将大型数据集存储在多个存储桶中

• 如果没有成本报告，没有人注意到存储和数据传输成本的增长速度，比计算成本的增长速度更快

• 在添加了标签规则和成本仪表板之后，团队发现了未使用的数据集，并大幅降低了每月账单

云计费提供详细信息，但过程较为复杂。

成本分摊到各项服务、地区和账户中，如果没有合理的结构，就很难了解谁在花多少钱。

常见原因：

• 禁止标记

• 没有集中报告

• 没有共享仪表板

如果只注重速度而不跟踪成本，就会造成“神秘支出”，每个人都认为其他人正在监控使用情况。

成本透明度不足会导致：

• 优化工作进展缓慢或停滞不前

• 过度配置或闲置的资源保持在线状态

• 设计和规模化决策脱离了财务现实

• 存储和自动扩展选项的成本超出预期

• 团队不敢删除资源，因为不知道会造成什么影响

• 明确各团队的成本责任

• 按成本中心、所有者和环境标记资源

• 使用内置的成本工具（AWS Cost Explorer、Azure Cost Management、GCP Billing Reports）

• 为每个项目或帐户设置预算、预测和异常警报

• 在架构和运营会议上定期审查成本数据

• 添加仪表盘，显示支出趋势和绩效指标

成本透明度差往往会掩盖浪费，其中一个常见原因是收集了过多的数据。

作者丨Magdalena    编译丨Rio

来源丨网址：https://newsletter.systemdesign.one/p/cloud-system-design?utm_source=profile&utm_medium=reader2

dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn