企业IT本身是个复杂的系统工程，这也是为什么DevOps的实施不是一个一蹴而就的过程，大多数企业需要至少2~3年的时间才能够逐步达成一个相对成熟的DevOps实施状态。

DevOps落地也不应只停留在理论上。本系列文章旨在介绍一个非常清晰简洁的DevOps实施框架*（见题图），帮助企业厘清落地步骤。根据这个框架，DevOps相关的能力分布在SDLC的4个阶段，一共11个核心服务能力。这里重点要强调的是能力。

实践DevOps很像健身，这11个能力相当于11个核心肌肉群，但是要达成理想的效果个人要根据自身状况，不断练习，不断突破自我。这也是LEAN运动的本质。健身是没法通过简单地购买健身器械，请健身教练或是吃什么营养品达成的，一定是一个付出汗水、努力和自我修炼的过程。

今天将简单介绍一下这个框架，后继会按模块分解介绍。争取每个模块给出一些企业实践的案例。企业需要根据自身现有情况，选择从某个能力项入手，做到最优，然后发展下一个能立项。争取逐步在2~3年内建立起完整的核心“肌肉群”。

1.    PPM（Project and Portfolio Managment ）- 项目组合或项目群管理。这个是企业如何把想法转换成开发团队可接受的需求的过程。涉及到分析、立项、排优先级，资源分配等一系列过程。

2.    API / Microserive - API和微服务。系统的架构方式。

3.    Agile Management - 敏捷管理。管理敏捷形态的团队和项目。

4.    Test-Driven Development - 测试驱动开发：快速给予开发者反馈，并从一开始就定义（对于开发来讲）什么是工作完成的关键实践。

5.    Service Virtulization - 服务虚拟化：模拟外部系统行为，加速自动化测试实现。

6.    Test Data Management - 测试数据管理：你有多快可以通过自服务的方式帮助开发和测试团队建立有效的测试数据。

7.    Environment Management - 环境管理：自动化各个环境（从开发、测试、预发布到生产）的供应和配置的能力。

8.    Continuous Integration - 持续集成：频繁、小批量提交、自动触发一系列自动化测试的能力。

9.    Cointinuous Delivery - 持续交付：持续集成的拓展。自动部署到不同环境并对环境及配置持续自动测试的能力。

10. Security - 安全：整合安全及合规要求到整个开发、部署及运维的能力。

11. Monitoring - 监控：业务、开发和运维所需要的所有相关的Telemetry (测量）收集、整合、可视化的能力。

本文面向的是企业IT用户（尤其是每年要投入数以百计的人力，开发维护十几个甚至几十个上百个上不同系统的企业），在组织范围内的计划和需求消耗太多的问题。而对于只有十几个人的单一产品团队来说，也许对这部分不用做特别考虑。

主要问题是：

1）你的企业是否花了大量的人力和时间在计划上？

2）是否有大量的需求处于等待开发状态？

3）是否有很高比例的需求在最初定义好之后需要重复再修改？

4）开发出来的需求是否有很高比例其实没有被最终用户所使用？

如果你的企业存在这样的情况，请继续阅读。

我们来看一个典型的项目开发声明周期模型：

虽然很多项目已经在采用Agile/Scrum的方法进行开发，但在一头（从业务想法到开发团队可执行的需求）一尾（从代码完成到上线）还是典型的瀑布式。

IT面对的问题是试图用瀑布模型来尽早确定软件的功能（Scope），发布日期（Schedule)和资源/成本（Cost）。但对软件来说，这个三角形的三边总是处于变化过程中（尤其是功能和日期），很难在一开始确定下来，而是始终处于动态变化过程中。但对企业管理而言，IT又不能把所有的计划都推后，不作出任何承诺。

这里的重点是针对长期战略性、中期提供附加值、和短期不可预测的需求采取不同的计划策略。

根据HP固件系统的例子：

1.    长期（6个月或以上）战略性（MUST）的工作：因为软件（固件系统）要配合新型号打印机产品发布的日期，而这个日期一般是希望很早就确定下来的。所以软件开发部门一定做到按时交付这类需求。这里的策略是：此种计类型的工作只占用工程师团队50%或以下的总工作量。

2.    中期（3~6个月）提供附加值（NICE-TO-HAVE) 的工作：保证核心系统能够按照确定日期按时交付之后，接下来有一部分需求是业务希望能够提供给客户、带来附加价值或者提升客户体验的新功能。对于这部分需求，维护一个粗粒度的估计列表，并赋予优先级，而且保证占用工程师团队的工作量不能超过30%。此种类型的工作也应包含一些必要的重构，增加

3.    短期（3个月以内）临时出现、紧急或计划外（UNPLANNED)的工作：对于这种类型的工作，只做短期计划，比如1~2个迭代的需求，并且控制工作量占总工作量的20%以内。

还是用健身作比喻，如何你希望在新年的第一天开始做个详尽的计划，规定每一天要健身多长时间，做几组规定动作，可能要不了多久你就会发现很不现实。更好的做法是长期来讲你要达成什么目标，是力量训练、跑10KM，还是有氧运动，而且要预留出足够让自己可以灵活时间。这个是长期的战略目标，中短期可以结合其他类型的训练。这样才能保证不是花了很长时间做计划，然后发现不可执行。

（（本文的主要思想来自于Gary Gruver的Leading the Transformation：Applying Agile and DevOps Principles at Scale一书））

