3.11 云架构

概述与动机

云计算就是通过网络按需租用他人的基础设施，按使用量计费，用完即释放。云架构这门学科，讲的是如何设计系统，把这些租来的资源当作它们与生俱来的家，而不是把它们当作你旧数据中心的一份租来的翻版。这一区别正是本章的全部要点所在。你可以把一个遗留应用迁移到云服务商那里，对其设计完全不做改动，得到的结果会是一张更大的账单，以及大致相同的脆弱性。又或者，你可以为云而设计，从而获得弹性伸缩能力、能够抹去整整一类无差异化工作的托管服务，以及在无需惊动任何人的情况下扛过整栋建筑物故障的能力。本章直接建立在第 3.1 章基础之上：云架构就是架构，只是把同样的权衡取舍和质量属性，应用在一个你并不拥有的基底之上。

对于大型团队来说，利害关系更高，因为云重新划定了谁该做什么。当一个团队能在几分钟内配置出一个数据库、一个队列和一个全球负载均衡器时，瓶颈就不再是采购，而变成了治理：成本、安全，以及数十个团队同时这样操作时的一致性。云给每一位工程师都配了一张公司信用卡和一整间仓库的强力工具，这既美妙又危险，程度相当。把架构做对，意味着既要捕获其中的好处（速度、弹性、韧性），又要设置好护栏，把支出、安全态势和数据驻留控制在可控范围内。

企业和政府对这两面感受都格外强烈。企业带着数十年积累下来的既有系统入场，所以它们的上云故事通常是一个迁移故事，充满了混合连接和艰难的自建还是购买的抉择。政府则额外背负着主权、授权制度，以及依法不能离开特定国境的公民数据这份重担。这里做出的决策（选择哪种服务模型、涉及多少家服务商、故障域划在哪里、哪些用托管服务运行、哪些用自己的代码运行）会在长达十年的时间里塑造成本和风险。

关键原则

为云而设计，而不是给你的数据中心拍一张照片。 弹性伸缩、托管服务和故障域意识，正是你选择上云的理由；照搬照抬会把这些好处全部丢掉。
一切都以代码方式配置。 如果是人手点出来的，它就是未经记录、不可复现、也无法审计的。
有意识地跨故障域进行设计。 区域、可用区和服务都会发生故障；你的架构决定了这究竟只是耸耸肩，还是一次服务中断。
责任共担模型是一份合同，不是一句口号。 清楚知道服务商守卫的是哪条线，你自己守卫的又是哪条线。
购买无差异化的部分，自建有差异化的部分。 托管服务在管道类工作上物有所值；把你的竞争优势留在自己手里。
锁定是一项需要定价的成本，而不是一种需要回避的罪过。 可移植性是有代价的，杠杆效应也是有价值的；要有意识地做决定，而不是凭反射动作。
成本是一项一等质量属性。 在云上，架构决策和账单是同一个决策。

建议

有意识地选择服务模型，默认倾向托管服务

云服务商沿着一个由 as-a-service 模型所构成的谱系进行销售：基础设施即服务（IaaS）出租原始的计算、存储和网络资源；平台即服务（PaaS）出租一个托管运行时，让你部署代码而无需照料服务器；软件即服务（SaaS）出租成品应用。无服务器计算，包括函数和托管的事件驱动服务，把这一趋势推得更远：你只需提供代码或配置，服务商负责处理所有的资源配置，闲置时自动缩容到零。谱系上每往上走一级，就是用控制力换取杠杆效应，从控制力最强、运维负担也最重的 IaaS，一直到两者都最少的无服务器。

默认策略应当是在需求允许的范围内，尽量往这个谱系的高处走。一个负责打补丁、备份、故障切换和扩容的托管数据库，几乎总是比自己运维的数据库更能善用你的工程师。把更底层的 IaaS 留给那些真正需要它的场景：专用硬件、特殊的合规边界、许可限制，或者托管方案无法满足的性能要求。把理由写成一份架构决策记录（第 3.1 章），因为”我们自己运行消息代理”这样的主张，应当每年都被重新论证一次。

把跨区域和跨可用区当作明确的故障域来设计

