DevOps-实践心得

基于最近几年从事与DevOps的相关实践,对这篇文章的观点深有体会,所以记录在这里。加粗部分是我比较深有体会的,但是对于最后作者对于“运维”有些悲观,我有点不敢苟同,反而对于运维的要求其实是更高了,”自动化-容器化-集群-智能化“代替了传统的“人肉”

1. DevOps 的本质

DevOps从本质来讲只是倡导开发运维一体化的理念(MindSet)。这个理念的提出是为了解决很多企业面临的转型挑战,也就是将业务数字化,并且缩短数字化业务上线的周期,快速试错,快速占领市场。

DevOps并没有改变固有的软件生命周期:需求,设计,开发,测试,交付。但伴随着基础设施,软件设计方法等的改变,软件开发的思路,或者方式产生了比较大的变化。

DevOps带来的最大好处是,软件生命周期数据链路的打通

这不仅仅是运维和开发的结合。从顶层视角看,这是业务和生产的紧密结合。以前从业务和开发是脱节的。想要查看需求的实现进度,需要大量的人工汇报,更别提运营了。而现在以一个微服务实现一个特性的粒度来看,可以从需求,开发,测试,部署一直追溯到这个特性运营情况。这也是DevOps成为数字化企业基因的原因,业务和生产实现了完美的结合。

从敏捷实践的角度来讲,你会发现开发组织中参与者好似生物体中的神经元,大家各司其职,自成一体,接受反馈,并向外主动反馈。团队的自组织使得工作更加自然,能产生更大的效能。由以前的项目经理驱动,改为自我驱动的协作方式。每个人都可以给相关的团队以及责任人提需求,大家有机的协调在一起。

2. 一个DevOps改造案例

这里给大家分享一个改造案例,公司A存在的问题:

  1. 软件交付周期很长,一年只能交付一个大版本,以及一个小版本。
  2. 人员分工不明确,一个决定的做出往往需要很多人参与。
  3. 用大量的时间挖掘需求。在真正的开发期,会发现用户的需求仍在改变。需求分析的时间被浪费。
  4. 采用瀑布模式开发,在不同时期,某些角色的人员会无事可做。
  5. 在软件交付过程中,开发与运维人员需要花费大量的时间去协调产品安装,配置中出现的问题。

改造步骤:

  • 第一阶段:
    行动:为了实行DevOps,公司A为不同的生命周期购置了支撑工具,涵盖JIRA,PagerDuty,GitHubEnterprise,Jenkins等。公司针对每个工具都进行了专门培训,专人管理。

    结果:大家开始将不同的工具应用到软件生产的各个环节中,统一的工具塑造了统一的工作方式,创造了工作契约。统一工具的运用确实对软件交付带来了一些积极的改变。

  • 第二阶段:

    问题:各个工具仍旧是割裂的,代码管理和任务管理无法协调。开发人员声明已经完成的工作,测试人员却发现无法找到构建来完成测试。运维人员和开发人员只是利用了同一种工具,而没有做到工作产物的共享。

    行动:公司A开始关注工具所提供的能力而不是功能,将不同工具的关键交付物连接起来,形成可追溯的管理。开发人员发现提交的代码可以产生可用构建后才声明功能完成。并且用同一个任务来追溯开发到上线的工作。尤在开发与运维结合方面,运维人员可以利用开发人员已经实现的部署设计,进行发布演练,确保软件平滑交付。

  • 第三阶段:

    问题:有了好的工具,但是公司A发现虽然开发到运维的路通了,但是软件质量却难以保证,甚至在产品发布日期邻近的时候,仍有很多未完成的任务,测试团队顶着很大的压力,最终还是会发生不少测试逃逸,产品的技术欠债比较大。

    行动:在开发阶段采取分支开发的方法,功能实现并且通过一定的代码测试之后才能合并到主干。开发人员负责部分的测试任务,由于对产品比较熟悉,所以加快了测试效率。专门的测试团队会承担例如性能测试等更加专业的测试任务。有节奏的控制软件开发的进度,在软件发布的稳定期严格控制代码提交,每个新功能的开发负责人会和运维人员一起进行发布演练,DevOps的好处终于开始见效。

  • 第四阶段:
    问题:团队前期在需求分析中会花费大量的时间进行文档编写,但开发开始后,开发人员会花费大量的时间对文档进行理解,并且用户对需求的调整最终导致文档失去维护的意义;大家的主动性不强,需要领导的督促才能进行工作安排。

    行动:公司A意识到他们之前只是采用看似敏捷的方式,实际瀑布的方式做开发。比如说项目经理变成了Scrum主管,周会变成了每天的站会。在进行调研分析后,公司A决定开始进行敏捷实践。分阶段的按照重要程度以及优先级进行需求规划,周期性的互动使得客户在第一时间可以看到期望的需求被逐步实现,双方都避免最后一科的意外。开发人员发现可以对自己负责的任务有话语权之后,大大激发了积极性,大家开始主动的从Backlog中寻找重要的任务去实现。

