DevOps的历程始于2009年，在成功采用了Agile，Scrum和XP等方法论后，一些客户，开始极富想象力在使用网站服务时，从传统PC应用转移为移动设备应用了，比如说iPhone。当然Scrum团队是能够更快的开发和发布软件。不过业务主管却担心即使开发时间减少了一半，却依然不能提高业务的速度。表面上看起来开发的过程是瓶颈，但是在调查中发现开发的过程并不是瓶颈，反而业务流程却应该要被改善。

1、DevOps 如何应用于企业体系?

关于DevOps的书有很多，但不幸的是，大多数都是描述网站和产品开发中如何使用DevOps的。很少有相关资料是考虑DevOps如何用于企业体系的。企业往往兼有交互型系统（System of Engagement，SoE）和记录型系统（System of Record，SoR）。SoE关注的是速度，SoR关注的是业务连续性。问题是当SoE频繁变更的时候，如何保障SoR的业务连续性呢？

Gartner公司把这称为双峰挑战（Bimodal challenge）。大多数企业的SoR正努力使用着遗留的系统与应用，可以通过使用DevOps建立一个准时制（just-in-time, JIT）概念的流水线过程。DevOps不能简单认为是工具、方法、技能或组织结构，DevOps的框架结合所有这一切元素，去建立一个流水线的过程，使业务更快的运营并且更快地应对变化。DevOps还可以通过戴明博士的计划（戴明环）来提升其成熟度。企业级的DevOps不仅仅是增强敏捷开发和持续交付，同时也通过IT服务管理和应用程序管理最终实现促进业务增长并保障业务连续性。

2、DevOps 的目标是什么?

DevOps的目标是建立流水线式的准时制（JIT）的业务流程。DevOps旨在通过合适的准时制业务流程来最大化业务成果，例如增加销售和利润率，提高业务速度，或尽量减少运营成本。DevOps意味着在业务中建立了一条IT服务供应链，而业务以同样的方式作为其他产品的供应链以嵌入到业务中。这种从提供软件交付转移为提供IT服务的模式转变是巨大的。

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

3、DevOps 的知识体系

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

3.1 规范敏捷

一支训练有素的敏捷开发团队是成功实施DevOps的关键。

规范敏捷意味着：

• 速度稳定（Stabilized Velocity）
  
  

• 适应变化（Adaptability for change）
  
  

• 总是能发布优质的无错误代码（Always release high quality bug free code）
  
  

在IT服务生命周期中，越来越频繁和快速的发布反应取决于依赖开发速度的业务变更。因为工作的质量是最重要的，所以得通过将工作分割为小任务来进行支持。Ji-Koutei-Kanketsu（JKK）认为能100%的完成一个条目，是有助于保持一个高质量工作的。而“做完了”（Done）与“结束了”（Completion）的这些概念，对每个人来说都必须定义清楚。造成产品负责人可能改变他/她的任务的，未必一定是对待办项（Product Backlog）的管理，也可能是新的IT服务计划.

3.2 持续交付

持续交付指的是自动实现应用程序的构建、部署、测试和发布。

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

每个组织都有不同的途径（Pipeline），这取决于发布软件的价值流。一个关键的成功因素是为IT服务建立一个单一的部署管线。

3.3 IT 服务管理

当技术成为大多数业务流程的核心环节时，IT服务的连续性和高可用性是业务存亡之道的关键因素。这可以通过引入降低风险措施和恢复方案来实现。就像IT服务管理所有要素都提及的，只有成功实现服务的连续性才能实现对高层的承诺，并支持组织的所有成员。对于保持高效性而言，持续维护其恢复能力是最基本的前提条件。服务连续性是服务保障的必要组成部分。如果服务无法按照业务的要求保持连续性或恢复，那么业务将无法实现所承诺的价值。服务将无法被提供，从而失去持续的功效。