云区域是一个地理区域；在其内部，可用区是物理上相互独立的数据中心，各自拥有独立的电力、制冷和网络，彼此近到足以进行低延迟复制，又远到足以让一个故障不会波及其他可用区。这些正是云出现裂缝的接缝所在，所以你的架构必须把它们当作一等公民来对待。任何认真对待的工作负载，基线都应当是多可用区：把计算和数据分布在至少两个、理想情况下三个可用区上，这样失去一个可用区只会造成容量下降，而不会造成服务中断。这是一份便宜的保险，很少有好的理由可以跳过它。

多区域是一个更重的决策，与你的韧性和恢复目标（第 3.5 章）以及你的灾难恢复计划（第 9.5 章）紧密相关。跨区域分布能买来对整个区域故障的抵御能力，并能让数据更靠近用户，但它也带来了真实的成本、延迟和一致性问题，因为跨区域同步复制速度很慢，而异步复制则意味着在故障切换时要接受数据丢失。要基于明确的恢复时间目标和恢复点目标来做决定，而不是出于一种模糊的”希望高可用”的愿望。大多数系统需要健壮的多可用区能力和一条经过测试的多区域恢复路径；真正需要跨区域主动 - 主动架构的系统很少，而那些在不需要的情况下构建了它的系统，则每天都要为这份复杂性买单。

把责任共担模型当作一条架构边界来对待

云安全建立在责任共担模型之上：服务商守卫云本身（物理设施、虚拟机监控程序、托管服务的内部实现），而你守卫你放进云里的东西（你的数据、访问控制、网络配置和代码）。这条确切的分界线，会随着你在服务谱系上向上攀升而移动。使用 IaaS 时，你要给操作系统打补丁；使用托管数据库时你不需要，但你仍然要负责谁可以连接、数据是否加密。代价最高昂的事件，往往源于误读了这条分界线，最著名的例子就是那种因为有人以为服务商默认就会把它设为私有，结果导致数百万条记录泄露的公开存储桶。

在你的设计中把这条边界明确写出来，具体细节交给第 4.3 章，那里深入讨论了基础设施和云安全。从架构角度看，这些原则是恒定不变的：默认对静态数据和传输中的数据进行加密，通过身份而非网络位置来授予最小权限，让任何单一凭证的影响范围保持较小，并假设任何可从互联网访问的资源都会在几分钟内被探测到。把这些原则内置到你的登陆区（landing zone）中，让各团队自然而然地继承它们。

在受治理的登陆区内，把一切都以代码方式配置

在一套成熟的云实践中，不应有任何生产资源是因为有人在控制台上点了一下才存在的。一切都通过基础设施即代码（第 8.2 章）来声明，接受版本控制、评审，并通过流水线来应用，这样你的基础设施就是可复现、可审计、可比对差异的。正是这一点，让多可用区、多区域和灾难恢复变得真实，而不只是一种愿望：你可以在一个新区域中搭建出一个完全相同的环境，因为这个环境是一段程序，而不是一段记忆。

把这些代码包裹在一个登陆区里：一个预先搭建好、受治理的基础，涵盖账户（或订阅、项目）、网络、身份、日志和护栏，每个团队都在此基础上构建。使用独立的账户作为影响范围和计费边界，这样一个团队的失误就无法波及另一个团队的数据，每一分钱都能追溯到一个负责人。把护栏作为”策略即代码”来强制执行，阻止被禁止的配置（一个公开的数据库、一个未加密的卷、一个位于不允许区域的资源），而不是依赖事后的评审。登陆区通常由一个中央平台团队负责，这把本章与平台工程（第 8.4 章）以及容器和云原生运行时（第 8.3 章）联系了起来。

诚实地为锁定定价，并对多云保持怀疑

供应商锁定是切换服务商的代价，它是一个谱系，而不是一个二元选择。使用某服务商的托管队列会造成一定程度的锁定；使用其专有的机器学习平台则会造成很大程度的锁定。对锁定的本能恐惧，会驱使团队牺牲真正的杠杆效应（让云值得使用的那些托管服务），去保留一种他们永远不会真正行使的可移植性。诚实的做法是给它定价：对每一项重要的依赖关系，估算离开的真实代价，并将其与该服务当下为你节省的成本进行权衡。为了保持可移植性而对一项托管服务做抽象封装，往往会永久性地付出比你所防范的那次迁移本身更高的代价。

