《平台工程：技术、产品与团队》—

平台工程：技术、产品与团队

茹炳晟, 徐德晨译

出版时间：2025年08月

页数：264

“平台工程是一项团队行动。这是你们的行动指南。”
——Kelsey Hightower
Google前杰出工程师，Kubernetes: Up & Running合著者
在过去的25年里，软件组织一直在努力应对一个持续存在的挑战：如何管理跨多个团队共享的代码、工具和基础设施。共享服务团队往往未能满足需求——他们提供笨重且不灵活的系统，忽视用户需求，也无法提供稳定性和可靠性。一些组织甚至尝试走向另一个极端，但结果却常常是一片混乱，小团队深陷复杂性之中。然而，少数组织通过采用一种截然不同的方法破解了这个难题，这种方法就是平台工程。这些团队通过打造强大且用户友好的平台，成功化解了复杂性难题，提供了杠杆效应，并显著提升了应用开发团队的生产力。
本书将帮助工程师、管理者、产品经理和领导者了解现代以平台为核心的组织所需的转变。你将深入学习平台工程的定义及其边界，以及为何它正逐渐成为一项不可或缺的能力。
通过阅读本书，你将：
● 培养将平台视为产品的思维，并以开发者为核心。
● 了解平台工程团队的本质：团队的职责包括什么，不包括什么。
● 开启平台工程的引入流程。
● 探索成为平台团队产品经理的关键能力。
● 洞悉在平台扩展过程中所面临的挑战。
● 深入了解成功领导平台工程团队的最佳实践，助力团队迈向卓越

目录
产品信息
关于作者
封面介绍

