DevOps原则,听伍道长细细道来

讲师简介

伍斌_Ben,悟道者,ThoughtWorks软件开发咨询师。著有《驯服烂代码:在编程操练中悟道》,译有《测试驱动数据库开发》和《优质代码》。自1993年大学毕业以来,先后做过程序员、测试工程师、项目经理和软件开发咨询师。2013年4月创办全栈开发者的编程操练社区“bjdp.org北京设计模式学习组”。微信公众号bjdp_org。

分享内容介绍

DevOps原则所追求的愿景是什么?

DevOps的实践包括Scrum和用户故事的实践吗?

还是仅仅指自动化测试和部署?

DevOps与Agile和Lean的关系是什么?

有哪4个维度可以用来组织丰富多彩的DevOps原则?

这些原则有没有一些所对应的实践的例子?

让我们一起在本次分享中寻找上述问题的答案。

分享内容总结

Dev指的是“开发”,Ops指的是“运维”,那么到底什么是DevOps?它的原则是什么?它和敏捷和精益的关系是什么?

 

要回答这些问题,让我们先观察一下DevOps的起源

 

DevOps的起源可以分为两条线。

 

第一条线就是比利时独立咨询师Patrick Debois。2007年他在比利时参与一个测试工作时,需要频繁往返于Dev团队和Ops团队。Dev团队已经实践了敏捷,而Ops团队还是传统运维的工作方式。看到Ops团队每天忙于救火和疲于奔命的状态,他在想:能否把敏捷的实践引入Ops团队呢?

 

第二条线是当时雅虎旗下的图片分享网站Flickr。这家公司的运维部门经理John Allspaw和工程师Paul Hammond,于2009年6月23日,在美国圣荷西举办的Velocity 2009大会上,发表了演讲 “每天部署10次以上:Flickr公司的Dev与Ops的合作”。

 

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

 

了解了这个演讲的议题后, Debois撸起袖子,于2009年10月30至31日,在比利时 城市根特,以社区自发的形式,举办了一个名为DevOpsDays的大会。这次大会吸引了不少开发者、系统管理员和软件工具程序员来参加。 会议结束后,大家继续在“推特”上聊。 Debois把DevOpsDays中的Days去掉,而创建了#DevOps这个“推特”聊天主题标签,DevOps诞生了。

 

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

 

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

 

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

 

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

  

本人试着从“人、产品、流程和工具”4个维度,来把DevOps的一些原则进行梳理。 其中,“高于”表示右边的实践虽然不如左边的好,但还是有价值的。“而非”表示右边的实践并不值得推荐。这就是本文标题中“实例化”的由来。


领导者身体力行持续改进 高于 关注工具和基础设施

要想让DevOps这颗树苗茁壮成长,企业要为其提供一个良好的土壤——即企业文化。而企业文化,是企业领导者所塑造的。 只有领导者身体力行,不仅自己做试验和持续改进,并给工程师时间来做试验和持续改进,这样所创造出良好的土壤,才能让那些自动化工具和基础设施在企业内部得到有效利用。


试验并改进流程 而非 指责人的过失

DevOps对于国内大部分企业都是新事物,需要做试验来“摸着石头过河”,做试验就有失败的时候,此时就要调整流程,而不是怪罪于人,否则企业没有人会去继续尝试DevOps。


产品思维 高于 项目思维

根据这一个原则可以定义“人”的组织结构——团队结构,即可以按照产品而不是项目来组建团队。这种自治的全功能团队,能令团队的不同角色目标一致,比起从目标不一致的各种职能团队(比如Dev团队、Tester团队和BA团队)抽调人员拼凑成临时的项目团队,磨合期更短,更加有战斗力。

 

产品


质量和安全内建 而非 晚期度量和检查

通过持续改进流程,“一次就把事情做对”,这样就能在不进行后期大规模检查的情况下保证高质量,同时保证质量的成本也趋近于零。


客户反馈 高于 按期交付

产品是否实现了价值,只有通过客户的反馈才能知道。很多团队往往过分关注交付期限,而忽视经常从客户那里获得反馈。这样做的后果,就是虽然按期交付,但是产品却不是客户所期望的,造成返工或项目失败。


基于不可变容器的微服务 高于 单块应用

