软件世界的战场

如果你对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需要你去不断地尝试和调整，不要害怕失败和挫折，它们是积累宝贵经验的源泉，但是绝对不要在同样的坑里摔倒第二遍。 我喜欢这句话：所谓专家，就是在一个很小的领域里把所有错误都犯过了的人。（来自我是开发经理）

软件世界的战场

如果你对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需要你去不断地尝试和调整，不要害怕失败和挫折，它们是积累宝贵经验的源泉，但是绝对不要在同样的坑里摔倒第二遍。 我喜欢这句话：所谓专家，就是在一个很小的领域里把所有错误都犯过了的人。（来自我是开发经理）