从以上的例子可以看出,一个好工具的运用会对工作产生积极的影响,但是更核心的是人做事思维,以及人与人之间的协作方式才会体现DevOps的好处,我想从这点大家可以看到为什么DevOps是一种Mindset。

3. 微服务、容器和DevOps的关系

微服务只是一种设计思路,或者说他给出了如何用正确的方法来进行SOA的实施。理论上来讲他的确和DevOps没什么关系,但是从如何实践DevOps的角度来讲,微服务是非常有意义的。此外,随着诸如Spring Cloud以及微软Fabric等SDK的完善,微服务开发模式也逐步完善,实现了概念的落地

Docker可谓是一种敏捷化的虚拟化技术(较之虚拟机而言)。其实微软Fabric或者CloudFoundry也都脱离开容器的概念提供了微服务开发的解决方案,所以这两者并不是强绑定的关系。但是容器用不可变配置架构实现了微服务从开发到运维的质量保真度,这恰好解决了粒度小,数量多的微服务所带来的运维难题。再加上K8S,Swarm等容器云的支持,docker容器已经形成了事实上的标准。

如何利用这个强大的运行环境帮助企业敏捷,推进业务数字化,并且加快业务的投产? DevOps为上面所说的开发模式提供了软件生产线。

所以总结的来讲,企业业务敏捷是DevOps发展的直接推动力,容器云,以及微服务为DevOps提供了技术可行性。而敏捷帮助提高DevOps工作效能。

对于团队的拆分,这个问题真的要结合产品规模来看。团队的拆分有很多办法,贝索斯说的two pizza team,是建议一个团队中的人尽可能少,不要超过两个Pizza能吃饱的规模。用敏捷实践来讲,可以分为多个特性团队,以及维护团队,不同的团队各司其职,合理分工。在我以前的实践中,三个人可以做一个Feature,来交付一个月迭代的工作量。

当然将原有的巨石应用分割成更小的微服务是挑战很大的事情。因为理论上的微服务的设计对现有的团队组织结构,以及工程师设计能力都带来了一定的挑战。有些组织按照DDD(领域驱动的设计)的方式去实践微服务,会发现以前一个应用的复杂度变得很高,对项目管理来讲也是一件头疼的事情。现在有个比较新的看法就是,大家宣称做微服务(MicroService)的时候,实际上做的是迷你服务(MiniService)。迷你服务的粒度较之微服务的粒度更粗一些,关注度由一个域Domain,变成了能力。一个迷你服务提供一种能力,这种能力的提供也许是跨越多个域的。

最好的方法是以一个团队能承担的任务划定微服务的界限比较好,这样以来,不论是任务管理,代码构建,产品部署都会比较好做。

更关注服务的能力,这样也会减少因为跨域而带来的复杂事物处理

4. 为什么落地DevOps还是那么难?

我认为DevOps概念对市场的教育工作已经完成了,并且它宣传在国内有点泛滥的趋势,甚至一些以前做项目管理工具的厂商也宣传他们在做DevOps。究其原因在于DevOps的概念太大,几乎可以成为软件工程的代名词。

至于落地的痛点,我觉得有以下几个:

  1. DevOps对于组织来讲是一个系统工程化的投入,在贯彻的过程中,需要一个组织建立标准,统一纪律,而这个过程往往需要组织中的强力部门自始至终的贯彻执行

  2. DevOps对组织现存的管理方式,或者人员知识结构多少带来了一些挑战。

  3. 认为购置了工具就是DevOps,却忽略了工具产物之间的联系。

  4. 认为有了全生命周期的工具就是DevOps,忽略了软件过程方法的运用,所以很多组织停留在用旧的方法使用新的工具上

开启DevOps工具和文化缺一不可。DevOps的最高目标是让组织内的人都具有相同的工作理念,最终形成一种工作文化。而有些倡导者谈到如何去培养这种文化就显得有点空谈了。我认为在形成DevOps文化的过程中,敏捷实践必不可少。过去的敏捷实践更多的是在开发阶段,而现在DevOps的理念下,其实可以很顺畅的将部署阶段的事情也纳入敏捷实践中。让合适的人去做合适的事。当然团队文化的改变需要一个过程。