传统的IT服务管理（ITSM）最佳实践，比如ITIL看起来很繁琐，不匹配DevOps中所倡导的快速流程。有必要考虑一下如何减少管理工作量。基于DevOps去重新调整ITSM是有必要的，创建一个轻量级的ITSM完全集中在业务连续性的最低要求信息上。每个组织的MRI设置取决于他们的业务。

3.4 TPS精益管理

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

TPS的概念包括JIT和自动化，TPS可以帮助做到以下环节：

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

4、DevOps 团队角色

为了保证IT服务的业务连续性，希望在您的组织中建立DevOps团队。最好是组建一个小型优质的DevOps团队，这是根据亚马逊的“两个披萨规则”来设立的：就是说团队人数不能多到两个披萨饼还不够他们吃的地步。

团队角色描述如下：

流程主管（Process Master）

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

• 对整个过程实施可视化管控，力求建立单件流作业（one-piece flow）的流水线式的流程。
  
  

• 可视化管控意味着“在不需要解释的情况下，通过看板是否每个人都能很容易的理解？”它不显示状态。但它可以表示问题发生与否。
  
  

• 相关经验：Scrum Master，敏捷项目领导（Agile Project Leader）。
  
  

服务主管（Service Master）

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

• 这个角色就像产品负责人（Product Owner）在Scrum中一样，对待办项（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（Continuous Integration，持续集成）和CD （Continuous Delivery，持续交付）。
  
  

• 监视和管理复杂的构建管线的工作流。
  
  

• 有义务提升测试流程。
  
  

• 相关经验：测试（Testing），工具（Tools），质量保证（Quality assurance）。
  
  
  

开发团队（Development team）

• DevOps 的关键成功因素之一是建立一个训练有素的敏捷团队。
  
  

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

• 相关经验：开发（Development），敏捷（Agile）
  
  
  

运维团队（Operation team）

• 采用轻量级的ITSM 并在整体战略的环境中支持对服务的设计、实施、运维与改进。
  
  

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

• 相关经验：运维（Operations），持续改善（KAIZEN）。
  
  
  

5、组织

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

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

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

6、DevOps 的流程

要建立一个流水线式的流程，采用JKK 在指导DevOps 团队是最有效的办法。JKK 是一种高质量的工作方式，它意味着对目标理解清晰，理解正确的工作方式，使工作正确的100%的完成，并在没有检查的情况下维护质量要求。

DevOps 的一个配置示例

6.1 业务战略和规划

IT 服务与业务策略和规划有密切的关系服务的主管应该参加业务规划会议并提出如何通过IT 服务获得业务优势的建议。

6.2 市场营销

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

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

6.3 管理

流程主管很希望了解如何将整个过程可视化。一种方法是使用Obeya（丰田的一种工程合作方式）为整个流程进行设定。Obeya 这个作战室具有两个目的——信息管理和现场决策。这里面有很多可视化管理工具。团队成员可以很快看到他们在过程中的方方面面。当跨职能团队在一起工作时，Obeya 系统能够快速，准确做出决策，加强沟通、保持队形、迅速收集信息、并形成重要的团队意识。

6.4 项目规划

服务主管组织服务管理办公室（SMO）并定义团队的基本规则。服务主管创建愿景、目标和项目的价值，然后整合DevOps的团队成员。在这个阶段，运行中的基础设施被定义。一个整体流程的价值流图表被设计。

6.5 需求和设计

服务主管定义待办任务（Product backlogs）和并安排优先级。DevOps团队使用待办任务（Product backlogs）来定义故事（Story）。

• 用户故事：角色，职能，业务价值/理由，以及运营条件。

• 测试故事：:验收测试用例和服务验收标准。

• 运营故事：设置IT 服务的优先级的和业务连续性的运营条件。

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

• DevOps 工程师和运营团队定义转换、测试和开发的基础设施。
  
  

• 开发团队还创建发布和迭代计划。
  
  

