摘要

在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时，DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地，王津银带来了他的实践经验分享。

DevOps的全局理解

DevOps的整体框架首先是一连串工程实践的组合，其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础，强调自动化拉动式的管理。

DevOps与ITIL的对比融合

ITIL面向整个管理过程，规范优先，效率偏低，成本偏高。DevOps则是面向IT运营过程，是一个执行能力的自动化。

ITIL是以离线任务的管理为主要特征，但DevOps今天已侵入到在线服务。

DevOps自动化与ITIL规范之间的融合

根据我们的实践，在传统行业交互过程中，我们的产品跟ITIL产品做对接时得出了三种模式。

• 第一种模式是在线服务开通流程。
  
  

• 第二种是重大变更流程。
  
  

• 第三种是敏捷发布流程。
  
  

从软件研发模式看DevOps

第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现，就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。

随着研发模式的变化，各个角色在里面所承担的工作量配比也在发生变化，研发越来越重要。

DevOps的落地经验谈

一、理念与价值先行

强调五点理念：

1、通过持续的服务交付价值链打破孤岛。

2、整合开发和运维的能力，成为一个协作的团队。

3、端到端持续交付流程的变革。

4、对新的应用和服务，加快且缩短实现价值的时间。

5、不影响安全性、兼容性和性能。

二、顶层设计与全局规划

我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。

组织：首先必须打破组织之间的隔阂，其次DevOps组织要面向产品而非项目的协作文化。

过程：轻量级流程和自动化工具的完美结合，确保企业的高度敏捷性；自动化为先，而后再流程。

架构：架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构，基础架构是讲标准化基础设施。

工具：把质量成本和效率这几者维度同时兼顾，具备可落地化。

基础设施：虚拟化到容器化的平台。

度量：度量体系能不断驱动能力优化。

在纵向的维度上，把能力评估分为五个等级，这个五个等级参考CMI。

Quota定义了namespace中能利用的最大资源，而BatchJobController算的值则在中间来回浮动。

三、Start Small，从小做起

基于某个角色和某个场景去进行从小做起。

基于某个系统或者某个功能域来实施导入。

切忌贪大求全。

四、构建IT元数据平台，驱动IT平台间整合

因为要缩小范围，CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后，只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后，再从应用的视角看到底用了哪些资源，把这两层维度强关联起来，再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转，在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。

五、痛苦的事情优先解决

因为运维的角色很多，最终的能力管理过程也非常多，所以一定要通过角色加场景，最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力，这个能力应被上层各个子系统使用。

六、工具也是一种文化

作业管理和调度管理是一种平台级的能力，不需要对它进行场景化的理解，只要认为在自动化的构成要素里面有个原子化的事物，同时要有一个调度引擎去编排这个原子化的事物，有两个要素就够了。基于这两者的能力，面向角色和场景收敛去归类。

工具也是一种文化，通过它，我们可以构建各种各样的原子工具把我们的能力进行拼装起来，然后在各个场景下使用。

好的经验一定要通过自动化的手段去去沉淀，而不是通过文档去沉淀。工具是真正推动变革的有效手段。

七、组织二次元，加群落地力

我认为这里面其实要把它变成一种虚拟组织的形式，所以我把它做了一个改进。把中心的角色去掉了，并用技术化的思维做了一个拆分。但这一块强调技术的能力，要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则，和技术、组织架构完全保持一致。不改变现有的组织结构，通过技术的一些手段来加强组织的映射能力。

八、价值拉动，而非事务驱动

经营核心的准则就是以家客户的价值流作为驱动。

在识别整个价值流的时候要看哪些是无效的活动，哪些是不增值的活动，还有哪些是给客户产生价值的活动。

九、平台+插件=服务能力产品化，和组织一致

产品一定要有一个平台化的思维。这个平台化思维有个边界的，不能跨越这个边界。同时要去适配各个公司的现状，怎样把公司现有的一些能力插件化进来。

从DevOps的角度来说，一定是交付流水线的平台，IT端到端的调度。整个插件的适配层是插件的协议标准，把开发者、测试者和运维的能力，全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

十、自动化别人，先自动化自己

