从软件研发模式看 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 系统要实现向资源管理系统的过渡, 应用的变更场景最终是对资源的变更, 应用的状态最终是由其资源的状态来决定的.
来源: https://juejin.im/post/5ae03d6b6fb9a07ac85a1508