• 把关人研究IT 服务的合规性以及IT 服务的监管要求。
  
  

• 可靠性工程师定义测试方法和测试用例。
  
  
  

6.6 开发

Scrum 是这个阶段最适用的方法论。开发团队必须提交发布计划并使用规范的敏捷方法。每次迭代的周期需要遵循业务的需要。从质量的角度来看，XP（极限编程）的实践，例如结对编程、TDD（测试驱动开发）、重构和十分钟构建都是有效的。

6.7 部署

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

• 可靠性工程师和DevOps 工程师将共同提升测试流程。把关人（Gatekeeper）监控整个过程的进度，决定是否上线。
  
  

• 运维团队研究如何保持业务连续性。
  
  
  

6.8 运维

运维团队采用轻量级的ITSM 流程来监控运行的IT 服务状态。发生灾难事件时，确保关键服务保持运营是至关重要的。这个团队应该包括可靠性工程师，需要注意两个关键参数：恢复点目标和恢复时间目标。

6.9 维保

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

6.10 客户服务

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

6.11 生命周期终止

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

7、DevOps 的实施

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

7.1 丰田方式（先进复杂）

这种方式重点在于关注IT 服务战略，并给予业务的战略优势。这需要由业务负责人或服务主管来领导。在一个大型企业最好选择矩阵式管理组织架构，并且在IT 战略和业务战略之间保持密切的关系。这个结构很适合IT 服务提供商。

7.2 协同方式（标准）

这种方式将专注如何快速和频繁的提供IT 服务，并保障可靠运行，一般由由服务主管来主导。这种方式尤其适合交互型系统和记录型系统共存。

7.3 持续交付（基本）

这种方式侧重于快速和频繁的软件发布，可以由产品负责人主导。它最适合数码产品提供商（许多新型的互联网企业都属于此列）。

作者： Koichiro (Luke) Toda Nobuyuki Mitsui

译者：刘颋，史鹏程

　　DevOps的历程始于2009年，在成功采用了Agile，Scrum和XP等方法论后，一些客户，开始极富想象力在使用网站服务时，从传统PC应用转移为移动设备应用了，比如说iPhone。当然Scrum团队是能够更快的开发和发布软件。不过业务主管却担心即使开发时间减少了一半，却依然不能提高业务的速度。表面上看起来开发的过程是瓶颈，但是在调查中发现开发的过程并不是瓶颈，反而业务流程却应该要被改善。

1、DevOps 如何应用于企业体系?

关于DevOps的书有很多，但不幸的是，大多数都是描述网站和产品开发中如何使用DevOps的。很少有相关资料是考虑DevOps如何用于企业体系的。企业往往兼有交互型系统（System of Engagement，SoE）和记录型系统（System of Record，SoR）。SoE关注的是速度，SoR关注的是业务连续性。问题是当SoE频繁变更的时候，如何保障SoR的业务连续性呢？

Gartner公司把这称为双峰挑战（Bimodal challenge）。大多数企业的SoR正努力使用着遗留的系统与应用，可以通过使用DevOps建立一个准时制（just-in-time, JIT）概念的流水线过程。DevOps不能简单认为是工具、方法、技能或组织结构，DevOps的框架结合所有这一切元素，去建立一个流水线的过程，使业务更快的运营并且更快地应对变化。DevOps还可以通过戴明博士的计划（戴明环）来提升其成熟度。企业级的DevOps不仅仅是增强敏捷开发和持续交付，同时也通过IT服务管理和应用程序管理最终实现促进业务增长并保障业务连续性。

2、DevOps 的目标是什么?

DevOps的目标是建立流水线式的准时制（JIT）的业务流程。DevOps旨在通过合适的准时制业务流程来最大化业务成果，例如增加销售和利润率，提高业务速度，或尽量减少运营成本。DevOps意味着在业务中建立了一条IT服务供应链，而业务以同样的方式作为其他产品的供应链以嵌入到业务中。这种从提供软件交付转移为提供IT服务的模式转变是巨大的。

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

