[转载]DevOps在传统企业的落地实践及案例分享

内容来源：2017年6月10日，优维科技高级解决方案架构师黄星玲在“DevOps&SRE 超越传统运维之道”进行《DevOps在传统企业的落地实践及案例分享》演讲分享。IT 大咖说做为独家视频合做方，经主办方和讲者审阅受权发布。

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

DevOps是一连串的工程实践的有机组合，其中包括敏捷管理、持续交付、IT服务管理等等。
DevOps是关注整个业务/应用/服务生命周期的管理，把业务和IT的战略进行了对齐。
DevOps以精益思想为基础，强调自动化、拉动式、“拒绝浪费、创造价值”等。

从软件研发模式看DevOps
目前的“瀑布流”模式开发中间有不少部门墙，从研发到测试再到运维，它们中间是彻底断层的。断层的理念会致使咱们在研发的过程当中测试和运维都无事可作，这就是一种浪费。
如今作的敏捷迭代、测试驱动开发让咱们组成小team模式。这种模式以业务价值流来进行交付，要可以保证快速交付产品、模块，而且是能够独立运行的。
DevOps让团队共享面向客户的价值、共享集成目标、共享质量责任。
DevOps也让运维的做用变得更加突显，此时须要全新的思惟/平台/方法论来实现Dev的软件快速交付到Ops阶段，而且可以稳定地运营。DevOps的落地经验谈
移动互联网时代的业务特征就是快！产品的决策快、推出快、迭代快、变革快，快能抓住机遇、掌握主动。
对IT支撑也带来了一些挑战，例如快速交付产品、IT支撑可灵活扩展、更高要求的客户体验、项目时间紧、须要快速响应业务/需求变化。
没法快速响应业务激增的需求：新型互联网业务对资源需求的波峰波谷现象更突出，服务对外开放使业务量的不可预估。目前临时业务不管高峰、低峰期均须要大量的人工介入，系统灵活扩展性不足。
系统维护难度高：支撑系统X86分布式集群架构改造后，应用主机多，故障定位困难；缺少自动化的系统处理，须要大量的人工介入，处理时间长，对维护人员技术要求很是高。
不能实现敏捷开发：须要开发人员对每台服务器进行复杂操做才能完成部署，需求测试环节须要根据业务依赖关系逐一测试，开发难度和上线效率不高，很难作到敏捷开发，快速发布，持续集成。
传统架构架构简单，运维快速定位，快速发布。但支撑内部总体目标架构没有统一的规划设计，系统烟囱式建设。
转变为云化架构后，经过核心云构建，实现资源共享，和设备资源层造成联动，实现应用的弹性伸缩。可是云化架构比较复杂，须要运维过程智能化，自动化转型。
咱们如何提升产品交付给客户的速度、如何改变产品更快更好知足咱们客户、如何恢复故障不至于影响咱们的客户、如何更快经过咱们的努力得到客户承认？
打通市场需求、开发、测试、发布、部署上线、运维等各环节，促进需求、开发、测试、运维团队更紧密地合做，敏捷开发，持续交付、自动运维，提升支持系统的生产、交付效率。

理念与价值先行
经过持续服务交付价值链打破孤岛，整合开发和运维的能力成为一个协做的团队。进行端到端持续服务交付流程的变革。对新的应用和服务，加快且缩短实现价值的时间。不影响安全性、兼容性和性能。顶层设计、全局规划

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

要构建元数据基础平台CMDB，应该是自动化的。

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

CMDB分核心模型和扩展模型。核心模型是业务、应用、主机和程序包；扩展模型是基于这个实例的关联对象。创建以应用为中心的资源管理模型。

工具也一种文化
做业管理，一方面把运维的脚本能力可视化，另外一方面也在提升运维的效率和质量。
调度管理，提供面向复琐事务的能力封装。

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

服务主管，对IT服务及时性相应负责，相似Scrum的PO。
DevOps工程师，有义务提升和维护自动化流程，构建完整的自动化过程和工具，提高效率。
把关人，负责监控IT服务的运行状态和下一步发布的进展。
可靠性工程师，监控部署过程当中的服务并处理正在服务执行中产生的问题。
流程主管，领导并促进团队，这个角色相似于在Scrum中的Scrum Master。

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

自动化是一个由点到线到面的过程。要先从一个小的点切入，把自动化作完以后才能够一点一点影响到周围，进行扩散。
自动化是一个逐步覆盖更多角色的过程。作完一件事再作第二件事的时候，它们都是互相影响的。
自动化也是一个环境逐步覆盖的过程，先生产，再测试，再开发。持续交付是最佳的DevOps实践

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

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

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