产品需要能快速地开发、测试和部署才能有效地交付价值。对于复杂度高的大型产品,如果可以由多个微服务组合而成,每个微服务都能独立地开发、测试、部署和上线。这比起必须集成各个模块才能进行手工测试的单块应用来说,能实现各个微服务之间的并行研发,加快每个微服务的开发下游至上游的反馈环的反馈速度,进而缩短项目进度,让价值交付得更快。

流程


管理层实践Improvement Kata和Coaching Kata进行流程持续改进 高于 用结果导向进行管理

传统按结果导向进行管理的一个弊病,就是团队成员会把注意力放到结果上,而不是产生这样结果的原因——即过程改进之上。这样的后果就是,大家会把精力放到如何让报表好看,而不是真正地提高团队成员的持续改进能力来真正达到所期望的结果。企业管理层可以参考《丰田套路》一书来带头实践Improvement Kata和Coaching Kata,让企业产生持续改进的文化。


全局优化 而非 局部优化

由于大部分按职能组织团队的企业内部所存在的部门割据的问题,导致大家都在做本职能部门内做局部优化,而没人做部门间的整体优化。有些部门间的扯皮时间甚至长达数月,严重影响了产品的交付。这提醒我们,全局优化来提高企业整体竞争力,才是各个部门赖以生存的保障。


单件流 高于 库存

单件流指的是,正在制作的产品的各个模块,能从最初的对其增加价值的加工步骤,直接传递到下一个增值加工步骤进行加工,并最终被传递到客户手中,在这个过程中,各个步骤之间没有发生等待或者排队的现象。而如果在各个步骤的传递过程中发生了等待或排队,那就等同于建立了库存。 软件开发中的库存就是让项目延期的最大原因。而企业如果能做到单件流,那么就相当于消灭了库存,让价值在不同环节之间流动得最快,进而实现了前文所提到的全局优化。

 

工具


自动化 高于 手工

按照固定流程所进行的手工工作,比如手工回归测试和手工部署工作,无趣、缓慢且无法审计。如果能将其代码化,且用版本控制系统管理起来,并加以自动化,这既能节省以后手工运行的大量时间,又能体验到开发测试和部署脚本工作的乐趣。


基础设施及代码 高于 手工配置

传统Ops的部署工作有些需要用鼠标在界面上点来点去,效率很低;效率高一些的Ops用了自动化脚本,但很多脚本都没有进行版本控制。如果能够将基础设施的维护工作都通过编写代码并加以版本控制来完成,那么让团队了解基础设施的配置,并方便做自动化, 大幅度提升Ops的工作效率。


部署流水线 而非 每日构建

有些团队每晚做一次代码构建。这样做的问题是:团队程序员们每天代码的提交会有很多,如果晚上构建发现了错误,第二天从这些众多提交中发现谁导致的错误,将是一个很困难的事情。推荐的做法是每一次代码提交,都能自动触发部署流水线来检查该提交是否通过了自动化单元、验收和性能等测试。一旦发现问题,就能轻松定位是谁在哪个环节出现了什么问题。

总结一下,DevOps的原则来自从业者们的在日常工作中运用Agile、Lean原则的具体实践。这些原则可以按照“人、产品、流程和工具”4个维度来组织。这些原则和实践的目的,都是要实现DevOps的愿景——让业务所要求的那些变化能随时上线可用。

 

精彩问答

请问老师,devops的实践在legacy系统中如何运用呢?有没有可能呢?

在legacy系统中,也是可以运用DevOps的某些原则的,比如“质量和安全内建 而非 晚期度量和检查”、“客户反馈 高于 按期交付”、“全局优化 而非 局部优化”、“单件流 高于 库存”、“自动化 高于 手工”等等。是有可能的。我听到一句很给力的话:其实没有Legacy的系统,而只有Legacy的思维模式。

伍老师能介绍下工作中具体如何落地的吗,具体案例?

这个问题是不是讲DevOps转型如何落地?如果是的话,那么在工作中具体落地的方法是个很大的话题,而且实施方法因组织的具体情况而异。但我个人认为,转型能否落地最重要的一点,就是专注在“因”,而不是“果”上。就是“菩萨畏因”的“因”和“众生畏果”的“果”。“因”其实就是工程师的“行为模式”。要改变“行为模式”,就需要老师。老师可以是组织内有经验的经理,还可以外请教练。没有转型经验的组织,需要让有经验的人带一下。具体案例可以参考Flickr. :-)

devops原则是针对所有软件产品,还是主要针对线上产品?

这些原则可以针对所有软件产品来定制。定制时需要注意:要做试验,来找到适合自己组织的实践方式。

