说到DevOps这个词，相信很多人都会耳熟能详。DevOps作为一个流行的概念，近年来频频出现在各大技术社区和媒体的文章中。那么，什么是DevOps？有人说是方法，有人说是工具，有人说是思想。更重要的是，它是一种哲学。越说越神秘，感觉自己要成神了！DevOps真的有那么夸张吗？它是干什么用的？为何在业界如此受欢迎？今天的文章，小枣君就跟大家聊聊这个DevOps。DevOps的由来说来话长，还是从头说起吧。1940年代，世界上第一台计算机诞生。从它诞生之日起，就离不开程序的驱动。负责编写程序的人称为“程序员”。程序员是计算机的驱动者，也是极为紧缺的人才。那时候，只有高学历、名校出身的人才有资格成为程序员，操纵计算机。随着人类科技的不断发展，个人电脑、互联网相继问世，我们已经进入了全民拥抱信息技术的时代。越来越多的公司开始使用电脑作为办公工具来提高生产力。普通个人用户也开始将电脑作为娱乐工具来提高生活质量。结果，计算机程序开始成为一门生意。逐渐演变为“软件”的程序成为最赚钱的产品之一。在软件行业，程序员有一个更专业的称呼，叫做“软件开发工程师（SoftwareDevelopmentEngineer）”，也就是我们常说的“码农”。我们知道，一个软件从无到有到最终交付大概包括以下几个阶段：规划、编码、构建、测试、发布、部署和维护。最初，程序比较简单，工作量也不大，程序员可以自己完成所有阶段的工作。随着软件行业的发展，软件的规模逐渐变得庞大。软件的复杂性不断攀升。当一个人坚持不住的时候，一种精细化的分工就开始出现了。码农队伍扩大了，工作种类也增加了。除了软件开发工程师，还有软件测试工程师和软件运维工程师。分工后，传统的软件开发流程是这样的：软件开发人员花费数周、数月的时间编写代码，然后将代码交给QA（质量保证）团队进行测试，再将最终的发布版本交给运维团队部署。所有这三个阶段，即开发、测试、部署。早期采用的软件交付模型称为“瀑布（Waterfall）模型”。瀑布模型，简而言之，就是等待一个阶段的所有工作完成后，再进入下一阶段。这种模式适用于条件比较理想（用户需求非常明确，开发时间充足）的项目。大家按部就班，轮流履职。但是，项目不能单向运行。客户也有需求。产品也有问题，需要改进。随着时间的推移，用户对系统的需求不断增加，与此同时，用户给定的时间段也越来越少。在这种情况下，大家发现繁琐缓慢的瀑布式开发已经落伍了。因此，软件开发团队引入了一个新的概念，这就是大名鼎鼎的——“敏捷开发（AgileDevelopment）”。敏捷开发在2000年前后开始受到全世界的关注，它是一种能够响应快速变化的需求的软件开发能力。其实简单来说就是把大项目变成小项目，把大时间点变成小时间点，然后像这样：敏捷开发中有两个词经常和DevOps一起出现，就是CI和光盘。CI是ContinuousIntegration（持续集成），CD对应多种英文，ContinuousDelivery（持续交付）或ContinuousDeployment（持续部署）。美其名曰“Continuous”，其实就是“加速-重复-加速-重复...”的意思，像这样。画个图大家可能会更明白一点：敏捷开发大大提高了开发团队的工作效率，让版本更新速度更快。很多人可能会想，“版本更新越快，风险越大？”事实上，情况并非如此。敏捷开发可以帮助更快地发现问题，更快地将产品交付给用户，团队也可以更快地得到用户的反馈，从而更快地做出响应。而且DevOps小步运行带来的版本变更比较小，风险也会更小（如下图）。即使出现问题，修复起来也相对容易。敏捷开发虽然大大提高了软件开发的效率和版本更新的速度，但其作用仅限于开发过程。研发团队发现运维端依然铁板一块，成为新的瓶颈。运维工程师和开发工程师的思维逻辑完全不同。运维团队的座右铭很简单，就是“稳定压倒一切”。运维的核心需求没问题。什么时候最容易出错？有变化的时候最容易出错。所以，运维是非常抗拒“变化”的。于是乎，两人的矛盾爆发了。这个时候，我们的DevOps就隆重登场了。DevOps究竟是什么？DevOps这个词实际上是Development和Operations这两个词的组合。它的英文发音是/de'v?ps/，类似于“divops”。维基百科对DevOps的定义是这样的：DevOps是一组流程、方法和系统的统称，用于促进开发、技术运营和质量保证(QA)部门之间的沟通、协作和集成。这个定位有点抽象，但是不难理解。无论如何，它不是特定软件、工具或平台的名称。从目标来看，DevOps是为了让开发人员和运维人员能够更好的沟通和协作，通过自动化的流程让整个软件过程变得更快、更可靠。很多人可能认为所谓的DevOps就是Dev+Ops。合并两个团队，或者把运维交给开发，不就完事了吗，简单粗暴。注意，这个观点是错误的。这也是DevOps这些年落地难的主要原因。要想真正落地DevOps，第一点就是转变思路，也就是“洗脑”。不仅运维要洗，开发也要洗。员工要洗，领导更要洗。DevOps不仅仅是组织架构的改变，更是企业文化和理念的改变。如果你不能改变心态，即使你把人放在一起，也不会产生火花。除了洗脑，就是按照DevOps的思维重新梳理整个流程的规范和标准。在DevOps流程下，运维人员会在项目开发过程中介入开发过程，了解开发者使用的系统架构和技术路线，制定合适的运维方案。开发者也会在运维前期参与系统部署，为系统部署提供优化建议。DevOps的实施促进了开发和运维人员之间的交流，增进了相互的了解（gan）和了解（qing）。在思维和流程都在变化的同时，想要全面实施DevOps，当然离不开软件和平台的支持。目前支持DevOps的软件太多了。限于篇幅，我们就不一一介绍了。话说回来，现在DevOps之所以被大肆炒作，也是因为有这些软件和平台的功劳，可以趁机卖钱。DevOps生态中令人眼花缭乱的工具在上面提到的关键要素中，技术（工具和平台）是最容易实现的，其次是流程，最难改变思维。也就是说，DevOps考验的不仅仅是企业的技术，更考验的是管理水平和企业文化。对比前面提到的瀑布式开发和敏捷开发，我们可以清楚地看到，DevOps贯穿于软件的整个生命周期，并不局限于开发阶段。下图更清楚地说明了DevOps的地位和价值：DevOps的发展现状DevOps这个词来源于2009年在比利时根特举办的第一届DevOpsDays大会，为了在Twitter上更方便的传播DevOps的简称作为DevOpsDays的DevOps。目前，DevOps正处于快速成长阶段。尤其是在大型企业中，DevOps获得了很大的普及。根据2018年的调查，74%的受访者接受了DevOps，而前一年这一比例为66%。企业越大，越喜欢DevOps。Adobe、亚马逊、苹果、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、星巴克、沃尔玛、索尼等公司都在采用DevOps。如今，DevOps几乎已经成为软件工程的代名词。随着DevOps的快速发展，相关专业人士的薪资也相应水涨船高。据调查，美国DevOps工程师的平均年薪为13万，中国的平均年薪也在40万到50万之间，能力强者年薪可见一斑。到处。数据来源于招聘网站薪水的飙升，带动了IT工程师学习认证的热潮。最受欢迎的DevOps认证是EXINDevOpsMaster和EXINDevOpsProfessional。这些认证的培训费用不低，但还是吸引了很多人踊跃报名。EXINDevOps认证体系DevOps与虚拟化、容器和微服务云计算技术近年来突飞猛进。您应该熟悉虚拟化、容器和微服务的概念。当我们提到这些概念时，我们也偶尔会提到DevOps。它们之间有什么联系？其实很简单。你可以想象，如果我们要微调一个工作，我们加工一个大铁块方便吗？还是拆成碎片加工更方便？显然，拆分后会更方便。所谓“微服务”，就是将一个原本是黑盒子的产品整体，从一个提供多种服务的整体拆分（解耦）为多个个体，每个个体提供不同的服务。如下图所示：Monolithic→Microservices在微服务架构下，不同的工程师可以处理各自负责的模块，如开发、测试、部署、迭代等。虚拟化实际上是一种敏捷的云计算服务。在硬件方面，它把一个系统“分割”成多个系统，系统之间相互隔离，方便微服务。容器甚至更彻底。不是分成不同的操作系统，而是在操作系统上分成不同的“运行环境”（Container），占用资源少，部署速度更快。知道了？虚拟化和容器实际上为DevOps提供了一个很好的先决条件。可以更好的隔离开发环境和部署环境，减少相互影响。这也是DevOps在2009年还不火，现在却越来越火的主要原因之一。DevOps与通信作为一名通信工程师，小枣老师会讲一下DevOps与通信的关系。刚开始接触DevOps的时候，和很多人一样，我认为它是一个纯粹的IT概念，与我们的交流没有任何关系。后来随着对DevOps的深入理解，我发现这个概念和我们的沟通是息息相关的。我什至说过，我十多年前刚入行的时候，其实遇到过DevOps面临的问题。在当时（2005年左右）的电信行业，产品的稳定性和可靠性就是一切（其实现在也是）。因此，电信行业的软件版本更新非常缓慢。像朗讯、爱立信这样的传统巨头，通常半年就会出一个正式版。此版本经过仔细检查和制作，因此非常稳定。随着3G的兴起，全球运营商开始更新网络。华为、中兴开始借机进军国际运营商市场，试图从国际巨头手中分一杯羹。除了价格，华为中兴最大的杀手锏是什么？就是响应速度。当时，运营商客户对电信设备软硬件的需求非常多，而且非常频繁。在印度这样的地方，客户特别难找，每天都有新的需求进来。当时，几家海外设备制造商的反应速度很慢，从来没有轻易答应接受需求。即使你接受了，半年甚至一年后你才会回复。客户听了这话立马崩溃了。但是，华为和中兴不一样。两家公司的售前市场人员对客户需求都很“大方”，基本有求必应。（那时候售后的同事会骂售前的同事，但是仔细想想，如果不同意，就没有机会进入市场。）发布频率有多快？当时华为和中兴的版本是多少？最快的时候，三天就有一个版本。.甚至，大量研发人员长期驻守在客户办公室，现场修改版本，提交“热补丁”。那时候是2006年，DevOps的概念还没有。在研发方面，敏捷开发似乎刚刚被提出来。没有理论框架和工具平台的支撑，版本的快速迭代完全靠人力来实现。当然，其中涉及的成本和风险也非常高。不仅开发人员很累很辛苦，项目中的统一（工程服务）工程师，也就是本文中的技术支持工程师、运维工程师就更惨了。想一想，几个月才升到一个新的等级，现在才几天，不辛苦吗？但也正是这种拼搏，才把市场份额从传统巨头的嘴里逼出来，最终一步步做大做强。后来逐渐产生了敏捷开发的概念，现在有了DevOps，有了各种工具和平台，为快速的版本迭代提供了良好的条件。对于通信行业的运维来说，DevOps既是机遇也是挑战。就像前面提到的容器和虚拟化一样。5G核心网采用的NFV虚拟化技术，将网元功能隔离开来，大大降低了核心网工程师的运维风险和难度。这是一个积极的变化。但是，DevOps对运维工程师的能力要求大大提高。..通信软件是IT软件的一个重要分支，与DevOps有着密切的关系。建议通信工程师充分了解DevOps，升级知识库，做好技能储备。硬道理，天下武功，唯速成。时代发展到现在，客户的需求瞬息万变，市场走向也难以预料。作为企业，要想生存，就只能让自己更快。作为一名员工，我们必须让我们的愿景更长远，更宽容。好了，以上就是今天的内容，感谢您的耐心阅读！下期见！