3、DevOps 的知识体系

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

3.1 规范敏捷

一支训练有素的敏捷开发团队是成功实施DevOps的关键。

规范敏捷意味着：

• 速度稳定（Stabilized Velocity）
  
  

• 适应变化（Adaptability for change）
  
  

• 总是能发布优质的无错误代码（Always release high quality bug free code）
  
  

在IT服务生命周期中，越来越频繁和快速的发布反应取决于依赖开发速度的业务变更。因为工作的质量是最重要的，所以得通过将工作分割为小任务来进行支持。Ji-Koutei-Kanketsu（JKK）认为能100%的完成一个条目，是有助于保持一个高质量工作的。而“做完了”（Done）与“结束了”（Completion）的这些概念，对每个人来说都必须定义清楚。造成产品负责人可能改变他/她的任务的，未必一定是对待办项（Product Backlog）的管理，也可能是新的IT服务计划.

3.2 持续交付

持续交付指的是自动实现应用程序的构建、部署、测试和发布。

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

每个组织都有不同的途径（Pipeline），这取决于发布软件的价值流。一个关键的成功因素是为IT服务建立一个单一的部署管线。

3.3 IT 服务管理

当技术成为大多数业务流程的核心环节时，IT服务的连续性和高可用性是业务存亡之道的关键因素。这可以通过引入降低风险措施和恢复方案来实现。就像IT服务管理所有要素都提及的，只有成功实现服务的连续性才能实现对高层的承诺，并支持组织的所有成员。对于保持高效性而言，持续维护其恢复能力是最基本的前提条件。服务连续性是服务保障的必要组成部分。如果服务无法按照业务的要求保持连续性或恢复，那么业务将无法实现所承诺的价值。服务将无法被提供，从而失去持续的功效。

传统的IT服务管理（ITSM）最佳实践，比如ITIL看起来很繁琐，不匹配DevOps中所倡导的快速流程。有必要考虑一下如何减少管理工作量。基于DevOps去重新调整ITSM是有必要的，创建一个轻量级的ITSM完全集中在业务连续性的最低要求信息上。每个组织的MRI设置取决于他们的业务。

3.4 TPS精益管理

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

TPS的概念包括JIT和自动化，TPS可以帮助做到以下环节：

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

4、DevOps 团队角色

为了保证IT服务的业务连续性，希望在您的组织中建立DevOps团队。最好是组建一个小型优质的DevOps团队，这是根据亚马逊的“两个披萨规则”来设立的：就是说团队人数不能多到两个披萨饼还不够他们吃的地步。

团队角色描述如下：

流程主管（Process Master）

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

• 对整个过程实施可视化管控，力求建立单件流作业（one-piece flow）的流水线式的流程。
  
  

• 可视化管控意味着“在不需要解释的情况下，通过看板是否每个人都能很容易的理解？”它不显示状态。但它可以表示问题发生与否。
  
  

• 相关经验：Scrum Master，敏捷项目领导（Agile Project Leader）。
  
  

服务主管（Service Master）

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

• 这个角色就像产品负责人（Product Owner）在Scrum中一样，对待办项（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（Continuous Integration，持续集成）和CD （Continuous Delivery，持续交付）。
  
  

• 监视和管理复杂的构建管线的工作流。
  
  

• 有义务提升测试流程。
  
  

• 相关经验：测试（Testing），工具（Tools），质量保证（Quality assurance）。
  
  
  

开发团队（Development team）

• DevOps 的关键成功因素之一是建立一个训练有素的敏捷团队。
  
  

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

• 相关经验：开发（Development），敏捷（Agile）
  
  
  

运维团队（Operation team）

• 采用轻量级的ITSM 并在整体战略的环境中支持对服务的设计、实施、运维与改进。
  
  

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

