书中提到了DevOps三要义：
- 流动
- 反馈
- 持续学习与探索
持续学习这块还提到了「学习型组织的概念」。
书中也提到了康威定律，这在软件工程中还挺常见的。按照百度百科的说法，康威定律是马尔文康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。康威定律可总结为四个定律：
- 第一定律组织沟通方式会通过系统设计表达出来。
- 第二定律时间再多一件事情也不可能做的完美，但总有时间做完一件事情。
- 第三定律线型系统和线型组织架构间有潜在的异质同态特性。
- 第四定律大的系统组织总是比小系统更倾向于分解。
书中令我印象深刻的部分在于Netflix的Chaos Monkey，甚至还衍生出了「猿猴军团」，这很符合我的想法，即使是在政府部门在也可以试一试。
Chaos Monkey 是由 Netflix 开发的一款用于实现容错测试的开源工具，它随机地“搞破坏”，比如终止虚拟机或实例，以确保系统的弹性和健壮性。
Chaos Monkey is a resiliency tool that helps applications tolerate random instance failures.
书中还提到了安东绳，安东绳（日语：アンドン，源自"行灯"）是丰田汽车生产线使用的特殊拉绳，该装置允许员工在发现异常时拉动绳索暂停生产，防止瑕疵品流入后续工序，其设计可追溯至丰田佐吉发明的自动停止纺织机。
在安东绳的扩展之上，丰田总结出一套安东精益生产管理体系，即丰田管理模式，是一种现代企业的信息管理工具。Andon也称暗灯或安灯，原为日语的音译，日语的意思为“灯”、“灯笼”，在这里表示一个系统， Andon系统能够收集生产线上有关设备和质量管理等与生产有关的信息，加以处理后，控制分布于车间各处的灯光和声音报警系统。从而实现生产信息的透明化。
安东绳构成安东系统（ANDON）的核心机制，触发后传送带减速或整线停止，体现“自工序完结”质量管理体系。系统通过声光信号实现生产可视化，集成设备与质量管理信息，赋予一线员工停线权以保障品质优先，使员工摆脱了传统生产线上"可替换标准化零件"的角色定位。
最后，政府部门写代码的实践还挺一致的，中国的某些部门编程序，有编制的人复制粘贴没编制的人写的代码（连外包都不算）。
书籍简介#
作者: [美] 吉恩·金（Gene Kim） / [英] 耶斯·亨布尔（Jez Humble） / [比] 帕特里克·德布瓦（Patrick Debois） / [美] 约翰·威利斯（John Willis）
出版社: 人民邮电出版社
出品方: 图灵教育
原作名: The DevOps Handbook: How to Create World-Class Agility, Reliability, & Security in Technology Organizations
译者: 茹炳晟 / 管俊 / 董越 / 王晓翔
出版年: 2024-1
页数: 298
定价: 139.8元
装帧: 平装
ISBN: 9787115638779
内容简介#
本书是软件开发与运维领域经典参考书最新升级版，由DevOps领域几位先驱撰写。第2版根据最新研究和最佳实践更新了内容，增加了大量新案例，方便大家在各行各业落地DevOps实践。
本书内容分为六部分，围绕“DevOps三要义”（流动、反馈、持续学习与探索）探讨DevOps的理论、原则和落地实践。第一部分介绍DevOps理论基础和关键主题，第二部分介绍如何寻找切入点并启动转型，第三部分介绍如何通过构建部署流水线来加速流动，第四部分讨论如何通过建立有效的生产环境监控发现和解决问题，第五部分探讨如何通过建立公正的文化促进持续学习与探索，第六部分介绍将安全与合规活动集成到日常工作。
本书适合所有互联网企业和传统企业从业者阅读。
编辑推荐
1-【经典】DevOps领域经典重磅升级，原版Amazon 4.7星好评
2-【权威】DevOps先驱Gene Kim、持续交付之父Jez Humble领衔作品
3-【专业】国内DevOps资深实践者翻译，一线专家联袂推荐
4-【实战】汇聚全球一线DevOps落地案例（40个大案例）
5-【系统】IT名作《凤凰项目》实战篇，数字化转型三剑客读本
6-【落地】打造敏捷、可靠、安全、高效的技术型组织
作者简介#
Gene Kim · DevOps先驱
畅销书作者、研究员、首席技术官、IT Revolution创始人、DevOps企业峰会创始人，专注于研究大型复杂组织的技术转型。著有风靡全球的《凤凰项目》《独角兽项目》。
Jez Humble · 持续交付之父
Google Cloud SRE、加州大学伯克利分校讲师、畅销书作者，著有Jolt大奖获奖图书《持续交付》。
Patrick Debois · DevOps之父
Snyk公司DevOps关系总监兼顾问。致力于通过在开发、项目管理和系统管理中运用敏捷技术，弥合项目和运营之间的鸿沟。
John Willis · DevOps先驱
Red Hat全球转型办公室高级总监、Beyond The Phoenix Project作者、Profound播客主持人。在IT管理行业拥有超过40年经验。
正文摘录#
第一部分 DevOps三要义#
第1章 敏捷、持续交付与DevOps三要义#
1.1 制造业价值流#
1.2 技术价值流#
1.2.1 聚焦部署前置时间#
1.2.2 关注返工指标——%C/A#
1.3 DevOps三要义：DevOps的基础原则#
案例研究：向着巡航高度爬升：美国航空的DevOps之旅（第一部分，2020年）#
1.4 小结#
第2章 第一要义：流动#
2.1 使工作可视化#
2.2 限制在制品数量#
2.3 缩减批量大小#
2.4 减少工作交接#
2.5 持续识别并改进约束#
2.6 消除价值流中的困境和浪费#
案例研究：医疗行业中改善流动性和改进约束的实践（2021年）#
2.7 小结#
第3章 第二要义：反馈#
3.1 在复杂系统中安全地工作#
3.2 及时发现问题#
3.3 群策群力，攻克难题#
案例研究：Excella的安灯绳实验（2018年）#
3.4 从源头保障质量#
3.5 为下游工作中心优化#
3.6 小结#
第4章 第三要义：持续学习与探索#
4.1 建立学习型组织，打造安全文化#
4.2 将日常工作的改进制度化#
4.3 将局部经验转化为全局改进#
4.4 在日常工作中注入弹性模式#
4.5 领导层强化与巩固学习文化#
案例研究：贝尔实验室的故事（1925年）#
4.6 小结#
第一部分总结#
第二部分 从哪里开始#
第5章 选择合适的价值流切入#
5.1 绿地项目与棕地项目#
案例研究：Kessel Run：空中加油系统的棕地项目转型（2020年）#
5.2 兼顾记录型系统和交互型系统#
5.3 从最具同理心和创新精神的团队开始#
案例研究：在整个企业中推广DevOps转型：美国航空的DevOps之旅（第二部分，2020年）#
5.4 在组织中推广DevOps转型#
案例研究：英国税务及海关总署如何通过超大规模PaaS拯救经济于水火（2020年）#
5.5 小结#
第6章 理解、可视化和运用价值流#
6.1 通过绘制价值流图改进工作#
6.2 确定价值流的参与团队#
6.3 通过绘制价值流图展现工作#
6.4 组建专职转型团队#
6.4.1 目标一致#
6.4.2 保持小跨度的改进计划#
6.4.3 为非功能性需求和偿还技术债务预留20%的时间#
案例研究：LinkedIn的“反转行动”（2011年）#
6.4.4 提高工作的可视化程度#
6.5 使用工具强化预期行为#
6.6 小结#
第7章 参照康威定律设计组织结构与系统架构#
7.1 组织原型#
7.2 过度以职能为导向的危害（“成本优化”）#
7.3 组建市场型团队（“速度优化”）#
7.4 让职能型组织高效运转#
7.5 将测试、运维和信息安全纳入日常工作#
7.6 让团队成员都成为通才#
7.7 投资服务与产品，而非项目#
7.8 依照康威定律设定团队边界#
7.9 创建松耦合的架构，保证生产力和安全#
7.10 保持小规模团队（“两张比萨”原则）#
案例研究：Target公司的“API启用”项目（2015年）#
7.11 小结#
第8章 将运维融入日常开发工作#
8.1 构建共享服务，提升开发人员生产力#
8.2 将运维工程师融入服务团队#
8.3 为服务团队指派运维联络人#
8.4 邀请运维工程师参加开发团队的例行活动#
8.4.1 邀请运维工程师参加每日站会#
8.4.2 邀请运维工程师参加回顾会议#
8.4.3 使用共享的看板展示相关运维工作#
案例研究：全英房屋抵押贷款协会：拥抱更好的工作方式（2020年）#
8.5 小结#
第二部分总结#
第三部分 “第一要义：流动”的具体实践#
第9章 为部署流水线奠定基础#
9.1 按需搭建开发、测试和生产环境#
9.2 使用统一的代码仓库#
9.3 简化基础设施的重建#
案例研究：酒店公司如何通过容器技术实现年收入300亿美元（2020年）#
9.4 代码运行在类生产环境才算“开发完成”#
9.5 小结#
第10章 实现快速可靠的自动化测试#
10.1 持续构建、测试和集成代码与环境#
10.2 构建快速可靠的自动化测试套件#
10.3 在自动化测试阶段尽早发现问题#
10.3.1 确保测试快速运行#
10.3.2 测试驱动开发#
10.3.3 尽可能将手工测试自动化#
10.3.4 在测试套件中集成性能测试#
10.3.5 在测试套件中集成非功能性需求测试#
10.4 在部署流水线失败时拉下安灯绳#
10.5 小结#
第11章 实现持续集成#
11.1 小批量开发vs大批量合并#
11.2 基于主干的开发实践#
案例研究：Bazaarvoice的持续集成实践（2012年）#
11.3 小结#
第12章 自动化和低风险的发布#
12.1 部署流程自动化#
案例研究：CSG的每日部署（2013年）#
12.1.1 实现自动化的自助部署#
12.1.2 将代码部署集成到部署流水线#
案例研究：Etsy持续部署案例：开发者自助部署（2014年）#
12.2 部署与发布解耦#
12.2.1 基于部署环境的发布模式#
案例研究：Dixons Retail：蓝绿部署在POS系统中的应用（2008年）#
12.2.2 基于应用程序的发布模式#
案例研究：Facebook Chat功能的灰度发布案例（2008年）#
12.3 持续交付和持续部署实践调研#
案例研究：CSG：实现开发与运维的双赢（2016年）#
12.4 小结#
第13章 降低发布风险的架构#
13.1 提高研发效能、可测试性和安全性的架构#
13.2 架构原型：单体架构vs微服务#
案例研究：亚马逊的演进式架构（2002年）#
13.3 安全地演进企业架构#
案例研究：Blackboard Learn的绞杀者应用模式（2011年）#
13.4 小结#
第三部分总结#
第四部分 “第二要义：反馈”的具体实践#
第14章 使用监控发现和解决问题#
14.1 搭建集中式的监控基础设施#
14.2 为应用程序添加日志监控#
14.3 用监控指引问题的分析和解决#
14.4 把添加监控融入日常工作#
14.5 以自助方式访问监控数据#
案例研究：搭建自助的监控体系：LinkedIn的实践（2011年）#
14.6 对监控配置查漏补缺#
14.6.1 应用程序和业务的监控#
14.6.2 基础设施的监控#
14.6.3 显示其他相关信息#
14.7 小结#
第15章 使用监控预防问题并实现业务目标#
15.1 用均值和标准差发现潜在问题#
15.2 监测到非预期结果时告警#
15.3 监控数据非高斯分布带来的问题#
案例研究：Netflix的自动扩容能力（2012年）#
15.4 使用异常检测技术#
案例研究：异常检测中的高级技术（2014年）#
15.5 小结#
第16章 引入反馈机制实现安全部署#
16.1 利用监控确保部署上线更安全#
16.2 让开发和运维轮流值班#
16.3 让开发人员到价值流下游看一看#
16.4 先由开发人员自行运维#
案例研究：谷歌的移交就绪评审和发布就绪评审（2010年）#
16.5 小结#
第17章 将假设驱动开发和A/B测试纳入日常工作#
17.1 A/B测试简史#
17.2 在新功能测试中整合A/B测试#
17.3 在软件发布中整合A/B测试#
17.4 在功能规划中整合A/B测试#
案例研究：雅虎问答在快速迭代中实验，实现收入翻倍#
17.5 小结#
第18章 通过评审和协调提升工作质量#
18.1 变更审批流程带来的问题#
18.2 过度变更控制带来的问题#
案例研究：从三位高管审批到自动审批——阿迪达斯的大规模发布实践（2020年）#
18.3 对变更进行协调和规划#
18.4 对变更进行同行评议#
案例研究：谷歌的代码评审（2010年）#
18.5 冻结变更并进行大量手工测试的隐患#
18.6 用结对编程提升各种类型变更的质量#
案例研究：Pivotal用结对编程代替阻滞的代码评审过程（2011年）#
18.7 分析拉取请求过程的有效性#
18.8 对官僚化流程进行大胆简化#
18.9 小结#
第四部分 总结#
第五部分 “第三要义：持续学习与探索”的具体实践#
第19章 将学习融入日常工作#
19.1 建立公正的学习文化#
19.2 故障发生后及时召开回顾会议#
19.3 尽可能广泛公开回顾会议纪要#
19.4 降低事故容差以发现更弱的故障信号#
19.5 重新定义失败并鼓励评估风险#
19.6 向生产环境注入故障，培养系统弹性和学习氛围#
19.7 设立故障演练日#
案例研究：CSG如何将故障转化为有效的学习机会（2021）#
19.8 小结#
第20章 将局部经验转化为全局改进#
20.1 将可复用的标准流程自动化#
20.2 创建组织级的单一共享源代码仓库#
20.3 用自动化测试记录、交流实践以传播知识#
20.4 通过规范非功能性需求来设计运维#
20.5 将可复用的运维用户故事融入开发过程#
20.6 确保技术选型有助于组织达成目标#
案例研究：Etsy的新技术栈标准化（2010年）#
案例研究：Target的众包技术治理（2018年）#
20.7 小结#
第21章 预留时间开展组织学习和改进#
21.1 将偿还技术债务变为例行活动#
21.2 让所有人教学相长#
21.3 在DevOps会议中分享经验#
案例研究：美国全国保险、Capital One和Target的内部技术会议（2014年）#
21.4 创建社区结构来推广实践#
21.5 小结#
第五部分 总结#
第六部分 整合信息安全、变更管理和合规性的技术实践#
第22章 信息安全是每个人的日常工作#
22.1 将安全集成到开发迭代演示#
22.2 将安全问题纳入缺陷跟踪和事后分析#
22.3 将预防性安全控制集成到共享源代码仓库及共享服务#
22.4 将安全集成到部署流水线#
22.5 保障应用程序安全#
22.6 保障软件供应链安全#
22.7 保障环境安全#
案例研究：18F使用Compliance Masonry实现联邦政府合规性审查自动化（2016年）#
22.8 将信息安全集成到生产监控系统#
22.8.1 为应用程序创建安全监控#
22.8.2 为环境创建安全监控#
案例研究：Etsy的环境监测（2010年）#
22.9 保护部署流水线#
案例研究：在Fannie Mae开展安全左移（2020年）#
22.10 小结#
第23章 保护部署流水线#
23.1 将安全和合规集成到变更审批流程#
23.2 将低风险的变更归类为标准变更#
23.3 当变更被归类为常规变更时如何处理#
案例研究：Salesforce将自动化基础设施变更归类为标准变更（2012年）#
23.4 通过代码评审实现职责分离#
案例研究：Etsy的PCI合规性以及一则职责分离的警示故事（2014年）#
案例研究：通过业务与技术合作，Capital One实现每天10次有信心的发布（2020年）#
23.5 确保为合规官和审计师提供文档和证据#
案例研究：证明监管环境下的合规性（2015年）#
案例研究：ATM系统离不开生产监控（2013年）#
23.6 小结#
第六部分 总结#
附录1：DevOps大融合#
附录2：约束理论和长期存在的根本矛盾#
附录3：恶性循环列表#
附录4：交接和队列的危害#
附录5：工业安全的误区#
附录6：丰田安灯绳#
附录7：COTS软件#
附录8：事后分析会议（回顾会议）#
附录9：猿猴军团#
附录10：上线时间透明化#
