软件世界的战场

如果你对devops的概念不是很了解的话,没有关系,可以先跳到维基百科阅读一下DevOps条目。有了模模糊糊的概念之后, 我们先抛开所有市面上对于devops的各种夸大和炒作,首先来思考一下为什么近年来会出现这么一个职位。

在软件开发中,一个人可以孤军奋战身兼数职:产品设计,开发,测试,运维等等。无需考虑多人协作带来的沟通成本,很好地控制项目进度。

可惜,这种美好景象仅在小项目或者项目初期会出现,一个优秀的产品往往是由众多子项目组成,是一个庞大的系统工程,需要多人的协作才能使之如期交付。

在一个公司的研发部门中,每一个项目常常会涉及到开发团队,测试团队,运维团队。项目leader在设计好架构和确定技术路线之后,会将开发任务按功能和模块分给开发团队,开发人员完成开发后,交给测试人员进行测试,反复迭代直到通过集成测试完成预期目标,交给运维团队去完成产品的交付或上线。期间会有项目经理持续跟踪进度。是曾相识么,这就是软件公司以及互联网公司中最常见的软件开发的场景了。

这个过程看上去不是挺不错的么,有什么问题?

问题很大,就像是在谈现实和理想。

首先,技术主管给出的架构并不是那么合理,并且也没有做到把业务完全解耦和模块化,在开发过程中,才发现那些看似相互独立的开发工作,还有强依赖关系。

接着,在给出的技术路线中使用了一些很cool的语言,开发框架,设计模式,但是暗中布满了密密麻麻还没跌过的坑,留下了运维隐患。在随后的线上运维中,相关的开发/运维人员发现了一些很诡异的现象却只能抓耳挠腮。

然后,开发人员的水平参差不齐,在随手写出惊为天书的代码的同时,还免费附赠了一堆已知和未知的bug,导致后人在接替工作或维护的时候,几乎看不懂前人留下的神奇符号,然后就是重构,重构,重构。

同时,代码的版本管理毫无章法,最终在部署的时候出现了大量问题。

随后,测试人员拿到刚出炉的代码后直呼开发人员坑爹却没能力挽狂澜擒下所有臭虫,留下了一些未知的bug,这些彩蛋将会伴随着运维人员手机上的午夜凶铃逐一浮现。

终于到了集成的日子,每个小组拿着子系统/模块/组件ABCDE进行整合,跑集成测试的时候发现了各种不可预料的问题,原定本周交付的项目突然变得无法预期。

最后,代码终于到了运维人员的手里,接力棒到了最后一公里,这里将会是最混乱的战场:运维人员参考开发人员给出的部署文档,进行部署,可惜有些开发人员的文档写得很烂,更多的是不写文档,跑过来递给运维人员一支芙蓉王,你只需要执行我精心准备的start.sh就可以运行了。接着,运维人员对软件进行编译,打包,有时被后面虎视眈眈的项目经理逼得丢弃了节操,怎么快捷就怎么来,KPI is more important,直接上源码。在经过几次测试后,胆战心惊地把软件交付给了客户,或是将服务上线。

那么,接力棒传送就此结束了吗? 在随后的日子里,运维人员每晚都会被该死的报警短信吵醒,为了业务赶紧恢复正常,开发人员测试也没写赶紧把bug hotfix了,有的甚至直接在线上环境就进行了修改。

接着大家就睡觉了,一觉起来的时候已经忘记了昨晚发生的一切,直到某日,开发人员把新的升级包部署上去,结果旧bug又复活了,同时新版本又引入了新的bug,服务无法正常启动。运维人员需要进行回滚操作,但是预先就没有考虑回滚策略,只好手动进行回滚操作,却发现数据库表格式居然也变了…

另外一边的世界是客户的浏览器:503 Service UnAvailable。 卧槽,这是什么破网站。

然后Boss在听完业务部经理的汇报后,怒气冲冲地召集了研发部的所有老大们。研发,测试,运维的老大们开始了激烈的相互吐槽...

