《持续交付2.0：业务引领的DevOps精要》读书摘记

部分内容可能来自网络或者由AI生成。
如有雷同，纯属巧合，仅供学习参考之用。

概述

《持续交付2.0》以业务价值驱动为核心，重新定义了DevOps时代的软件交付方法论。相较于持续交付1.0关注“从代码提交到发布”的流程自动化，2.0版本更强调业务与IT的双向闭环，通过探索环与验证环的双环模型，结合精益思想实现快速价值交付。书中新增组织管理、架构设计等维度，并辅以互联网企业案例，为技术管理者提供从战略到落地的完整框架。

一、 核心理念

• 业务驱动的 DevOps 理念
  • 业务与技术深度融合：强调 DevOps 不应仅局限于技术层面的改进，而需紧密围绕业务目标展开。企业的业务需求瞬息万变，软件研发团队必须快速响应。
  • 价值流分析：引入价值流概念，帮助企业梳理从业务创意提出到最终交付给客户价值的全过程。通过对价值流的分析，识别其中的浪费环节与瓶颈。
• 持续交付的关键实践
  • 自动化流水线：构建涵盖代码构建、测试、部署等环节的自动化流水线是持续交付的核心实践。自动化流水线减少人为干预，提升交付的准确性与效率。
  • 微服务架构：微服务架构将大型应用拆分为多个小型、独立的服务，每个服务专注于特定业务功能。这使得服务的开发、部署和维护更加灵活。
  • 基础设施即代码（IaC）：将基础设施的配置和管理通过代码形式进行描述和版本控制。
• 团队协作与文化变革
  • 跨职能团队组建：DevOps 强调打破开发、运维、测试等部门之间的壁垒，组建跨职能团队。团队成员共同对产品交付负责，从需求分析到上线运维全程参与。
  • 持续学习与反馈文化：鼓励团队成员持续学习新知识、新技术，适应快速变化的技术环境。同时，建立完善的反馈机制，从客户、生产环境获取反馈信息，及时调整产品与流程。
• 持续交付的度量与优化
  • 关键指标设定：确定一系列关键指标衡量持续交付的效果，如交付周期（从需求提出到上线的时间）、部署频率、变更失败率等。通过对这些指标的监测，直观了解交付过程的效率与质量。
  • 持续优化：基于度量数据，持续优化交付流程与实践。当发现变更失败率较高时，深入分析原因，可能是测试覆盖不足、部署流程不稳定等，针对性采取改进措施，如增加测试用例、优化部署脚本等，不断提升持续交付能力。

二、核心方法论与框架

1. 双环模型：价值探索与快速验证

（1）探索环（价值假设验证）

• 目标：识别业务问题，定义最小可行解决方案
• 四步法：
  • 提问：通过“5WHY”法挖掘需求本质（如用户要咖啡的真实诉求是防止困意影响学习）
  • 锚定：定义SMART目标（如用户增长指标需满足“可衡量、有时限”）
  • 共创：利用影响地图、用户旅程图等工具生成多维度解决方案
  • 精炼：筛选优先级最高的最小可行方案（MVP），如“装饰窗法”模拟功能验证用户需求

（2）验证环（方案效果反馈）

• 目标：快速交付MVP并收集真实数据
• 四步法：
  • 构建：采用“时间盒”管理法拆分任务，确保每次迭代交付可验证成果
  • 运行：部署到生产环境或用户手中（如Zappos早期通过手工发货模拟电商功能）
  • 监测：通过系统监控与业务数据收集反馈（如用户提现功能的点击转化率分析）
  • 决策：基于数据调整方向（继续优化/转型/终止）

2. 持续交付四大核心原则

• 坚持少做：聚焦高价值需求（微软仅1/3新功能真正提升核心指标）
• 持续分解问题：将复杂需求拆解为可独立验证的子任务
• 坚持快速反馈：通过自动化测试、流水线缩短反馈周期
• 持续改进并衡量：用引领性指标（如部署频率）驱动过程优化

