前言
这是一篇介绍DevOps 概念入门的文章,文章里讲解了DevOps起源、DevOps 热度走势,浅析了DevOps的到来改变了什么?如何做好 DevOps?最后为大家梳理了一些国内外DevOps/效能领域的信息源。
定义
根据维基百科的定义,DevOps是Development和Operations的组合词,是一组结合了软件开发(Dev)和IT运营( Ops)的实践,一开始的定义是一种重视软件开发人员(Dev)和IT运营(Ops)之间沟通合作的文化、运动或惯例,透过自动化「软件交付」和「架构变更」的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。它的目的是缩短系统开发生命周期,提供高质量的持续交付。DevOps与敏捷软件开发是互补的,DevOps的一些方法实践来自敏捷方法。
起源
DevOps实践中的很多基本理念都是受到制造业等领域质量、效率实践的启发,如精益和戴明的 PDCA(Plan-Do- Check-Act:计划-做-检查-行动循环)、丰田方法、分解组件和批量大小的敏捷方法。1993年,电信信息网络体系结构联盟(TINA-C)定义了一个服务生命周期模型,该模型将软件开发与(电信)服务运营相结合有人说,DevOps的出现部分是对上世纪90年代“自上而下”的ITIL禁用方法的反应。DevOps 作为一种“自底向上”的方法,因为它是由软件工程师为软件工程师创建的,并且是一种灵活的实践,而不是一个僵化的框架,所以得到了坚持和发展。
2009 年,名为 devopsdays活动的第一次会议在比利时根特举行。该会议是由比利时顾问、项目经理和敏捷实践者 Patrick Debois 创立的。很快,devopsdays 开始传播到世界各国。
热度走势
DevOps在中国搜索热度:
在2020年一年,“devops”关键字百度指数均值为1229,相比于2019年1125增涨了8.5%,2019年同比增长率是 T%(1125-1113)/1125),2020年相比2019年devops 指数增产率上升了8倍。
关键词 +原加时比德定
时间 -01-00-1-31
d
回顾过去10年,从DevOps理念刚刚传入中国到如今,DevOps指数持续增长,这其中很大原因是国内大厂(BAT等)开始重视效能,记得2017年参加DevOpsDays大会时,参会的分享者基本都是一些国企或小的互联网公司,随后几年,大量诸如阿里(云效)、腾讯(蓝鲸)等开始分享效能领域的实践,以及一些国内bocloud,teambition. leangoo. DevOps Gitee等产品面世带动效能热潮!
DevOps 改变了什么?
DevOps 的到来引进了很多优秀的实践、文化、工具,DevOps的改变,最主要的是->解决问题的视角变了!
(1)从“零散”的各自为战到“中心化”的研发体系转变
在传统的瀑布流开发模式中,虽然也有完整的需求分析-原型设计-开发-测试-部署-发布研发生命周期,但是每个研发人员都只管理着自己的一个功能模块,不同职位之间的信息传递、沟通效率、流程推进效率非常低,无法适应快速变化的互联网时代。
Waterfall Model
Waterfall model is a traditional approach
of software develcoment
Requirement Analysis
Desigr
in watertall mode!. develooment hagpen
im a step by step manner Developmer
Testing
Matenanc
DevOps第一次开始从全局视角研究整个研发生命周期的效前,推动了很多优秀的DevOps Tools不断演进
(2)目标“共驱感”更强
在传统的研发流程中,不同人员是由不同的目标驱动的:开发是由功能性需求(通常与业务需求直接相关)驱动的。测试是由 BUG性需求(寻找功能缺陷)驱动的
运维是由稳定性(非功能性)需求(例如可获得性、可靠性、性能等驱动的。
,不同人员的目标差异性,导致整个研发效率提升不可避免的隔阂。
在历史的研发流程中,开发人员对配置或环境进行修改之后,经常没有及时与运维人员沟通,导致新的代码不能运行,开发人员可能不考虑自己写的代码会对运维造成什么影响。他们在交付代码之前,并不邀请运维人员参与架构决策或代码评审;由于运维人员尝试避免变更,新功能流入生产环境的速度因此被延缓,从而延缓了开发人员将特性交付给用户使用的速度,运维人员可能对应用程序内部缺乏了解,从而难以正确地选择运行时环境和发布流程。
而DevOps通过CVCD 工具、测试实践(TDD)、敏捷站会等等一切有用的手段,降低开发使用测试、运维工具的成本,增加开发、测试、运维的沟通频次,将问题前置,让开发提前感知代码质量、风险,提高DevOps整体效能目标的共
同时,通过俯视整个研发生命周期,基于DevOpa的工具、文化、实践,会让我们重新思考,重塑研发流程甚至是职位。我们真的需要那么多的测试嘛?能让降低开发去做运维的成本嘛?一个高效的研发组织合理的结构是什么样的?反正肯定不是一成不变的。
比如微软在早期的开发、测试、PM比例是1:1:0.5,其中将测试分为了两个独立的角色。分别是SDETs(负责测试基础设施软件设计的工程师)和STEs(主要负责运行自动化或手工测试的软件测试工程师),通过这种模式产生了像
Windows.Ofice等大型商业化优秀产品,这种模式的好处是产品的交付流程和质量都非常正式标准。但是坏处也非常明显,由于设立了较长的研发、测试流程,问题发现反馈周期也变得很长,很多问题无法及时修正,大量技术债被隐藏了。所以微软移除了 STEs 角色,使得SDETs不仅负责开发测试,而且负责运行和维护自动化。(引自How Does Microsof Do DevOps)
(3)个人对整体生命周期的感知更多,不再是螺丝钉的机会
基于优秀的DevOpsTooschain+一整文化实践,相比于以前的瀑布式开发流程,个人可以更低成本的完成一个传统研发团队才能完成的事情(开发,测试、发布、监控等)。
DevOps也对开发同学提出了更高的要求,不要轻易拒绝新的工具,我们需要不断学习新的好用的效能工具,来不断提升研发过程的效率和体验。
如何做好DevOps
,"长期”体验
一定要深入到到研发一线,长期体验一线整个研发链路的各种问题,走一次新应用上线、深入到日常的流程审批、测试、Coding、CodeReview、发布等等的细节中,才能对研发过程的效能问题有更深的体感,除了亲自体验,工单回溯就是非常好的方法。
(2)敢于打破“常规"思维
来到蚂蚁3年多,时常听见“以前是这么做的”、“以前流程就是这样的”,一些系统、规则早已经失去了其早期定义的意义,丧失了实践作用,需要有人站出来提出质疑,做出改变。
质量分设置是否合理、审批流程是否合理等等。我们要敢于打破研发链路各种不合理的流程、不合理的规则,我们要勇于去修复技术债,提出质疑,基于一线实践,做出真正的更好体验、更高效率的产品。
(3)善用“杠杆”思维
做好 DevOps是所有研发工程师的事情,不是某个团队的事情。
优秀的个人一定是自驱动的,优秀的团队亦是如此,研发效能团队需要做的事情不是帮研发同学把所有研发过程的事情全部做好,而是要做降低一线同学参与DevOps和效能建设的成本事情,开源产品核心能力、通过做一些典型优秀实践和一些优秀工具来推动更大范围的实践,来让更多的团队重视并参与效能的建设。
目前有一个不好的现象,不少研发效能的同学大量时间沉没在咨询工单中,并且大量是重复性的工单,这时我们需要非常警惕,一定要逼着自己推出一些时间,来思考如何改进产品,如何通过"杠杆“思维来“拉着”一线研发或团队一起来解决研发链路的各种问题。
(4)能让一线有"辛福”感
还记得3年多前刚来研发效能部,龙哥带领大家一起提出的效能slogan ->“提高研发的辛福感”,我认为这点这一点非常重要(当然也很难),DevOps/研发效能的长期发展一定需要有“温度”,能让研发同学高频的进入“心流”状态,减少工作打断,减少不合理的加班,才能让更多研发自内心的提高研发效率,也是团队效能可持续性的催化剂。
DevOps信息源
从事效能行业,专业的分析前提是需要大量专业的输入,这里抛砖为大家整理了DevOps/效能领域国内外很多资科,有兴趣可以参考参考。
会抽空每周末分享一篇国内:外效前动态、效能概
效能业界动态周刊 念普及等文章,目前不鸽车89.3%(已持续分
享28周,满3周)
阿重系研发效能文章收录 持续收集阿里系相关效销交章,不定期更新
翻译了 List of DevOps Blogs and Rescurces
史上最全 DevOps 学习资源 for Learning,这篇文章收录了大量DevOps资
源
2020最佳DavOps社区和工具 原文ModiaOps Announces the 2020 DivOps
Dozen Awards Honorees
devopsdays 动态 devopsdays 官网,全国各地DevOps 活动最新
引用
[1].DevOps Wkipedia,传送门[2]. devopsdays官网,传送门[3].devops 百度指数,传送门
4.How Does Microsoft Do DevOps,传送门
[5.3000帧定格动画告诉你什么是DevOps,传送门
[6]. Introduction To DevOps| Devops Tutorial For Boginners | DevOps Training For Beginners |Simplleam 传送门[7].DevOps Roadmap 2021-How to become a DevOps Engineer?
END