全剧终。

我们该怎么办

大量的事实表明,在大型企业中会滋生更多的“我们 VS 他们”的部落文化而阻碍了生产力。而且这些部落文化并不仅限于“开发 VS 运维”,同时也存在于“产品 VS 销售”,“市场 VS 开发”以及“开发 VS 质量保证”等。

在实际的场景中,开发组老大为了争取在XX技术会议上吹嘘一番,总是乐于往新版本里引入新技术新框架,加入尽可能多的新特性;而运维组老大出于对运维稳定性的考虑,总是倾向于变化越少越好。项目经理则总是希望开发进度越快越好,为了进度不停逼迫开发人员砍掉一些测试,等等等。

如果,我是说如果:

如果,负责架构的哥们,可以把解耦做得再好点。

如果,负责技术路线的哥们,可以从运维的角度出发,多使用一些成熟的技术。

如果,开发人员再努力一些,提高本身的代码质量。

如果,测试人员的覆盖率再高一些,多捉住几只臭虫。

如果,运维人员再经验丰富一些,熟悉市面上所有主流和新兴的技术,会使用先进的自动化工具来进行部署和监控。

可惜,没有如果。

对于架构的设计需要长时间高强度的积累,不是用心就能做到完美的。

新技术的使用将会提高生产力,同时带来潜在的隐患,仅通过数天时间的技术调研而不深入使用是无法断言手上正握着的双刃剑到底是哪一面对着自己。

开发人员的水平是受诸多因素影响的,你不可能对着最牛逼的那个开发者按ctrl+c,ctrl+v。

测试只是减少故障发生的概率,而不能避免没有bug。

同样的,运维人员也不可能对于每种技术细节了如指掌。

你应该干什么

上述是我们很难去改变的。

但是

这时候你出现了,大吼一声我是DevOps。

别人以看外星人的眼神瞪着你:DevOps这个职位存在的意思是什么?

我们的存在是为了团队的和谐和幸福。

我们现在都很苦逼,你能帮助我们摆脱这种困境?

我们将会采用统一的规约和完善的工具链来改善当前的僵局。

统一的代码管理

首先在代码的版本控制上必须有一个统一标准,细致到仓库的命名和分类,代码分支的规约以及软件的发布周期管理都必须有一个统一规范来约束。

为什么这需要由DevOps来做?首先,研发、测试和运维部门都是会涉及到代码的管理,因此需要有人来统一所有部门的代码管理,其次在版本控制和分支开发规范上,使得所有人员只需要阅读同一份文档,就可以完成相应的协同工作,例如某开发小组喜欢用master作为develop分支,而其他小组则用master分支作为production分支,这将导致运维人员在部署时就需要分散精力去区别对待。

严格的代码审查机制

其次在代码的质量上,引入代码审查机制,让有经验的开发人员来审查其他人的代码,从而来减少bug,提高代码的质量。

当然人工审查并不能保证代码的万无一失,在每次代码提交中,就应该附带相应的测试代码,通过自动化的测试工具,确保每次提交的代码逻辑上符合期望。

同时,将只有通过了测试和人工审查的代码入库并打包。

频繁的集成构建

从项目可以进行集成的当天起,所有项目将被进行频繁地集成构建,运行单元测试,功能测试,人肉测试等等,并将构建失败的错误日志发送给相关人员,然后找出导致这次集成失败的原因,并且必须在当天解决。

频繁的集成构建把留到最终的集成风险平摊到了每一天,使得项目的开发进度变得可控。

生产环境的所有操作拒绝人工干预

我们将使用生命周期管理和系统配置管理工具编写部署代码,在编写这些脚本前,你需要和开发/运维人员反复地沟通,在规范问题上不要做任何的妥协,直到完成目标。最后将这些部署代码交付给运维人员,所有的软件部署通过工具自动完成而无需人工干预。

加强各小组间的沟通