三、组织与文化变革

1. DevOps文化的三大支柱

• 安全与信任：允许失败的文化（如“故障演练日”机制）
• 持续改善：通过“改善套路”循环（计划-执行-检查-行动）推动渐进式优化
• 度量驱动：关注MTTR（平均修复时间）、发布频率等关键指标，避免“唯数字论”

2. 组织能力建设四步法

1. 定义目标（如“实现每日多次部署”）
2. 设计协作流程（如跨职能团队的“站会+看板管理”）
3. 提供工具链支持（如自动化测试平台、云原生基础设施）
4. 强化行为激励（如将部署成功率纳入绩效考核）

四、技术架构与实践

1. 架构设计原则

• “大系统小做”：通过微服务、插件化架构实现模块解耦（如Microcore/Plugin模式）
• 可测试性与可部署性：设计独立部署单元，支持灰度发布
• 容错设计：实现故障隔离与快速回滚（如断路器模式）

2. 部署流水线设计

• 分层质量关卡：单元测试→集成测试→性能测试→安全扫描
• 环境标准化：使用容器技术实现开发、测试、生产环境一致性
• 制品管理：建立企业级制品库（如Nexus），确保构建物可追溯

3. 分支策略选择

• Trunk-Based Development：主干开发+短生命周期分支，适合高频交付
• Git Flow：功能分支+发布分支，适合版本化产品
• 折中方案：特性开关（Feature Toggle）实现未完成功能的隐藏发布

五、案例与启示

1. 典型实践案例

• GoDC工具开发：200+功能中半数被废弃，验证“少做原则”重要性
• 某金融App用户增长：通过影响地图分析渠道商角色，优化应用商店曝光策略
• 微服务架构改造：采用“绞杀者模式”逐步替换单体系统，降低迁移风险
• 技术债务管理：定期通过“代码健康度扫描”识别高维护成本模块
• 业务对齐技巧：用“用户故事地图”可视化需求价值流，避免技术自嗨

• 战略层面：深刻认识到业务驱动在 DevOps 中的核心地位，企业的技术决策与实践应紧密围绕业务目标，以实现业务价值最大化为导向。这促使企业在制定技术战略时，充分考虑业务需求与市场动态，将技术作为推动业务发展的有力工具。
• 实践层面：学习到一系列实用的持续交付实践方法，如自动化流水线、微服务架构、IaC 等，为提升软件交付效率与质量提供了具体路径。企业可结合自身情况，逐步引入这些实践，优化研发与运维流程，增强应对市场变化的能力。
• 组织层面：理解跨职能团队协作与文化变革在 DevOps 实施中的重要性。打破部门墙，培养持续学习与反馈文化，有助于提升团队凝聚力与创新能力，使企业在数字化竞争中保持优势。技术管理者需兼具架构视野与组织协调能力（如推动测试左移文化）

总结
《持续交付2.0》不仅是一本技术指南，更是一套业务与技术协同进化的系统思维框架。其核心价值在于打破“交付速度vs质量”的伪命题，通过双环模型实现价值驱动的快速迭代，为数字化转型中的组织提供了从文化到架构的完整解决方案。

————书籍摘要————

• 他的观点如此鲜明，没有咨询师的“口头禅”——“It depends”（视情况而定），却道出了产品整个生命周期中的一个不变法则

• 我的口头禅成了“别提敏捷，只解决问题！”。

• 无论什么样的方法，都应该以“解决问题”为出发点，而“解决问题”的一个重要前提是“能够正确定义问题，并达成共识”。

◆ 第1章 持续交付2.0

• 《持续交付》（Continuous Delivery）已出版8年，一直受到软件行业从业者的关注。书中的软件开发原则和实践也随着商业环境VUCA特性的明显增强而逐渐受到软件技术人员的认可。VUCA是volatility（易变性）、uncertainty（不确定性）、complexity（复杂性）和ambiguity（模糊性）的首字母缩写。VUCA这个术语源于军事用语，在20世纪90年代开始被普遍使用，用来描述冷战结束后的越发不稳定的、不确定的、复杂、模棱两可和多边的世界。