这就是为什么真正意义上的多云（把同一个工作负载运行在两家服务商上）通常是一种形式主义，而不是一项战略。它会把你压到最低公分母的水平，让你的运维面翻倍，并成倍增加你的团队必须掌握的专业知识（）所有这些，都只是为了对冲一种很少真正发生的风险。触碰不止一家服务商确实存在正当理由：来自第二家供应商的最佳同类 SaaS 产品、监管机构提出的韧性授权要求，或者一项刻意的主权要求（第 10.11 章）。混合云（）让部分系统留在本地、并与云连接（）在企业迁移过程中，以及对于依法不能迁移的数据来说，往往是不可避免的。要带着清醒的认知和一份书面理由来选择这些方案，而不是因为某张幻灯片上写着”多云”。

为成本而架构，并采纳”架构良好”思维方式

在云上，一项架构决策就是一项支出决策：出于”以防万一”而过度配置，会体现在下个月的账单上。把成本当作一项你要为之设计的质量属性，并采纳 FinOps 实践（）一门为云支出共担财务问责的学科（第 9.4 章）（）让工程、财务和产品共同为账单负责。给每项资源打上负责人标签，让成本按团队、按服务可见，持续进行资源适配，使用自动伸缩以便按负载而非按峰值付费，并利用云所提供的定价杠杆（承诺使用折扣、用于可中断工作的竞价容量）。

除了成本之外，把”架构良好”框架当作一份评审清单来使用。各主要服务商都各自发布了一份这样的框架，它们都收敛到同一组支柱上：可靠性、安全性、成本优化、性能效率、运维卓越，以及可持续性。在设计阶段以及之后定期运行一次轻量级评审，依据每根支柱为系统打分，并把发现的差距记录为可跟踪的工作项。这是一种发现你没注意到的权衡取舍的廉价方式。

权衡：优缺点

方式	优点	缺点
照搬迁移（重新托管）	快速、初期投入低、能迅速退出数据中心	保留了旧有的脆弱性，错失了弹性和托管服务，往往成本更高
云原生重新设计	完全的弹性、韧性、托管服务的杠杆效应	前期投入和所需技能更高；需要消化更大的变化
单一云、深度集成	简单、杠杆效应最大、运维面更小	锁定和服务商风险集中
多云（同一工作负载、两家服务商）	对冲服务商故障风险、增加谈判筹码	设计被压到最低公分母、运维和专业知识要求翻倍
混合（云加本地）	满足数据驻留和遗留系统约束、可分阶段迁移	网络复杂性、需要同时运行两套运维模型
无服务器 / 高度托管	繁重劳动最少、可缩容到零、交付速度快	控制力较弱、与特定服务商绑定、存在冷启动和配额限制

核心张力在于控制力与杠杆效应之间的取舍，这条线贯穿每一行。你交给服务商的越多，你行动得越快、需要运维的也越少，代价是耦合程度更深。解决办法不是选定一个极端，而是有意识地为每个工作负载做定位：对通用管道类工作，尽量往托管谱系的高处走；在控制力真正物有所值的地方，保持在较低的层级；并从两个方向都给锁定定价，而不是把可移植性当作免费的东西、把依赖当作一种罪过。大型组织陷入麻烦的原因，往往是让恐惧（对锁定的恐惧、对云的恐惧、对成本的恐惧）凭反射做出这个选择，而不是通过分析来做出选择。

与团队讨论的问题

