平台工程师
平台工程师构建的是一个内部产品，而它的用户是组织自己的工程师。产出是一套自助式的路径，让人能够创建、发布、观测和运维服务，其中那些受支持的路线本身就带着组织的标准，不需要每次重新拼装一遍。这门学科的成败取决于是否有人采用，因此它既是基础设施问题，也是产品问题。以下说明这一角色涵盖的范围、组织到了什么规模才值得设立它，以及它与现有团队的协作方式。
平台工程师做什么？
平台工程师构建并运维内部开发者平台（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
这个角色如何与您的团队协作
工程师在您的团队内部工作，遵循您的优先级和标准。日常开发方向由您掌握，Talent.ID 负责雇佣关系。下面的分工就是全部安排。
由您掌握
- 产品
- 业务优先级
- 路线图
- 架构
- 冲刺优先级
- 工程标准
- 日常技术协作
由 Talent.ID 负责
- 雇佣关系
- 薪资发放
- 员工福利
- 人才管理
- 持续的员工关系
实际协作大致是这样
这是一个假设场景，用于说明协作方式如何落地。它并不描述 Talent.ID 的客户或已完成的项目。
- 挑战
- 某个组织的交付团队数量不断增加，结果发现每个团队都各自拼出了一套发布和运维服务的做法。标准以书面指引的形式存在，执行程度参差不齐；资源开通依赖一个小组，而这个小组的积压在持续变长；新建一个服务耗时之久，让团队宁可回避。建设一个共享的内部界面在原则上已经取得共识，却腾不出人手去做。
- 做法
- 新增的工程力量在平台小组已有的约定之内工作——他们的接口设计、他们的发布流程、他们的评审标准，以及在他们自己的规划中确定的优先级。平台将走向何处、下一步服务哪些团队，其路线图仍然由内部工程师掌握；那些铺好的路，是和将要使用它们的团队一起建起来的。
- 为团队带来什么
- 平台的方向，以及它与内部用户之间的关系，其归属始终留在组织内部。哪些东西被抽象掉、哪些保持可见、哪些标准成为默认值，都由将要维护它们的人来决定。
常见问题
- 平台工程和 DevOps 有什么区别？
- 两者的区别在于工作是为谁做的，以及产出的是什么。DevOps 关注的是变更进入生产环境的过程，以及此后回传的信号，它通常在一个交付团队内部、为这个团队而实践。平台工程产出的是许多团队共同使用的东西：一个带有自助式界面和受支持路线的内部产品，使用它不需要了解底层的那套机器。前者的衡量标准是软件多安全、多频繁地到达用户；后者的衡量标准是一个团队能否在无人协助的情况下拿到自己需要的东西。这种混淆可以理解，因为平台小组常常也会做交付工具，而且很多平台工程师本来就是从交付工作转过来的——但一个没有人使用的平台就是失败的，哪怕它产出的每一条流水线都很出色。
- 平台工程师只是换了名字的基础设施工程师或云工程师吗？
- 在实践中有时确实如此——当一个组织只换了团队的名字，工作方式却没有变。但就其本身而言，不是。云与基础设施工程产出的是基础设施：账号拓扑、身份模型、韧性策略、成本结构。平台工程产出的是同事会去使用的东西——随之而来的是“用户可以另作选择”所带来的义务，包括文档、支持、版本管理、带迁移路径的废弃流程，以及经过测量而非想当然的采用情况。平台位于那层基础设施之上，并且依赖它足够扎实，这也正是先后顺序为什么重要的原因。
- 一个组织要有多大规模，做这件事才说得过去？
- 并不存在一个通用的门槛，但有一个可靠的检验方式：数一数同一个基础设施决策被独立做出了多少次，以及这些答案彼此的差异有多大。只有两三个团队时，诚实的答案通常是维护良好的模板、一个共享模块库和清晰的文档。随着团队数量增长、不一致带来的代价超过一个平台的代价，理由才逐渐成立。为单一使用方建一个平台，得到的是一层只服务于一种情况、并把它复杂化的抽象。
- 使用内部平台应该是强制的吗？
- 把它做成显而易见的选择，效果要比把它定成硬性规定好得多。强制会把采用变成合规，从而遮蔽平台真正需要的反馈：团队不再反映某处别扭，而是默不作声地绕过去。确实有少数事情没有商量余地，通常是安全和监管方面的控制，这些应当落在自动化的护栏里，无论走不走那条铺好的路都同样生效。除此之外，团队选择了别的方案，这说明的是平台的情况，而不是团队的情况。
- 当一个平台团队变成工单队列时，会发生什么？
- 它就不再是一个平台团队，而成了换个名字的共享服务台。工作围绕关闭请求重新组织起来，小组按吞吐量被衡量，没有人腾得出余地去建设那种能让这些请求变得不必要的自助能力。此后无论队列被处理得多有效率，它都在变长，因为需求正是由那样东西的缺席产生的，而队列本身又让任何人都腾不出手去把它建起来。要走出来，就得在请求持续到来的同时，刻意为平台工作留出人力，而这是一个只有管理层才能做、且并不舒服的决定。
- 平台由谁来值班？
- 平台团队负责平台本身。这也是支持这门学科的较为清晰的理由之一：当一个共享组件出故障时，由一个真正了解它的小组来响应，而不是几个产品团队各自去诊断同一个故障。边界必须写明——平台负责什么、什么仍然留在拥有该服务的团队手里，以及在归属不清时告警如何路由。含糊会带来最糟的结果：一次故障以“这是谁的问题”的一场谈判开场。
- 平台工程师如何与现有的工程团队协作？
- 在技术团队扩展的模式下，加入您团队的工程师遵循这个团队既有的工作方式：它的评审约定、它的发布流程、它的架构方向，以及您在规划周期中设定的优先级。工作的方向属于您，产品、路线图和工程标准也一样。Talent.ID 负责雇佣关系、薪资发放和员工福利，以及人才管理和持续的员工关系。
告诉我们您的团队需要什么
描述一下缺口——工作内容、技术栈、团队的运作方式——我们会告诉您能支持到什么程度。如果这不是我们能帮上忙的事情，我们会直说。