云工程师
云工程师决定一个系统在云服务商这一层由什么构成：使用哪些托管服务、网络与账号如何划分、谁被允许做什么、设计如何撑过一次并非自己选择的故障，以及由此产生的账单是什么样子。这些决策做起来成本很低，回头修改却代价高昂。本指南说明这一学科包含哪些工作、哪些情形需要它，以及在一个认证容易、判断力不容易的领域里，真正的深度体现在哪里。
云工程师做什么？
云工程师设计、搭建并运维系统在云服务商内部运行所依赖的基础设施：账号与网络拓扑、身份与权限模型、在托管服务与自建组件之间的取舍、让系统在某个可用区或地域发生故障时仍然可用的安排，以及这一切所产生的支出。这个角色面向云服务商层——它关心基础设施由什么构成、如何配置，而不是把软件交付到其上的流水线，也不是其他工程师用来接触它的内部工具。
云服务商不是可以互相替换的主机托管。每一家都提供数百项服务，各有不同的计费方式、配额、故障特性和安全语义；一个稳健的设计与一个昂贵的设计之间，差别很大程度上就在于选了哪些服务、以及它们是怎么连起来的。这里的价值大多在于知道一项托管服务真正保证了什么、又在不声张地不保证什么，以及日后若要离开它需要付出什么。
难度集中在身份模型上。早期授予的权限事后很少被收窄，而一份凭据一旦泄露能造成多大破坏，取决于角色和信任关系当初是怎么设计的。各家云服务商对这套模型的表达方式差异足够大，经验并不能干净地迁移；因此，一位能够精确推理一条策略最终如何生效、以及一个账号的边界究竟停在哪里的工程师，处理的正是整个环境里事后最难纠正的那一部分。
成本属于工程，而不属于财务。公网出流量、跨可用区流量、闲置的预置容量、存储类型、留存策略，以及常驻算力与按请求计费算力之间的选择，都是在架构阶段定下来的，却要到很久以后才出现在账单上。到那个时候，决策已经嵌进设计里了，而常见的应对是去谈折扣而不是改架构——这处理的是账单，原因仍然留在原地。
团队在什么时候需要这项能力
云基础设施常常是由应用工程师为解决眼前问题而顺手搭起来的，这种做法一直有效，直到需要做出一个结构性决策为止。以下这些节点，说明缺少云服务商层的深度已经开始变得昂贵。
迁移已经进入计划阶段，而不再只是被讨论
迁移一个既有系统，会迫使团队做出一个原本很容易拖延的决定：尽量原样复刻现有架构，还是围绕托管服务重新塑形。两条路都成立。而如果是一项服务一项服务地、在无意之间做出选择，最后得到的往往是后者的成本结构，加上前者的运维负担。
账号结构是长出来的，不是设计出来的
所有东西共用一个账号，环境之间靠命名约定区分，还有好几个人手上握着能影响生产环境的凭据。一旦出错，没有任何东西能把影响圈住；而事后再补一道边界意味着搬迁正在运行的资源，这也正是它一再被推迟的原因。
支出已经变得既不可预测，也无法归因
账单的增速快过用量，而没有人说得清是哪个团队、哪个功能或哪个环境造成的。缺少归因，唯一可用的手段就是笼统地要求少花钱——这最终落在最谨慎的人身上，而不是落在最浪费的地方。
可用性承诺首次被写成了明文条款
一份客户合同或一项监管要求带来了明确的恢复目标。把它们落成可用区与地域拓扑、复制方式的选择、备份可恢复性的验证，以及一次真正执行过的故障切换，是专门的工作；而写在文档里的方案与被验证过的方案之间的落差，正是组织认清自己真实位置的地方。
权限被授予的次数，远多于被复核的次数
权限在故障处理、迁移和新人入职的过程中不断累积，却没有一项被收回。现在没有人说得清谁能读取生产数据库，而要回答这个问题，需要读的是策略如何判定，而不是一份用户名单。
第二家云服务商或一个受监管的地域进入了范围
数据驻留规则、某个客户要求特定司法辖区，或者一次并购带来了另一家云服务商。每一种情形都会引出同一类问题：身份联邦、网络互通、数据流动，以及用哪些抽象才能让两套环境同时保持可理解。
核心能力
云服务商层架构
依据负载的真实形态——请求量、突发程度、数据引力、延迟容忍度——来选择计算模型、存储类型和托管服务，并且知道云服务商的抽象在哪里开始不再匹配应用真正需要的东西。
网络设计
地址规划、子网与路由结构、与其他环境之间的私网互通、受控的出网流量以及负载均衡。一旦有负载落在网络上，网络就成了最难重新规划的东西之一，因此这里的决策会比大多数决策留存得久得多。
身份与访问（IAM）
设计角色、策略和信任关系，让最小权限来自结构本身，而不是来自事后复核。这包括与企业目录做身份联邦、用工作负载身份替代长期存储的密钥，以及在多条策略同时适用时，清楚一次访问判定最终如何得出。
托管服务的取舍判断
判断什么时候直接使用云服务商提供的服务，什么时候自己运行这个组件。托管服务降低运维负担，同时加深耦合，因此推理必须涵盖它保证了什么、在预期用量下要花多少钱，以及日后迁走要付出什么。
数据存储与生命周期
按访问模式选择合适的持久化存储，有意识地制定留存与归档策略，验证备份能够恢复而不只是能够生成，并且对复制语义了解到足以说清一次故障切换会丢失什么。
韧性与恢复设计
把对停机时间和数据丢失的容忍度表达为明确的目标，再据此设计可用区与地域拓扑，并演练故障本身。一套从未执行过的恢复流程只是一份文档，而文档在压力之下的表现和系统并不一样。
云服务商的安全模型
传输中与静态数据的加密、密钥管理与轮换、凭据的存放、网络隔离，以及能够整类杜绝配置错误的组织级护栏。它同样意味着清楚云服务商的责任在哪里结束、客户的责任从哪里开始。
环境可见性
把云服务商的指标、流日志、审计记录和配置历史收集成事后能够回答问题的形式：改了什么、谁改的、这个资源之前是什么样子。云服务商自带的监控擅长回答预先定义好的问题，对没有预料到的问题则很吃力，这正是审计历史与看板同样重要的原因。
成本工程
通过标签和分摊让支出可以归因，按观测到的而不是假设的负载做规格调整，有意识地选择承诺型计费工具，并把出网流量和跨可用区流量当作设计输入。最大的节省来自架构，而不是来自采购。
迁移执行
安排迁移的顺序，让系统在整个过程中保持可用：依赖梳理、数据搬迁与对账、带明确回退路径的切换，以及把没有人记录过的东西清点出来这类不体面的活儿。迁移失败在无人记录的部分上，远多于失败在技术部分上。
技术生态
以下列出云工程领域常见的技术。这描述的是该学科在业界的一般实践，而不是对任何特定工程师技术栈的说明。由于每家云服务商对等价概念的命名各不相同，考察一个人如何推理网络、身份与故障，比核对他认得清单上的哪几个名字更有信息量。
云服务商
- AWS
- Google Cloud
- Microsoft Azure
- Alibaba Cloud
- Oracle Cloud
计算与运行时
- EC2
- Compute Engine
- AWS Lambda
- Cloud Run
- Azure Functions
- EKS, GKE and AKS
网络与边缘
- VPC
- Route 53
- Cloud DNS
- CloudFront
- Transit Gateway
- Private Link
身份与安全
- AWS IAM
- Google Cloud IAM
- Microsoft Entra ID
- AWS Organizations
- KMS
- Secrets Manager
数据与存储
- S3
- Cloud Storage
- RDS and Aurora
- Cloud SQL
- DynamoDB
- BigQuery
资源供给与编排
- Terraform
- CloudFormation
- Bicep
- AWS CDK
- Pulumi
治理与成本
- AWS Config
- Azure Policy
- Cost Explorer
- Billing export
- Infracost
- OpenCost
这个角色如何与您的团队协作
工程师在您的团队内部工作，遵循您的优先级和标准。日常开发方向由您掌握，Talent.ID 负责雇佣关系。下面的分工就是全部安排。
由您掌握
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
由 Talent.ID 负责
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
实际协作大致是这样
这是一个假设场景，用于说明协作方式如何落地。它并不描述 Talent.ID 的客户或已完成的项目。
- 挑战
- 某个组织在单一云服务商上运行着一套不断增长的环境，早期的决策已经开始形成约束。各环境共用一个账号，权限被授予的次数多于被复核的次数，支出无法归因到任何一个团队，而一项新的客户承诺又带来了当前拓扑当初并未按此设计的可用性要求。
- 做法
- 新增的基础设施工程力量在团队已经确定的架构原则之下加入，在团队既有的资源供给流程、账号约定和变更流程之内工作。设计方案由日后要与之共处的内部工程师评审，整改工作则按团队自己商定的优先级排定顺序。
- 为团队带来什么
- 架构决定权和安全责任仍然留在该组织手里，团队因此获得余量去处理那些一直被搁置的结构性工作。哪些取舍可以接受，由承担商业后果的人来判断。
相关领域
常见问题
- 云工程师和 DevOps 工程师有什么区别？
- 云工程师专精于云服务商这一层：账号与网络如何组织、身份如何授予与判定、系统依赖哪些云服务商的服务、当某个可用区或地域发生故障时它如何表现，以及这一切要花多少钱。DevOps 工程师专精于把变更送到既有基础设施之上——流水线、部署策略、发布自动化，以及发布之后的反馈。一个学科关心系统由什么构成，另一个关心变更如何抵达它。规模较小的组织会把两者合在一个人身上；环境更大之后，这两种深度就装不进同一个岗位了。
- 云工程师和平台工程师是一回事吗？
- 不是，尽管两者经常被混淆，因为它们都位于应用之下。云工程交付的是满足某项要求的基础设施：拓扑、权限、韧性、支出。平台工程交付的是一套面向基础设施的界面，为那些本来也能自己搭起来的内部工程师而建，评判标准是他们是否愿意采用。平台一般叠加在云工程已经打好的基础之上，所以在一个本身就不成体系的环境上盖一层平台，得到的是一个整洁的外壳，背后原有的每一个问题都还在。
- 我们应该同时使用多家云服务商吗？
- 很少是主动选择，更多是形势所致。有意为之的多云，大致会让一个组织需要理解的面翻倍——两套身份模型、两套网络模型、两套故障表现——换来的是更强的议价位置，以及一个大多数组织从未真正用上的可移植选项。数据驻留规则、客户的硬性要求、一次并购或者一项确实存在的监管义务，都能成为它的理由。而以云服务商宕机作为理由则很少成立，因为增加的复杂度往往比它避免的停机造成更多停机。
- 云认证能说明多少问题？
- 它们能确认一个人研读过某家云服务商的服务清单，并且能回忆起这些部件本应如何拼合，这是一条实实在在的基线，在职业早期也确实有价值。它们不能说明这个人是否设计过一套经受住考验的权限模型、是否见过故障切换的实际表现与文档不符、是否把一笔意料之外的费用追查到了源头。把认证当作准备程度的证据，而不是判断力的证据，把面试时间花在判断力上。
- 云环境里的安全由谁负责？
- 云服务商负责底层基础设施的安全；客户负责配置、身份、网络暴露面、数据保护，以及构建在其上的一切。几乎所有被公开报道的云上数据暴露事件，都落在这条线的客户一侧——一个比预期更宽的权限、一处可从公网访问的存储、一份提交进代码仓库的凭据、一个方便但并不安全的默认值。一位说不清自己所用服务的这条边界在哪里的工程师，身上带着一个他可能并未意识到的缺口。
- 云工程师能把我们的支出控制住吗？
- 能起到一部分作用，而在为此招人之前，值得先了解它的边界。真正的降本通常需要架构层面的改动——存储类型与留存策略、流量路径、把闲置容量迁到按请求计费的算力上、下线没有人使用的东西——而这需要拥有这些系统的团队投入工程时间。如果把这个角色安排成一个处理成本工单和权限申请的队列，它每个月会产出一份报告，实际改变很少。如果允许它把归因暴露出来并提出设计改动建议，它才能影响到底层的趋势。
- 云工程师如何与现有的工程团队协作？
- 技术团队扩展意味着工程师加入您的团队内部，而不是在旁边并行推进。您的架构原则、账号规范、安全策略和迭代优先级约束着这项工作，由您的人决定构建什么以及按什么顺序构建。Talent.ID 负责雇佣关系、薪资发放和员工福利，以及人才管理和持续的员工关系。
告诉我们您的团队需要什么
描述一下缺口——工作内容、技术栈、团队的运作方式——我们会告诉您能支持到什么程度。如果这不是我们能帮上忙的事情，我们会直说。