摘要
在传统支撑模式无法满足业务价值快速交付要求的情况下，传统企业应该如何引入DevOps能力进行突破创新，本次分享将从以下几个方面具体探讨DevOps如何与传统融合进而落地：
1.DevOps的整体框架及落地方法探讨；
2.DevOps落地关键点之一：IT元数据平台的重要性及设计标准；
3.DevOps落地关键点之二：持续交付在传统企业的融合方法探讨；
4. 电力行业案例分享。DevOps整体体系框架

这张图是我们产品设计的全局规模规划图，但在所有公司都适用。以后无论是做运维自动化还是DevOps整体门户化，都是有一个统一运维的门户。从小做起，Start Small
基于某个角色、某个场景从小做起，从自己做起。基于某个系统或者某个功能域来实施导入，切忌贪大求全。构建元数据基础平台CMDB

CMDB成为IT运营管理平台的核心元数据。CMDB数据的“鲜活性”，核心靠场景驱动。

基于作业和调度能力，面向角色场景化收敛和归类各类能力。
好的经验，通过自动化的手段沉淀，工具化，极简管理过程。工具是真正推动变革的有效手段，自底向上的核心手段。组织二元性

运维交付团队。分资源交付团队、应用交付团队、运维研发团队。运维研发负责运维交付能力自动化。
开发测试团队。设立测试研发团队，负责测试能力自动化。
DevOps研发团队。负责从持续交付的角度端到端的能力集成。
服务主管、流程主管角色不变。
如上图所示，等待时间和实际所用时间相差很大，这中间的浪费非常大，这就是部门墙导致的。我们需要保证每一个运转的中心都是一直在工作的。不管是需求、开发、测试还是运维，都应该是拉动式的，因为只有他自己才知道当下处于运行状态还是空闲状态。自动化别人，先自动化自己

从上图可见，开发、测试、预发布和生产所做的事有很多都是重复的。如果能把这些自动化、工具化，重复的工作就不存在了。
还要做到标准化。从开发、测试到运维，基础环境和应用架构都是标准化的。当我们把所有的事情都做到标准化、无状态化、微服务化的时候，这些操作将会变得特别简单。并且要把整个交付的过程可视化，要知道进度到了哪个阶段。构建面向应用的最强驱动力

CMDB系统要实现向资源管理系统的过渡，应用的变更场景最终是对资源的变更，应用的状态最终是由其资源的状态来决定的。
今天的分享就到这里，谢谢大家！

转自《DevOps在传统企业的落地实践及案例分享》

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树首页概览8582 人正在系统学习中 相关资源：SAMM软件保证成熟度模型落地工具- 络安全文档类资源-CSDN文库