《DevOps 精要:业务视角》- 读书笔记（七）

DevOps历程

我们的DevOps旅程始于2009年，在我们为某客户（该客户提供将Web从PC转换到iPhone等移动设备的优质服务）成功实施了敏捷、Scrum和XP方法之后。

当时，客户的Scrum团队已经能做到更快地开发和发布软件。即使开发时间减少了一半，业务总监依然吐露业务速度的提升并不如意。

看起来，开发过程是瓶颈，但经过调查发现开发过程并非瓶颈，而是业务流程应该改进。

我们据此将TMS这一概念从业务战略和规划一直到客户服务的整个业务流程实施起来。而使用DevOps的概念将有助于建立一个流水线式（stream-lined）的业务运营过程，并缩短交付前置时间（delivdery lead-time）。

这个项目于2012年成功完成。整个流程从端到端进行了重新调整，并使用可视化控制、单件流（One-piece flow）、每周进程同步、每天反馈循环以及KAIZEN建立起整个业务的协作。经理、管理员、销售、设计师、程序员、运维和客服形成了一个团队，大家在可视化看板上共享所有业务信息。

项目实施后，业绩得到了明显的提升：交付前置时间缩短、销售量提升、利润率和员工积极性也都得到了提升。这些是DevOps的真正价值。

DevOps框架应该直接支持到业务结果，不仅仅是为了IT服务中开发与运维的协同，而是要能帮助企业使用IT服务来支持和提升他们的业务。

DevOps的价值应以业务结果来衡量，而不是根据IT项目范围和IT成果来评判。

什么是企业体系的DevOps？

关于DevOps的书有很多，但不幸的是，大多数都是描述在网站和产品开发中是如何应用DevOps的。很少有相关资料讲述DevOps如何应用于企业体系。

企业往往同时拥有交互型系统（SoE）和记录型系统（SoR）。SoE系统关注的是速度，SoR系统关注的是业务连续性。问题是SoR系统也受到面向速度的SoE系统频繁更改的影响，SoR系统如何适应频繁更改影响的同时还要保持业务的连续性？Gartner公司把这称为“双峰挑战”（Bimodal challenge）。

大多数企业的SoR既有传统的系统与应用需要维系和使用，使用DevOps建立及时制（just-in-time, JIT）概念的流水线式过程可以助力这类系统。

DevOps不能简单认为是一种工具、方法、技能或组织结构，DevOps的框架是结合所有这些元素来建立一个流水线的过程，使业务更快地运营，并能更快地应对变化。DevOps还可以通过戴明博士的Plan-Do-Check-Act（PDCA，戴明环）来提升成熟度。企业级的DevOps不仅仅是增强的敏捷开发和持续交付，同时也通过IT服务管理和应用程序管理来实现和促进业务增长并保障业务连续性。

DevOps的目标是什么？

DevOps的目标是建立流水线式的及时制（JIT）的业务流程。DevOps旨在通过调整及时制（JIT）业务流程来最大化业务成果，例如增加销售和利润、提高业务速度或最小化运营成本。

DevOps意味着在业务中建立一条IT服务供应链，与其他产品的供应链嵌入业务的方式相同。这种从提供软件交付到供给IT服务的模式转变是巨大的。

从架构的角度来看，DevOps需要建立一个自动化的快速部署系统。有很多方法和工具可以利用。DevOps没有统一的实施模板，每个组织都应该考虑并建立自己的DevOps流程来提升业务。因此，真正理解DevOps的概念，对员工遵循正确的流程有效执行来说至关重要。

DevOps的知识体系

当实施DevOps时，我们将从很多知识源、方法论、实践案例和工具中去选择参考。DevOps主要由以下的三大支柱和一个基础组成。

规范敏捷

一支训练有素的敏捷开发团队是成功实施DevOps的关键。规范敏捷（Disciplined Agile）意味着下面三个方面。