我认为以敏捷方法为核心配合以下三个方面来开启DevOps。

  • 看板:以任务的状态为核心,管理在制品的生产情况。任务是自组织团队的工作契约。

  • 基线:以工件的版本为核心,选取合格的交付物。比如说开发团队决定哪个代码提交版本,或者编译的构建版本为最终交付的版本。度量指导基线的产生。

  • 流水线:以生命周期的阶段为核心,控制基线交付物的投产。比如说一个合格的代码基线目前处于编译态,还是部署态。自动化工具围绕管道互相集成。

其实工具和文化最终的落实还是要靠人的提高,特别是通过上一段举出的例子。

DevOps会重新塑造IT组织的研发系统,从工具到文化,再到方法。因此参与这个生态系统的所有人都应该关注。

  • 从开发的角度看:开发人员会变得更加业务化,有更多的机会和客户交流。开发人员将从以前对代码负责,转向编译构建负责,对测试负责,甚至对部署物负责。敏捷可以让需求足够的小,这样就可以让一个开发人员变得全生命周期化了。

  • 从运维的角度看:其实运维的前景是有些悲观了,至少运维的规模要缩减很多。

    原因有三。首先,自动化部署工具的发展,使得部署工作提前了,以前碎片化的脚本,被更加规范化的部署设计代替,用设计驱动脚本生成,这都是自动化的。其次,基础环境的改善使得开发环境和生产环境的差异性极大缩小了,企业完全可以制造一个和生产环境一样的预发环境,来保证交付的成功率。容器技术的不可变配置也保证了同样的镜像在不同的环境中不会出现太大的差异。最后,运维工作相对开发工作来讲,可以自动化,甚至运用人工智能的空间都比较大。我们已经看到百度已经开始AIOps。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


前言我们于2022年5月宣布推出 AmazonDevOpsGuruforServerless ,这是面向AmazonDevOpsGuru https://aws.amazon.com/devops-guru/的全新功能。通过此功能,开发人员能够提高无服务器应用程序的运行性能和可用性。该产品链接可点击:https://aws.amazon.com/devops-guru/fe
GIT、GITLAB、GITHUB、GITLIBGit是一款免费、开源的分布式版本控制系统,用于敏捷高效地处理任何或小或大的项目。Git是一个开源的分布式版本控制系统,可以有效、高速的处理从很小到非常大的项目版本管理。Github - 一个网站,提供给用户空间创建git仓储,保存用户的一些数据文档或者代码等作为开源代码库以及版本控制系统,Github目前拥有140多万开发者用户。随着越来越...
初识JFrog Artifactory背景在软件项目开发中,一个项目常常依赖于大量的外部库,而这些外部库又在不断的进行版本更新,特别是在当前微服务开发越来越流行的情况下,一个服务依赖于多个服务,如何管理依赖库以及依赖版本,确保开发有序进行呢?JFrog ArtiFactoryArtiFactory是一款二进制存储管理工具,用来管理构建构建工具(如:gradle)等所依赖的二进制仓库,以方...
在删除文件夹的时候,可能会遇到文件夹正在使用,操作无法完成,因为其中的文件,或文件夹已在另一个程序中打开,请关闭该文件夹或或文件,然后重试。这类无法关闭删除文件夹的情况,如下图所示。 解决这个的关键是,找到是哪个程序在使用该文件夹,把这个程序关闭掉就行了。 但有时说实在的并不好找。 下面来介绍一个方便的找到这些程序的方法。 首先按ctrl+shitf+esc快捷键,打开任务管理器。然后...
xcopy 若目标盘上不存在此子目录,而在目标盘的结束符又不以""为结束,则将提示:does destination specify a file name or directory name on the target[f=file,d=directory]?在目标盘上创建文件[按下]还是创建子目录[按下d] ?应选择d键如何在命令中指定copy的是一个文件或者目录?而不用再手动输入F或...
DevOps软件开发工艺解读随着业务复杂化和人员的增加,开发人员和运维人员逐渐演化成两个独立的部门,他们工作地点分离,工具链不同,业务目标也有差异,这使得他们之间出现一条鸿沟。而发布软件就是将一个软件想从鸿沟的这边送去那边,这之中困难重重。另一方面,行业竞争更加激烈,无论是客户还是公司自身,都要求软件能快速发布,频繁修改,而上边所说的这种隔阂,阻碍了开发团队的生产力,成了企业亟待解决的难题。面对...
创建任务创建任务比较简单,这里我们创建自由风格项目:General信息这里填写项目或任务的基本信息,如下:GitBucket这里我们用到的就以下两点,一个是参数化构建:构建的时候可以指定部分参数,比如这里我们这里指定要构建的分支作参数,第二个是丢弃旧的构建:这样每次构建都会丢弃之前历史构建,防止jenkins构建项目过多导致内存泄漏等问题:源码管理源码管理主要是填写我们要构建的...
一、在任务设置-构建触发器模块,选中“Build periodically”二、然后在日程表里输入你的定时构建时间,输入的时间语法参考如下:1、时间字段遵循cron的语法,每行由TAB或空格分隔的5个字段组成:MINUTE HOUR DOM MONOW DOW - 分钟:小时内的分钟数(0-59) - 小时 :一天中的小时(0-23) - DOM:月份的日子(1-31) ...
DevOps进阶(九)使用assembly plugin实现自定义打包assembly plugin的使用方式比较简单,主要有:1. 修改pom.xml pom.xml中设置如下:<build> <plugins> <plugin> <artifactId&g
<h2 id="1-操作环境"><strong>1. 操作环境</strong></h2>1. Windows:win72. JenkinsJenkins 1.6193. JavaJDK_1.7.0_64bit.exe4. Tomcatapache-tomcat-8.
在使用linux时,经常需要进行文件查找。其中查找的命令主要有find和grep。两个命令是有区的。区别:(1)find命令是根据文件的属性进行查找,如文件名,文件大小,所有者,所属组,是否为空,访问时间,修改时间等。(2)grep是根据文件的内容进行查找,会对文件的每一行按照给定的模式(patter)进行匹配查找。一.find命令基本格式:find path expres......
走近DevOps工程师我们之前已经听到很多谈论DevOps和DevOps世界的最新趋势的事情,但是就DevOps工程师本身,到底干些什么呢?在最纯粹的存在形式上来说,DevOps工程师是为了加快开发和运营团队之间的交付效率而存在的桥梁。DevOps工程师在软件生命周期中能带来什么?在传统的交付周期中,软件开发人员会在经年累月的编写代码后,将软件交给QA团队进行测试,然后将最终版本交给运营...
1、关闭Jenkins 只需要在访问jenkins服务器的网址url地址后加上exit。例如我jenkins的地址http://localhost:8080/,那么我只需要在浏览器地址栏上敲下http://localhost:8080/exit 网址就能关闭jenkins服务.2、重启Jenkieshttp://localhost:8080/restart3、重新加载配置信息http...
   我们在执行Jenkins的项目构建的时候一般都是通过web管理界面中的”构建”来执行项目构建操作,但是除此之外我们还可以通过项目配置中的”构建触发器”来触发构建操作,其中”构建触发器”有一种方式是通过配置令牌远程触发项目构建;要启用Token(令牌)远程触发项目构建首先要保证Jenkins服务安装了build-token-root 插件,...
