平台工程将其视为产品解决软件交付难题提升工程组织回报率几年前我参加了一场事后分析会至今难忘。当时我们遭遇一起生产事故常规部署采用了错误配置发现并回滚耗时之久大家都不愿承认。追溯根本原因几乎与功能代码无关问题出在周边支撑架构一个 Kubernetes 清单与集群不匹配一个 CI 管道的绿色对勾实际未验证我们所想内容还有一个密钥管理步骤三个不同服务采用三种不同方式。代码本身一周内运行正常真正让我们陷入困境的是代码周边的一切。过去 15 年我在多家公司工作过包括大型 IT 服务公司、医疗设备制造商、医疗科技公司、云迁移初创企业以及现在的大型 SaaS 平台。公司名称和技术栈不断变化但问题模式始终如一。聪明的工程师每周花大量时间处理的并非受雇解决的问题而是软件交付过程中意外产生的复杂性。很长一段时间我认为解决办法是更好的文档、更严格的 DevOps 文化或者招聘更熟悉 YAML 的人员。但这三个想法都错了。真正改变我想法的是重新定义问题这种阻碍并非知识差距或纪律差距而是产品差距。没人像产品经理关注客户使用应用的体验那样关注开发者交付软件的体验。如今填补这一差距的领域有了名字平台工程。Gartner 认为它“是为应对现代软件工具和架构复杂性导致的认知负担增加而出现的”。Gartner 也毫不掩饰其发展速度之快预测“到 2026 年80% 的大型软件工程组织将组建平台工程团队”而 2022 年这一比例为 45%。如果这个预测接近准确那么有趣的问题不再是是否组建平台团队而是能否组建一个优秀的团队。“DevOps”悄然失去扩展性我要说明“DevOps 已死”是偷懒的标题我并不认同。DevOps 的原则包括共同所有权、自动化和紧密的反馈循环这些原则如今和运动开始时一样正确。在我看来出现问题的是运营模式。最初承诺“你构建你运行”每个团队负责自己的部署、监控和值班。团队数量少且有共同经验传承时这种模式效果好。但有 50 个团队时问题就来了因为有 50 种略有不同的方式完成相同的无差异工作50 种定义服务的方式、50 种微妙错误的 Kubernetes 配置、50 个值班轮班表凌晨 3 点会有 50 名工程师被呼叫处理同一类问题。“自己运行”带来的认知负担增长速度超出了大多数团队的承受能力。将认知负担作为优化目标的理念源自《团队拓扑》*Team Topologies*这本书。它对我组织设计观念的影响超过了我读过的任何纯技术书籍。书中第四条原则明确指出了极限“团队在崩溃前只能处理一定程度的复杂性”“当领导者不断给团队增加任务而不减少时有能力的团队也会变得低效”。最后这句话精准描述了我自己的团队让我深感刺痛。《团队拓扑》还为我提供了一直缺失的术语。它定义了四种基本团队类型并将平台团队定义为“为与业务流对齐的团队提供有吸引力的内部产品以加速交付的团队组合”。请再次阅读这个定义有吸引力的内部产品而不是共享服务台也不是附带维基文档的 Terraform 仓库而是产品。这一个词就是核心所在。将平台视为产品会改变一切平台采用靠自身赢得而非强制推行我早期参与内部工具开发时帮助构建了一项我们颇为自豪的平台功能然后做了基础设施团队常做的事宣布它的存在并认为人们会主动使用。但事实并非如此团队选择绕过它因为我们铺设的“黄金路径”实际上是条石子路。这个教训让我印象深刻。一个需要强制开发者使用的平台不是真正的平台而是一种负担。当我们重新构建它让铺设的路径真正成为最便捷的选择时情况就不同了。这也是 Spotify 开发并已成为 CNCF 项目的开发者门户 Backstage 的核心理念它宣称“为你的微服务和基础设施恢复秩序”让产品团队能够快速交付。需要用户主动选择的秩序并非真正的秩序只有当选择工具成为一种“偷懒”的选择时工具才能获胜。“自助服务”必须名副其实这是一个被过度使用的词汇我采用 CNCF 在平台白皮书中的定义“平台应该是自助服务的用户必须能够自主、自动地请求并获得功能”。如果开发者需要提交工单等待我的团队来配置数据库那我构建的就不是平台而是一个效率更低的帮助台。同一份白皮书明确指出了目标“平台的一个重要目标是减轻产品团队的认知负担”。我开始用这句话作为衡量标准对于任何我们想要添加的功能我都会问自己它是减轻了产品团队的负担还是悄悄增加了负担。令人惊讶的是很多本意良好的平台功能都无法通过这个测试。像衡量任何产品一样衡量平台要避免只关注那些让平台团队自我感觉良好的指标。“我们运行了多少个集群”是我的团队关心但其他人并不在意的指标。真正重要的指标应该描述开发者的实际体验我所知最可靠的一组指标来自 DORA这是一个长期研究软件交付性能的项目。其指标从最初的“四个关键指标”发展到了五个。核心的吞吐量指标仍然问对了问题变更前置时间“从代码提交到版本控制到部署到生产环境所需的时间”、部署频率、部署失败恢复时间以及变更失败率。我发现这些指标对平台团队来说是非常客观的成绩单因为它们不会奖励无意义的忙碌工作。你无法通过发布更多没人使用的内部工具来获得良好的前置时间。平台产品需要路线图、用户研究和说“不”的勇气这从文化层面来说是最难的一点。我见过一些平台项目最终沦为各种一次性请求的大杂烩每个请求本身都合理但加在一起就成了一堆让人摸不着头脑的工具。对善意的请求说“不”是一种产品管理技能那些从未掌握这一技能的平台团队最终会重建他们原本想要消除的混乱局面。我合作过的优秀平台负责人花在与内部用户交流上的时间和面向消费者的产品经理一样多。我想对过去的自己说的话从铺设道路开始而非搭建平台你不需要在第一个季度就构建一个内部开发者门户你需要找到最痛苦、最常重复的无差异工作即从“这是我的容器”到“它在生产环境中安全运行”之间的距离。通过出色地完成这一项工作来赢得拓展下一项工作的机会。那些以宏大架构起步的平台往往会以失败告终而能够存活下来的平台都是从一条真正有用的、人们自愿选择的道路开始的。抵制将一切抽象化的冲动一个好的平台的目标不是完全隐藏 Kubernetes让人们不了解底层发生的事情这只是用一种脆弱性换取另一种脆弱性。目标是在保留理解的基础上消除繁琐的工作。当抽象层出现漏洞时你需要的是能够理解底层原理的工程师而不是一群只知道按按钮的人。我曾为这两种错误付出过代价平台过于单薄无法提供帮助或者平台过于复杂一旦出现事故就像进行考古挖掘一样困难。将“开发者体验”视为重要的业务指标它不仅仅是提升士气的手段。工程师每花一个小时与交付管道作斗争就少花一个小时在客户真正付费的事情上。当我向领导层说明平台投资是为了收回我最昂贵员工的大量时间时讨论就不再是关于成本而是关于杠杆效应。这实际上是工程组织能做出的回报率最高的投资之一但它几乎从未在预算中体现为一项明显的支出。平台团队不是维持日常运转的团队而是决定其他团队前进速度的团队。当我开始将其视为组织内部交付的最重要产品时几乎所有其他决策都变得容易了。只可惜我花了一次发布失败和一群沮丧的工程师的代价才明白这一点。