序
前言
第一部分平台工程的内容和意义
第1章平台工程为何变得不可或缺
1.1 定义“平台”及其他重要术语
1.2 过度泛化的泥沼
1.3 我们如何陷入过度泛化的泥沼
1.3.1 变革之一：选择的爆炸性增长
1.3.2 变革之二：更高的运营需求
1.3.3 结果：深陷泥沼
1.4 平台工程如何疏通泥沼
1.4.1 在限制原语的同时最小化开销
1.4.2 减少应用程序间的黏合代码
1.4.3 集中管理迁移成本
1.4.4 允许应用程序开发人员运营他们开发的系统
1.5 赋能团队专注于构建平台
1.6 结语
第2章平台工程的支柱
2.1 采用精心策划并以产品为导向的方法
2.2 开发基于软件的抽象
2.2.1 主要抽象层：平台服务及API
2.2.2 胖客户端
2.2.3 OSS定制化
2.2.4 集成元数据注册表
2.3 服务广大应用程序开发人员
2.4 作为企业的基础设施开展运维
2.4.1 对整个平台的责任
2.4.2 支持平台
2.4.3 运维规范
2.5 结语
第二部分平台工程实践
第3章如何开始以及何时开始
3.1 培育小规模的平台合作
3.2 构建替代传统协作模式的平台团队
3.2.1 集中所有权的收益是否值得付出这些成本
3.2.2 认识到集体动力已消失
3.2.3 专注于解决问题，而不是一味关注新技术或架构
3.2.4 谨防来自超大规模公司的新工程师
3.2.5 谨慎且缓慢地招聘产品经理（并避免项目经理）
3.2.6 集成/共享服务平台的附加问题
3.3 传统基础设施组织的转型
3.3.1 工程文化需要彻底改变
3.3.2 确定最具潜力的起步领域
3.3.3 要认识到，不能只靠产品经理来搞定一切
3.3.4 改变产品支持方式
3.3.5 更新面试流程
3.3.6 更新认可与奖励体系
3.3.7 不要设置过多的项目经理
3.3.8 应当接受团队将花更多时间与客户沟通，并减少写代码的时间
3.3.9 进行必要的重组
3.3.10 保持乐趣
3.4 结语
第4章打造优秀的平台团队
4.1 单一职能平台团队的风险
4.1.1 过度关注系统
4.1.2 过度关注开发
4.2 平台工程师的不同角色
4.2.1 软件工程师
4.2.2 系统工程师
4.2.3 可靠性工程师
4.2.4 系统专家
4.3 各类工程师的招聘与认可
4.3.1 允许角色特定的职位头衔
4.3.2 应避免创建新的软件工程师职级矩阵
4.3.3 最多使用一级矩阵来表示系统角色
4.3.4 如有必要，创建新的软件工程师面试流程
4.3.5 系统相关岗位的面试仅需略作调整
4.3.6 客户同理心面试
4.4 优秀的平台工程经理需要具备哪些特质
4.4.1 平台运维实践经验
4.4.2 大型长期项目的经验
4.4.3 注重细节
4.5 平台团队的其他角色
4.5.1 产品经理
4.5.2 产品负责人
4.5.3 项目经理/技术项目经理
4.5.4 开发者布道师、技术文档撰写者及支持工程师
4.6 构建平台工程团队文化
4.6.1 一个由开发团队和SRE团队共生的平台
4.6.2 开发团队的优势与劣势
4.6.3 合并团队与增加产品管理
4.6.4 注入平台工程文化
4.7 结语
第5章平台即产品
5.1 产品文化以客户为中心
5.1.1 内部客户的特征
5.1.2 与内部客户协作
5.1.3 设身处地为客户着想
5.1.4 摆脱“功能商店陷阱”，更全面地服务客户
5.2 产品发现与市场分析
5.2.1 识别潜在的平台产品
5.2.2 改进现有产品/服务：是边缘优化还是重新思考问题
5.2.3 市场调研：验证新投资
5.2.4 产品度量指标
5.3 成功的产品执行：制定产品路线图
5.3.1 愿景：长期
5.3.2 战略：中期
5.3.3 目标和指标：本年度
5.3.4 里程碑：季度性
5.3.5 面向客户的路线图
5.3.6 功能规格说明
5.3.7 熟能生巧
5.4 产品失效模式
5.4.1 低估迁移成本
5.4.2 高估用户的变更预算
5.4.3 在稳定性较差时高估新功能的价值
5.4.4 产品经理过多导致的工程团队配比失衡
5.4.5 产品经理承担了工程经理应履行的工作
5.5 结语
第6章平台的运维
6.1 值班实践
6.1.1 为什么需要24×7全天候值班保障
6.1.2 为什么要合并DevOps
6.1.3 实现可持续的值班工作负载
6.2 用户支持实践
6.2.1 平台工程师为何应该参与支持工作
6.2.2 第一阶段：确定支持级别
6.2.3 第二阶段：将非关键支持从值班工作中区分开
6.2.4 第三阶段：聘请支持专员
6.2.5 第四阶段：在规模化条件下的工程支持部门
6.3 运维反馈实践
6.3.1 SLO和SLA是必要的，错误预算则是可选的
6.3.2 变更管理
6.3.3 合成监控
6.3.4 运维评审
6.4 结语
第7章规划与交付
7.1 规划长期项目
7.1.1 在提案文件中明确目标与需求
7.1.2 从提案到行动计划
7.1.3 避免长期拖延
7.2 自下而上的路线图规划
7.2.1 “基础运维”工作
7.2.2 强制任务
7.2.3 系统改进
7.2.4 综合分析
7.3 双周状态沟通：成果与挑战
7.3.1 基本原理
7.3.2 为什么：价值是什么
7.3.3 是什么：结构化成果与挑战更新
7.3.4 别忘了这些挑战
7.3.5 让团队主动记录成功经验与面临的挑战
7.4 结语
第8章平台架构重构
8.1 为什么选择架构重构而不是构建2.0版本
8.1.1 不同的工程思维模式
8.1.2 架构需求驱动思维模式需求
8.1.3 为什么构建2.0版本很难但重构具有可行性
8.2 通过架构解决安全问题
8.3 架构重构的防护准则
8.3.1 兼容性
8.3.2 测试
8.3.3 前期环境
8.3.4 分批次部署、缓慢发布与版本滞后
8.4 架构重构规划
8.4.1 第一步：对最终重构目标要有远大构想
8.4.2 第二步：考虑迁移成本
8.4.3 第三步：确定未来12个月的主要成果
8.4.4 第四步：争取管理层的支持与认同，并做好等待的准备
8.5 结语
第9章平台迁移与退役
9.1 迁移的不良模式
9.2 构建更简易的迁移
9.2.1 使用产品抽象：减少黏合代码并限制变化
9.2.2 设计透明迁移架构
9.2.3 跟踪使用元数据
9.2.4 开发自动化功能以避免使用记录板
9.2.5 使用文档帮助用户建立切换路径
9.3 协调更平稳的迁移
9.3.1 界定、限制和确定计划变更的优先级
9.3.2 及早公开沟通
9.3.3 完成最后20%的工作
9.3.4 谨慎使用强制命令
9.4 平台退役
9.4.1 决定何时终止
9.4.2 协调退役操作
9.4.3 在适当的时候不要害怕逐步让平台退役
9.5 结语
第10章管理与利益相关者的关系
10.1 利益相关者图谱：权力-利益矩阵
10.2 以恰当的透明度进行沟通
10.2.1 警惕过度分享细节
10.2.2 恰当安排一对一会谈
10.2.3 跟踪期望和承诺
10.2.4 通过协作会议和客户顾问委员会扩展规模
10.2.5 在困难时期加强沟通
10.3 寻找可接受的折中方案
10.3.1 明确商业影响
10.3.2 有时需要“接受妥协”
10.3.3 如何说“不”而不破坏关系
10.3.4 影子平台的妥协方案
10.4 资金困境：成本与预算管理
10.4.1 第一步：弄清楚谁将在未来受益
10.4.2 第二步：将工作划分为团队（避免逐一分配给个人）
10.4.3 第三步：提出削减内容的建议，并对需要保留的内容表达明确意见
10.5 结语
第三部分怎样算成功
第11章你的平台相互协同
11.1 目标一致
11.1.1 通过合适的人才组合使团队与目标保持一致
11.1.2 通过共同实践使文化与目标保持一致
11.1.3 借助团队协作使文化与目标保持一致
11.2 产品战略的协同
11.2.1 通过独立产品管理培养跨平台思维
11.2.2 促进具有独立贡献者的跨平台架构体系
11.2.3 从全平台客户调查的评论中主动寻求反馈
11.2.4 审慎地通过重组解决缺乏协同问题
11.3 计划的协同
11.3.1 仅需在较大型项目上达成一致，而无须关注每一个细枝末节
11.3.2 直面分歧时要坦诚相待
11.3.3 最终的协同源于原则驱动的领导力
11.4 统筹整合：推动组织协同
11.5 结语
第12章你的平台值得信任
12.1 信任你的运维方式
12.1.1 通过充分授权经验丰富的领导者加速信任的建立
12.1.2 通过用例排序优化信任增长
12.2 信任你的重大投资
12.2.1 获得技术利益相关者对架构重构的认可与信任
12.2.2 为赢得对新产品的信任寻求高管背书
12.2.3 维护旧系统以保持信任
12.2.4 赢得信任需要对“正确”保持灵活性
12.3 信任优先交付
12.3.1 打造高效文化
12.3.2 确定项目优先级以释放团队产能
12.3.3 挑战产品范围的假设
12.4 整合探讨：过度耦合平台案例
12.5 结语
第13章你的平台管理复杂性
13.1 应对人际协调中的非本质复杂性
13.2 管理影子平台的复杂性
13.3 通过控制增长管理复杂性
13.4 通过产品发现管理复杂性
13.5 整合全局：平衡内外复杂性
13.5.1 开源软件运维的倦怠问题
13.5.2 试图改变局面（但未能成功）
13.5.3 影子平台带来重新规划
13.5.4 重新规划的执行
13.6 结语
第14章你的平台深受喜爱
14.1 喜爱，自然而然
14.2 喜爱也可能是一种取巧之道
14.3 喜爱可以很明显
14.4 喜爱的力量：让用户非凡卓越
14.5 结语
结束语