• 项目管理者希望通过这种重计划、重流程、重文档的方式来解决软件危机。很多人将具有以上3个特征的软件开发方法统称为“重型软件开发方法”。

• 敏捷软件开发方法强调发挥人的主观能动性，提倡面对面沟通、拥抱变化、通过迭代和增量开发尽早交付有价值的软件。

• DevOps是一种软件工程文化和实践，旨在统一整合软件开发和软件运维。DevOps运动的主要特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化和监控。DevOps的目标是缩短开发周期，提高部署频率和更可靠地发布，与业务目标保持一致。

• 持续交付是一种能力，也就是说，能够以可持续方式，安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。

• 持续部署（continuous deployment）是持续交付（continuous delivery）的进阶状态，是指代码提交后一旦成功通过所有质量验证，就立即自动部署到生产环境中，不需要任何人的审批。事实上，“部署”与“交付”这两个主干词的意义并不相同。

• 精益思想是指导企业根据用户需求，定义企业生产价值，按照价值流来组织全部生产活动，使价值在生产活动之间流动起来，由需求拉动产品的生产，从而识别整个生产过程中不经意间产生的浪费，并消除之。

• 持续交付2.0的双环模型。第一个环为“探索环”，其主要目标是识别和定义业务问题，并制订出最小可行解决方案进入第二个环；第二个环为“验证环”，其主要目标是以最快速度交付最小可行方案，可靠地收集真实反馈，并分析和验证业务问题的解决效果，以便决定下一步行动。

• 探索环包含4个可持续循环步骤，分别是提问、锚定、共创和精炼。

（1）提问，即定义问题。通
（2）锚定，即定义结果目标指示器
（3）共创，即共同探索和创造解决或验证该问题的多种具有可行性的解决方案。
（4）精炼，即对所有的可行试验方案进行选择，找到最小可行性解决方案，它既可能是单个方案，也可能是多个方案的组合。

• 验证环也包含4个可持续循环的步骤，分别是构建、运行、监测和决策。

（1）构建，是指根据非数字化描述，将最小可行性解决方案准确地转换成符合质量要求的软件包。
（2）运行，是指将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。
（3）监测，是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。
（4）决策，是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。

• 探索环就像是一部车子的前轮，把握前进方向。验证环则像车子的后轮，使车子平稳且驱动快速前进。

• “持续交付2.0”的4个核心工作原则是坚持少做、持续分解问题、坚持快速反馈和持续改进并衡量。

1.少做：做高回报的事。
2.分解问题：把任务拆分成最小单元。各个击破。
3.快速反馈：总结才有进步，回顾目标是否达成。
4.持续改进并衡量：把目标定时限，量化。什么时候完成多少。

◆ 第2章 价值探索环

• 探索环（Discovery Loop）是指团队通过一系列工作环节，能够识别和定义业务问题，制订相应的衡量指标，并找出低成本且可快速验证的最小可行解决方案（Minimum Viable Solution）。这是一个理解真实需求、判断优先级、再评估需求的过程，具体包括以下4个环节。
  （1）提问：通过有针对性的提问与讨论，找出团队期望达成的业务目标或者希望解决的业务本质问题。
  （2）锚定：针对该问题进行信息收集，经过分析，去除干扰信息，得到适当的指标项，并用其描述现在的状况，以及我们希望的结果或状态。
  （3）共创：通过深入讨论，找到所有可能的解决方案。它是一个深入理解和验证问题的环节。
  （4）精炼：结合实际情况，进行评估，筛选出最小可行性解决方案或方案的集合，以作为验证环的输入。等待它的真实反馈，再做价值判断

