内容简介

本书作者拨开平台工程的浮夸迷雾，直面构建和管理内部平台的现实。他们结合自身的实践经验，分享了规避常见失败模式的方法，以及如何打造一个令人信赖且备受喜爱的内部平台。本书分为三部分：第一部分介绍了平台工程的定义、意义以及核心要素，旨在帮助读者理解平台工程的核心内容；第二部分深入探讨了平台领域中的各种常见挑战，为读者提供关于领导力和执行实践等重要概念与方法的全面概述；第三部分分享了很多成功案例，向读者展示成功的平台工程。本书的目标读者是组织中负责软件平台设计和运维的技术、产品及团队领导者，包括资深工程师、架构师、产品经理、项目经理和工程经理。

目录

目录

序1

前言3

第一部分 平台工程的内容和意义

第1章 平台工程为何变得不可或缺11

1.1 定义“平台”及其他重要术语12

1.2 过度泛化的泥沼13

1.3 我们如何陷入过度泛化的泥沼15

1.3.1 变革之一：选择的爆炸性增长15

1.3.2 变革之二：更高的运营需求17

1.3.3 结果：深陷泥沼19

1.4 平台工程如何疏通泥沼20

1.4.1 在限制原语的同时最小化开销20

1.4.2 减少应用程序间的黏合代码21

1.4.3 集中管理迁移成本22

1.4.4 允许应用程序开发人员运营他们开发的系统23

1.5 赋能团队专注于构建平台23

1.6 结语26

第2章 平台工程的支柱27

2.1 采用精心策划并以产品为导向的方法28

2.2 开发基于软件的抽象29

2.2.1 主要抽象层：平台服务及API30

2.2.2 胖客户端31

2.2.3 OSS定制化32

2.2.4 集成元数据注册表32

2.3 服务广大应用程序开发人员34

2.4 作为企业的基础设施开展运维36

2.4.1 对整个平台的责任36

2.4.2 支持平台37

2.4.3 运维规范38

2.5 结语39

第二部分 平台工程实践

第3章 如何开始以及何时开始45

3.1 培育小规模的平台合作45

3.2 构建替代传统协作模式的平台团队51

3.2.1 集中所有权的收益是否值得付出这些成本52

3.2.2 认识到集体动力已消失52

3.2.3 专注于解决问题，而不是一味关注新技术或架构53

3.2.4 谨防来自超大规模公司的新工程师53

3.2.5 谨慎且缓慢地招聘产品经理（并避免项目经理）54

3.2.6 集成/共享服务平台的附加问题55

3.3 传统基础设施组织的转型57

3.3.1 工程文化需要彻底改变57

3.3.2 确定最具潜力的起步领域57

3.3.3 要认识到，不能只靠产品经理来搞定一切58

3.3.4 改变产品支持方式58

3.3.5 更新面试流程58

3.3.6 更新认可与奖励体系59

3.3.7 不要设置过多的项目经理59

3.3.8 应当接受团队将花更多时间与客户沟通，并减少写代码的时间59

3.3.9 进行必要的重组60

3.3.10 保持乐趣60

3.4 结语60

第4章 打造优秀的平台团队62

4.1 单一职能平台团队的风险63

4.1.1 过度关注系统63

4.1.2 过度关注开发64

4.2 平台工程师的不同角色65

4.2.1 软件工程师66

4.2.2 系统工程师67

4.2.3 可靠性工程师68

4.2.4 系统专家69

4.3 各类工程师的招聘与认可70

4.3.1 允许角色特定的职位头衔71

4.3.2 应避免创建新的软件工程师职级矩阵71

4.3.3 最多使用一级矩阵来表示系统角色72

4.3.4 如有必要，创建新的软件工程师面试流程73

4.3.5 系统相关岗位的面试仅需略作调整74

4.3.6 客户同理心面试75

4.4 优秀的平台工程经理需要具备哪些特质76

4.4.1 平台运维实践经验76

4.4.2 大型长期项目的经验77

4.4.3 注重细节77

4.5 平台团队的其他角色78

4.5.1 产品经理78

4.5.2 产品负责人79

4.5.3 项目经理/技术项目经理79

4.5.4 开发者布道师、技术文档撰写者及支持工程师80

4.6 构建平台工程团队文化80

4.6.1 一个由开发团队和SRE团队共生的平台80

4.6.2 开发团队的优势与劣势81

4.6.3 合并团队与增加产品管理81

4.6.4 注入平台工程文化82

4.7 结语83

第5章 平台即产品84

5.1 产品文化以客户为中心85

5.1.1 内部客户的特征85

5.1.2 与内部客户协作87

5.1.3 设身处地为客户着想89

5.1.4 摆脱“功能商店陷阱”，更全面地服务客户91

5.2 产品发现与市场分析92

5.2.1 识别潜在的平台产品92

5.2.2 改进现有产品/服务：是边缘优化还是重新思考问题95

5.2.3 市场调研：验证新投资97

5.2.4 产品度量指标100

5.3 成功的产品执行：制定产品路线图104

5.3.1 愿景：长期105

5.3.2 战略：中期105

5.3.3 目标和指标：本年度106

5.3.4 里程碑：季度性106

5.3.5 面向客户的路线图106

5.3.6 功能规格说明107

5.3.7 熟能生巧107

5.4 产品失效模式109

5.4.1 低估迁移成本109

5.4.2 高估用户的变更预算109

5.4.3 在稳定性较差时高估新功能的价值110