在软件开发的整个流程中,开发不懂运维,运维不懂开发是很常见的事情,因为我们要加强各小组间的沟通,我们会去了解DBA们为什么会讨厌那几个做后端的开发人员,运维人员为什么会在埋怨某个项目的部署。

这里我隐藏了许多细节,从大体上给出了DevOps的主要职责所在。

看到这里,你应该会眼前一亮,devops的职责之一是规范,规范是保证团队协作有序进行的先决条件。

其次使用持续集成工具链如Gitlab,Jenkins,Gerrit,Foreman,Puppet等来替代人工操作,使用自动化的方法来减少重复劳动和避免人为造成的失误。

另外一个重要工作是沟通,促进各种团队间的协作。

我们需要专职的DevOps人员吗

如果你发现你已经在做上述事情中的某一些时,其实你已经在做devops相关的工作了。那么是否可以让众人各领相应的活儿,而不需要设这么一个职位?

我的回答是不可以。

一个职位对应着一份职责。

如果你是一个开发人员,运维小组的代码管理混乱你会去关心吗,你会为此负责吗?

如果你是一个运维人员,开发小组的代码没有人审查也没有跑测试就推到仓库中,你会去关心,你会为此负责吗?

但是如果你是devops人员,你必须纠正混乱的代码管理,你必须在源头上掐死没有人工审查和没有跑过测试的代码提交。

所以,我们需要一个负责devops的人员。

不过我并不赞同在一个小团队中设置一个专职的devops人员,在我看来,一个devops工程师,首先他得是一个合格的开发/测试/运维人员,devops表明他还担负着另一个重要的职责。

因为,假如devops脱离了实际的岗位,就犹如纸上谈兵一般,无法触碰团队中的痛点,就无法解决实际问题。

因此,一个“兼职”的devops才是我心目中理想的devops工程师。

关于Top

很庆幸你能耐着性子能阅读到这里,如果能胜任以上工作,恭喜你,你就是一个合格的DevOps工程师了。

等等,文章的题目不是写着如何成为一名Top DevOps Engineer么?!

额,我不认为想要成为顶级的Devops工程师仅仅通过阅读一篇陈词滥调的文章就能够速成的。实际上devops的活儿并不好做,作为devops必须强势,必须有话语权,否则你怎么去摆平研发,测试,运维组;作为devops必须熟悉甚至精通每个领域,否则你怎么去制定一套规范合理的规约;作为devops必须熟悉各种持续集成的工具,否则你怎么挑选符合团队实际需求的工具链;作为devops必须善于交流,否则你怎么去掌握每个人的真实想法。在成为一名devops之前,你应该有计划地把精力投入到Dev,Test和Ops各个领域,站在他们的角度来思考问题,然后再回到DevOps的位子上来,再去rethink应该怎么做。

DevOps需要你去不断地尝试和调整,不要害怕失败和挫折,它们是积累宝贵经验的源泉,但是绝对不要在同样的坑里摔倒第二遍。 我喜欢这句话:所谓专家,就是在一个很小的领域里把所有错误都犯过了的人。

写于初春的午夜

