啥是DevOps
DevOps(Deveplopment和Operations的简称)，中译为开发运维一体化，可定义为是一种过程、方法、文化、运动或实践，主要是为了通过高度自动化的过程来加强开发和其他IT职能部门之间的沟通和协作，加速软件和服务的持续交付。
DevOps是一个虚无缥缈的玩意儿，它并不能简单的被工具或软件来定义或量化，但工具或软件却是实现DevOps的一个重要组成部分。
在一个较成熟的软件和服务交付的公司里，就技术层面来说主要分为三个组成部分——开发、测试和运维。DevOps的作用就是将这三个部分紧密的连接起来，提供一条从软件开发到质量保障到技术运营的自动化流水线，加强不同角色之间的沟通和协作，基于用户需求实现软件和服务的快速可持续交付。
个人认为DevOps更应该更全面的被称为DevTestOps,测试(高端点说是质量管控)往往是很容易被忽视的一个部分，但是偏偏这个环节却又异常重要和复杂。虽然我从未干过测试的活儿，但脑补一下也可大概了解是个什么情况。所以特此提出来，希望看到此贴的朋友们能够更加重视所交付软件产品的质量管控，同时也给予测试工作必须的重视以及测试工程师必要的尊重。
为啥要DevOps
“开发的这群傻叉新给的发布包又把系统CPU搞到100%了，应用又夯住了，都是些什么水平的人**”
“运维的这绑傻鸟技术太差，维护的是些什么稀烂的系统，在我这跑得好好的，上他们那应用就挂…”
“这是开发的锅…”
“这是运维的盘…”
描述得略显浮夸…但这种踢皮球的事情在IT团队里面真的是随时随处可见。无所谓对错，也找不到谁来背锅，这都是由开发和运维的基因所决定的，但是最终的受害者却是用户。偏偏比较有意思的就是，开发和运维人员所做的这些也都是为了用户，开发人员必须根据用户的需求对应用的功能进行不停的变更，运维人员也必须根据用户的需求提供稳定和持续的服务。各司其职的同时也在两者之间形成了一面无形的墙，阻碍了开发和运维之间的沟通和协作，进而损害了用户的利益，而DevOps的出现就是为了击碎这面无形之墙。
能踏上IT这条不归路的人都不傻(也许是真傻…)，IT管理者们也知道有这样的问题存在，但是一直也没有一个很好的方式来解决，或者说还没有到火烧眉毛迫切需要解决的时候。
我最早接触的”DevOps”是在5年前运维某企业的一套SAP财务系统，该系统配备了开发、测试和生产三套环境，一个新功能的开发、测试和发布都基于这三套环境来完成，通过层层把控到最终上线交付给业务。真的很棒，这样至少解决了因环境差异而带来的一系列问题。但这并不是真正意义上的DevOps，因为当时的这些操作都需要人来手动完成，而且不同角色间的定位和协作也没有受到足够的重视。

 

为啥DevOps会火
DevOps在2009年就已经被提出，结果到2015年末才算真正的火起来。为啥?
用户体验时代到来
用户基于IT应用的需求变化越来越快、数量也越来越多，这使得软件交付的响应必须得快速和敏捷。传统的瀑布式开发已经无法适应当下的场景了，因为在你怒憋大招的时候可能就已经被KO了，抑或等你大招开出来的时候已经成了空气，因为没人愿意为此买单。
因此，企业所遇到的Dev|Ops问题就到了一个就算没有很好的方式也必须被解决的地步，而DevOps的出现就跟救命稻草一样，帮助企业实现快速交付和变更，以便于快速响应市场的变化和用户的需求。
云计算的普及
云计算的特性之一就是快速和灵活的环境交付。试想在交付的过程中，我们可以极其快速的部署出承载应用的基础环境，但是由于传统的开发运维模式，软件需要一个很长的时间才能交付(上线)。那么基础环境的快速部署就变得没有任何意义，还会起到反作用(云计算得按量计费)。所以必须要使用某种方式来加速应用开发到运维的整个过程，DevOps也算是顺应时势。
工具日益成熟
DevOps再好，空谈概念或文化，无法落地全是白搭。好在现今实现DevOps的工具越来越多，而且越来越成熟。从代码开发、代码构建、应用打包、功能测试、发布上线、配置管理到运行监控都有大量且成熟的工具来组成一个工具链，这无疑在技术层面对DevOps的落地有了有效的支撑。
尤其Docker带来的一波容器技术热浪和衍生出来基于应用的容器云平台更是完美解决了开发和生产环境的异构问题。
DevOps咋落地
DevOps的如何落地无疑是很多朋友所关心的问题。其实本人也不知该如何落地，因为没有完整的去实践过，所以也不敢随意胡编乱造。以下纯属个人见解:
技术层面

DevOps 不是一个工具，但它需要被工具来实现，好在现在已经有了很多商业版和开源版的软件来形成一个有效的工具链来作为DevOps技术层的支撑。但是光有工具还不够，再好的工具没人会用也没意义，还需要有熟悉这个工具链的IT人员来提供技术支持，熟练利用这些工具来实现DevOps。

 

流程层面

DevOps是一条从软件代码开发到应用上线运维的流水线，想要流水线能够高效和平滑的自动运作，必须得设定一系列的流程和规范来进行管控。IT的管理者需要具备软件交付的全局观，能够清晰的认识到交付周期中不同角色的痛点在哪里，进而定制出合适的协作流程。

 

组织层面

DevOps并不是简单的将开发部门和运维部门合并，而是加强开发部门和运维部门之间的协作和沟通。这需要管理者们对企业的IT部门有着足够的重视并且愿意去推动DevOps这种开发和运维间高效的协作模式，而且开发和运维的人员之间也需要有开放、接纳和合作的意识。
信息时代没有任何企业能够离开IT部门而独立运转，但DevOps的落地还是得取决于IT部门在企业中所体现的价值。如果IT在企业中只是一个边缘部门，实践DevOps就没有太大的必要;但相反如果IT部门决定企业的命脉，需要对市场的变化和用户的需求做到快速的响应，那DevOps势在必行。
相对而言DevOps在互联网企业比传统企业需求更为迫切，在新创公司的实践也比成型公司更为容易。企业最终是不是需要实践DevOps，真正决定的并不是企业本身，而是用户需求和应用场景。

比如说企业内部的HR系统可能只有几十个人使用并且半年才有一次功能发布，这样就没有必要耗时费力的为了DevOps去上DevOps。再比如企业的信息服务得面向大量用户，用户越多需求就越多，需求越多对信息系统的功能变更就越多，这种变更频繁的场景上DevOps就比较合适了。

 

总结陈词
这是一个瞬息万变的时代，身处IT行业，这几年感受尤为深切。以前软件补丁发布可能是三月一次，现在软件补丁都快到一月三次了…很多软件还没等你用熟呢，下一个大版本瞬间就蹦出来了…这所有的一切都是由用户需求的快速变化来决定的，在这种快速可持续交付的大环境下，DevOps在企业中落地也只是时间问题，没有人能够阻止时代前进的步伐，这波洪流让我们拭目以待。

最后还是说说我心中的DevOps吧(好像有点晚了…)，DevOps它不是工具、不是文化、不是方法、不是实践、不是运动、不是流程…而是一场革命！

革谁的命？成就用户，革我们这群挨踢狗的命…

转载请注明：靠谱运维 » 我眼中的DevOps