• 在“提问”这一环节中，组织者需要注意以下4点。
  （1）问题域的提出方及解决方案的提供方代表尽量到场，参与讨论。
  （2） 多问几个“为什么”。尽量避免因为感觉自己熟悉这个问题域，而过早地放弃探索。
  （3）在条件允许的情况下，尽可能收集数据信息，以便作为问题理解和分析的佐证。
  （4）移情，使用同理心。设身处地站在客户或问题提出方的角度思考问题，还原客户问题的场景。

• “锚定”是设定目标以及目标分解的讨论过程，其目的是确定要达成的目标以及可以衡量它的指标，并能够指导后续的共创与精炼活动。

• 在“共创”这一环节中，需要注意两个陷阱，分别是分析瘫痪（paralysis by analysis）和直觉决策（extinct by instinct）

• 精炼环节就是对共创环节中得出的众多方案进行评估，从中筛选出团队认为最小可行性解决方案的过程。评估因素包括备选方案的实施成本、时间与人力、效果反馈周期，以及该方案对业务目标的影响程度

• 我们相信，通过实现（xxxxx这样的最小功能组合），我们的指标可以达到（yyyyy程度），说明我们关于（zzzzz）的假设是成立的。

• 在探索环的工作中应该遵循“分解并快速试错”“一次只验证一点”“允许失败”原则

• 所谓装饰窗方法（Decorative Window），就是指为新功能预留一个“入口”，让用户能够看到，但实际上并没有真正实现其功能。就像一个装饰性的窗户

• 最小可行特性法（Minimum Viable Feature）是指在产品从1到n的过程中，寻找用户可直接感知到的需求假设作为产品的最小可行特性优先开发的方法，以尽可能少的成本快速增加或修改某个产品特性，让用户使用，收集真实反馈，专注于验证功能改进，同时也可提升用户使用体验

• 特区法（Special Zone）是指在特定用户范围内进行试验，以验证某个新功能的有效性

• 定向探索法（Directional Explorer）是指针对具有某种特定行为的特定用户群体，依据该用户的具体行为模式，设计调查提纲，有针对性地探索其行为背后的动机。

• 稻草人法（Corn Dolly）就是指：不开发任何真实的功能，只假装这个功能已经完成了，并向用户展示该功能的真实效果，从而得到用户的真实反馈。这种方法与装饰窗方法的区别在于它让用户真实地感受到了功能提供的结果，而事实上并没有开发这个功能

◆ 第3章 快速验证环

• 验证环的主要工作内容就是以最可靠的质量和最快的速度，将最小可行性解决方案从描述性语言转换成可运行的软件包，并将其部署到生产环境中运行，准确收集相关数据并呈现，以便团队根据相关数据做出判断和决策。
  （1）构建：是指根据非数字化描述，将解决方案准确地变成达到质量要求且可运行的软件包。
  （2）运行：是指将达到质量要求的软件包部署到生产环境或交到用户手中，并使之为用户提供服务。
  （3）监测：是指收集生产系统中产生的数据，对系统进行监控，确保其正常运行。同时将业务数据以适当的形式及时呈现出来。
  （4）决策：是指将收集到的数据信息与探索环得出的对应目标进行对比分析，做出决策，确定下一步的方向。

◆ 第4章 持续交付2.0的组织文化

• “持续交付2.0”强调“持续探索”和“快速验证”

• 这就要求组织必须建立“安全、互相信任和持续改善”的组织文化。

• “价值导向，快速验证，持续学习”作为行动原则。

• 度量指标分为引导性指标、结果性指标、可观测性指标和可行动性指标。