maven三种打包插件maven有多种可以打包的插件,如下: plugin function 官网 maven-jar-plugin maven 默认打包插件,用来创建 project jar maven-shade-plugin 用来打可执行包,executable(fat) jar http://maven.apache.org/plug...
Linux下查看和添加环境变量$PATH:决定了shell将到哪些目录中寻找命令或程序,PATH的值是一系列目录,当您运行一个程序时,Linux在这些目录下进行搜寻编译链接。编辑你的 PATH 声明,其格式为:PATH=$PATH:<PATH 1>:<PATH 2>:<PATH 3>:------:你可以自己加上指定的路径,中间用冒号隔开。环境变量更改后......
贾磊:高级质量经理&敏捷教练曾就职于外企、国企、大型上市企业等,担任过测试工程师、测试经理、项目经理、敏捷教练、质量总监、高级质量经理等岗位。是一名敏捷变革的爱好者和践行者。爱好网球、羽毛球。正文原文链接:https://www.scaledagileframework.com/continuous-explorati
在IT流行语的字母组合中,DevSecOps是一个很容易让人混淆的缩写。DevSecOps是一个特定工具吗?是否有DevSecOps流程或最佳实践?DevSecOps应该成为内部IT部门的优先事项,还是更广泛的公司理念?如果一个公司已经利用了DevOps的流程和技术栈,那么它应该升级到DevSecOps吗?或者这只
企业项目开发流程商城1.1B2C直销商城商家与会员直接交易(BusinessToCustomer)1.2B2B批发商城商家与商家直接交易1.3B2B2C购物平台商家和会员在另一个商家提供的平台上面进行交易1.4C2B定制商城会员向商家发起定制商品的需求,商家去完成。1.5O2O线上线下
jenkins清除工作空间报错 错误如下: Error:WipeOutWorkspaceblockedbySCM   解决方法:进入jenkins服务器,进入workspace,手动rmcd/var/jenkins_home/workspace  ===================注释==================如果你的启动命令如下:【进行了外部目录的挂载