• 全国400电话网上服务平台
    强大号码库资源任选,方便,快捷,快速开通。
    咨询热线:400-1100-266  

    4个维度,实例化DevOps原则
    POST TIME:2018-12-03 21:41
     

    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 – 分享:分享成功和失败的经验来彼此学习。
    
    Copyright © 2003-2016
    时间:9:00-21:00 (节假日不休)
    版权所有:巨人网络(扬州)科技有限公司
    总部地址:江苏省信息产业基地11号楼四层
    《增值电信业务经营许可证》 苏B2-20120278
    X

    截屏,微信识别二维码

    微信号:veteran88

    (点击微信号复制,添加好友)

     打开微信

    微信号已复制,请打开微信添加咨询详情!