如何成为一名Top DevOps Engineer相关推荐

  1. 怎样成为一名A“.NET研究”ndroid开发者

    Chris(克里斯)是一位来自波兰的Androi上海企业网站设计与制作d应用开发者,作为一名非著名的开发者,他开发的应用在Android Market上免费提供下载,并通过广告获得收入,最近他在自己的 ...

  2. 如何成为一名Web前端开发人员?入行学习完整指南

    经过如此多的试验和测试,而不是说你从头开始创建了所有内容,接着,你在网页上创建了第一个登录表单时,你感觉如何? 经过了多次更改后,将布局分配给第一个Web应用程序时感觉如何? 当成功处理了数千个用户的 ...

  3. 如何成为一名Web前端开发人员?

    如何成为一名Web前端开发人员? 文章目录 如何成为一名Web前端开发人员? 1.首先确定你的目标或道路 2. Web开发的基本工具和软件 3.从HTML和CSS开始 4. 响应式布局 5. 自定义可 ...

  4. 英语很差,可能不会阻止你成为一名程序员,但一定会限制你成为一名“优秀的”程序员...

    作者 l 会点代码的大叔(CodeDaShu) 我在很多平台上发表技术类的文章,收到过很多朋友的私信,问一些技术类和程序员职业发展类的问题,常见的问题比如"我已经 XX 岁了,想转行做程序员 ...

  5. linux系统编程需要什么,若想成为一名Linux下编程高手,必须能对各种系统调用有透彻的了解...

    原标题:若想成为一名Linux下编程高手,必须能对各种系统调用有透彻的了解 什么是系统调用? Linux内核中设置了一组用于实现各种系统功能的子程序,称为系统调用.用户可以通过系统调用命令在自己的应用 ...

  6. python程序员工作怎样-怎样才能成为一名Python程序员

    随着互联网的不断发展,从事IT行的的人越来越多,近几年用Python编程的程序员更是十分火爆,有些人是看中Python语言的优势,有些人是看中Python程序员的人才缺口,为将来的就业和职业发展做好准 ...

  7. java里面如何加入高级的东西_如何成为一名Java高级架构师

    近些年来互联网快速发展,现阶段的数据量和高并发的诉求,引起了不少传统的技术人员的力不从心,企业愈发关注到了系统架构的重要性,既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的领导型人物 ...

  8. 【ios】如何成为一名ios开发

    https://medium.com/app-coder-io/10-steps-to-become-a-professional-ios-developer-11b82b6aea4c 本文列出了成为 ...

  9. ta leader是什么岗位_阿里专家:如何成为一名“值得跟”的Leader?

    有时会听到小伙伴,吐槽自己的现任或前任直接主管.随着工作时间和经验的增长,每每看到这种吐槽,我就会反思,假设有一天我是那位被吐槽的主管,我就一定能做的更好吗? 图片来自 Pexels 如果自己不敢 S ...

最新文章

  1. 电脑识别指令和代码的原理
  2. 机器学习在信道建模中的应用综述
  3. qq邮箱格式的Java代码_Java实现QQ邮件发送
  4. 【毕业求职季】-听说你想去大厂看学妹,带你看看腾讯微信产品岗面经(已offer)
  5. Openlayers中实现地图上添加一条红色直线
  6. Verilog功能模块 —— 按键消抖
  7. 如何诊断ORA-125XX连接问题
  8. UDO compare ABAP代码的实现
  9. [BZOJ 1452] Count
  10. r510服务器开机无显示,联智通达工业主板常见问题之工控电脑开机无显示
  11. WCF项目中出现常见错误的解决方法:基础连接已经关闭: 连接被意外关闭
  12. Javascript当中的RSA加解密
  13. 计算机一级在线模拟试题,全国计算机等级考试一级模拟试题及答案解析
  14. 吉利GKUI车机任意安装第三方APP软件教程,DNS劫持应用商店安装软件
  15. 设计模式初探-观察者模式(OBSERVER)又称发布-订阅(Publish-Subscribe)依赖(Dependents)
  16. 经济管理专业必备的15种国内数据库推荐
  17. 1.1.2 计算机网络的组成
  18. 推荐下载:三款主流文件校验码工具HashCalc、WinMD5、Hasher
  19. [浪风分享]移动电商:不是渠道拓展,而是一次重新创业
  20. 视频素材免费下载网站

热门文章

  1. Foxmail邮件客户端邮箱密码解密
  2. 相对论通俗演义(1-10) 第十章
  3. SpringSecurity系列学习(一):基于JWT的认证
  4. 8本入门级大数据经典图书,开启你的“深度学习” | 世界读书日
  5. ADS1220的几种应用介绍(含源码)
  6. RAD Studio/Delphi 2010 3615下载+破解
  7. Joan Baez - Jackaroe
  8. idea创建maven工程没有src文件夹,或者是maven文件结构不能完整创建,可能是因为你的网速问题
  9. 安防无战事:一场10213亿元的误会 1
  10. Android 使用shape实现虚线或者虚线框