• 迈克•鲁斯在《丰田套路：转变我们对领导力与管理的认知》一书中介绍了一种“改善套路”，它包含4个阶段，以循环方式不断重复，如图4-6所示。
  • 第一阶段：明确方向。管理者需要明白，企业必须始终以愿景为工作目标，并持续不断地改进。在前进的路上，必然会遇到问题。我们需要通过不断试验与迭代，才能达成目标。
  • 第二阶段：掌握当前状态。团队要掌握当前的状态，获得事实与数据，才能充分认识自己，以对下一步目标状态进行合理的描述。
  • 第三阶段：定义下一个目标状态。目标状态就是确定团队希望达到的状态，设置期望达到该状态的日期，并定义可衡量的指标项。
  • 第四阶段：迭代改进。遵循戴明环，不断迭代试验，发现、实施、评估并改善方案，直到达成目标状态。戴明环，又叫PDCA循环，是由美国统计学家戴明博士提出来的，它反映了质量管理活动的规律。P（Plan）表示计划，D（Do）表示执行，C（Check）表示检查，A（Action）表示处理。PDCA循环是提高产品质量、改善企业经营管理的重要方法，是质量保证体系运转的基本方式。

◆ 第5章 持续交付的软件系统架构

• 一是微核架构，常用于需要向用户分发的客户端软件；二是微服务架构，用于企业自身可控的后台服务端软件；三是分层的巨石应用，常见于创业公司的产品项目

• 微核架构（microcore architecture）又称为插件架构（plugin architecture），指的是软件的核心框架相对较小，而其主要业务功能和业务逻辑都通过插件实现

• 微服务架构（microservice architecture）是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值

• 巨石应用（monolithic application）也称巨石架构，是指由单一结构体组成的软件应用，其用户接口和数据访问代码都绑定在同一语言平台的同一应用程序。

• 这类改造有3种实施模式，分别是拆迁者模式、绞杀者模式和修缮者模式。其中，绞杀者模式和修缮者模式都有利于持续交付，降低架构改造和发布的风险

• “拆迁者模式”就是指根据当前的业务需求，对软件架构重新设计，并组织单独的团队，重新开发一个全新的版本，一次性完全替代原有的遗留系统

• “绞杀者模式”是指保持原来的遗留系统不变，当需要开发新的功能时，重新开发一个服务，实现新的功能。通过不断构建新的服务，逐步使遗留系统失效，并最终替代它

• “修缮者模式”是指将遗留系统的部分功能与其余部分隔离，以新的架构进行单独改善。

◆ 第6章 业务需求协作管理

• 产品的整个生命周期可以分成以下5个阶段，即概念阶段、孵化阶段、验证阶段、运营阶段和业务退市阶段。

• 相比于传统的瀑布式交付模型，敏捷交付模型的核心点之一就是将需求拆分成一个个可独立交付的小的需求，快速交付，增量迭代，快速试错。但这其中有几个核心的问题需要解决，否则无法做到真正的敏捷。

1、需求的拆分，一定要站在业务的角度，将一个大的需求，拆分为多个可以独立交付、增量迭代的小的需求。
2、项目管理能力，拆分以后，需要管理的需求变多了，可能会出现在一个迭代中开发和测试并存的情况，需要管理好这些需求，协调好并行的团队。
3、技术和架构能力，需求拆分为多个可独立交付的需求以后，需要我们有一个低耦合的架构，无损发布的架构，以及具备客观性的架构（业务指标和技术指标）。
4、需要有强大的自动化工程能力，拆分以后，意味这测试和发布的次数会变多，需要有强大的自动化测试和流水线作为基础，如果靠人拉肩抗，那么只会使得团队的效率变得更低。

• 需求拆分的收益

1、团队的所有相关人员参与需求拆分，更容易建立共识，协调工作
2、小批量交付，提前得到反馈，更容易验证价值，加速价值流动
3、低成本拥抱变化、便于试错。
4、多次集成、便于反馈质量

