代价英文怎么说(承担代价英文)

自主先造教室

作者肖早军

相信很多人都会对DevOps这个词比较熟悉。

DevOps作为一个炙手可热的概念，近年来频频出现在各大技术社区和媒体的文章中，受到了业内大咖的大力追捧，也吸引了不少吃瓜群众的围观。

那么，什么是DevOps？

有人说是方法，有人说是工具，还有人说是理念。更何况是一种哲学。

越是神秘，越觉得要封神！DevOps这个东西真的有那么夸张吗？到底是为了什么？为什么在业内这么受欢迎？

今天在这篇文章里，小枣君就和大家好好聊聊这个DevOps。

DevOps的起源

这个故事有点长。让我们从头开始。

20世纪40年代，世界上第一台计算机诞生了。自诞生之日起，就离不开节目的驱动。负责编写程序的人被称为“程序员”。

程序员是计算机的驱动者，是极其稀缺的人才。当时只有受过高等教育，有名校背景的人才有资格成为程序员，控制计算机。

随着人类科技的不断发展，PC和互联网相继问世，我们进入了全民拥抱信息化的时代。越来越多的企业开始使用电脑作为办公工具来提高生产力。普通个人用户也开始将电脑作为娱乐工具来提高生活质量。

因此，计算机程序开始成为一门生意。程序，逐渐演变成“软件”，成为最赚钱的产品之一。

在软件行业，程序员有一个更专业的头衔，叫做“软件开发工程师”，也就是我们常说的“码农”。

我们知道，一个软件从无到有到最终交付大概包括以下几个阶段:规划、编码、构建、测试、发布、部署和维护。

一开始程序比较简单，工作量也不大。程序员可以自己完成所有阶段的工作。

随着软件产业的不断发展，软件的规模逐渐变得庞大。软件的复杂性正在上升。当一个人把持不住的时候，精细化的分工就开始出现了。

码农队伍扩大了，工作岗位也增加了。除了软件开发工程师，还有软件测试工程师和软件运维工程师。

分工之后，传统的软件开发流程是这样的:

软件开发人员花费数周、数月时间编写代码，然后发送给QA(质量保证)团队进行测试，再将最终发布版本发送给运维团队进行部署。所有这三个阶段，即开发、测试和部署。

早期的软件交付模型被称为“瀑布模型”。

瀑布模型，简而言之，就是等到一个阶段的工作全部完成，再进入下一个阶段。

这种模式适合条件比较理想的项目(用户需求明确，开发时间充足)。大家可以轮流按部就班地履行自己的职责。

但是，项目不能单向运作。客户也有需求。产品也会有问题，需要改进。

随着时间的推移，用户对系统的需求越来越大，但同时用户给的时间段却越来越少。在这种情况下，发现笨重缓慢的瀑布式开发已经不合时宜。

因此，软件开发团队引入了一个新概念，即著名的“敏捷开发”。

敏捷开发在2000年左右开始被世人关注，是一种能够应对快速变化需求的软件开发能力。其实简单来说就是把大项目变成小项目，把大时间点变成小时间点，然后这个:

敏捷开发

有两个词经常伴随DevOps，那就是CI和CD。CI是持续集成，CD对应多种英文，持续交付或持续部署。

它美其名曰“持续”，其实就是“加速-重复-加速-重复……”，像这样。

画张图你可能会更清楚:

敏捷开发大大提高了开发团队的工作效率，使版本的更新速度更快。

很多人可能会想，“更新版本的速度越快，风险不是越大吗？”

其实并不是这样的。

敏捷开发可以帮助更快地发现问题，产品可以更快地交付给用户，团队可以更快地获得用户的反馈，从而更快地做出响应。而且DevOps小步跑的形式带来的版本变化比较小，风险也会更小(如下图所示)。即使出了问题，修复起来也会相对容易。

敏捷开发虽然大大提高了软件开发的效率和版本更新的速度，但其作用仅限于开发环节。研究人员发现，运维端仍然是铁板一块，这成为了新的瓶颈。

运维工程师和开发工程师的思维逻辑完全不同。运维团队的座右铭很简单，就是“稳定压倒一切”。运维的核心需求是没有问题。

什么情况下最容易出问题？当变化发生时，事情最容易出错。所以运维是很排斥“变”的。

于是，两人的矛盾爆发了。

这时，我们的DevOps，隆重登场了。

DevOps到底是什么

DevOps这个词其实是开发和运营的结合。它的英文发音是/de ‘vps/，类似于“Divops”。

维基百科对DevOps的定义如下:

Ops是一套过程、方法和系统的统称，用于促进开发、技术运营和质量保证(QA)部门之间的沟通、协作和集成。

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

从目标上来看，DevOps是为了让开发者和运维人员更好的沟通和合作，通过流程的自动化，让整个软件流程更快更可靠。

破壁工具

很多人可能觉得所谓的DevOps就是Dev+Ops而已。两个团队合并或者运维转开发，简单粗暴。

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

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

DevOps不仅仅是组织架构的改变，更是企业文化和理念的改变。如果不能转变观念，即使把员工放在一起，也不会有火花。

除了洗脑，就是按照DevOps的思想重新组织整个流程的规范和标准。

在DevOps的流程下，运维人员会在项目开发时介入开发过程，了解开发人员使用的系统架构和技术路线，然后制定出合适的运维方案。开发人员也会参与到运维前期的系统部署中，为系统部署提供优化建议。

DevOps的实施将促进开发和运营人员之间的沟通，增进他们之间的相互了解(感)和(情)。

在思维和流程变革的同时，要想全面实现DevOps，离不开软件和平台的支持。

目前支持DevOps的软件太多了。限于篇幅，我就不一一介绍了。另一方面，DevOps现在之所以被吹得天花乱坠，是这些软件和平台推波助澜，你可以趁机卖钱。

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