• 速度稳定（Stabilized Velocity）
• 适应变化（Adaptability for change）
• 总是能发布优质的无错误代码（Always release high quality bug free code）IT服务需要以更频繁、更快速的发布周期来响应业务变化，这取决于开发速度。工作质量是最重要的，需要将工作分割为小任务来加以支持。

Ji-Koutei-Kanketsu（JKK）概念，认为100%的完成每个条目，是有助于保持高质量工作的。而“完成定义”（Definition of Done）或“结束”（Completion），对每个人都必须清楚定义。

产品负责人需要改变他/她的使命，不单单是管理待办事项列表（Product Backlog），也需要规划IT服务的运维成本。在丰田，这项工作是由首席工程师来完成的。

持续交付

持续交付（Continuous Delivery）是应用程序的构建、部署、测试和发布流程的自动化实施。

一个关键的关注点是测试，如验收测试和性能测试等。TPI NEXT（测试流程优化）可以用于提高这个过程的成熟度。

每个组织部署流水线（Deployment Pipeline）的实现都会有差异，因为软件发布的价值流不同。成功的关键因素是该部署流水线应该为单一流程构成，而非多个。

IT服务管理

当技术成为大多数业务流程的核心环节时，IT服务的连续性和高可用性是业务存亡的关键因素。这可以通过引入降低风险措施和恢复方案来实现。就像IT服务管理所有要素都提及的，成功实现服务的连续性需要得到高层的承诺，以及组织中所有成员的支持。要保持恢复方案的有效性，持续维护是至关重要的。服务连续性是服务功效（warranty, fitness for use）的必要组成部分。如果服务连续性无法按照业务的要求维护和/或恢复，那么业务将无法实现所承诺的价值。没有了连续性，服务的功用（utility, fitness for purpose）也无法使用。

传统的IT服务管理（ITSM）最佳实践，比如ITIL看起来很繁琐，不匹配DevOps中所倡导的快速流程。有必要考虑一下如何降低管理工作量。

基于DevOps去重新调整ITSM是有必要的，创建轻量级的只包含所需最少必要信息（Minimum Required Information，MRI）且严格聚焦于业务持续性的轻量级ITSM。每个组织的MRI设置取决于他们的业务。

以TPS理念为基础

建立一个流水线式的IT服务供应链并不容易，因为其包含的内容很多，并且要改变现有熟悉的开发周期和方法论，你很有必要观念上做改变。

TPS（精益管理Lean）的概念包括JIT和自动化，对建立这样的供应链有很大的帮助。

JIT意味着以单件流（one-piece flow）的方式建立一个流水线式的供应链。而自动化意味着尽可能实现自动化，并且当出现缺陷时能停止整个过程。这个过程需要设计并且员工也需要充分理解这两个概念。另一个关键问题是开发和运维的管理周期。需要在工作方式上采用敏捷的方法，包括开发和运维之间每周或每天的信息同步。

下图展示了DevOps的知识体系：

DevOps团队角色

为了保证IT服务的业务连续性，推荐在组织中建立DevOps团队。最好是组建一个小型优质的DevOps团队，根据亚马逊的“两个披萨规则”，团队成员的规模为两个披萨饼就可以喂饱。团队角色描述如下。

流程主管（Process Master）

领导并引导团队，这个角色类似于在Scrum中的Scrum Master。

对整个过程实施可视化管控，并特别注重建立单件流的流水线式的流程。

可视化管控意味着“在不需要解释的情况下，通过看板是否每个人都能很容易理解当前的状况？”它并不显示状态。但它可以用来表达是否有问题出现。

经验需求：Scrum Master或敏捷项目领导（Agile Project Leader）。

服务主管（Service Master）

对及时（JIT）提供IT服务负有全责。

这个角色就类似于Scrum中的产品负责人（Product Owner）或对待办事项（Product Backlog）做管理和排序，另外还负责IT服务的成本规划。

经验需求：Scrum产品负责人（Scrum Product Owner）、服务负责人（Service Owner）。

DevOps工程师（DevOps Engineer）

以优化和维护自动化流程为主要使命。