• INVEST[2]原则是用于检验用户故事是否拆分得当的6个原则，它由下面6个英文单词的首字母组成。
  （1）independent（独立）：用户故事必须彼此独立，低耦合。
  （2）negotiable（可协商）：在进入开发前，故事卡用来提醒团队和干系人要进行讨论，而不是直接作为产品人员与开发人员之间的契约来使用。
  （3）valuable（有价值）：用户故事对用户或客户来讲必须是重要的，有价值的。
  （4）estimable（可估算）：开发团队必须能够估算创建用户故事所需的工作量。
  （5）small & similar size（规模小且适中）：用户故事必须足够小，尽可能要在一个迭代内完成（建议用户故事的开发工作量应该少于3个工作日）；并且多个用户故事之间的开发工作量差异不宜过大。你对足球体积的估算偏差一定远远小于对月亮体积的估算偏差。
  （6）testable（可验证）：用户故事必须是可以被验证的。

• 为了帮助大家掌握更好的用户故事拆分方法，下面介绍5种技法。只要多加练习，就能掌握用户故事。

1．路径拆分法
路径拆分法是指根据用户使用场景中的不同路径进行拆分。
2．按接触点拆分
所谓接触点就是指用户与系统之间的交互通道，例如移动端应用和PC浏览器是两种不同的接触点。而在PC浏览器上，又可以按不同的浏览器来分，如Safari、Chrome、Firefox和IE。
3．按数据类型或格式拆分
4．按规则拆分
规则是指业务规则或者技术规则。
5．按探索路径拆分
可以将对陌生事物的试验性探索逐步分拆成不同的探索故事。这种探索故事有较大的不确定性，因此要作为高风险点管理，时刻关注其进展。

◆ 第7章 部署流水线原则与工具设计

• GoCD系统是典型的服务器/代理（server/agent）架构，服务器和客户端各自可独立启动运行。服务器本身曾是一个典型的巨石应用，包含关系型数据库和Java应用服务器。用户可以通过浏览器访问其Web服务，同时它也提供REST风格的API接口，方便用户进行程序扩展，架构示意图如图7-1所示。
  [插图]

• GoCD团队遵守持续集成六步提交法（参见第9章），任何人提交代码后，立即自动触发一次部署流水线实例化，该部署流水线如图7-3所示。

1．一次构建，多次使用
2．与业务逻辑松耦合
3．并行化原则
4．快速反馈优先
5．重要反馈优先

◆ 第8章 利于集成的分支策略

• “持续交付2.0”提倡鼓励持续集成的分支策略，因此，选择分支模式的原则有以下几条。
  （1）分支越少越好，最好只有一条主干。
  （2）分支生存周期越短越好，最好在3天以内。
  （3）在业务允许的前提下，发布周期越短越好。
  企业管理者应该遵循“持续交付2.0”的思想、理念与原则，制订合理的改善目标，促进公司IT交付能力不断提升，才能够跟上时代的发展。

◆ 第9章 持续集成

• “冒烟测试”这一术语来源于电子硬件测试。硬件样品只要通电后没有冒烟，就说明该硬件最基本的质量要求达到了。

• 持续集成是一种质量反馈机制，其目的是“尽早发现代码中的质量问题”。

• 能够提供持续集成功能的平台或工具不少于35种，既有商业收费软件（如TeamCity等），也有开源的软件（如Jenkins、goCD、Buildbot）

• 单元测试，用例回归，e2e，人工探索

• 快速建立团队的持续集成实践

1．构建脚本化，搭建持续集成框架
2．向构建中添加已有的自动化验
3．选择利于持续集成的分支策略
4．建立六步提交法
5．持续优化
6．工程师改变习惯，并提升技能

• 介绍了持续集成6步提交法，以及快速建立团队持续集成实践的5个步骤。并不是安装部署了一个持续集成服务器，每天用它进行自动化编译打包，就说明团队正在使用持续集成实践。要真正做到持续集成，获得最大的持续集成收益，需要做到以下6点。
  （1）主干开发，频率提交代码。
  （2）每次提交都是完整有意义的工作。
  （3）提交构建阶段在10分钟之内完成。
  （4）提交构建失败后，立即修复；且其他人不得在修复之前提交代码。
  （5）应该在10分钟内修复失败，否则回滚引起失败的代码。
  （6）自动化构建成功后，团队对软件质量比较有信心。