• 相关经验：运维（Operations），持续改善（KAIZEN）。
  
  
  

5、组织

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

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

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

6、DevOps 的流程

要建立一个流水线式的流程，采用JKK 在指导DevOps 团队是最有效的办法。JKK 是一种高质量的工作方式，它意味着对目标理解清晰，理解正确的工作方式，使工作正确的100%的完成，并在没有检查的情况下维护质量要求。

DevOps 的一个配置示例

6.1 业务战略和规划

IT 服务与业务策略和规划有密切的关系服务的主管应该参加业务规划会议并提出如何通过IT 服务获得业务优势的建议。

6.2 市场营销

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

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

6.3 管理

流程主管很希望了解如何将整个过程可视化。一种方法是使用Obeya（丰田的一种工程合作方式）为整个流程进行设定。Obeya 这个作战室具有两个目的——信息管理和现场决策。这里面有很多可视化管理工具。团队成员可以很快看到他们在过程中的方方面面。当跨职能团队在一起工作时，Obeya 系统能够快速，准确做出决策，加强沟通、保持队形、迅速收集信息、并形成重要的团队意识。

6.4 项目规划

服务主管组织服务管理办公室（SMO）并定义团队的基本规则。服务主管创建愿景、目标和项目的价值，然后整合DevOps的团队成员。在这个阶段，运行中的基础设施被定义。一个整体流程的价值流图表被设计。

6.5 需求和设计

服务主管定义待办任务（Product backlogs）和并安排优先级。DevOps团队使用待办任务（Product backlogs）来定义故事（Story）。

• 用户故事：角色，职能，业务价值/理由，以及运营条件。

• 测试故事：:验收测试用例和服务验收标准。

• 运营故事：设置IT 服务的优先级的和业务连续性的运营条件。

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

• DevOps 工程师和运营团队定义转换、测试和开发的基础设施。
  
  

• 开发团队还创建发布和迭代计划。
  
  

• 把关人研究IT 服务的合规性以及IT 服务的监管要求。
  
  

• 可靠性工程师定义测试方法和测试用例。
  
  
  

6.6 开发

Scrum 是这个阶段最适用的方法论。开发团队必须提交发布计划并使用规范的敏捷方法。每次迭代的周期需要遵循业务的需要。从质量的角度来看，XP（极限编程）的实践，例如结对编程、TDD（测试驱动开发）、重构和十分钟构建都是有效的。

6.7 部署

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

• 可靠性工程师和DevOps 工程师将共同提升测试流程。把关人（Gatekeeper）监控整个过程的进度，决定是否上线。
  
  

• 运维团队研究如何保持业务连续性。
  
  
  

6.8 运维

运维团队采用轻量级的ITSM 流程来监控运行的IT 服务状态。发生灾难事件时，确保关键服务保持运营是至关重要的。这个团队应该包括可靠性工程师，需要注意两个关键参数：恢复点目标和恢复时间目标。

6.9 维保

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

6.10 客户服务

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

6.11 生命周期终止

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

7、DevOps 的实施

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

7.1 丰田方式（先进复杂）

这种方式重点在于关注IT 服务战略，并给予业务的战略优势。这需要由业务负责人或服务主管来领导。在一个大型企业最好选择矩阵式管理组织架构，并且在IT 战略和业务战略之间保持密切的关系。这个结构很适合IT 服务提供商。

7.2 协同方式（标准）

这种方式将专注如何快速和频繁的提供IT 服务，并保障可靠运行，一般由由服务主管来主导。这种方式尤其适合交互型系统和记录型系统共存。

7.3 持续交付（基本）

这种方式侧重于快速和频繁的软件发布，可以由产品负责人主导。它最适合数码产品提供商（许多新型的互联网企业都属于此列）。

作者： Koichiro (Luke) Toda Nobuyuki Mitsui

译者：刘颋，史鹏程