工程师将检查整个自动化过程和工具。DevOps流程需要很多工具。

经验需求：开发（Development）和工具（Tools）。

把关人/发布协调员（Gatekeeper/Release coordinator）

负责监控IT服务的运维状态和下一次发布的进展。

做关于部署是做或不做的决定，需要参照的标准包括安全性、合规性、监管要求或运维团队的成熟度以及他们的流程观念。

经验需求：IT服务管理（IT service management）、运维（Operations）。

可靠性工程师（Reliability Engineer）（可选）

监控部署过程中服务的测试质量，处理服务运行中所产生的问题。

监控流程状态以确保开发团队严格遵守CI（持续集成）和CD（持续交付）的规则。监视和管理复杂的构建管线的工作流。以提升测试流程为使命。

经验需求：测试（Testing）、工具（Tools）或质量保证（Quality assurance）。

开发团队（Development team）

DevOps的关键成功因素之一是建立一个规范的敏捷团队。

规范的敏捷团队致力于以可持续的速度来满足发布计划和发布质量。

经验需求：开发（Development）或敏捷（Agile）

运维团队（Operation team）

采用轻量级的ITSM并在总体战略范围内支持对服务的设计、实施、运维与改进。

采用TPS中的“提前持续改善（KAIZEN in Advance）”的实践。

经验需求：运维（Operations）或持续改善（KAIZEN）。

组织

有必要在服务管理办公室（Service Management Office）中组建DevOps团队来支持服务主管。

有两种类型的组织架构展示如下：

适合小型组织的扁平化组织

下图是小型组织的基本架构。

适合大型复杂组织的矩阵组织架构

建立专家池并安排他们作为一个团队给到服务主管。这个矩阵组织的想法来自丰田的首席工程师。

DevOps的流程

要建立一个流水线式的流程，采用JKK来指导DevOps团队是最有效的办法。

JKK是一种高质量的工作方式，它意味着对目标理解清晰，理解正确的工作方式，使工作百分百地正确完成，并在没有检查的情况下维护质量要求。

业务战略和规划（Business Strategy and Planning）

IT服务与业务战略和规划有密切的关系。

服务主管应该参加业务规划会议并提出如何通过IT服务来获得业务优势的建议。

市场营销（Marketing and sales）

服务主管应该与市场部门讨论如何从IT服务中获得优势。

服务主管识别IT服务的客户，收集具有业务价值的需求，并约定时间范围。

管理（Administration）

流程主管就如何可视化整个过程与团队成员达成一致。一种方法是使用Obeya（作战室，丰田的一种工程合作方式），它可以设定为可视化整个流程。Obeya作战室具有两个目的：信息管理和现场决策（on-the-spot decision）。这里面有很多可视化管理工具。团队成员可以很快看到他们在过程中的方方面面。

当跨职能团队在一起工作时，Obeya系统能够快速、准确做出决策，加强沟通、保持一致、迅速收集信息、并形成重要的团队集体意识。

项目规划（Project Planning）

服务主管组织服务管理办公室（SMO）并定义团队的基本规则。服务主管创建愿景、目标和项目的价值，然后整合DevOps的团队成员。

在这个阶段，运行中的基础设施被定义。要设计一个整体流程的价值流图表。

需求和设计（Requirements and Design）

服务主管定义产品待办事项（Product backlogs）安排优先级。

• 用户故事：角色，职能，业务价值/理由，以及运维条件。
• 测试故事：验收测试用例和服务验收标准。
• 运维故事：设置IT服务的优先级的和业务连续性的运维条件。

创建服务级别和运维级别协议。

DevOps工程师和运维团队定义转换、测试和开发的基础设施。开发团队还创建了发布和迭代计划。

把关人研究IT服务的合规性以及IT服务的监管要求。可靠性工程师定义测试方法和测试用例。

开发（Development）

Scrum是这个阶段最适用的方法论。

开发团队应该提交并遵守发布计划，并使用规范的敏捷方法。迭代（Sprint）的周期取决于业务的需要。