◆ 第10章 自动化测试策略与方法

• 微服务+DDD架构下的测试金字塔，至底而上为：
  1、单元测试：包含对资源库接口，值对象、实体和聚合的接口，领域服务和应用服务层接口的代码即覆盖测试。使用junit或者spock等单元测试框架实现，单元测试需要在本地开发环境即可运行，对底层基础设施（如数据库、redis）或者其他服务的依赖通过模拟桩的方式实现。
  2、本地集成测试，代码构建为可部署的软件包以后，在本地集成环境部署后，连接数据库和redis等基础设施进行单元测试。和单元测试的区别就是去除模拟装进行单元测试。
  3、接口测试，在本地集成环境部署后，针对对外提供的API或者消息生产和消费接口进行测试。
  4、端到端流程测试，在端到端集成测试环境部署所有微服务，使用自动化工具对端到端业务流程进行测试。

◆ 第11章 软件配置管理

• 一切自动化”是持续交付部署流水线的一个重要原则，也是提升“持续交付验证环”运转速度的一个重要影响因素。

• 软件配置管理的3个核心原则。
  （1）对一切进行版本管理。
  （2）共享唯一受信源。
  （3）标准化与自动化。

◆ 第12章 低风险发布

• 降低发布风险的相关方法如蓝绿部署、金丝雀发布（或灰度发布）和暗部署（dark launch），支撑高频发布的相关技术手段如开关技术、数据迁移方法、抽象分支策略等

• 蓝绿部署（blue-green deployment）是指准备两套完全一致的运行环境，其中一套环境作为正式生产环境，对外提供软件服务。另一套环境作为新版本的预生产环境，部署软件的新版本，并对其进行验收测试。当确认没有问题后，将访问流量引流到这个新版本所在的环境中，作为正式的生产环境，同时保持旧版本所在环境不变。直至确定新版本没有问题后，再将旧版本所运行的环境作为下一个新版本的预生产环境，部署未来的新版本，

• “金丝雀发布”（canary release）就是泛指通过让一小部分用户先行使用新版本，以便提前发现软件存在的问题，从而避免让更多用户受到伤害的发布方式。

• “灰度发布”是指将发布分成不同的阶段，每个阶段的用户数量逐级增加。

• 暗部署（dark launch）是指功能或特性在正式发布之前，将其第一个版本部署到生产环境，以便在向最终用户提供该功能之前，团队可以对其进行测试，并发现可能的错误

◆ 第13章 监测与决策

• 根据监测内容的不同，可以将其分为3个层次，即资源监测、应用监测和业务监测。

（1）采集上报：将事先定义的事件数据在当地采集并上报。
（2）数据整理：对各数据源上报后的数据进行收集、清洗和整理。
（3）实时分析：对实时数据进行分析处理。
（4）离线分析：通过大量数据进行模型或规则提取。
（5）结果输出：将实时和离线分析的结果展现，供决策参考。
（6）问题决策：根据上一步的输出，人为或自动给出下一步的行动判定；同时将判定记录保存下来，以便为后续决策提供依据。
（7）数据存储：离线的原始数据、分析数据以及处理记录的保存。
（8）自动修复与运维执行体系的接口：它需要将修复指令发送给运维执行体系，由执行体系将指令分发到对应节点，并进行相应的操作。

◆ 第14章 大型互联网团队的FT化

• 是Feature Team的英文缩写，中文通常翻译为全功能团队

• （1）其任务是负责端到端的软件功能交付，（2）具交付该软件功能的所必备的所有能力，（3）相对稳定的人员组成

• “目标驱动，从简单问题开始，持续改善”是整个改进的指导思想。

• 对这种以业务为导向的全功能团队来说，其目标不再是敏捷软件开发中所提的“快速交付一组功能”，而是负责面向业务价值的交付，即“以业务目标为导向的子业务团队”，确保整个部门业务战略目标的落地实现。