一定要先自动化自己的能力再去自动化别人，千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程，还是一个环境逐步覆盖的过程。

十一、持续交付是DevOps落地的最佳实践

持续交付是DevOps的最佳工程实践，以部署流水线为基础，以快速交付为目标。

十二、IT运营管理驱动Ops能力建设

应用上线之后运营过程该怎么去覆盖合并，我把它分成几个阶段，人工运维、平台化运维、孵化运营和智能化运营。

运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

十三、构建面向应用的最强管理驱动力

应用在今天是变得越来越重要，云的形态底层把能力服务化，那么应用怎样去抽象成三个维度，一是资源的维度，二是动作的维度，三是状态。

应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。

最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题，数据分析面向整个的服务、数据可视化。

十三、构建面向应用的最强管理驱动力

应用在今天是变得越来越重要，云的形态底层把能力服务化，那么应用怎样去抽象成三个维度，一是资源的维度，二是动作的维度，三是状态。

十四、构建指标，驱动DevOps落地

1.变更时长

2.服务恢复时长

3.发布频率

4.变更失败率

合理的指标驱动构建的是不同的组织，高性能的组织、中等效能组织和低效能的组织。

我的分享到此结束，谢谢大家！

原创：王津银

摘要

在云计算、大数据等技术颠覆性趋势继续在应用经济下发挥作用的同时，DevOps也已经稳健地在业务思维方式中占有一席之地。那么DevOps与传统如何融合落地，王津银带来了他的实践经验分享。

DevOps的全局理解

DevOps的整体框架首先是一连串工程实践的组合，其次它关注的是整个业务和生命周期的管理。另外它还是以经营思想作为基础，强调自动化拉动式的管理。

DevOps与ITIL的对比融合

ITIL面向整个管理过程，规范优先，效率偏低，成本偏高。DevOps则是面向IT运营过程，是一个执行能力的自动化。

ITIL是以离线任务的管理为主要特征，但DevOps今天已侵入到在线服务。

DevOps自动化与ITIL规范之间的融合

根据我们的实践，在传统行业交互过程中，我们的产品跟ITIL产品做对接时得出了三种模式。

• 第一种模式是在线服务开通流程。
  
  

• 第二种是重大变更流程。
  
  

• 第三种是敏捷发布流程。
  
  

从软件研发模式看DevOps

第一种是瀑布流的模式。然后就是敏捷研发的模式。随着新的业务形态出现，就要强调端到端能力的整合。这就是今天要讲的DevOps的软件研发模式。

随着研发模式的变化，各个角色在里面所承担的工作量配比也在发生变化，研发越来越重要。

DevOps的落地经验谈

一、理念与价值先行

强调五点理念：

1、通过持续的服务交付价值链打破孤岛。

2、整合开发和运维的能力，成为一个协作的团队。

3、端到端持续交付流程的变革。

4、对新的应用和服务，加快且缩短实现价值的时间。

5、不影响安全性、兼容性和性能。

二、顶层设计与全局规划

我把DevOps整个体系分成了六个维度加一个文化。六个维度包含了组织、过程架构、工具和基础设施以及度量。

组织：首先必须打破组织之间的隔阂，其次DevOps组织要面向产品而非项目的协作文化。

过程：轻量级流程和自动化工具的完美结合，确保企业的高度敏捷性；自动化为先，而后再流程。

架构：架构又分成应用架构、基础架构和数据架构。应用架构和基础架构这两点是比较明确的。应用架构讲的是微服务架构，基础架构是讲标准化基础设施。

工具：把质量成本和效率这几者维度同时兼顾，具备可落地化。

基础设施：虚拟化到容器化的平台。

度量：度量体系能不断驱动能力优化。

在纵向的维度上，把能力评估分为五个等级，这个五个等级参考CMI。

Quota定义了namespace中能利用的最大资源，而BatchJobController算的值则在中间来回浮动。

三、Start Small，从小做起

基于某个角色和某个场景去进行从小做起。

基于某个系统或者某个功能域来实施导入。

切忌贪大求全。

四、构建IT元数据平台，驱动IT平台间整合

