云架构与 landing zone
我们设计其余一切都将继承的账号、订阅或项目结构：环境隔离、身份边界、网络分段与防护栏。结构的选取原则是，让被攻陷的工作负载或一次误操作的变更被限制在单一边界之内。云厂商的选择取决于工作负载和组织现有的技术资产，而不是个人偏好。
- AWS Organizations、Azure 管理组与 Google Cloud 文件夹
- 环境与工作负载的账号隔离
- 服务控制策略与组织策略防护栏
- 集中式身份管理，配合短时效的角色代入
- 用于成本归属的标签与负责人规范
能力
为工作负载而设计的基础设施，而不只是完成部署
我们在 AWS、Microsoft Azure 与 Google Cloud 上设计云平台，从应用的需求出发向外推导。网络、计算、数据持久性、恢复与成本都经过审慎决策，以代码编写，并通过自动化来运维。
概览
把应用部署到云上只是一件小事。设计它所运行的基础设施则是另一门学问：流量如何进入，状态存放在哪里，哪些部分可以彼此独立地失效，容量如何跟随需求变化，以及平台每单位工作量的成本是多少。早在任何应用代码被优化之前，这些决策就已经决定了可用性、延迟与安全性的上限。
我们的原则是：基础设施应当围绕应用需求、安全、韧性、性能与经济性来设计，按这个顺序逐项厘清，并让五者始终相互制衡。对延迟敏感的交易服务、批处理分析管道与 GPU 推理负载，需要不同的网络拓扑、伸缩信号与恢复策略。先搭一个通用的 landing zone，之后再把工作负载硬塞进去，得到的平台往往在无关紧要的地方花费高昂，在真正关键的地方却很脆弱。
我们构建的一切都以基础设施即代码来表达，通常使用 Terraform；各个环境由同一套模块创建，并通过流水线逐级晋升。这让平台可评审、可复现、可恢复：一个区域、一个账号或一个集群可以依据代码仓库重建，而不是凭记忆重建；每一次生产变更都有作者、有 diff、有回滚路径。
我们构建什么
技术领域
网络与流量管理
云网络同时决定了攻击面和延迟下限。我们设计地址规划、子网分层、通往托管服务的私有连接，以及一个请求从边缘到工作负载所经过的路径。负载均衡是分层的：边缘负责全局路由与 TLS 终结，区域入口负责七层路由，集群内部负责服务间流量。
- CIDR 规划互不重叠的 VPC 与 VNet 设计
- 私有端点、中转网关与对等连接
- 基于健康状态路由的四层与七层负载均衡
- 边缘的 CDN、WAF 与 DDoS 防护
- DNS 故障切换，以及基于延迟或权重的路由
- 通过 NAT 与显式允许列表控制出站流量
容器与编排
我们用 Docker 打包工作负载，并让它们运行在与其运维复杂度相称的编排层上。只有当 Kubernetes 的调度、扩展机制与多租户模型配得上其运维成本时才使用它；不值得时则使用托管容器服务。集群设计涵盖节点池、Pod 安全、资源请求与限制、中断预算以及升级路径。
- Amazon EKS、Azure AKS 与 Google GKE
- 基于 Fargate 的 Amazon ECS、Azure Container Apps 与 Cloud Run
- 使用 Helm 与 Kustomize 打包工作负载
- Pod 水平自动伸缩，以及基于 KEDA 的事件驱动伸缩
- 集群自动伸缩，以及基于 Karpenter 的节点供给
- Ingress 控制器、Gateway API，以及在确有必要时引入的服务网格
基础设施即代码与交付自动化
基础设施变更与应用代码走同样的评审、测试与晋升流程。Terraform 模块把组织的标准一次性固化下来，CI/CD 流水线则借助远程状态、锁与策略检查来执行 plan、校验与 apply。在控制台上的手工变更被视为漂移，会被检测出来，而不是被容忍。
- Terraform 与 OpenTofu，配合版本化的模块仓库
- 带锁的远程状态，并按环境隔离
- 在 pull request 中进行 plan 评审与策略检查
- 漂移检测与定期调谐
- 通过 Argo CD 或 Flux 以 GitOps 方式交付到集群
- 由同一套模块构建的临时预览环境
韧性、备份与灾难恢复
高可用与灾难恢复是两个不同的问题，需要各自的设计。可用性靠跨可用区冗余、健康检查与自动故障切换来保障；恢复则靠备份、复制以及一套演练过的异地重建流程。我们与业务方一起，为每个系统设定恢复时间目标与恢复点目标，然后设计出能满足这些目标且成本最低的架构。
- 默认采用多可用区部署
- pilot light、warm standby 与多区域 active-active 模式
- 跨区域数据库复制与时间点恢复
- 存放于独立账号中的不可变、版本化备份
- 定期的恢复测试与故障切换演练
- 随代码一同生成并维护的 runbook
可观测性、密钥与成本工程
只有状态可见、凭证受控，平台才谈得上可运维。我们通过 OpenTelemetry 为基础设施与工作负载采集指标、日志与链路追踪，并针对服务水平目标而非原始资源阈值来定义告警。密钥由托管的密钥存储签发并定期轮换；成本按服务、按环境进行跟踪，使架构决策能够在看得见价格的前提下做出。
- Prometheus、Grafana 与 OpenTelemetry collector
- 集中式结构化日志，并按保留期分层
- AWS Secrets Manager、Azure Key Vault、Google Secret Manager 与 HashiCorp Vault
- 以工作负载身份取代长期有效的访问密钥
- 资源规格优化、承诺用量规划，以及为可容忍中断的负载使用 spot 容量
- 单位成本仪表盘与预算告警
隐形的基础设施
衡量基础设施好坏的标准，是它对产品研发人员注意力的占用有多少。当一个团队合并一次变更之后，构建、部署、伸缩、监控乃至必要时的回滚都能自动完成，既不用打开控制台，也不用呼叫某位专家，基础设施就算尽到了职责。它并没有变得简单；复杂性只是被转移到了经过测试和版本管理的自动化之中。
要达到这种状态，需要把平台当作一个产品来对待，而工程师就是它的用户。部署是一条流水线，而不是一套操作规程。伸缩跟随能反映真实负载的信号，例如请求并发数或队列深度，而不是靠人盯着仪表盘。监控只在面向用户的目标面临风险时才发出告警。节点故障、可用区故障或一次有问题的发布，其恢复首先是一个自动化的控制回路，其次才是 runbook。
不这样做的代价，是以工程时间来支付的。手工配置环境的团队，会把精力耗费在抹平预发布环境与生产环境之间的差异上，而每一次事故都要从重新弄清系统是如何拼装起来的开始。由自动化来处理部署、伸缩、监控与恢复，就是把这些时间还给产品。
- 部署：每一次变更都经由同一条流水线、通过同样的检查进入生产
- 伸缩：容量在既定的最小值与最大值范围内跟随工作负载信号变化
- 监控：告警与服务水平目标挂钩，并附带 runbook 链接
- 恢复：故障的实例、Pod 与可用区无需人工介入即可被替换
架构
云平台架构
边缘
- DNS
- CDN
- WAF
- DDoS 防护
网络
工作负载与数据位于私有子网
- VPC
- 公有与私有子网
- 负载均衡器
- NAT 与对等连接
计算
- Kubernetes
- 容器
- Serverless 函数
- 自动伸缩
数据
- 托管数据库
- 缓存
- 对象存储
- 消息队列
平台服务
- 机密管理
- IAM
- 基础设施即代码
- 容器镜像仓库
可观测性与灾备
恢复要经过演练，而不是想当然
- 指标与日志
- 链路追踪
- 备份
- 多可用区故障切换
可用性是一笔预算，而不是一个配置项
每多一个 9 的可用性，无论在基础设施开销上还是在架构复杂度上，代价都比上一个更高。单区域、多可用区并带有自动故障切换的部署，可以承受一个数据中心的损失，适合大多数业务系统。多区域 active-passive 增加了对区域级故障的防护，代价是复制延迟和一次故障切换决策。跨区域 active-active 省去了故障切换这一步，却迫使每一个有状态组件去处理并发写入、冲突解决以及跨地域的一致性。
正确的设计从与业务方商定的两个数字出发：系统最长可以不可用多久，以及最多可以丢失多少最近的数据。恢复时间目标为四小时的系统并不需要 active-active，硬要去建只是浪费本可用于加固单区域的预算。恢复点目标接近于零的支付或交易系统，则需要区域内的同步复制，并且要对区域故障切换期间在途交易如何处置有一个经过严谨推演的立场。
未经测试的恢复计划只是一种假设。我们把恢复测试与故障切换演练纳入运维日程，因为从未恢复过的备份和从未承接过流量的备用区域，会以只有在真实条件下才会暴露的方式失败。
成本是一种架构属性
云成本在很大程度上是在设计阶段决定的。常驻实例还是可缩容至零的服务，跨可用区的频繁通信还是可用区感知路由，热存储还是按生命周期分层的存储，托管服务还是自行运维，这些选择在第一张账单到来之前就已经锁定了大部分费用。事后优化所能挽回的，只是审慎设计所能避免的一小部分。
在架构阶段，我们依据工作负载的预期形态，把成本与性能一并建模：平稳还是突发，延迟敏感还是批处理，有状态还是无状态。数据传输、NAT 网关流量、日志摄入以及闲置的非生产环境，是最常见的意外开销来源，而每一项都有成熟的设计对策。平台运行之后，通过标签把成本归属到服务与团队，让能够改变开销的人也能看到开销。
我们如何构建
我们的方法
我们分阶段从需求走到一个运行中的平台，每个阶段都产出可供评审的成果：一份文档、一个模块或一个环境。
- 01
明确工作负载需求
我们为每个系统梳理流量形态、延迟预算、数据分级、恢复目标、监管约束与预期增长。这些内容将成为衡量基础设施的验收标准。
- 02
设计目标架构
我们产出账号结构、网络拓扑、计算模型、数据放置方案与故障域图，并写明考虑过的备选方案及其被否决的理由。预期负载与峰值负载下的成本也在这一阶段估算。
- 03
以代码构建基础底座
landing zone、网络、身份与共享服务都写成 Terraform 模块，并通过流水线应用。防护栏与策略检查在第一个工作负载进入之前就已就位。
- 04
通过铺好的路径接入工作负载
服务被容器化，套用标准的部署模板，接入密钥、日志与指标，并通过 CI/CD 部署。第一个服务用来验证这条路径，后续服务直接复用。
- 05
验证韧性与容量
我们针对伸缩策略进行压测，终止实例与可用区以验证故障切换，并把备份恢复到一个干净的环境中。发现的问题在代码里修复，而不是写进某个 wiki 页面。
- 06
运维、度量与调优
服务水平目标、单位成本与容量余量按固定节奏进行评审。集群、基础镜像与 provider 版本的升级是排入计划的工作，而不是紧急事件。
取舍
决定设计走向的决策
在确定架构之前，我们会与您的团队逐一厘清的问题。
- 我们需要 Kubernetes，还是托管容器服务就够了？
- 如果运行的无状态服务数量不多，没有专职的平台工程师，需要的也不过是部署、伸缩与路由，就选择 ECS on Fargate、Cloud Run 或 Azure Container Apps 这类托管容器服务。如果需要自定义调度、面向有状态系统的 operator、多租户隔离、跨云厂商的可移植性或丰富的控制器生态，就选择 Kubernetes。只有当多个团队共用这个平台、并且有人对它负责时，Kubernetes 的运维成本才能收回。
- 单区域加快速恢复，还是多区域 active-active？
- 单区域横跨三个可用区，配合经过测试的备份与可重建的备用环境，能以很小一部分成本满足大多数系统的可用性目标。当区域级故障会突破恢复时间目标时，再采用多区域 active-passive。只有在用户分布于全球且对延迟敏感，或停机完全不可接受，并且数据层能够处理多写入方一致性时，才选择 active-active。
- 单一云厂商，还是多云？
- 除非有具体需求迫使你另作选择，否则应统一使用一家云厂商。这类需求包括：某家厂商未覆盖的司法辖区内的数据驻留要求、某项特定的托管服务，或合同义务。多云会让你需要维护的技能、工具与安全面成倍增加，而且通常只能使用各家功能的公共子集。要获得可移植性，通过容器、Terraform 与开放协议来实现，比同时在所有云上运行更好。
- 使用托管的数据库与消息服务，还是在 Kubernetes 上自行运维？
- 当云厂商在版本、扩展与配置上的限制符合你的需求时，PostgreSQL、Redis 与 Kafka 应优先选用托管服务；这样补丁、故障切换与备份就成了别人的 on-call 负担。当你需要托管产品不允许的扩展、调优或拓扑，或者规模化之后的费用明显超过自行运维的工程成本时，再选择自行运维。对这笔工程成本要如实做好预算。
- Serverless 函数、容器还是虚拟机？
- 函数适合事件驱动、生命周期短、流量呈尖峰状的工作，前提是缩容至零有价值且冷启动可以接受。容器适合流量平稳、需要可预测延迟或带有较复杂运行时依赖的长时间运行服务。当工作负载需要内核级控制、需要特定驱动的 GPU 等专用硬件，或使用与主机绑定授权的软件时，使用虚拟机。
- 伸缩应该由 CPU、请求速率还是队列深度来驱动？
- 应依据最接近用户感知负载的信号来伸缩。CPU 适用于计算密集型服务，但对 I/O 密集型服务反应滞后，后者以请求并发数或延迟作为触发条件更合适。异步 worker 应依据队列深度或消费延迟来伸缩。无论采用哪种信号，最小容量都要设置到足以承受一个可用区的损失，最大容量则要能保护下游数据库不被压垮。
生产就绪
怎样才算生产就绪
如何保障安全
工作负载运行在私有子网中，不直接暴露于互联网，通过私有端点访问托管服务，并以工作负载身份而非静态密钥进行认证。数据在传输中和静态存储时均加密，在数据分级有要求时使用客户自管密钥；组织级策略则杜绝公开存储、未加密卷和未经批准的区域。
如何扩展
无状态服务依据工作负载信号水平伸缩，其背后的集群或实例容量自动供给。有状态组件则通过只读副本、分区与连接池有计划地扩展，并由压测在生产流量触及之前先行摸清每一层的饱和点。
如何监控
指标、日志与链路追踪通过 OpenTelemetry 采集，并借助 trace 标识符在边缘、服务与数据层之间关联。告警依据服务水平目标的燃烧率（burn rate）触发，仪表盘则展示每个服务的饱和度、错误率、延迟与成本。
如何部署
基础设施变更在 pull request 中完成 plan，经过策略检查，由流水线应用，并记录在版本控制中。应用发布采用滚动、蓝绿或金丝雀策略，一旦健康状态或错误率出现退化即自动回滚。
如何集成
平台通过 VPN 或专线与既有环境互联，与企业目录进行身份联邦，并通过认证方式一致的 API 网关对外暴露服务。混合云与迁移场景通过分阶段切换与数据复制来处理，使系统的迁移不依赖某一次高风险的切换。
技术
根据工作负载和您现有的技术资产来选择。
- AWS
- Microsoft Azure
- Google Cloud
- Kubernetes
- Docker
- Terraform
- Helm
- Argo CD
- GitHub Actions
- Prometheus
- Grafana
- OpenTelemetry
- HashiCorp Vault
- Cloudflare
从零到生产
工程生命周期
- 01
想法
- 02
探索
- 03
系统架构
- 04
UX / 产品设计
- 05
应用工程
- 06
AI / 数据层
- 07
云基础设施
- 08
安全
- 09
质量保证与性能
- 10
部署
- 11
可观测性
- 12
持续演进
常见问题
常见问题
你们推荐哪家云厂商？
适合工作负载和组织本身的那一家。AWS、Microsoft Azure 与 Google Cloud 都提供了生产级平台所需的基础构件；真正有影响的差异在于特定的托管服务、区域覆盖、既有的企业协议，以及团队已经具备的技能。我们针对选定的厂商进行设计，并通过容器与开放接口保持应用层的可移植性。
你们能接手并改进现有的云环境吗？
可以。我们先评估当前的架构、安全态势、成本结构与运维实践，然后通过导入现有资源，逐步把整个环境纳入基础设施即代码的管理之下。改进工作按风险排序，使平台在底层被重建的同时保持正常运行。
你们如何对待云成本？
从第一次架构讨论起，就把它当作一项设计约束。我们估算预期负载与峰值负载下的成本，选择与工作负载形态相匹配的计算与存储模型，并通过标签把开销归属到各个服务。上线之后，再依据实测的利用率进行资源规格优化、承诺用量采购并应用生命周期策略。
一套灾难恢复设计包含哪些内容？
包括为每个系统商定的恢复时间目标与恢复点目标、能够满足这些目标的备份与复制架构、可以在另一个区域重建平台的基础设施代码，以及一份经过测试的 runbook。它还包括恢复测试与故障切换演练的日程安排，因为恢复能力不经演练就会退化。
基础设施建成之后，你们负责运维吗？
我们可以负责平台的运维，可以把它移交给内部团队，也可以在过渡期内与该团队并肩工作。无论哪种情形，交付物都包含他人接手运行所需的代码、文档与 runbook。