大厂都用DevOps，从多角度了解DevOps

本文主要是介绍大厂都用DevOps，从多角度了解DevOps，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

目前很多大厂如阿里、腾讯、百度、头条、滴滴、美团等公司内部都在做DevOps，那么 DevOps是什么？为什么大厂都对其趋之若鹜？ DevOps到底应该怎么做？刚好我也负责我们公司的DevOps，今天就来讲讲吧！

前言

提到DevOps这个词，我相信很多人一定不会陌生。作为一个热门的概念，DevOps近年来频频出现在各大技术社区和媒体的文章中，备受行业大咖的追捧，也吸引了很多吃瓜群众的围观。

那么什么是DevOps呢？

有人说它是一种方法，也有人说它是一种工具，还有人说它是一种思想。更有甚者，说它是一种哲学。

DevOPs是一种方法论。

DevOps=Developers+Operators，即开发团队和运维团队一体化，尽可能的为公司创造更多价值。

现在流行的做法是将两个职能部门的人融合为一个职能部门，实现开发运维一体化，而早期的时候是两波人分别承担不同的职能，中期的时候是要求两波人密切配合、快速迭代，这中间的变化取决于开发模式的转变。

瀑布开发模型

早期的时候是瀑布开发模型。因为互联网上涌入的网民还不多，大家的关注点是能用、能解决问题即可，所以早期在需求评审阶段产品经理给到的是完整、清晰、固定的需求，研发人员只需要根据需求在约定的时间点进行交差即可

这种开发模式存在的问题是需求不能快速得到验证，很有可能团队花费半年的时间开发出来的东西早已经不适合市场了，也还有种可能是在开发阶段研发需求理解不到位，等到后期验证时发现有问题再去做调整耽误整体工期。

敏捷开发模型

中期的时候是敏捷开发模型。因为互联网上涌入的网民开始增多，大家的关注点开始变成好用、好玩，而此时一些有远见的人开始注意到互联网红利，投身于互联网，此时的开发模式演变成了敏捷开发模型。

敏捷开发模型面对的是频繁的需求变化，要求快速开发。比较流行的实际案例则是Scrum、XP极限编程。在新迭代（一般2-6周）开始前，产品经理将需求拆分成具体的开发任务，研发人员进行任务认领，每日会进行任务的review，直到开发完成，发布新的可用版本。

DevOps

现在最流行的是DevOps。因为互联网上涌入的网民在海量的增加，互联网企业的竞争也开始变得激烈，同一块蛋糕很多人来抢来分（电商领域的淘宝、京东、网易严选、拼多多、小鹅拼拼等），快速迭代产品，快速占领市场，快速占据用户心智成为了各互联网公司的目标，此时的开发模型变成了DevOps，需要持续开发、持续集成、持续测试、持续部署、持续监控，每一次代码的改动都触发一次校验，每天每时每刻都可进行新版本的上线。

DevOps是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

这个定位稍微有点抽象，但是并不难理解。反正它不是某一个特定软件、工具或平台的名字。

从目标来看，DevOps就是让开发人员和运维人员更好地沟通合作，通过自动化流程来使得软件整体过程更加快捷和可靠。

破墙工具

很多人可能觉得，所谓DevOps，不就是Dev+Ops嘛，把两个团队合并，或者将运维划归开发，不就完事了嘛，简单粗暴。

注意，这个观点是不对的。这也是DevOps这些年一直难以落地的主要原因。

想要将DevOps真正落地，首先第一点，是思维转变，也就是“洗脑”。不仅是运维的要洗，开发的也要洗。员工要洗，领导更要洗。

DevOps并不仅仅是组织架构变革，更是企业文化和思想观念的变革。如果不能改变观念，即使将员工放在一起，也不会产生火花。

除了洗脑之外，就是根据DevOps思想重新梳理全流程的规范和标准。

在DevOps的流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。

DevOps的实施，促进开发和运维人员的沟通，增进彼此的理（gan）解（qing）。

在思维和流程改变的同时，想要充分落地DevOps，当然离不开软件和平台的支持。

目前支持DevOps的软件实在是太多了。限于篇幅，就不一一介绍了。话说回来，现在DevOps之所以被吹得天花乱坠，也有这些软件和平台的功劳，可以趁机卖钱啊。

DevOps生态圈中令人眼花缭乱的工具

上述这些关键要素里面，技术（工具和平台）是最容易实现的，流程次之，思维转变反而最困难。

换言之，DevOps考验的不仅是一家企业的技术，更是管理水平和企业文化。

对比前面所说的瀑布式开发和敏捷开发，我们可以明显看出，DevOps贯穿了软件全生命周期，而不仅限于开发阶段。

下面这张图，更明显地说明了DevOps所处的位置，还有它的价值：

DevOps生命周期

在不了解DevOps生命周期的情况下，对DevOps的理解也会片面化。现在让我们看看DevOps生命周期，并探讨它们如何与软件开发阶段相关联。

持续开发

这是DevOps生命周期中软件不断开发的阶段。与瀑布模型不同的是，软件可交付成果被分解为短开发周期的多个任务节点，在很短的时间内开发并交付。这个阶段包括编码和构建阶段，并使用Git和SVN等工具来维护不同版本的代码，以及Ant、Maven、Gradle等工具来构建/打包代码到可执行文件中，这些文件可以转发给自动化测试系统进行测试。

持续测试

在这个阶段，开发的软件将被持续地测试bug。对于持续测试，使用自动化测试工具，如Selenium、TestNG、JUnit等。这些工具允许质量管理系统完全并行地测试多个代码库，以确保功能中没有缺陷。在这个阶段，使用Docker容器实时模拟“测试环境”也是首选。一旦代码测试通过，它就会不断地与现有代码集成。

持续集成

这是支持新功能的代码与现有代码集成的阶段。由于软件在不断地开发，更新后的代码需要不断地集成，并顺利地与系统集成，以反映对最终用户的需求更改。更改后的代码，还应该确保运行时环境中没有错误，允许我们测试更改并检查它如何与其他更改发生反应。

Jenkins是一个非常流行的用于持续集成的工具。使用Jenkins，可以从git存储库提取最新的代码修订，并生成一个构建，最终可以部署到测试或生产服务器。可以将其设置为在git存储库中发生更改时自动触发新构建，也可以在单击按钮时手动触发。

持续部署

它是将代码部署到生产环境的阶段。在这里，我们确保在所有服务器上正确部署代码。如果添加了任何功能或引入了新功能，那么应该准备好迎接更多的网站流量。因此，系统运维人员还有责任扩展服务器以容纳更多用户。由于新代码是连续部署的，因此配置管理工具可以快速，频繁地执行任务。

Puppet，Chef，SaltStack和Ansible是这个阶段使用的一些流行工具。容器化工具在部署阶段也发挥着重要作用。Docker和Vagrant是流行的工具，有助于在开发，测试，登台和生产环境中实现一致性。除此之外，它们还有助于轻松扩展和缩小实例。

持续监控

这是DevOps生命周期中非常关键的阶段，旨在通过监控软件的性能来提高软件的质量。这种做法涉及运营团队的参与，他们将监视用户活动中的错误/系统的任何不正当行为。这也可以通过使用专用监控工具来实现，该工具将持续监控应用程序性能并突出问题。

使用的一些流行工具是Splunk，ELK Stack，Nagios，NewRelic，Sensu，Promethus。这些工具可帮助密切监视应用程序和服务器，以主动检查系统的运行状况。它们还可以提高生产率并提高系统的可靠性，从而降低IT支持成本。发现的任何重大问题都可以向开发团队报告，以便可以在持续开发阶段进行修复。