我国最大的IT项目管理门户网站,国内IT项目管理培训与咨询服务提供商

当前位置:首页 > DevOps > 正文

DevOps面面观

2018-11-12 来源:AgileRunner 姚冬
  源于一月份读了《凤凰项目:一个IT运维的传奇故事》一书(感谢徐磊同学的推荐),这本小说体一气呵成的书,阅读感受非常好,提笔想做读书笔记却有些犯难,小说貌似只有写读后感的;恰好随后给同事做过两次DevOps的介绍,乘机整理了一下思路,将自己对DevOps方方面面的理解,最终呈现为这篇文档,作为阶段性的总结。
  什么是DevOps?
  DevOps不只是开发与运维的问题
  从大处着眼
  从小处下手
  通过加大部署/发布频度来撬动整个交付过程
  自动化、标准化、配置化
  DevOps实践
  DevOps与云
  DevOps与精益、敏捷
  三步工作法
  1、以下问题有没有解?
 “快速将产品推向市场” 与 “提供稳定、安全并可靠的IT服务” 是否可以兼得?
用更少的资源完成更多的业绩,既要保持竞争力,又要削减成本;
如何解决任务交接出现的问题,例如业务与开发,开发与运维之间;
运维人员能否和其他人一样,正常上下班,而不用在夜里或者周末加班?
  2、什么是DevOps? 众说纷纭
  WikiPedia上说:"DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发与运维之间相互依存关系的一种新的理解。“
  百度百科说:“DevOps(英文Development和Operations的组合)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营 和质量保障(QA)部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到:为了按时交付软件产品和服务,开发和运营工作必须紧密合作。”
  IBM这样说:DevOps是企业必备的持续交付能力,通过软件驱动的创新,保证组织抓住市场机会,同时减少反馈到客户的时间。
  3、DevOps不只是开发与运维的问题
  一般而言,开发与运维有着不同的文化;开发部门的驱动力通常是“频繁交付新特性”,而运维部门则更关注IT服务的可靠性和IT成本投入的效率,降低风险。两者目标的不匹配,在开发与运维部门之间造成了鸿沟,从而减慢了IT交付业务价值的速度。运维从维稳出发,自然希望生产系统部署上线次数越少越好,而上线频度降低,对开发人员是一个负激励:反正我发布的版本也不会上线,反正我再积极也不能实时的体现出来,团队积极性和人员士气都会受到打击。
  与此同时,业务部门则希望业务需求尽快的推向市场,而维稳的要求导致价值交付用户的速度被延缓,价值无法迅速得到反馈验证。
  当发布列车变成3个月一趟车次时,业务人员习惯于自己的需求无法快速得到满足,能想出的的方法就是把所有的业务需求都设置成最高优先级,去抢占发布窗口。所有人都这样想这样做,拥堵就此产生,真正高价值的需求无法得到快速交付。(试想,如果每天有十次发布,大家还会拼得头破血流去抢一个发布窗口么?)
  上线频度低的另一个副作用是,单次上线中包含的变更规模变大,风险也随之增加。事实上,减少上线次数不仅不会降低风险,反而让每一次上线都变得像一个火药桶,危机四伏。
  4、从大处着眼
  究其根本,DevOps目的是提升业务交付能力:如何快速的交付想法;如何让客户进行尝试(从而获取反馈);如何快速响应客户反馈;
  DevOps不应该只是IT内部的几个部门玩的游戏。必须跳出IT的角度,端到端(业务端到客户端)分析,才能弄清公司需要依靠IT的哪些工作来支撑业务目标,支撑企业战略 ,从而实现更完整、真正的DevOps。
  需要将IT变成一种能力,融入公司的日常运作中,融入业务活动中。在快鱼吃慢鱼的时代,需要快速试错,不断整合来自市场的反馈。
  所以最终,DevOps是一个端到端的问题,是产品管理部、开发部、测试部、IT运维部、信息安全部协同工作,共同支持。
  DevOps尝试建立一个业务价值交付管道,业务规划、需求梳理、计划、开发、构建、测试、部署、运维、监控 ,在此交付过程中涉及到的部门/团队、过程、系统、方法都归属于DevOps关心的内容。
  5、从小处下手
  理解了DevOps是一个端到端的过程,整个交付链条涉及太多的领域,问题也层出不穷,无从下嘴。实际操作中,需要有一个切入点。
  DevOps的思想以精益与敏捷为核心,通过暴露问题,解决问题,从而实现持续改进。从精益的角度看,在代码投产之前,实际上未产生任何价值,都只是半成品。 要限制半成品,即在制品(WIP)数量,让其尽快流过生产线,让投入产生交付价值。
  DevOps是一个复杂问题,我们却希望可以把一个复杂的问题简单化:正如装修时通过加压检查管道是否泄露,是否有阻塞;我们也通过加压的方式来暴露软件交付管道的问题。
  如何加压?以终为始,我们选择业务价值交付的那个点,也就是部署与发布来对整个交付管道进行加压。
  可以简单的问自己一个问题:“能不能一天部署10次?”如果没有办法?那么原因何在?流程不规范?自动化不够?沟通导致效率低下?过程无法复用?环境差异导致回归出错?逐一的暴露问题,解决问题,交付能力自然提升。
  需要注意的是,根据《凤凰项目》中提到的TOC约束理论(Theory of Constraints),在瓶颈之外的任何地方做出的改进都是假象,在瓶颈之后做的任何改进都是徒劳的,因为只能干等着瓶颈把工作传送过来,而在瓶颈之前做的任何改进则只会导致瓶颈处堆积更多的库存。所以如何识别真正的瓶颈变得尤为重要,在发现问题之后多问几个为什么,力求找到根源原因。
  DevOps的由来
  Flickr公司的约翰.阿尔斯帕瓦和保罗.哈蒙德在2009年Velocity技术大会关于开发速率的一场演讲,“一天十次部署”,是2009年前后兴起的DevOps运动的一部分,提倡开发和IT运维通力协作,在完成高频率部署的同时,提高生产环境的可靠性、稳定性、灵敏性和安全性。2009年一天十次部署就算很快了,但现在只能算平均水平,2012年亚马逊公司宣布,他们平均每天能开展23000个部署。
  Wikipedia上说,有以下几方面因素可能促使一个组织引入DevOps:
  -使用敏捷或其他软件开发过程与方法
  -业务负责人要求加快产品交付的速率 (新兴技术趋势,例如云计算、移动应用、大数据和社交媒体)
  -虚拟化和云计算基础设施(可能来自内部或外部供应商)日益普遍
  -数据中心自动化技术和配置管 理工具的普及
  -传统的管理方式导致“烟囱式自动化”,从而造成开发与运维之间的鸿沟
  6、通过加大部署/发布频度来撬动整个交付过程
  以应用部署自动化作为切入点,由部署自动化,往前倒逼测试自动化、构建自动化;进一步往前,配置管理、变更管理是基础要求;再往前,业务需求与敏捷计划同步关联,通过短周期迭代交付与反馈,加强业务与开发的协作沟通;
  同样的,往后端与运维衔接,更小、更频繁的变更,需要让开发人员更多地控制生产环境,更多地以应用程序为中心来理解基础设施;需要定义简洁明了的流程,尽可能地自动化;从而在完成高频率部署的同时,提高生产环境的可适应性,与此同时,可靠性、稳定性、弹性和安全性也同时提升;
  由此也促成了开发与运维的协作,通过不断缩减批量规模,实现快速工作流,确保了部署环境时刻准备就绪,按需投产。频繁的发布、意味着每次发布包含的变化更少,每次部署不会对生产系统造成巨大影响,应用程序会以平滑的速率逐渐生长。逐步协调和弥合开发与运维之间的技能鸿沟和沟通鸿沟。
  7、DevOps要实现:自动化、标准化、配置化
  自动化:全面自动化,构建、部署、测试、升级、扩展、维护、数据卫生、监测、安全和策略管理。通过自动化,倒逼团队高效沟通,倒逼流程规范;自动化手段确保部署任务的可重复性、减少部署出错的可能性。
  标准化:(流程,环境,配置)基础环境标准化,运行环境标准化,应用环境标准化/多样化 ;
  配置化:通过配置,尽量避免代码,通过功能开关或者参数设置,来支持A/B testing、灰度发布;
  8、DevOps实践
  不做什么比做什么更重要:相比起向系统中投入更多的工作,将无用的工作剔出系统更为重要;无用的工作,无用的项目,无用的产品;排优先级,哪些是重要的工作;