我们哪些工作负载属于照搬迁移，我们是不是在为数据中心式的架构支付云端的价格？ 在截止日期压力下进行迁移、原样重新托管一切并宣布胜利，是很常见的做法，随后却发现账单比数据中心时代还高，而韧性或弹性方面的好处一个都没实现。诚实的审计方法是列出你的主要工作负载，把每一个都标注为重新托管、重新平台化，还是真正经过了重新设计，然后看看哪些仍然运行在固定规模、常年开机、单可用区的形态下。部分照搬迁移是合理的第一步，所以问题不在于你是否这样做了，而在于你是否有计划和时间表进一步推进。带来每个工作负载的成本和事件历史，因为那些既昂贵又脆弱的工作负载，正是重新设计回报最快的地方。如果迁移一年后一切看起来仍然是旧数据中心的样子，你只是买了一个更贵的数据中心。
当一个可用区或整个区域发生故障时，实际会发生什么，我们测试过吗？ 许多团队相信自己有韧性，仅仅因为他们部署到了云上，却从未真正设计过自己的故障域，也从未真正拔过插头去检验。具体化的版本是：对于每个关键系统，它跨越了多少个可用区，有文档记录的恢复时间目标和恢复点目标是多少，我们上一次进行拔掉一个可用区的游戏日演练，或演练一次区域恢复，是什么时候？多可用区应当是那种不值一提的基线配置，所以任何仍在单可用区运行的关键工作负载都是一项需要关注的发现；多区域则是一个更重、代价更高的决策，应与明确的恢复目标挂钩，而不是默认采用。带来你的依赖关系图，因为真正造成伤害的故障，往往来自一个共享服务（一个数据库、一个身份提供方），而它的故障域从来没有人真正梳理过。从未测试过的韧性只是一个假设，而不是一项属性。
对于我们最深度的几个服务商依赖关系，离开的真实代价是多少，为了避免它而付出这个代价值得吗？ 关于锁定的争论往往基于意识形态而非数字，一派把每一项托管服务都抽象封装起来以保持可移植性，另一派则完全忽视集中化风险。把它落到实处：挑出你依赖最深的三项，估算替换每一项所需的真实工程成本和耗时，并将其与该服务今天为你节省的成本，以及你真正会切换的可能性进行权衡。再叠加上那些可移植性无法解决的风险，例如监管机构要求一个第二来源，或者一条关于数据可存放在何处的主权规则，因为即使纯粹从经济角度看不划算，这些因素也可能为多云或混合方案提供正当理由。目标是针对每一项依赖关系形成一个明确的、书面的立场，而不是一条一刀切的政策。一旦你把它定价出来，你会发现大多数令人畏惧的锁定，接受起来其实比为规避它而构建的抽象层要便宜。
我们自己在运行哪些服务，而服务商本来乐意替我们运维，这个选择在工程师工时上花费了我们多少？ 云的全部杠杆效应，就在于把打补丁、备份、故障切换和扩容这些事，交给以此为全职工作的人去做，然而团队却常常出于习惯或错位的自豪感，坚持自己运维一个数据库、消息代理或搜索集群。对大型组织来说，这带来的代价不只是一个团队的繁重劳动，而是同样的无差异化运维工作，在十几个角落被各自重新发明了一遍，每一处都意味着一套待命轮值和一个漂移的源头。与之相抗衡的考量是真实存在的：专用硬件、许可条款、特殊的合规边界，或者托管方案无法满足的性能要求，都可能为留在谱系较低层级提供正当理由，所以答案应当逐个服务判断，而不是一刀切。带来一份自运维服务的清单、每一项在维护和事件处理上消耗的工程师工时，以及托管替代方案的价格，并要求每一个”我们自己运维”都配一份每年重新论证一次的架构决策记录。在企业和政府环境中，还要追问自运维的选择究竟是真正的合规或许可约束，还是仅仅披着约束外衣的惯性，因为审计人员和预算负责人会问同样的问题。
我们能否看清每个团队和每项服务这个月花了我们多少钱，是否有一个具名的人对这个数字感到负责？ 云支出往往悄悄膨胀，因为同样的那种自助服务能力，让一名工程师能在几分钟内配置出一个全球数据库，也同样让他能让它永远以峰值规模运行下去，而任何单独一行账单看起来都不会显得触目惊心。在一个没有按团队、按服务提供成本可见性的大型组织中，财务部门往往会在几个月后才发现问题，而反应通常是一刀切的冻结，把自律的团队和浪费的团队一并惩罚。这里的张力是真实的：追逐每一分钱会拖慢交付，所以目标应当是问责和资源适配，而不是紧缩，把成本当作一项你要为之设计的质量属性，而不是一份事后才读的报告。带来一份按团队划分的成本明细、未打标签或无法归因的支出占比、当前利用率相对于已配置容量的情况，以及承诺使用折扣或竞价容量哪些还没被用上。对企业和政府机构来说，要把这一点与 FinOps 实践以及公共支出审查联系起来，因为一项未打标签的资源，不仅仅是浪费，更是一个等着被发现的审计问题。
一个团队现在能否创建一个公开的数据存储、一个未加密的卷，或者一个位于禁区的资源，而我们甚至根本不会发现？ 大多数代价高昂的云事件都是配置错误，而不是服务商被攻破，而责任共担模型意味着，泄露的存储桶或对互联网开放的数据库，正正处于你这一侧的边界。在众多团队的规模下防范这一点，是一个登陆区层面的问题：把护栏作为”策略即代码”来强制执行，在被禁止的配置还没出现之前就将其阻断，而不是等记录已经泄露之后才靠事后评审去发现它们。与之相抗衡的压力是开发者自主性，因为过紧的护栏会把团队逼向影子账户，所以设计必须在防范真正危险的同时，留出足够的活动空间。带来一份实际强制执行的护栏清单、一次在真实账户中尝试配置不合规资源的诚实测试，以及防范失效时的检测延迟。在受监管和政府环境中，要把这一点与数据驻留和授权制度联系起来，因为一个位于禁区的资源不是一次风格违规，而是一次审计人员会当作可报告事件来处理的法律违规。