老师,这里提到的集成自动化,主要是那个层面的自动化测试呢?测试一般来说会有,单元,接口,到功能,ui。但是感觉到多数项目只会devops集成到api的自动化测试。这个会有一个通用的做法什么的吗?

这里提到的自动化,可以包括自动化测试和自动化部署,及一切可以用代码来自动化的手工操作。您提到的各种层面的自动化测试,需要按照测试金字塔来组织:即少量的UI自动化测试、中等数量的Service自动化测试和大量的自动化单元测试。

测试金字塔可以参考老马的博客:https://martinfowler.com/bliki/TestPyramid.html

基础设施设置工具推荐哪些,chef,ansible或者salt?

我这里有张图,体现了一些配置管理工具和DevOps工具诞生的时间顺序。

这些工具的对比,大家可以参考:https://www.upguard.com/articles/the-7-configuration-management-tools-you-need-to-know

请教下老师:目前在您实践DevOps的过程中,组织结构是如何演化的?

即用什么样的办法让组织结构从现有的以部门为单位,转向为以产品为单位?

最佳实践是什么?

另外问下,您目前一个产品团队,里面的成员结构和成员构成大概有哪些,人数如何?

我所看到的企业DevOps转型,组织的结构是公司高层由上到下来重新组合,来讲原先以职能划分的团队,调整为以产品为核心的特性团队。其实我觉得没有最佳实践,只有经过了在自己组织中试验并改进后得到的较好实践。但总原则是特性团队包括业务人员、开发人员、测试人员和运维人员,且各个角色的核心人员相对稳定,不会随着项目变化而解散。

人数可以参考亚马逊的“两个披萨”团队(即团队外出吃饭,两个大披萨就能喂饱)的设计:http://blog.jasoncrawford.org/two-pizza-teams

微服务和单件流,在 现实中存在4端,相互交叉版本依赖,这也做到微服务单个发布个集成,和单件流,这种情况怎么来完善和实施devops? 也难做到完全单个情况?

就是我们应用存在4端,划分微服务后,存在依赖太严重了,很慢做到单体价值交付,和单个微服务做ci这样……能否知道有解决方案之类的?

如果拆开微服务后,发现几个微服务的依赖太严重,那么多半是因为拆分的不合理导致的。微服务拆分原则是每一个微服务都能实现“自治”,微服务的拆分原则可以参考老马的“微服务”博客:http://www.10tiao.com/html/551/201603/404584177/1.html

就是我们应用存在4端,划分微服务后,存在依赖太严重了,很慢做到单体价值交付,和单个微服务做ci这样……能否知道有解决方案之类的?

如果拆开微服务后,发现几个微服务的依赖太严重,那么多半是因为拆分的不合理导致的。微服务拆分原则是每一个微服务都能实现“自治”,微服务的拆分原则可以参考老马的“微服务”博客:http://www.10tiao.com/html/551/201603/404584177/1.html

另外老马的“微服务”博客是我翻译的,可以告诉大家原版在这里:http://mp.weixin.qq.com/s?__biz=MjM5MjEwNTEzOQ==&mid=401500724&idx=1&sn=4e42fa2ffcd5732ae044fe6a387a1cc3#rd

来源:中生代技术

原文链接

时间: 2024-09-08 09:01:10

DevOps原则,听伍道长细细道来的相关文章

arraylist-关于ArrayList求大神为我解析以下几个问题,求大神细细道来,万分感激