运维参与研发评审:常见的现象是,运维人员很少被邀请参与架构决策或代码评审,开发代码是否会影响运维环境前期无人知晓,需要让运维人员参与架构评审,从运维角度提出对系统的要求;
  非功能性需求同样重要:偿还技术上的债务。每个人都像重视功能性要求一样重视非功能性要求QoS(质量,稳定性,可维护性,持续性,可扩展性,可管理性,安全性,可操作性),非功能性需求对于实现业务目标同等重要。要把非功能性需求设计到产品当中。
  整体协作:产品所有者,开发部,QA,IT运维部以及信息安全部通力协作,帮助彼此乃至整个企业取得胜利。
  质量为先:上游团队不再给下游团队造成麻烦,开发部将20%的时间用于帮助确保工作顺利的通过整个价值流,加快自动化测试,改进部署基础架构,并确保所有应用程序建立有用的产品遥测;
  基础架构即代码(Infrastructure as a Code):把创建和部署流程自动化,把基础架构当成代码一样对待;各套环境之间,代码版本、运行时、环境配置需要匹配;需要将基础环境配置化、版本化管理;
  运维服务化:DevOps会让开发部门承担更多的代码部署和维持服务水平的责任。要求把许多IT运维任务转变为自助服务。
  版本化一切(Versionlize Everything):应该把所有东西都进行版本控制,不只是代码,而是创建环境所需的每一样东西。
  ITIL:为了适应DevOps更短的交付周期和更高的部署频率,ITIL流程的很多方面都需要自动化,特别是变更、配置和发布流程等。
  云计算:有效的利用云技术,可以为开发和测试人员动态设置基础架构资源,快速获得测试环境;
  针对类生产系统进行开发和测试 (环境的标准化),利用可重复的可靠流程进行部署,监控并验证运维质量;
  放大反馈回路:快速反馈回路,防止问题代码进入生产环节,并且让代码能够迅速部署投产,从而迅速发现并修复任何产品问题。(编写代码时,单元测试、集成测试、验收测试一直在类生产环境运行,不断确认,代码和环境奖会按照预先设定的运行,并且总是处于可部署状态)
  9、DevOps与云
  DevOps要支持云,虚拟化与云技术可以带来DevOps要求的标准化以及自动化;