行业视角

初创企业。 从第一天起就在单一服务商上做云原生，并有意接受锁定。运行在能够缩容到零的无服务器和托管服务之上，让两名工程师就能掌管整个平台，因为你最稀缺的资源是注意力，而不是可移植性。严格控制支出上限，把一切都保持在基础设施即代码状态，这样一次爆火时刻就不会变成一次服务中断，并把这个刻意做出的锁定决策记录下来，留待规模扩大时重新审视，而不是假装它只是暂时的。

小型企业。 没有平台工程师，预算也紧张，所以要把云当作一种消费品，而不是需要自己运维的东西。优先选择 SaaS 和完全托管的服务，而不是任何需要自己运行的东西，依赖服务商的安全默认设置，并让托管数据库来处理备份和故障切换，这样就没人需要操心这些事。把这个选择诚实地框定为购买还是自建，且明显倾向于购买，设置一条账单告警，这样一个被遗忘的资源就不会拖垮整个月的预算，并且在动手搭建你根本没人手运维的服务器之前，先尝试低代码或托管方案。

企业。 你的上云故事，是一个横跨众多团队的迁移故事，所以架构问题本质上是一个治理问题。搭建一个受治理的登陆区，用按业务单元划分的账户作为影响范围和计费边界，配上默认加密的护栏，以及能阻止公开数据存储的”策略即代码”，并让一个中央平台团队负责这一基础。用按团队展示成本的方式运行 FinOps，用”架构良好”评审为重大设计把关，并管理好与那些多年内不会迁移的遗留记录系统之间的混合连接。

政府。 采购规则、透明度和主权塑造着每一项决策。部署到一个经授权的或政府专用的云区域，逐条为审计人员记录责任共担的边界线，并用”策略即代码”把存储和处理绑定在境内可用区、阻止任何位于禁区的资源。争取获得所需的授权制度认证，把审计证据保存为一份 git 历史记录而不是临时拼凑出来的材料，并优先选择服务商能够为其合规态势背书的托管服务，而不是你必须自行认证的定制基础设施。

示例

初创企业。 一家十二人规模的初创公司从第一天起就在单一服务商上进行云原生开发，且对此毫无负担感。API 运行在能够在一夜之间缩容到零的无服务器函数上，数据存放在带有自动备份和多可用区故障切换的托管 Postgres 中，后台任务运行在一个托管队列上。所有这一切都用基础设施即代码来定义，两名工程师就掌管着整个平台，因为服务商负责运维那些困难的部分。当一次爆火时刻在一小时内把流量推高五十倍时，自动伸缩机制吸收了这一冲击，账单也按真实使用量成比例上升，随后又回落。创始人有意接受锁定，把它当作用小团队快速前进的代价，并把这个决定记录了下来，留待规模扩大时重新审视。