问题描述 关于ArrayList求大神为我解析以下几个问题,求大神细细道来,万分感激 求大神为我解析以下几个问题:1.为什么保存的时候还要调用getList() ?2.为什么创建ArrayList?3.if()里什么意思?4. 第二段代码if{}最后一句什么意思?里边怎么就一个参数?5.第二段代码倒数第四句和第三句都什么意思?求大神细细道来,万分感激 public String getList() throws Exception { if ("""".equals

DevOps&SRE 超越传统运维之道 (上海站) 火热开启!

5月&6月, 优维科技与数人云分别在深圳和上海, 做了两场关于DevOps&SRE落地实践的深度分享, 带着大家的期待, 我们将<DevOps&SRE超越传统运维之道>话题在上海继续. 匡云竹@优维科技.张保珠@数人云.于绮@京东.周炎@东方财富网 四位业界大牛齐聚, 结合传统运维现状及实践案例,讲述DevOps&SRE的超越之道. DevOps与SRE.传统行业与互联网行业, 多个不同场景的DevOps.SRE落地实践,总有一个适合你! DevOps&

活动报名 | DevOps&amp;SRE 超越传统运维之道(北京站)

五月,优维科技与数人云的两位老王以及腾讯大梁相约深圳,做了一场关于DevOps&SRE落地实践的深度分享,现场气氛十分热烈: 带着大家的期待,由中生代技术社区发起,我们将<DevOps&SRE超越传统运维之道>话题在北京继续. 黄星玲@优维科技.邱戈川@数人云.王一男@百度.任发科(网名常新居士),四位业界大牛技术齐聚,结合传统运维现状及实践案例,讲述DevOps&SRE的超越之道. 嘉宾介绍 活动议程 13:30-14:00 签到14:00-14:40 黄星玲主题分享

DevOps&amp;SRE超越传统运维之道技术沙龙报道

6月10日,中生代技术联合数人云.优维科技在北京微软大厦举办了DevOps&SRE超越传统运维之道技术沙龙. 演讲嘉宾嘉宾黄星玲.邱戈川.任发科和王一男分别分享了<DevOps在传统企业的落地实践及案例分享><Scrum模式经验分享><如何打造易用的DevOps工具链><百度研发工具链的应用实践>,为大家带来了一场精彩纷呈的技术盛宴. 签到现场花絮 中生代北京站长Charles王做精彩开场主持秀 黄星玲讲解<DevOps在传统企业的落地实践及案

IT面试最难的科技公司分享 | 实例化DevOps原则

IT面试哪家难?非死不可把头点! 谷歌瘪嘴笑开颜,思特沃克耸耸肩~ 科技博客Business Insider撰稿人朱莉·波特(Julie Bort)上周五依据美国雇主评价网站Glassdoor.com提供的数据,评选出十大入职面试最难的科技公司.令人颇感意外的是,科技公司入职面试最难的并不是传说中的谷歌面试,而是软件开发顾问公司ThoughtWorks. 排行榜如下: 第一:ThoughtWorks 第二:谷歌(将会有多轮面试,内容涉及智商测试.随即数学问题等) 第三:Unisys(将会有多轮面

打通福道与善道

中国公益慈善事业发展面临的这种结构性挑战,最重要的表现就是福道和善道的堵塞 文 | 王振耀 目前,中国慈善业面临着非常大的结构型挑战,这种局面的出现与中国的发展现状有关.实际上,中国提前40年进入了中等发达国家阶段,中国社会在客观上进入了一个重建时期. 经济的发展促成了现代慈善阶段的快步来临,慈善已成为当代中国的一种时尚,这也使得中国慈善事业出现了快速发展趋势,表现在以下五大方面. 社会主流化:公益从配角走到社会舞台的中央,以慈善促和谐,成为朝野的共识,也成为中央推进社会政策建设的重大举措之一:

ComboBox遇到怪问题,听我细细道来~

问题描述 代码:privatevoidcomboBox_PKey_TextChanged(objectsender,EventArgse){//MessageBox.Show("哦......");stringsql;OleDbCommandcmd;//MessageBox.Show(OPKey);if(OPKey!=null){sql="ALTERTABLE["+textBox_TableName.Text+"]DROPCONSTRAINTPrimary

android 中监听按键的长按事件

1,key -- 实体按键, 现在手机物理按键越来越少 常见的有 KEYCODE_VOLUME_DOWN/UP KEYCODE_POWER KEYCODE_BACK KEYCODE_HOME KEYCODE_MENU 在一个activity 重载父类 的下面这三个方法来处理按键事件 public boolean onKeyDown(int keyCode, KeyEvent event) public boolean onKeyUp(int keyCode, KeyEvent event) pu

网易有道上线有道云协作 整合笔记和即时通讯功能

DoNews 11月4日消息 11月4日,网易有道企业级应用有道云协作正式上线,目前已经覆盖PC.MAC.Web.iphone以及Android多个终端和平台. 据悉,该应用主要具备团队资料管理和团队即时通讯两大功能,其中团队资料管理兼容各大主流文档格式,用户可通过云协作实现团队资料上传.下载.搜索.协同编辑以及协同表格管理和版本管理等功能.即时通讯则让支持用户通过不同终端实现团队沟通.对团队资料进行编辑和讨论.而这两大功能均通过"群"的概念来组织和实现. 网易高级副总裁周枫表示,有道