在这些关键要素中，技术(工具和平台)最容易实现，流程次之，思维的改变最难。

换句话说，DevOps考验的不仅仅是一家公司的技术，更是它的管理水平和企业文化。

对比上面提到的瀑布开发和敏捷开发，我们可以清楚的看到DevOps贯穿于软件的整个生命周期，而不仅仅是在开发阶段。

下图更清晰的显示了DevOps的位置和价值:

DevOps的发展现状

DevOps这个词来源于2009年在比利时根特举办的首届DevOpsDays大会。为了在Twitter上更方便的传播，DevOpsDays被缩写为DevOps。

目前DevOps正处于快速成长阶段。尤其是在大型企业中，DevOps受到了广泛的欢迎。

根据2018年的调查，74%的受访者接受了DevOps，而上一年为66%。

生意越大，越喜欢DevOps。包括Adobe、亚马逊、苹果、Airbnb、Ebay、Etsy、脸书、LinkedIn、网飞、NASA、星巴克、沃尔玛、索尼等公司都在采用DevOps。

如今，DevOps几乎成了软件工程的代名词。

随着DevOps的快速发展，相关专业人员的薪资也水涨船高。

据调查，美国DevOps工程师平均年薪13万美元，中国平均年薪也在40-50万区间，能力强的年薪上百万。

数据来自招聘网站

薪资的飙升带动了IT工程师学习和认证的热潮。

目前最受欢迎的DevOps认证是EXIN DevOps硕士和EXIN DevOps专业。这些认证的培训费用不低，但还是吸引了很多人报名。

EXIN DevOps认证体系

DevOps与虚拟化、容器、微服务

近年来，云计算技术发展突飞猛进，大家应该对虚拟化、容器、微服务等概念比较熟悉。当我们提到这些概念时，我们也会偶尔提到DevOps。

它们之间有什么联系？

其实很简单。

你可以想象一下，如果一项工作需要精细的分工，我们加工一大块铁方便吗？还是拆成块加工更方便？

显然拆分后会更方便。

所谓“微服务”，就是把一个原本黑箱化的整体产品，从一个提供多种服务的整体，拆分(解耦)给若干个各自提供不同服务的个体。如下图所示:

单片)→架构→微服务架构

在微服务架构下，不同的工程师可以处理自己负责的模块，比如开发、测试、部署、迭代等。

虚拟化实际上是一种敏捷的云计算服务。硬件方面，它将一个系统“划分”成多个系统，相互隔离，为微服务提供便利。

容器更彻底。不是分成不同的操作系统，而是分成操作系统上不同的“运行环境”(容器)，占用资源更少，部署更快。

看到了吗？虚拟化和容器实际上为DevOps提供了一个很好的先决条件。可以更好的隔离开发环境和部署环境，减少相互影响。

这也是2009年DevOps不火，现在却越来越火的主要原因之一。

DevOps和通信

作为一名通信工程师，小早君谈到了DevOps与通信的关系。

刚接触DevOps的时候，我和很多人一样，认为这是一个纯粹的it概念，和我们的交流无关。

后来随着我对DevOps的深入了解，我发现这个概念和我们的交流息息相关。甚至，早在十几年前，我刚入行的时候，其实也遇到过DevOps面临的问题。

当时(2005年左右)，在电信行业，产品的稳定性和可靠性就是一切(其实现在也是)。所以电信行业的软件版本更新速度非常慢。对于朗讯、爱立信等传统巨头，通常需要半年时间才能出正式版。这个版本非常稳定，因为它经过了仔细的检查和制作。

随着3G的兴起，全球运营商开始更新网络。华为和中兴开始借机切入国际运营商市场，试图从国际巨头那里分一杯羹。

除了价格，华为中兴最大的杀手锏是什么？就是反应速度。

当时，运营商的客户对电信设备的硬件和软件有很多和频繁的需求。在印度这样的地方，客户特别难，每天都有新的需求提出来。

当时几家海外设备厂商的反应速度都很慢，从来不会轻易同意接受需求。即使接受了，也要半年甚至一年才能得到回答和实现。顾客就这么崩溃了。

而华为和中兴则不同。两家公司的售前营销人员对客户的需求都很“大方”，基本都是回应他们的诉求。(当时售后同事会骂售前同事，但仔细一想，拒绝了就没机会进场了。)

当时华为和中兴发布版本的速度有多快？最快的时候，三天一个版本。甚至，在很长一段时间内，大量R&D人员进驻客户办公室，现场改版本，提交“热补丁”。

那是2006年，还没有DevOps这个概念的影子。在R&D这边，敏捷开发似乎刚刚被提出来。没有理论框架和工具平台的支持，靠人力实现版本的快速迭代。当然，所涉及的成本和风险也是非常高的。

不光是开发人员很累很辛苦，项目中的工程服务工程师，也就是技术支持工程师，还有本文中的运维工程师，更是苦不堪言。想想吧。几个月前升了一次，现在几天就要升一次。会很难吗？

但就是这种从传统巨头口中抢夺市场份额的努力，最终一步步做大做强。

后来敏捷开发的概念产生了，现在有了DevOps，各种工具和平台，为版本的快速迭代提供了很好的条件。

DevOps对于通信行业的运维来说，既是机遇也是挑战。

如前所述，容器和虚拟化。5G核心网采用的NFV虚拟化技术隔离了网元的功能，大大降低了核心网工程师的操作风险和难度。这是一个积极的变化。但是DevOps对运维工程师的能力要求有了很大的提高。。。

通信软件是IT软件的一个重要分支，与DevOps密切相关。建议通信工程师好好了解DevOps，升级知识库，储备技能。