企业IT本身是个复杂的系统工程，这也是为什么DevOps的实施不是一个一蹴而就的过程，大多数企业需要至少2~3年的时间才能够逐步达成一个相对成熟的DevOps实施状态。

DevOps落地也不应只停留在理论上。本系列文章旨在介绍一个非常清晰简洁的DevOps实施框架*（见题图），帮助企业厘清落地步骤。根据这个框架，DevOps相关的能力分布在SDLC的4个阶段，一共11个核心服务能力。这里重点要强调的是能力。

实践DevOps很像健身，这11个能力相当于11个核心肌肉群，但是要达成理想的效果个人要根据自身状况，不断练习，不断突破自我。这也是LEAN运动的本质。健身是没法通过简单地购买健身器械，请健身教练或是吃什么营养品达成的，一定是一个付出汗水、努力和自我修炼的过程。

今天将简单介绍一下这个框架，后继会按模块分解介绍。争取每个模块给出一些企业实践的案例。企业需要根据自身现有情况，选择从某个能力项入手，做到最优，然后发展下一个能立项。争取逐步在2~3年内建立起完整的核心“肌肉群”。

1.    PPM（Project and Portfolio Managment ）- 项目组合或项目群管理。这个是企业如何把想法转换成开发团队可接受的需求的过程。涉及到分析、立项、排优先级，资源分配等一系列过程。

2.    API / Microserive - API和微服务。系统的架构方式。

3.    Agile Management - 敏捷管理。管理敏捷形态的团队和项目。

4.    Test-Driven Development - 测试驱动开发：快速给予开发者反馈，并从一开始就定义（对于开发来讲）什么是工作完成的关键实践。

5.    Service Virtulization - 服务虚拟化：模拟外部系统行为，加速自动化测试实现。

6.    Test Data Management - 测试数据管理：你有多快可以通过自服务的方式帮助开发和测试团队建立有效的测试数据。

7.    Environment Management - 环境管理：自动化各个环境（从开发、测试、预发布到生产）的供应和配置的能力。

8.    Continuous Integration - 持续集成：频繁、小批量提交、自动触发一系列自动化测试的能力。

9.    Cointinuous Delivery - 持续交付：持续集成的拓展。自动部署到不同环境并对环境及配置持续自动测试的能力。

10. Security - 安全：整合安全及合规要求到整个开发、部署及运维的能力。

11. Monitoring - 监控：业务、开发和运维所需要的所有相关的Telemetry (测量）收集、整合、可视化的能力。

本文面向的是企业IT用户（尤其是每年要投入数以百计的人力，开发维护十几个甚至几十个上百个上不同系统的企业），在组织范围内的计划和需求消耗太多的问题。而对于只有十几个人的单一产品团队来说，也许对这部分不用做特别考虑。

主要问题是：

1）你的企业是否花了大量的人力和时间在计划上？

2）是否有大量的需求处于等待开发状态？

3）是否有很高比例的需求在最初定义好之后需要重复再修改？

4）开发出来的需求是否有很高比例其实没有被最终用户所使用？

如果你的企业存在这样的情况，请继续阅读。

我们来看一个典型的项目开发声明周期模型：

虽然很多项目已经在采用Agile/Scrum的方法进行开发，但在一头（从业务想法到开发团队可执行的需求）一尾（从代码完成到上线）还是典型的瀑布式。

IT面对的问题是试图用瀑布模型来尽早确定软件的功能（Scope），发布日期（Schedule)和资源/成本（Cost）。但对软件来说，这个三角形的三边总是处于变化过程中（尤其是功能和日期），很难在一开始确定下来，而是始终处于动态变化过程中。但对企业管理而言，IT又不能把所有的计划都推后，不作出任何承诺。

这里的重点是针对长期战略性、中期提供附加值、和短期不可预测的需求采取不同的计划策略。

根据HP固件系统的例子：

1.    长期（6个月或以上）战略性（MUST）的工作：因为软件（固件系统）要配合新型号打印机产品发布的日期，而这个日期一般是希望很早就确定下来的。所以软件开发部门一定做到按时交付这类需求。这里的策略是：此种计类型的工作只占用工程师团队50%或以下的总工作量。

2.    中期（3~6个月）提供附加值（NICE-TO-HAVE) 的工作：保证核心系统能够按照确定日期按时交付之后，接下来有一部分需求是业务希望能够提供给客户、带来附加价值或者提升客户体验的新功能。对于这部分需求，维护一个粗粒度的估计列表，并赋予优先级，而且保证占用工程师团队的工作量不能超过30%。此种类型的工作也应包含一些必要的重构，增加

3.    短期（3个月以内）临时出现、紧急或计划外（UNPLANNED)的工作：对于这种类型的工作，只做短期计划，比如1~2个迭代的需求，并且控制工作量占总工作量的20%以内。

还是用健身作比喻，如何你希望在新年的第一天开始做个详尽的计划，规定每一天要健身多长时间，做几组规定动作，可能要不了多久你就会发现很不现实。更好的做法是长期来讲你要达成什么目标，是力量训练、跑10KM，还是有氧运动，而且要预留出足够让自己可以灵活时间。这个是长期的战略目标，中短期可以结合其他类型的训练。这样才能保证不是花了很长时间做计划，然后发现不可执行。

（（本文的主要思想来自于Gary Gruver的Leading the Transformation：Applying Agile and DevOps Principles at Scale一书））