平台工程师
平台工程师构建的是一个内部产品，而它的用户是组织自己的工程师。产出是一套自助式的路径，让人能够创建、发布、观测和运维服务，其中那些受支持的路线本身就带着组织的标准，不需要每次重新拼装一遍。这门学科的成败取决于是否有人采用，因此它既是基础设施问题，也是产品问题。以下说明这一角色涵盖的范围、组织到了什么规模才值得设立它，以及如何评估候选人。
平台工程师做什么？
平台工程师构建并运维内部开发者平台（IDP）：一个自助式的界面，组织内的工程师通过它创建服务、部署服务、获取基础设施、观测并运维自己所运行的东西，而不需要理解或自行拼装底层组件。平台上那些得到良好支持的路线，会默认带上组织在安全、可靠性和成本方面的要求。这一角色把基础设施视为应当被一个有意设计的接口封装起来的对象，并且像评价任何产品那样评价它——看它服务的那些人是否愿意使用它。
核心理念是“铺好的路”（paved road）：对一件常见的事给出一种得到良好支持的做法，让它比其他选择更省事，而且到手时组织的各项要求就已经满足了。团队仍然可以离开这条路，然后自己承担由此接手的一切。这正是平台与强制规定的区别——平台让正确的路线成为省事的路线，而强制规定让不正确的路线成为被禁止的路线，并催生出一整套精巧的规避手段，通常还无处记录。
从投入产出上看，这件事关乎注意力。每一个产品团队如果都得自行搞清楚集群网络、证书续期、日志留存、告警路由和云上权限，就会把本可以投入产品的注意力花在这些地方，而且每个团队得到的答案都略有不同。当同一个基础设施决策被反复做出、每次结论又彼此不一致时，平台才值得建；在此之前，它只是对单一场景的一层抽象，维护成本高过它所消除的重复。
这门学科与相邻学科最大的不同，在于它有可以拒绝它的用户。一个没人采用的内部平台并不算取得了部分成功——它是一份维护负担，旁边还并排放着各团队自行搭起来的那套东西。这就带来了基础设施工作通常不承担的产品义务：了解用户需要什么、文档、支持、版本管理、带迁移路径的废弃流程，以及测量这东西究竟有没有人用。
团队在什么时候需要这项能力
平台工程很容易起步过早，那样只会为单一场景造出一层精巧的抽象。以下这些情形，通常说明这项投入开始产生回报了。
几个团队用不同的方式解决了同一个问题
每个服务都有自己的部署做法、自己的日志约定、自己的告警方式，以及自己对安全要求的一套理解。没有哪一种是错的，但每一种都略有不同，于是没有人能在团队之间流动而不重新学一遍基础。真正的代价不在重复劳动，而在于任何一处改进都意味着要在所有地方各改一遍。
要拿到基础设施，得看某个特定的人
新建一个数据库、队列、环境或一组凭证，都需要去找一位本来就很忙的人。交付于是卡在那个人的日程上，组织真正遇到的是一个可用性问题，感受到的却是速度问题。
标准以文档的形式存在，而不是以默认值的形式存在
组织已经写下服务应当如何处理密钥、留存、加密和告警，而是否合规靠的是记性和评审。写在文档里的标准，执行程度参差不齐；建进团队本来就要走的那条路里的标准，则是被构造出来的。
启动一个新服务，要先做上几周没有区分度的工作
在写下任何产品代码之前，先得有人把仓库、流水线、运行时、密钥、监控、告警路由和访问权限拼齐。因为这件事很繁琐，即便拆分本来是更好的设计，团队也会回避新建服务，于是架构就被搭建成本悄悄塑形了。
基础设施小组变成了一条队列
请求进来的速度快过处理完成的速度，积压成了主要产物，小组则按吞吐量被衡量。没有人腾得出时间去消除这些请求产生的原因，于是无论队列被处理得多有效率，它都在变长。这说明需要改变的是工作的形态，而不是需要更多人手。
组织的团队数量已经足以让一个共享的界面回本
平台有固定成本，而它的收益随使用它的团队数量而增长。这里存在一个门槛——各处不同，但确实存在——在门槛之下，几套维护良好的模板加上一个共享模块库更划算；在门槛之上，没有平台这件事会以不一致的形式出现在每一个角落。
核心能力
把平台当作产品来做
弄清楚用户是谁、他们在此之前是怎么做的，以及平台真正解决了他们的哪些问题。这带来一件产品该有的那些寻常义务：用户调研、文档、支持、经过斟酌的路线图，以及诚实地测量采用情况而不是产出数量。
黄金路径与服务模板
提供一条受支持的路线，从零到一个可运行、可观测、安全性配置得当的服务——脚手架、流水线、运行时配置、遥测和告警路由一并到位，并且在团队改动过之后依然可维护。
自助式资源开通
让团队通过一份声明式的申请自动拿到数据库、队列、环境、DNS 记录和权限，并处在平台强制约束的范围之内。成功的标准是不必再去问某个人，而不是问人这件事变快了。
抽象的设计
决定隐藏什么、暴露什么，以及在哪里留出退出抽象的出口。隐藏得太多，团队的需求只要稍微特殊一点就会被卡住；隐藏得太少，做出来的不过是一份多了几个步骤的文档。这条边界是这门学科真正的核心思考所在。
多租户与隔离
在共享的基础设施上运行多个团队的负载，同时不让其中一个拖累另一个：资源限额、命名空间与网络边界、配额策略，以及对于一个行为失当的租户，平台向它作出何种保证，要有明确的立场。
默认具备可观测性
让埋点随那条铺好的路一起交付，使链路追踪、结构化日志和有用的指标不必每个团队各自搭建就已经存在。这正是两类组织之间的差别：一类把监控当作一个项目，另一类则是任何服务一出状况就能立刻着手排查。
策略与护栏即代码
把各项要求编码成自动化的控制手段——准入策略、镜像来源规则、网络限制、运行时检测——让合规的配置成为默认值，任何偏离都能被看见。一道拒绝了某件事的护栏必须说明应该改用什么做法，否则团队就会绕开它。
工作负载的身份与密钥
给每个工作负载一个可验证的身份，并据此签发短时效凭证，让应用不再随身携带长期有效的密钥。分发、轮换和吊销于是成为平台自身的性质，而不再是每个团队各写一套的东西。
平台自身的可靠性
平台是构建在它之上的一切的依赖，因此它自身的可用性目标和错误预算，比任何单个服务的都更要紧。失效模式尤其值得关注：一个在故障时选择封闭（fail closed）的平台，可能会让组织在故障期间无法发布，而那恰恰是最需要发布的时候。
接口演进与废弃
对团队所依赖的东西做版本管理，并在下线旧接口时给出迁移路径、足够的提前通知，以及在可能的情况下提供自动化的转换工具。废弃处理得糟糕，是把平台赖以运转的信任消耗掉的最快方式，而信任比机器更难重建。
技术生态
以下列出平台工程领域常见的技术。这描述的是该学科在业界的一般实践，而不是对任何特定工程师技术栈的说明。平台是拼装出来的，而不是买来的，因此更有价值的问题是：一个人如何决定哪些自己造、哪些直接采用、哪些干脆不碰。
运行时与编排
- Kubernetes
- Nomad
- ECS
- Cloud Run
- Knative
开发者门户与界面
- Backstage
- Port
- Cortex
- Humanitec
- Internal CLIs
控制面与资源开通
- Crossplane
- Kubernetes operators
- Kubebuilder
- Terraform modules
- Pulumi
配置与模板
- Helm
- Kustomize
- CUE
- Jsonnet
- Cookiecutter
策略与工作负载安全
- Open Policy Agent
- Kyverno
- Falco
- cert-manager
- External Secrets Operator
- SPIFFE
遥测
- OpenTelemetry Collector
- Prometheus Operator
- Grafana
- Tempo
- Pyroscope
平台组件所用的编程语言
- Go
- Python
- TypeScript
- Rust
- Shell
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
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
招聘时应该关注什么
“平台工程”这个说法比它所描述的工作要新，因此它如今涵盖的岗位跨度很大，其中一些只是换了名字的普通基础设施工作。真正的平台工程师，区别在于面向内部用户的取向，以及谈采用情况时能和谈架构一样自如。
面向内部用户的取向
问他们上一个平台的用户是谁，以及他们是怎么弄清楚这些人需要什么的。真正做过这件事的工程师会说出具体的团队、具体的不满，以及自己具体做错了什么；没做过的则会描述架构，并默认需求本来就是显而易见的。
- 能说出自己做过、内部团队却并不使用的某个功能，以及原因
- 曾经坐在产品团队旁边，看着他们使用这个平台
- 把平台的用户当作有其他选择的人，而不是当作接收方
- 知道自己的平台上，哪些部分被抱怨得最多
关于抽象的判断力
任何一层内部抽象，最终都会遇上它没有预料到的需求。问他们那时会发生什么。回答能看出他们是有意识地设计了退出的出口，还是在与一个赶着交付的团队争论时才发现需要它。
- 提供一条受支持的方式让人走出抽象，而不是禁止这样做
- 能说出某样东西是他们刻意选择不去隐藏的，以及为什么
- 拆掉过一层抵不上自身维护成本的抽象
不靠强制而获得的采用
靠行政命令推下去的平台，积累的是抵触情绪和绕行方案；因为确实更省事而被采用的平台，积累的是用户。问他们是怎么说服一个团队迁移到自己做的东西上的——好的回答是把迁移变便宜，而不是把别的选择变成禁区。
- 会测量采用情况，并且说得出具体是什么水平，而不只是说它在增长
- 通过替团队做掉一部分工作来降低迁移成本
- 能区分一个真正被采用的平台，和一个所有人被要求使用的平台
把平台当作生产系统来运维
平台是其他一切的基础设施，这就改变了衡量它的标准。问他们当平台不可用时组织会怎么样，以及在放行更安全的场合，他们是否按“故障时放行”（fail open）来设计。
- 为平台本身设定了明确的可用性目标
- 考虑过在哪些故障之下，团队仍然应该能够发布
- 由平台团队自己承担平台的值班，而不是把它的故障转给产品团队
- 能讲清楚一次平台故障，以及它带来的改变
不会变成障碍的护栏
自动化的策略是让标准变成默认值的手段，同时也是让一个平台招人讨厌的最快方式。问他们是怎么引入一项拦下了团队原有做法的控制的，以及他们如何处理由此而来的反对意见。
- 在强制执行之前，先以仅记录（report-only）的模式上线该策略
- 写出的拒绝提示会说明应该改用什么做法
- 有一套会记录在案的例外流程，而不是私下商量
测量开发者体验
问他们凭什么知道平台确实起了作用。强的候选人会举出可以观察到的东西——从一个空仓库到一个可运行服务所需的时间、团队提出支持请求的频率——并且坦率地说出这套测量没有捕捉到什么。
- 使用的衡量指标连着开发者的实际感受，而不是平台的产出量
- 把定量信号与和当事人的交谈结合起来
- 能说出某样在数字上有改善、在实际中却没有改善的东西
让自己做过的东西退场
内部接口会不断堆积，而一个从不下线任何东西的组织，就得维护自己曾经发布过的每一个版本。问他们撤掉过什么，要听的是提前通知、迁移工具和后续跟进，而不是一纸公告加上对配合的期待。
- 提供了自动化迁移，或者亲手替对方完成了转换
- 给出的通知期与造成的干扰程度相称
- 在移除之前先确认旧路径已经没有人使用
值得一问的面试问题
以下问题能看出一位候选人是按内部用户来思考，还是只按基础设施来思考。它们供您自己的面试流程参考——是否合适由您来判断，依据的是只有您才能定义的要求。
请描述您上一个参与的平台。它的用户是谁，在它出现之前，这些人是怎么做的？
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.