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

基础设施一直是组织运行自家开发软件的核心。然而，随着云服务商逐渐接管计算资源，公司现在能够将敏捷和以客户为中心的优势引入开发流程。如今，将产品管理理念融入基础设施组织已经成为一种新趋势。但在基础设施仍然主导公司运营的背景下，这种转变如何实现呢？这本实用的书籍将引导工程师、管理者、产品经理和领导者了解现代平台驱动组织所需的变革。书中将深入探讨平台工程的概念（包括它的定义和不包括的内容）以及它为开发者和团队带来的好处和价值。你将学到如何将平台视作产品，并识别常见的技术和管理障碍。

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

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