书名：平台工程：技术、产品与团队

作者：Camille Fournier, Ian Nowland 著

译者：茹炳晟, 徐德晨译

国内出版社：机械工业出版社

出版时间：2025年08月

页数：264

书号：978-7-111-78808-9

原版书书名：Platform Engineering:A Guide for Technical,Product,and People Leaders

原版书出版商：O'Reilly Media

Camille Fournier

Camille Fournier是一位经验丰富的技术管理者，同时具备深厚的技术背景、行政领导力及工程管理能力。
Camille Fournier是一位资深科技高管，拥有从早期创业公司到《财富》全球50强企业的领导经验。她曾是CNCF技术指导委员会的创始成员之一，现在是ACM Queue的编委。她在O’Reilly出版了The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change和97 Things Every Engineering Manager Should Know两部著作。

查看Camille Fournier更多信息

Ian Nowland

Ian Nowland拥有25年软件行业从业经验，最近4年曾在Datadog担任核心工程高级副总裁。在此之前，他曾供职于AWS（2008年至2016年），担任Amazon EMR项目的技术负责人，并领导了EC2 Nitro项目最初5年的研发工作。目前，他是一家创业公司的联合创始人。

查看Ian Nowland更多信息

本书封面上的动物是一种名为大理石蝾螈（学名：Triturus marmoratus）的两栖动物，主要分布于西欧的法国和伊比利亚半岛。这种蝾螈因独特的外观而得名：深褐色或黑色的身体上布满不规则的绿色大理石状花纹。这种颜色为它在森林和草原的自然栖息地中提供了极好的伪装。此外，雌性大理石蝾螈的背部还有一条醒目的橙色条纹。雌性通常体型较大，体长为5~6.5英寸。
大理石蝾螈主要以昆虫、蠕虫和其他小型无脊椎动物为食，无论在陆地还是水中它都能捕食。虽然这种动物以陆生生活为主，但作为两栖动物，它们需要水域进行繁殖，并且通常在寒冷季节栖息在池塘中。每年二月的繁殖季节，雄性蝾螈的背部会长出醒目的羽状背冠，并通过摆动尾巴的动作传播信息素来吸引配偶。雌性螈产卵时极为谨慎，会先嗅闻和检查水生植物的叶片，然后选择合适的叶片将每一颗卵单独包裹起来。研究发现，大理石蝾螈能够依靠地磁场和星座等天体线索来准确找到它们熟悉的繁殖池塘。
大理石蝾螈因栖息地丧失，已被世界自然保护联盟（ICN）列为易危物种。

购买选项

定价：99.00元

书号：978-7-111-78808-9

出版社：机械工业出版社

联系出版社邮购