4个维度，实例化DevOps原则

　

DevOps原则所追求的愿景，就是“让业务所要求的那些变革能随时上线可用”；DevOps的起源表白，其原则是从Agile与Lean的实践傍边提炼而来，因此与Agile和Lean的原则并无二致；本文所讨论的DevOps原则可以用“人、产品、流程和工具”这4个维度来进行组织。

“你在做用户故事拆分？这不是在做DevOps。”这是笔者在2016年以咨询师的身份，参与一家大型跨国金融企业的Agile和DevOps转型时所听到的话。在这家企业，Agile和DevOps明显指的是差别的东西：前者专指每日站会、计划会、回顾会等Scrum的实践和用户故事实践；后者专指自动化、工具链和基础设施等实践。过了一段时间，笔者把本文所列举的一些DevOps原则发到一个相关微信群里面，得到了这样的反馈：“怎么满眼都是敏捷和精益？”“感觉DevOps被一群不操作Op的人给玩儿坏了。”

这些经历让笔者开始关心这些问题：既然Dev指的是“开发”，Ops指的是“运维”，那么到底什么是DevOps？它的原则是什么？它和敏捷、精益的关系是什么？让我们先不雅观察一下DevOps的起源。

DevOps的起源可以分为两条线第一条线：比利时独立咨询师Patrick Debois

2007年他在比利以咨询师的身份，参与了一个政府数据中心迁移中的测试工作。他在做测试时，需要频繁往返于Dev团队和Ops团队之间。Dev团队已经实践了敏捷，而Ops团队还是传统运维的工作方式。看到Ops团队每天忙于救火和疲于奔命的状态，他在想：能否把敏捷的实践引入Ops团队呢？

第二条线：当时雅虎旗下的图片分享网站Flickr

这家公司的运维部门经理John Allspaw和工程师Paul Hammond，于2009年6月23日在美国圣荷西举办的Velocity 2009大会上，颁发了一个引燃DevOps的演讲。这个演讲的标题问题在当时很抢眼——《每天安排10次以上：Flickr公司的Dev与Ops的合作》。

这个演讲有一个核心议题：Dev和Ops的目标到底是不是冲突？传统不雅观念认为Dev和Ops的目标是有冲突的——Dev的工作是添加新特性，而Ops的工作是连结系统运行的不变和快速；而Dev在添加新特性时所带来的代码变革，会导致系统运行不不变和变慢，从而引发Dev与Ops的冲突。然而从全局来看，Dev和Ops的目标是一致的，即都是“让业务所要求的那些变革能随时上线可用”。

这样抢眼的标题问题和鲜明的不雅观点，自然抓住了当时还在比利时的Debois。他在“推特”上发帖：“可惜没法去现场参加。”伴侣Paul Nasrat回帖说：“为什么不在比利时搞一个你本身的Velocity大会？”这两条线使得Debois撸起袖子，于2009年10月30至31日，在比利时的第二大城市根特，以社区自发的形式举办了一个名为DevOpsDays的大会。这次大会吸引了不少开发者、系统办理员和软件工具程序员。这两天大家聊得太开心了，会议结束还不过瘾，回去继续在“推特”上聊。限于推特140个字符的制约，Debois把DevOpsDays中的Days去掉，而创建了#DevOps#这个“推特”聊天主题标签，DevOps诞生了。

Flickr公司的两位演讲者所表达的“Dev和Ops的共同目标是让业务所要求的那些变革能随时上线可用”这一不雅观点，其实就是DevOps的愿景。而要达到这一点，可以使用一个现成的工具：精益。源自丰田生产方式的“精益”的愿景就是“Shortest lead time”，即用最短的时间来完成从客户下订单到收到货物的全过程。这恰好能帮手实现DevOps的上述愿景。《持续交付》的作者之一Jez Humble也体会出精益在DevOps中的重要性，以至于他把DevOps的CAMS框架修订为CALMS，其中增加的L指的就是Lean（精益），这一点下文还会提及。

从上面DevOps的起源中能够看出三点：

DevOps源自草根社区，最初并没有什么自上而下设计出来的理论框架；DevOps背后的原则，就是上面两条线中所涉及的敏捷和精益的原则；DevOps的愿景是让业务所要求的那些变革能随时上线可用。

一旦了解了上面第2点，就不会有前文中所说的“Agile和DevOps是差别的东西”和“感觉DevOps被一群不操作Op的人给玩儿坏了”这样的说法。

因为DevOps源自草根，没有什么框架，所以如何定义DevOps成了DevOps社区里面的一个大难题。一些DevOps从业者，纷纷设定本身的DevOps框架。其中比较有名的框架有上文提到的Damon Edwards所定义并被Jez Humble所修订的CALMS，和Gene Kim所定义的The Three Ways。

CALMS:

Culture – 文化：公司各个角色一起担当业务变革，实现有效协作和沟通；Automation – 自动化：在价值链中尽量除去手工步骤；Lean – 精益：运用精益原则更频繁地交付价值；Metrics – 度量：度量并使用数据来优化交付周期；Sharing – 分享：分享成功和失败的经验来彼此学习。

标签：林芝 东营 乌鲁木齐 九江 盐城