大版本上线前,所有开发、测试、运维甚至各级技术领导都如临大敌、打着十二分的精神熬夜加班,在夜深人静的时候,把新代码偷偷的替换到线上。紧张的几个测试回合下来,就已经发现了数个严重的问题。原本静悄悄的办公室不再保持安静,顿时各种声音四起。“这是谁开发的模块,快过来看看?”“在测试环境没有问题啊,怎么又让运维搞砸了?”“快点快点,看看部署文档里面的checklist是不是都执行了?”……

一个紧张的夜间大作战后,天亮了。红彤彤的太阳照着大地,而参与战斗的勇士们却只能眯着星星松松的睡眼,用一杯速溶豆浆和几个包子来补充能量。新版本终于上线了,现在只祈祷那脆弱的系统在上帝的保佑下平稳的度过一天。

这不是小说,这是一个我们常见的软件或者应用发布与部署的场景。

在《持续交付:发布可靠软件的系统方法》一书中,作者列出了几种持续交付的反模式,简单来说有以下几种:

(1)手工部署软件。

(2) 开发完成之后才向类生产环境部署。

(3) 生产环境的手工配置管理。

同样,在这本书中,也给出了实现持续交付的方法,那就是构建一套部署流水线。关于如何实现部署流水线的构建,不是本文的主要内容,在此不做赘述。

不得不说,这本得到第21届Jolt大奖的著作深深影响了一代人对DevOps的理解。甚至有人说,DevOps就是持续交付。

DevOps不仅仅是持续交付,持续交付仅仅是DevOps整个体系中的一个组成部分。DevOps是以精益(Lean)作为支撑的,由敏捷管理、持续交付和轻量级ITSM(IT Service Management,IT服务管理)为3个支柱的价值流体系。DevOps的本质是以消除浪费为最终目的的精益思想在IT服务交付方面的实践。

以单件流(One PieceFlow)流式供应链方式构建的JIT(Just-In-Time)和自动化是精益理论的2个核心。传统的以批量方式运作的生产模式,往往造成大量的WIP(在制品,即没有完成价值交付的半成品)积压和流转不畅,因此而带来大量浪费。而单件流模式,则以Pull(拉)的方式,以需求拉动生产流水线,并尽力减少不必要的步骤从而减少浪费,尽可能让在制品的数量降低,以达到价值的交付。

想想吧,在我们的IT服务交付链中,有多少存在浪费的地方?有多少环节出现了等待?有多少处在在制品状态的项目、软件、系统过程?

DevOps的首要目标就是解决这些浪费。

让开发和运维物理上坐在一个办公室工作不是DevOps,让开发参与运维或者运维参与开发也不是DevOps。DevOps是以精益思想为指导,以实现价值交付和杜绝浪费为最终目的,通过构建协作的文化、高效的沟通和系统集成(自动化)来实现的IT服务价值链。

原文来自:http://www.yunweipai.com/archives/19190.html

本文地址:https://www.linuxprobe.com/devops-is-devops.html编辑员:张雄,审核员:逄增宝

本文原创地址:https://www.linuxprobe.com/devops-is-devops.html编辑:问题终结者,审核员:暂无