Gartner的研究主管George Spafford说：“由于缺少标准的定义和方法，处于不断发展中，需要接受和管理风险，DevOps对传统IT思维提出了挑战。这个不确切的目标状态导致许多IT部门犹豫不决、不敢实施DevOps策略。”

虽然没有一系列具体的所需阶段，但Spafford建议基础设施及运营（I&O）领导人可以遵循这八个基本步骤来搞好DevOps项目。

1. 确定业务理由

DevOps项目要关注业务需求，而不是“纯粹为了DevOps搞DevOps”，避免方法和工具变得比客户需求还重要。企业要避免这个常见的错误：还没有明确搞DevOps项目的业务理由，就贸然上马。

Spafford解释到：“比如说，先从业务价值入手，问问DevOps能带来什么，而不是专注于发布速度、更快地完成工作。理由可能是‘通过提升发布速度，我们能够更快地创新，从而支持销售和营销部门使用移动应用进行订购。’最成功的企业希望通过DevOps获得业务的好处。”

2. 为所在企业定义DevOps

Gartner对DevOps下的定义是：这是一种使用敏捷方法、协作和自动化交付解决方案的业务驱动方法。能以所在企业易懂的措辞来定义目标状态显得很重要。为项目挑一个标签，提供员工认同和支持的一个“标语”，这有助于员工参与进来。这个定义应简短、明确重点，并支持业务理由。

3. 选择“先行者”应用软件

别指望一个步骤就部署好DevOps。DevOps要迭代式部署，每次同时满足这三个要素：

友好的环境：这意味着大家愿意使用先行者应用软件，真心尝试项目。

可接受的价值：先行者应用软件要提供足够的价值以赢得信誉和批准，以便继续下去。

可接受的风险：由于DevOps方面的不确定性，许多人认为它风险很高，害怕开始入手。企业应指出风险可接受的机会，因为IT、运营、开发、信息安全，法规遵从和审计等部门的每个人都要学习。

Spafford说：“DevOps主要用于敏捷开发以及不确定性相当大的场景（比如机器学习和物联网），但由于DevOps理念可以广泛应用，所以会有引入这套概念的其他机会。然而，最初运用于创新的系统通常比较好，因为现有功能可能无法支持像大数据、机器学习和物联网这些项目。”

4. 确定初始团队

人员是成功的DevOps项目的主要因素。挑选初始团队的成员时，要注重行为而不是注重技能。教技术技能比教正确行为来得容易――错误的行为会使DevOps工作偏离正常进程。物色优秀的团队成员，要聪明、有干劲，了解风险，致力于终生学习，还能适应新的工作方式。

5. 确立目标和度量指标

因为人员是DevOps项目中最重要的因素，了解和实施合适的激励措施至关重要。Spafford说：“在许多传统企业，目标由各部门确立，IT度量指标落实到位，以解决问题，奖励解决问题的人员。”

“在DevOps项目中，目标要由团队确立，并与下达给团队的业务目标保持一致。DevOps团队成员要认识到他们都有同一个目标，度量指标和激励措施要鼓励团队合作以实现业务目标，而不是度量指标强化风险规避和解决个别问题。”

6. 专注于限制因素

I&O领导人应找出限制生产能力的最大瓶颈。开发新的和变更的系统，并转移到生产环境中，这个生命周期会带来最大的限制因素，因而限制生产能力。如果专注于这个最大的限制因素，DevOps团队就能系统地识别什么在阻碍所需的工作节奏，并克服这个瓶颈。

7. 开发工具链

实施DevOps的总体目标包括一套集成的工具链，支持合理地评估和选择工具，以便每个工具都与应用程序生命周期中的相邻工具松散耦合。连接所有的自动化接触点和信息流可借助工具链来加快版本的发布，同时减少错误、缺陷、返工和停运。这将让在每个阶段使用的工具得以保持一致，便于了解在阶段内和阶段之间哪个地方需要实现自动化、集成和工具转换。

8. 准备好后扩展

太多的公司犯这样的错误：开始DevOps之前就需要扩展，以便获得批准。这导致了恶性循环。因为他们不知道如何扩展DevOps，所以无法开始。而由于他们无法开始，就无法摸索并搞清楚如何扩展。DevOps

Spafford建议：“切莫还没有准备好就试图扩展，结果让靠谱的DevOps项目偏离正道。”

“相反，把团队召集起来，开始朝着似乎最有意义的方向前进，克服遇到的限制因素。人员、技术和流程方面一定要循序渐进。带来技术债务是不可避免的，而管理这种债务是新模式的一部分。”

来源：CIO

