云工程师
云工程师决定一个系统在云服务商这一层由什么构成：使用哪些托管服务、网络与账号如何划分、谁被允许做什么、设计如何撑过一次并非自己选择的故障，以及由此产生的账单是什么样子。这些决策做起来成本很低，回头修改却代价高昂。本指南说明这一学科包含哪些工作、哪些情形需要它，以及在一个认证容易、判断力不容易的领域里，如何评估真实的深度。
云工程师做什么？
云工程师设计、搭建并运维系统在云服务商内部运行所依赖的基础设施：账号与网络拓扑、身份与权限模型、在托管服务与自建组件之间的取舍、让系统在某个可用区或地域发生故障时仍然可用的安排，以及这一切所产生的支出。这个角色面向云服务商层——它关心基础设施由什么构成、如何配置，而不是把软件交付到其上的流水线，也不是其他工程师用来接触它的内部工具。
云服务商不是可以互相替换的主机托管。每一家都提供数百项服务，各有不同的计费方式、配额、故障特性和安全语义；一个稳健的设计与一个昂贵的设计之间，差别很大程度上就在于选了哪些服务、以及它们是怎么连起来的。这里的价值大多在于知道一项托管服务真正保证了什么、又在不声张地不保证什么，以及日后若要离开它需要付出什么。
难度集中在身份模型上。早期授予的权限事后很少被收窄，而一份凭据一旦泄露能造成多大破坏，取决于角色和信任关系当初是怎么设计的。各家云服务商对这套模型的表达方式差异足够大，经验并不能干净地迁移；因此，一位能够精确推理一条策略最终如何生效、以及一个账号的边界究竟停在哪里的工程师，处理的正是整个环境里事后最难纠正的那一部分。
成本属于工程，而不属于财务。公网出流量、跨可用区流量、闲置的预置容量、存储类型、留存策略，以及常驻算力与按请求计费算力之间的选择，都是在架构阶段定下来的，却要到很久以后才出现在账单上。到那个时候，决策已经嵌进设计里了，而常见的应对是去谈折扣而不是改架构——这处理的是账单，原因仍然留在原地。
团队在什么时候需要这项能力
云基础设施常常是由应用工程师为解决眼前问题而顺手搭起来的，这种做法一直有效，直到需要做出一个结构性决策为止。以下这些节点，说明缺少云服务商层的深度已经开始变得昂贵。
迁移已经进入计划阶段，而不再只是被讨论
迁移一个既有系统，会迫使团队做出一个原本很容易拖延的决定：尽量原样复刻现有架构，还是围绕托管服务重新塑形。两条路都成立。而如果是一项服务一项服务地、在无意之间做出选择，最后得到的往往是后者的成本结构，加上前者的运维负担。
账号结构是长出来的，不是设计出来的
所有东西共用一个账号，环境之间靠命名约定区分，还有好几个人手上握着能影响生产环境的凭据。一旦出错，没有任何东西能把影响圈住；而事后再补一道边界意味着搬迁正在运行的资源，这也正是它一再被推迟的原因。
支出已经变得既不可预测，也无法归因
账单的增速快过用量，而没有人说得清是哪个团队、哪个功能或哪个环境造成的。缺少归因，唯一可用的手段就是笼统地要求少花钱——这最终落在最谨慎的人身上，而不是落在最浪费的地方。
可用性承诺首次被写成了明文条款
一份客户合同或一项监管要求带来了明确的恢复目标。把它们落成可用区与地域拓扑、复制方式的选择、备份可恢复性的验证，以及一次真正执行过的故障切换，是专门的工作；而写在文档里的方案与被验证过的方案之间的落差，正是组织认清自己真实位置的地方。
权限被授予的次数，远多于被复核的次数
权限在故障处理、迁移和新人入职的过程中不断累积，却没有一项被收回。现在没有人说得清谁能读取生产数据库，而要回答这个问题，需要读的是策略如何判定，而不是一份用户名单。
第二家云服务商或一个受监管的地域进入了范围
数据驻留规则、某个客户要求特定司法辖区，或者一次并购带来了另一家云服务商。每一种情形都会引出同一类问题：身份联邦、网络互通、数据流动，以及用哪些抽象才能让两套环境同时保持可理解。
核心能力
云服务商层架构
依据负载的真实形态——请求量、突发程度、数据引力、延迟容忍度——来选择计算模型、存储类型和托管服务，并且知道云服务商的抽象在哪里开始不再匹配应用真正需要的东西。
网络设计
地址规划、子网与路由结构、与其他环境之间的私网互通、受控的出网流量以及负载均衡。一旦有负载落在网络上，网络就成了最难重新规划的东西之一，因此这里的决策会比大多数决策留存得久得多。
身份与访问（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
How this role works with your team
Engineers work inside your team, on your priorities, to your standards. You direct the work; Talent.ID carries the employment. The division below is the whole arrangement.
You keep
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
Talent.ID handles
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
招聘时应该关注什么
在这个领域，证书与实际能力之间的落差异常之大。认证的持有面很广，考的是对服务名称的记忆；而这份工作真正回报的，是关于故障、权限和成本的判断力，没有任何一场考试在衡量它。以下这些方面，正是这种判断力会显现出来的地方。
先在一家云服务商上做深，再横向铺开
一位声称对三家云服务商同样精通的候选人，通常描述的是熟悉度。对配额、故障表现、计费边界情况和策略判定的真正理解是与具体云服务商绑定的，需要数年时间积累；而在一家上的深度，比在所有家上的浅覆盖更容易迁移。
- 能说出某个限制或配额如何影响了一次设计，以及他们是怎么发现它的
- 知道自己主用的云服务商在哪些地方表现不好，而不只是在哪些地方表现好
- 能区分真正可以迁移的概念，和只是看起来相似的名称
对身份与权限的推理
请他们说明如何让一个服务获得对一项资源的访问权，然后再问如何验证没有别的东西一并拿到了同样的访问权。深度显现在第二个问题上：弱的回答是描述挂上一条策略，强的回答会讲判定顺序、信任边界，以及如何确认最终结果。
- 优先使用工作负载身份，而不是长期存储的访问密钥
- 能解释在其主用的云服务商上，相互冲突的权限最终如何判定
- 审计过既有权限，并能讲清楚发现了什么
- 把账号或项目边界当作安全控制手段，而不是记账手段
网络设计及其后果
网络是经验不足的设计留下最持久问题的地方，因为地址段和连通性一旦被负载依赖，就很难再拆开。可以请他们讲一个自己规划过的网络，以及现在会怎样重新布局。
- 在规划地址空间时，会把未来的互通需求和可能的并购考虑进去
- 能解释流量如何离开自己的环境，以及这条路径的代价
- 理解私网互通与仅仅是限制了访问之间的区别
经过验证而不只是写在文档里的韧性
问他们上一次在非紧急情况下执行故障切换或从备份恢复是在什么时候。这个回答能把只是推理过的设计与真正验证过的设计区分开，而恢复目标最终被证明只是愿望的地方，就在这道落差里。
- 演练过故障切换，并能说出演练过程中出了什么问题
- 定期做恢复演练，而不是默认备份完成了就没问题
- 用时间和数据量来陈述恢复目标，而不是用形容词
- 清楚多可用区设计防不住哪些云服务商侧的故障
把成本当作架构输入
问他们会怎样查清账单为什么上涨。真正扛过这件事的人会去看分摊标签、用量报告和具体的账单条目；没扛过的会建议预留容量，或者要求各团队注意一点——这套做法在一个持续增长的环境面前撑不住。
- 能说出一次降低了成本的具体架构改动，以及它起作用的机制
- 对出网流量和跨可用区计费的理解，足以在设计时绕开它们
- 在问题变紧急之前就把归因建好，而不是等到复盘时才做
在云服务商故障期间的应对
云服务商的故障无法避免，也大多不在客户的控制范围内，所以真正有意思的问题是团队在故障期间做了什么。可以请他们讲一次亲历的服务降级，以及他们是如何判断该切换还是该等待的。
- 能快速区分云服务商的故障与应用自身的故障，并给得出依据
- 对什么时候切换比等待风险更高，有经过思考的立场
- 参与过一次改变了设计的复盘，而不是把责任归给云服务商
清楚云服务商的责任到哪里为止
人们经常默认托管服务开箱即安全、开箱即正确。可以问某一项具体的托管服务不会替你做什么：这里的精确程度，能看出一个人是读过文档，还是从一张架构图里继承了假设。
- 能说出某个方便但并不安全的默认配置
- 知道一项托管服务中，哪些部分仍然需要打补丁或自行配置
- 发现过自动化扫描没有报出的配置错误
值得一问的面试问题
以下问题供您自己的面试流程参考，用意是把对云服务商的判断力与对云服务商术语的熟悉度区分开。要求由您来定义，谁符合要求也由您来判断。
请描述一套由您设计的环境的账号与网络布局。如果从头再来，您会在结构上做哪些不同的安排？
What a strong answer shows
他们是否与自己的决策共处过。好的回答会解释划定边界背后的理由——隔离、爆炸半径、计费、合规——并且能指出一个具体的遗憾，而这一点很难编得让人信服。
某个服务需要读取一个对象存储桶。请带我走一遍授权的过程，然后再走一遍如何证明没有别的东西一并获得了访问权。
What a strong answer shows
对权限判定的精确程度。授权本身并不复杂，验证才是难点。可以留意他们是否使用身份而非密钥、是否把范围收窄到那一项具体资源，以及有没有一种确认结果的方法。
账单大幅上涨，流量却没有相应增长，您会怎样排查？
What a strong answer shows
成本对他们而言是可以诊断的东西，还是只能往上报的东西。期待听到分摊标签、用量拆解、对某一类具体费用的假设，以及一种认识：流量传输和闲置容量往往比计算本身更能解释账单。
您上一个负责的系统，恢复目标是什么？上一次验证自己能够达成这些目标是在什么时候？
What a strong answer shows
写在文档里的方案与被验证过的方案之间的距离。真正演练过恢复的候选人会给出一个日期，以及演练中出了什么问题的具体经过；其余的人会拿一张架构图来回答。
您被要求迁移一个没有人完全弄懂的系统。最初的一个月您打算怎么做？
What a strong answer shows
在信息不完整时的方法。好的回答会从观察和清点开始，而不是从目标架构开始：什么在跟什么通信、什么按定时任务运行、什么带着没有被记录过的依赖。
在什么情况下您会选择托管数据库而不是自己运行一套？又在什么情况下您会拒绝？
What a strong answer shows
他们是否会在运维负担、耦合和成本之间做权衡。回答应当涵盖版本与扩展插件的限制、扩缩容表现、可用性承诺实际覆盖了什么，以及日后迁走的代价。
您所在的地域，云服务商正在通报服务降级。您如何决定要不要做故障切换？
What a strong answer shows
沉着，以及对故障切换本身也带着风险的理解。可以关注他们如何收集证据、对复制延迟与数据一致性的意识，以及那条决策规则是在事故之前就约定好的，还是在事故当中临时拼出来的。
What this looks like in practice
A hypothetical scenario, written to show how the working model applies. It does not describe a Talent.ID client or a completed project.
- Challenge
- 某个组织在单一云服务商上运行着一套不断增长的环境，早期的决策已经开始形成约束。各环境共用一个账号，权限被授予的次数多于被复核的次数，支出无法归因到任何一个团队，而一项新的客户承诺又带来了当前拓扑当初并未按此设计的可用性要求。
- Approach
- 新增的基础设施工程力量在团队已经确定的架构原则之下加入，在团队既有的资源供给流程、账号约定和变更流程之内工作。设计方案由日后要与之共处的内部工程师评审，整改工作则按团队自己商定的优先级排定顺序。
- What this adds to the team
- 架构决定权和安全责任仍然留在该组织手里，团队因此获得余量去处理那些一直被搁置的结构性工作。哪些取舍可以接受，由承担商业后果的人来判断。
Related disciplines
Frequently asked questions
- 云工程师和 DevOps 工程师有什么区别？
- 云工程师专精于云服务商这一层：账号与网络如何组织、身份如何授予与判定、系统依赖哪些云服务商的服务、当某个可用区或地域发生故障时它如何表现，以及这一切要花多少钱。DevOps 工程师专精于把变更送到既有基础设施之上——流水线、部署策略、发布自动化，以及发布之后的反馈。一个学科关心系统由什么构成，另一个关心变更如何抵达它。规模较小的组织会把两者合在一个人身上；环境更大之后，这两种深度就装不进同一个岗位了。
- 云工程师和平台工程师是一回事吗？
- 不是，尽管两者经常被混淆，因为它们都位于应用之下。云工程交付的是满足某项要求的基础设施：拓扑、权限、韧性、支出。平台工程交付的是一套面向基础设施的界面，为那些本来也能自己搭起来的内部工程师而建，评判标准是他们是否愿意采用。平台一般叠加在云工程已经打好的基础之上，所以在一个本身就不成体系的环境上盖一层平台，得到的是一个整洁的外壳，背后原有的每一个问题都还在。
- 我们应该同时使用多家云服务商吗？
- 很少是主动选择，更多是形势所致。有意为之的多云，大致会让一个组织需要理解的面翻倍——两套身份模型、两套网络模型、两套故障表现——换来的是更强的议价位置，以及一个大多数组织从未真正用上的可移植选项。数据驻留规则、客户的硬性要求、一次并购或者一项确实存在的监管义务，都能成为它的理由。而以云服务商宕机作为理由则很少成立，因为增加的复杂度往往比它避免的停机造成更多停机。
- 云认证能说明多少问题？
- 它们能确认一个人研读过某家云服务商的服务清单，并且能回忆起这些部件本应如何拼合，这是一条实实在在的基线，在职业早期也确实有价值。它们不能说明这个人是否设计过一套经受住考验的权限模型、是否见过故障切换的实际表现与文档不符、是否把一笔意料之外的费用追查到了源头。把认证当作准备程度的证据，而不是判断力的证据，把面试时间花在判断力上。
- 云环境里的安全由谁负责？
- 云服务商负责底层基础设施的安全；客户负责配置、身份、网络暴露面、数据保护，以及构建在其上的一切。几乎所有被公开报道的云上数据暴露事件，都落在这条线的客户一侧——一个比预期更宽的权限、一处可从公网访问的存储、一份提交进代码仓库的凭据、一个方便但并不安全的默认值。一位说不清自己所用服务的这条边界在哪里的工程师，身上带着一个他可能并未意识到的缺口。
- 云工程师能把我们的支出控制住吗？
- 能起到一部分作用，而在为此招人之前，值得先了解它的边界。真正的降本通常需要架构层面的改动——存储类型与留存策略、流量路径、把闲置容量迁到按请求计费的算力上、下线没有人使用的东西——而这需要拥有这些系统的团队投入工程时间。如果把这个角色安排成一个处理成本工单和权限申请的队列，它每个月会产出一份报告，实际改变很少。如果允许它把归因暴露出来并提出设计改动建议，它才能影响到底层的趋势。
- 云工程师如何与现有的工程团队协作？
- 技术团队扩展意味着工程师加入您的团队内部，而不是在旁边并行推进。您的架构原则、账号规范、安全策略和迭代优先级约束着这项工作，由您的人决定构建什么以及按什么顺序构建。Talent.ID 负责雇佣关系、薪资发放和员工福利，以及人才管理和持续的员工关系。
Tell us what your team needs
Describe the gap — the work, the stack, the way your team runs — and we will tell you what we can support. If it is not something we can help with, we will say so.