企业。 一家拥有三百个遗留应用的跨国保险公司，按照”6R”框架（重新托管、重新平台化、重新购买、重构、淘汰、保留）推行一场为期多年的迁移。低价值的通用应用被迅速重新托管，以便在截止日期前退出两个数据中心；核心保单平台被重构为云原生架构；自研工具被以 SaaS 形式重新购买；过时的系统被淘汰。一个中央平台团队负责一个登陆区，配有按业务单元划分的账户、默认加密的护栏，以及能阻止公开数据存储的”策略即代码”，而混合连接则把云与那些多年内不会迁移的大型主机记录系统连接起来。成本通过一套按单元展示费用的 FinOps 实践来治理，每个应用的生产上线都要经过一次”架构良好”评审。

政府。 某国负责提供公民福利服务的机构，依法必须把居民数据保留在国境之内，并运行在经授权的基础设施上。它部署到该服务商的政府云区域，并按照美国的 FedRAMP（相关合规工作见第 4.6 章）之类的制度申请授权，逐条为审计人员记录责任共担的边界。数据驻留和更广泛的主权顾虑（第 10.11 章）推动了一种架构，把存储和处理绑定在境内可用区，并通过”策略即代码”阻止任何位于禁区的资源。该系统跨越三个可用区，配有经过测试的跨可用区恢复计划，并把一切都以代码方式配置，因此审计证据是一份 git 历史记录，而不是临时拼凑出来的材料。

商业理由：动机、投资回报率与总体拥有成本

云计算最引人注目的承诺，是把资本性支出转变为运营性支出：不再需要提前数年购买服务器、然后以较低的利用率运行它们，你只需为使用量付费，并随业务一起伸缩。这是真实的好处，但更深层的回报在于速度和专注度。一项能够抹去打补丁、备份和故障切换工作的托管服务，把这些工程师工时归还给了产品工作，而以分钟而非数月为单位完成资源配置，压缩了从想法到生产的时间。弹性伸缩意味着你不再需要为一年只用两次的峰值容量付费。当架构做对了，这些好处会复利累积成一个在成本和能力两方面都胜过数据中心的总体拥有成本。

把这件事做错的代价同样真实，所以商业理由必须诚实。不经重新设计的照搬迁移，往往会推高成本，却一项好处也没实现，而不受治理的支出可能会在数十个团队中悄悄膨胀，直到财务部门拉响警报。向领导层论证时，围绕三个杠杆展开：速度（更快的交付和更短的资源配置周期）、韧性（更少、更短的重大事件），以及可选性（无需一个数据中心项目就能进入一个新市场或新区域）。为省下的数据中心更新换代成本、为通用基础设施减少的编制人数，以及避免的服务中断分钟数标上数字，并将其与迁移成本以及持续的 FinOps 和平台投入进行对比。最有力的论据很少是单纯的成本节省，而是比仍在等待硬件到位的竞争对手更快行动所带来的期权价值。

反模式与陷阱

照搬迁移却称之为”上云”。 把一个数据中心式设计重新托管到租来的基础设施上，只承担了成本，却没有获得任何好处。
控制台点出来的基础设施。 手工创建的资源不可复现、未经记录，也无法恢复或审计；把任何手动的生产环境变更都当作一个缺陷来对待。
形式主义式的多云。 把同一个工作负载运行在两家服务商上，去对冲一种罕见的风险，却每天都要为复杂性和最低公分母式的设计买单。
单可用区的”高可用”。 相信云默认就是有韧性的，却在一个可用区内运行关键工作负载，且从未经过故障切换测试。
误读责任共担。 以为服务商会守卫那些实际上归你负责的部分，这是导致公开存储桶泄露数百万条记录的经典路径。
把成本当作事后才想起的事。 设计时不考虑支出，随后才发现是账单替你做出了架构决策。