因为要缩小范围，CMDB在下一个版本的名字将改成IT资源管理平台。缩小范围后，只管理基础设施和应用的资源。基础设施的资源属于资产状况。当资产状况管理起来之后，再从应用的视角看到底用了哪些资源，把这两层维度强关联起来，再在应用上层构建应用的各种管理场景。由它来进行进一步驱动CMDB的流转，在应用这个维度上才符合高频的特征。CMDN是IT运营平台的核心元数据。

五、痛苦的事情优先解决

因为运维的角色很多，最终的能力管理过程也非常多，所以一定要通过角色加场景，最后才能导出应该构建什么样能力管理的平台。运维自动化渗透在每个角色和场景里。作业和调度的能力属于一种底层平台化的能力，这个能力应被上层各个子系统使用。

六、工具也是一种文化

作业管理和调度管理是一种平台级的能力，不需要对它进行场景化的理解，只要认为在自动化的构成要素里面有个原子化的事物，同时要有一个调度引擎去编排这个原子化的事物，有两个要素就够了。基于这两者的能力，面向角色和场景收敛去归类。

工具也是一种文化，通过它，我们可以构建各种各样的原子工具把我们的能力进行拼装起来，然后在各个场景下使用。

好的经验一定要通过自动化的手段去去沉淀，而不是通过文档去沉淀。工具是真正推动变革的有效手段。

七、组织二次元，加群落地力

我认为这里面其实要把它变成一种虚拟组织的形式，所以我把它做了一个改进。把中心的角色去掉了，并用技术化的思维做了一个拆分。但这一块强调技术的能力，要通过持续交付平台团队来构建一个持续持续交付的、端到端的DevOps的平台坚守中心化的原则，和技术、组织架构完全保持一致。不改变现有的组织结构，通过技术的一些手段来加强组织的映射能力。

八、价值拉动，而非事务驱动

经营核心的准则就是以家客户的价值流作为驱动。

在识别整个价值流的时候要看哪些是无效的活动，哪些是不增值的活动，还有哪些是给客户产生价值的活动。

九、平台+插件=服务能力产品化，和组织一致

产品一定要有一个平台化的思维。这个平台化思维有个边界的，不能跨越这个边界。同时要去适配各个公司的现状，怎样把公司现有的一些能力插件化进来。

从DevOps的角度来说，一定是交付流水线的平台，IT端到端的调度。整个插件的适配层是插件的协议标准，把开发者、测试者和运维的能力，全通过插件放到交互流水线里。这里很多插件的标准可以认为是作业平台和调度平台的能力。

十、自动化别人，先自动化自己

一定要先自动化自己的能力再去自动化别人，千万不能越界。自动化是一个由点到线再到面的过程、一个逐步覆盖更多角色的过程，还是一个环境逐步覆盖的过程。

十一、持续交付是DevOps落地的最佳实践

持续交付是DevOps的最佳工程实践，以部署流水线为基础，以快速交付为目标。

十二、IT运营管理驱动Ops能力建设

应用上线之后运营过程该怎么去覆盖合并，我把它分成几个阶段，人工运维、平台化运维、孵化运营和智能化运营。

运维也分为运营阶段的划分、目标的划分、覆盖的场景是什么、达成的收益是什么、需要的资源有哪些。

十三、构建面向应用的最强管理驱动力

应用在今天是变得越来越重要，云的形态底层把能力服务化，那么应用怎样去抽象成三个维度，一是资源的维度，二是动作的维度，三是状态。

应用的运行一定依托于资源。应用的变更等于资源的变更。应用的状态等于资源的状态。

最终对应用的整个状态的评价和衡量就是对于资源的评价与衡量。状态里面分成智能监控、数据分析。监控面向问题，数据分析面向整个的服务、数据可视化。

十三、构建面向应用的最强管理驱动力

应用在今天是变得越来越重要，云的形态底层把能力服务化，那么应用怎样去抽象成三个维度，一是资源的维度，二是动作的维度，三是状态。

十四、构建指标，驱动DevOps落地

1.变更时长

2.服务恢复时长

3.发布频率

4.变更失败率

合理的指标驱动构建的是不同的组织，高性能的组织、中等效能组织和低效能的组织。

我的分享到此结束，谢谢大家！

原创：王津银