5.4.4 产品经理过多导致的工程团队配比失衡110

5.4.5 产品经理承担了工程经理应履行的工作111

5.5 结语112

第6章 平台的运维113

前言/序言

前言

Camille的前言

2017年，就在我的第一本书出版的时候，我开始了一份新工作，担任平台工程负责人。也正是在这时，我认识了Ian。他刚从西雅图搬到纽约，此前在亚马逊和AWS工作了好几年。我们一拍即合，迅速成了志同道合的伙伴：我们都面临着同样的挑战，要帮助一群才华横溢的工程师扭转团队声誉，把一个“只关注自己认为有趣的事情，而忽视客户需求和系统稳定性的团队”转变成一个成熟、高效、以客户为中心的平台团队。

在接下来的几年里，我们为这次转型奠定了基础。Ian向我传授了他在亚马逊工作期间积累的宝贵经验：从撰写六页文档用于设计和规划，到招募系统工程师，再到建立更严格的运营规范（同时始终对用户级网络操作保持审慎态度）。而我则专注于引入产品管理理念、展现果断的领导力、明确目标，以及为追求卓越而主动改变那些需要改变之处的普遍意愿。结合其他平台主管们在技术、产品、管理和运营方面的专业知识，我们成功地改变了团队文化，并实施了许多你将在本书中读到的实践方法。

多年后，Ian离开公司，投身快速发展的创业领域，迎接新的挑战，而我们一直保持着紧密的联系。毫不意外，Ian在创业公司担任高管期间取得了卓越的成就。在我们各自带领平台团队不断成长的职业旅程中，彼此扶持前行，共同经历了高峰与低谷。

时光飞逝，转眼已是2023年初，一个挥之不去的想法萦绕心头：既然“平台工程”日益流行，为什么不写一本关于它的书呢？当时我手头的工作繁忙，担心自己难以独自承担这样一个项目。但很快，我就想到了一位理想的合著者—Ian！他不仅文笔出色，思维清晰，而且对这一主题有着鲜明的见解。在给他发了一条短信，又与他进行了一次视频通话之后，我们便向O’Reilly出版社提交了策划书，本书就这样诞生了。

回顾往昔是为了说明，我们之所以撰写这本书，是因为平台工程多年来既是我们的热情所在，也是我们的职业追求。尽管“平台工程”这个术语可能是近期引发热议的技术热词，但我们一直在实践中努力探索如何做到极致，这远远早于这一概念引发热议的最新浪潮。

事实上，我们听说的大多数平台工程团队都有着相同的名声：仅凭兴趣开发技术，不考虑谁真正需要这些技术，甚至在这类关键工作中也缺乏应有的运营成熟度。这是因为做好平台工程确实非常困难！抛开浮夸的宣传，你会发现，这实际上是组织成熟度的一种演进。既然我们已经认识到产品管理的重要性，就不能仅因为觉得有趣而豪无目标地进行开发。我们也不能再以规划困难为借口来掩饰我们在执行上的不足。如果我们希望赢得信任，为其他工程师提供关键系统，就必须认真对待这些系统的操作稳定性。

本书不仅探讨了上述内容，还涵盖了更多深刻见解。我们多年来在这一领域积累的所有经验教训构成了本书的基础框架。为了确保内容的广度与深度，我们还邀请了行业内不同平台工程领域的多位专家分享他们的宝贵建议与真实故事。

读者对象

本书的目标读者是组织中负责软件平台设计和运维的技术、产品及团队领导者，包括资深工程师、架构师、产品经理、项目经理和工程经理。虽然这些读者中大多数人都本能地理解到，平台工程并非仅局限于云计算和开源系统的自动化构建，但是，他们往往难以明确自身应承担的职责，并且缺乏能够做好这些工作的具体实践经验。

我们同样希望能够触及更广泛的技术管理层，包括首席技术官（CTO）、高级副总裁（SVP）以及“产品工程”管理团队。这些领导者通常会提出以下问题：“既然我们已经采用了AWS，为什么平台团队仍然如此庞大？”“为什么我们的平台团队人手充足，却依然行动迟缓？”“为什么我们最近采用的［公有云/站点可靠性工程（Site Reliability Engineering，SRE）/开发者体验］未能解决这些问题？”本书的前两章将着力解答这些核心问题，而后续章节中详述的诸多技术方法不仅对产品组织大有裨益，还可能引发这些管理者的深刻反思。

最后，本书适合所有希望学习如何使平台工程超越技术实施层面并有效运作的读者阅读。无论你是在创业公司思考何时启动平台建设，还是在大型企业计划从基础设施工程转型为平台工程，抑或介于两者之间的任何情况，本书都将为你提供宝贵的指导与启发。

如何阅读本书

本书分为三部分。

第一部分将介绍平台工程的基础知识：它的定义、意义以及核心要素。这两个简短的章节旨在帮助你清晰理解我们在讨论平台工程时所指的核心内容。

第二部分是本书的核心内容，共包含8章，将深入探讨平台领域中的各种常见挑战，旨在概述重要的领导力和执行理念与实践。书中偶尔介绍一些技术内容，但本书的目的并非教授平台底层技术，而是聚焦于在这一领域取得成功所需的组织实践。其中部分章节只能提供宏观概述，而这些内容本身足以独立成书（例如，第5章虽然篇幅较长，但也仅触及表面）。我们希望，阅读本书的读者能够通过博客、演讲或书籍等形式与技术社区