成熟度模型

第 1 级，启动： 云的使用是临时性的、被动反应式的。团队在共享账户中随手点出资源，工作负载是照搬迁移过来的，没有登陆区，没有成本可见性，韧性是被假定的，而不是被设计出来的。第一次严重的服务中断或账单冲击，会是一个意外。
第 2 级，发展： 基本实践开始出现，但因团队而异。一些核心基础设施以代码方式配置，一些工作负载运行在多可用区，少数账户已经分离，但覆盖并不均衡：服务模型和锁定方面的选择是凭习惯做出的，成本是事后才被关注的，护栏也不一致，多区域恢复从未测试过。
第 3 级，标准化： 一个配有”策略即代码”护栏的受治理登陆区，被记录成文档并在整个组织范围内强制执行。一个平台团队负责这一基础，所有生产环境都以代码方式配置，“架构良好”评审为重大设计把关，自建还是购买以及故障域方面的决策是经过深思熟虑并在所有团队中一致记录下来的。
第 4 级，管理： 整个资产按基线进行度量和控制。通过 FinOps 按目标跟踪每个团队和每项服务的成本，恢复时间目标和恢复点目标是经过验证的，而不仅仅是宣称的，护栏违规和配置漂移作为指标被呈现出来，资源适配由利用率数据驱动，每一次继续或叫停的决策都有来自成本、可靠性和安全仪表盘的证据支撑。
第 5 级，协同： 云架构持续改进，并与业务和风险规划相整合。故障域通过常态化的游戏日演练加以检验，资源适配和定价实现自动化，主权和数据驻留通过策略强制执行，服务模型和锁定立场按固定节奏重新定价，工作负载组合随着市场、定价和风险状况的变化而自适应地重新平衡。

讨论思路

你的各项主要工作负载，在从 IaaS 到无服务器这个谱系上分别处在什么位置，其中有没有哪些可以在不失去你真正需要的控制力的前提下，往更高处攀升，以摆脱运维上的繁重劳动？
如果你的主要服务商大幅涨价，或者遭遇一次持续数天的区域性服务中断，你真正的应对计划是什么，它是否证明了你所背负的任何多云或混合复杂性是合理的？
谁负责你的登陆区及其护栏，一个团队今天能否交付一项不合规的资源（公开数据存储、未加密的卷、禁区内的资源）？
对于一个受监管或涉及主权的工作负载，你能否在不进行一场紧急演练的情况下，就拿出责任共担的边界和经授权的配置作为证据？

关键要点

为云而设计，而不是给你的数据中心拍一张照片；弹性伸缩、托管服务和故障域意识，正是你选择上云的理由。
对通用工作，沿着服务模型谱系向托管和无服务器方向攀升；只在控制力真正物有所值的地方，才保持在较低层级。
把区域和可用区当作明确的故障域：多可用区作为基线，多区域则与经过测试的恢复目标挂钩。
在一个配有”策略即代码”护栏、独立账户，以及负责这一基础的平台团队的受治理登陆区内，把一切都以代码方式配置。
从两个方向诚实地为供应商锁定定价，除非有具体的监管、主权或最佳同类产品方面的理由，否则对多云保持怀疑。
通过 FinOps 把成本当作一项一等质量属性来对待，并运行”架构良好”评审，以发现你错过的权衡取舍。

参考文献与延伸阅读

Peter Mell 与 Timothy Grance，《The NIST Definition of Cloud Computing》（NIST Special Publication 800-145）
Amazon Web Services，《AWS Well-Architected Framework》
Microsoft，《Azure Well-Architected Framework》与《Cloud Adoption Framework》
Google Cloud，《Google Cloud Architecture Framework》
Stephen Orban，《Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT》（以及”6R”迁移策略）
J.R. Storment 与 Mike Fuller，《Cloud FinOps: Collaborative, Real-Time Cloud Financial Management》
Gregor Hohpe，《Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration》
U.S. General Services Administration，《FedRAMP》项目文档与安全基线
Cloud Security Alliance，《Security Guidance for Critical Areas of Focus in Cloud Computing》