Gartner的研究主管George Spafford说：“由于缺少标准的定义和方法，处于不断发展中，需要接受和管理风险，DevOps对传统IT思维提出了挑战。这个不确切的目标状态导致许多IT部门犹豫不决、不敢实施DevOps策略。”

虽然没有一系列具体的所需阶段，但Spafford建议基础设施及运营（I&O）领导人可以遵循这八个基本步骤来搞好DevOps项目。

1. 确定业务理由

DevOps项目要关注业务需求，而不是“纯粹为了DevOps搞DevOps”，避免方法和工具变得比客户需求还重要。企业要避免这个常见的错误：还没有明确搞DevOps项目的业务理由，就贸然上马。

Spafford解释到：“比如说，先从业务价值入手，问问DevOps能带来什么，而不是专注于发布速度、更快地完成工作。理由可能是‘通过提升发布速度，我们能够更快地创新，从而支持销售和营销部门使用移动应用进行订购。’最成功的企业希望通过DevOps获得业务的好处。”

2. 为所在企业定义DevOps

Gartner对DevOps下的定义是：这是一种使用敏捷方法、协作和自动化交付解决方案的业务驱动方法。能以所在企业易懂的措辞来定义目标状态显得很重要。为项目挑一个标签，提供员工认同和支持的一个“标语”，这有助于员工参与进来。这个定义应简短、明确重点，并支持业务理由。

3. 选择“先行者”应用软件

别指望一个步骤就部署好DevOps。DevOps要迭代式部署，每次同时满足这三个要素：

友好的环境：这意味着大家愿意使用先行者应用软件，真心尝试项目。

可接受的价值：先行者应用软件要提供足够的价值以赢得信誉和批准，以便继续下去。

可接受的风险：由于DevOps方面的不确定性，许多人认为它风险很高，害怕开始入手。企业应指出风险可接受的机会，因为IT、运营、开发、信息安全，法规遵从和审计等部门的每个人都要学习。

Spafford说：“DevOps主要用于敏捷开发以及不确定性相当大的场景（比如机器学习和物联网），但由于DevOps理念可以广泛应用，所以会有引入这套概念的其他机会。然而，最初运用于创新的系统通常比较好，因为现有功能可能无法支持像大数据、机器学习和物联网这些项目。”

4. 确定初始团队

人员是成功的DevOps项目的主要因素。挑选初始团队的成员时，要注重行为而不是注重技能。教技术技能比教正确行为来得容易――错误的行为会使DevOps工作偏离正常进程。物色优秀的团队成员，要聪明、有干劲，了解风险，致力于终生学习，还能适应新的工作方式。

5. 确立目标和度量指标

因为人员是DevOps项目中最重要的因素，了解和实施合适的激励措施至关重要。Spafford说：“在许多传统企业，目标由各部门确立，IT度量指标落实到位，以解决问题，奖励解决问题的人员。”

“在DevOps项目中，目标要由团队确立，并与下达给团队的业务目标保持一致。DevOps团队成员要认识到他们都有同一个目标，度量指标和激励措施要鼓励团队合作以实现业务目标，而不是度量指标强化风险规避和解决个别问题。”

6. 专注于限制因素

I&O领导人应找出限制生产能力的最大瓶颈。开发新的和变更的系统，并转移到生产环境中，这个生命周期会带来最大的限制因素，因而限制生产能力。如果专注于这个最大的限制因素，DevOps团队就能系统地识别什么在阻碍所需的工作节奏，并克服这个瓶颈。

7. 开发工具链

实施DevOps的总体目标包括一套集成的工具链，支持合理地评估和选择工具，以便每个工具都与应用程序生命周期中的相邻工具松散耦合。连接所有的自动化接触点和信息流可借助工具链来加快版本的发布，同时减少错误、缺陷、返工和停运。这将让在每个阶段使用的工具得以保持一致，便于了解在阶段内和阶段之间哪个地方需要实现自动化、集成和工具转换。

8. 准备好后扩展

太多的公司犯这样的错误：开始DevOps之前就需要扩展，以便获得批准。这导致了恶性循环。因为他们不知道如何扩展DevOps，所以无法开始。而由于他们无法开始，就无法摸索并搞清楚如何扩展。DevOps

Spafford建议：“切莫还没有准备好就试图扩展，结果让靠谱的DevOps项目偏离正道。”

“相反，把团队召集起来，开始朝着似乎最有意义的方向前进，克服遇到的限制因素。人员、技术和流程方面一定要循序渐进。带来技术债务是不可避免的，而管理这种债务是新模式的一部分。”

来源：CIO