从质量的角度来看，XP（Extreme Programming，极限编程）的实践，例如结对编程（pair-programming）、TDD（Test-Driven Development，测试驱动开发）、重构（Refactoring）和十分钟构建（Ten-Minutes Build）都是有效的。

部署（Deployment）

在完成持续集成之后，自动化流程开始进行验收测试、性能测试和部署。DevOps工程师应该建立单件流（One-piece flow）方式构建一个单一的自动化部署流水线（pipeline）。

可靠性工程师和DevOps工程师将共同提升测试流程。

把关人（Gatekeeper）监控整个过程的进度，决定是否上线。运维团队研究如何保持业务连续性。

运维（Operation）

运维团队采用轻量级的ITSM流程来监控IT服务运行的状态。

发生灾难事件时，确保关键服务依然正常运行是至关重要的。运维团队此时应该让可靠性工程师参与进来，并需要注意两个关键参数：恢复点目标（Recovery Point Objective，RPO）和恢复时间目标（Recovery Time Objective，RTO）。

维保（Maintenance）

服务主管和可靠性工程师决定是否允许进行维保。经允许，它们被作为变更请求（Request for Change，RFC）添加到待办任务中。

客户服务（Customer service）

服务主管和可靠性工程师负责收集客户的反馈，例如包括用户体验和质量事件的运维问题。经允许，它们被作为变更请求添加到待办任务中。

生命周期终止（End of life）

服务主管决定IT服务生命周期的终止条件，包括发生事件以及如何发生。

下图显示了DevOps的一个配置示例。

• ACDM为Architecture-Centric Design Method，一种演进式软件架构设计方法。

轻量级的ITSM图表如下图所示。

DevOps的实施

DevOps有三种实施方式，可以根据企业的业务模式进行选择。

丰田方式（先进但复杂）

丰田方式（TOYOTA WAY）重点在于关注IT服务战略，并给予业务的战略优势。这需要由业务负责人或服务主管来领导。

在大型企业最好选择矩阵式管理组织架构，并且在IT战略和业务战略之间保持密切的关系。这个结构很适合IT服务提供商（IT Service Provider）。

协同方式（标准）

协同方式（Collaboration）将专注如何快速和频繁的提供IT服务，并保障可靠运行，一般由服务主管来主导。

这种方式尤其适合需要将交互型系统（SoE）和记录型系统（SoR）联结在一起的企业。

持续交付（基本）

持续交付（Continuous Delivery）侧重于快速和频繁的软件发布，可以由产品负责人主导。

它最适合数码产品提供商的软件部门

结论

显然，对于大多数IT经验来说，DevOps是一个整体的重大模式转变。因此，关于DevOps的培训对员工来说十分重要。这是您DevOps旅程的开始。

术语表

KAIZEN（持续改善）

持续改进意味着按照周、日循环进行PDCA。为了找到根本原因问五次“为什么”。

问题需要通过数据的方式来定义和支持。是否大家都能清晰地认识到问题？

设置一个你发现的问题的假设，然后基于防范方式来思考并验证你的假设。

防范措施必须基于活动在日常进行定义，也需要设定每周的KPI，这样人们可以感觉到一种成就感。

KAIZEN in Advance（提前改善）

当下游的环节意识到有些问题可能来自上游，最优的方式是他们站在整体流程的角度来为解决问题创造假设。然后他们可以向上游部门提出期望。这是一个反馈闭环的问题。

Ji-Koutei-Kanketsu（JKK，质量检查）

JKK的概念是一种完美状态：在你所处在的工作流程中不要做低质量的工作，不接受流程早期就出现错误的输出，不把糟糕的情形输出到下一个流程。

工作标准要求能够采用正确的方法去完成工作，这也意味着要定义一个度量方法去决定是否继续进行下一步。

TPI NEXT

TPI-Test Process Improvement测试流程优化是一种业务驱动的测试过程改进。

TPI是一套来自欧洲的软件测试最佳实践方法论

完整版术语表