环境标准化,无论是基础设施还是运行时环境,并把这些环境投入开发、QA和IT运维的日常使用,就能消除大部分在部署流程中因为差异而导致的问题。不仅应该拿出可部署的代码,还应该拥有部署这些代码的确切环境,并在版本控制中一并控制与检查。
混合云下的DevOps诉求:在云的场景下,如何利用虚拟化、容器等加速环境的创建以及标准化,如何通过自动化的方式加快环境搭建;如何在On-Prem、私有云、公有云,不同厂商不同类型的云的混合模式下,统一流程,统一DevOps的用户感受;
同时,由应用层的自动化部署,同样可以发现Infrastructure层, Runtime层的问题,虚拟化与云的技术也与DevOps相辅相成,相得益彰。
  10、DevOps与精益、敏捷
  DevOps是基于敏捷与精益原则的方法。DevOps是软件开发生命周期(SDLC)从瀑布式到敏捷再到精益的发展。
  DevOps超越了敏捷,它的关注点是从SDLC中移除浪费。通常情况下,发现浪费或者瓶颈的形式包括:不一致的环境,人工的构建和部署流程,差的质量,IT部门之间缺少沟通和理解,频繁的中断和等待,部分完成的工作,额外的功能,任务切换等。
DevOps强调流水线,交付管道,与传统生产与制造业有着千丝万缕的联系;而《凤凰项目》一书中直接用生产工厂来点化故事的主人公,与IT开发运维直接类比;
DevOps实施中,可以借鉴精益理论中的很多思想,例如:降低批量规模、减少半成品、缩短并增强反馈回路、价值流图分析、时间线分析、消除浪费,以及敏捷中持续集成、持续测试、持续交付、持续监控、A/B测试、灰度发布、滚动更新等;
  11、三步工作法
  《凤凰项目:一个IT运维的传奇故事》中建议的三步工作法以实现DevOps:
  第一工作法:(帮助理解在工作从开发移向IT运维时该如何建立快速工作流)从开发到IT运维再到客户的整个自左向右的工作流。为了使流量最大化,需要小的批量规模和工作间隔,绝不让缺陷流向下游工作重心,并且不断为了整体目标(相对于开发功能完成度、测试发现/修复比率或运维有效性等局部目标)进行优化。必要的做法:看板、持续构建、集成以及部署,按需创建环境,严控半成品,以及构建起能够顺利变更的安全系统和组织。
  第二工作法:(如何缩短以及放大反馈环路,从而在源头解决质量问题)价值流各阶段自右向左的快速持续反馈流,放大其效益以确保防治问题再次发生,或者更快的发现和修复问题。这样我们就能在所需支出获取或潜入知识,从源头上保证质量。必要的做法:在部署管道中的构建和测试失败时“停止生产线”;日复一日的持续改进日常工作;创建快速的自动化测试套装软件,以确保代码总是处于可部署的状态;在开发和IT运维之间建立共同的目标和共同解决问题的机制;建立普遍的产品遥测技术,让每个人都知道,代码和环境是否在按照设定运行,以及是否达到了客户的目标。
  第三工作法:(如何建立文化,技能鼓励碳酸,从失败中吸取教训,又能理解反复的时间是精通工作的先决条件)创造公司文化,带动两种风气的形成:不断创世,这需要承担风险并从成功和失败中吸取经验教训;理解重复和练习是熟练掌握的前提。不断加压,从而强化习惯并加以改进。(系统里要经常出些故障,长此以往,再遇到困难就没原来那么痛苦了)必要的做法:营造一种勇于创新、敢于保险以及高信任度的文化,把至少20%的开发和IT运维周期规划给非功能性需求,并不断鼓励进行改进。
  12、KPI与度量
  为了促进DevOps战略,调整绩效考核和激励机制是必要的,原本按各自为政的KPI考核只会造成部门之间的隔阂,依然只根据敲出代码的生产力来奖励开发人员,或者根据基础设施的可靠性来奖励运维人员,什么都无法改变;围绕业务系统而不是职责来组织工作,这就是DevOps打破IT分组壁垒的寓意。 团队一起协作,共同为他们的应用和系统负责。
  部分度量参考:
  开发应用所花费的最高时间(开发速率)
  失败部署的百分比(部署成功率)
  客户产生了多少问题(客户接受度)
  故障恢复的平均时间(团队解决故障的能力)
  用户数(用户欢迎度)
  参考资料:
  《凤凰项目:一个IT运维的传奇故事》
  百度百科
  (本文于 2016-03-01首次发布)
分享到:

免责声明:
  1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的,并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实,对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺,请浏览者仅作参考,并请自行核实相关内容。
  2、本站部分内容转载于其他网站和媒体,版权归原作者或原发布媒体所有。如文章涉及版权等问题,请联系本站,我们将在两个工作日内进行删除或修改处理。敬请谅解!

more

会议活动

more

公开课

more

PMO

Copyright © 2021 IT项目管理界 版权所有 京ICP备17062359号-4 如转载本站文章,请注明原作者和原发布媒体

本着互联网分享精神,本站部分内容转载于其他网站和媒体,如稿件涉及版权等问题,请联系本站进行删除或修改处理

客服电话:010-89506650 89504891 非工作时间可联系:18701278071(微信) QQ在线:511524637

新闻与原创文章投稿:tougao#cpmta.com 客服邮箱:info#cpmta.com(请将#换成@)

IT项目管理界——我国最大的IT项目管理门户网站,隶属卓橡公司

IT项目管理界官方微信

IT项目管理界官方微信

PMO大会官方微信

PMO大会官方微信