DevOps

DevOps

发展历史

一、前言

在《DevOps 的前世今生 | 1. DevOps 编年史》一文中，通过追溯 DevOps 活动产生的历史起源，我们发现了 DevOps 是敏捷思想从软件开发端 (Dev) 到系统维护端 (Ops) 的延伸。

无论是 DevOpsDays 的创始人 Patrick Debois，还是同时期的 The Agile Admin。

都想通过敏捷来改进传统的系统维护工作以及软件开发部门和系统维护部门的合作关系。

但是，DevOps 的矛盾从何而来？这还要从 Dev 和 Ops 的起源开始讲起。

二、上古时代——抱着计算机使用手册，自开发自运维

历史要追溯到刚刚出现计算机的时期。当时，软件开发还是少数人通过高学历才能够掌握的技能。

那个时候只有 “程序”（Program），但没有 “软件”（Software），所以那个时候编写程序的人员被称为 “程序员”（Programmer）。

基本的学习材料还只是计算机设备厂商附送的使用手册。所以，只能先购买设备，再自己培养人才。

早期的程序员

最先购买计算机的是科研单位，军队，政府以及少数大型企业。同时组建了新的部门，成立了信息技术部（IT Department)，或者叫信息化办公室（IT Office）。

在中国的有些单位里干脆直接叫 “电脑部”。他们一个科室，一个办公室主任，外加两三个科级干部和几个科员，专门管理这些电脑的使用情况，并且学习软件编程技术，用程序来解决其它各部门的。

这是最初的 IT 运维雏形，在这个时期是没有 Dev 和 Ops 之分的，他们统称为 Programmer。

由于开发和运维都由同样的人包揽，自己维护自己开发的程序，也可以被看做是原始的 DevOps。

这个时期的计算机系统和问题较简单，开发和维护并不复杂，无需进行专业区分。

桌面通用软件时代——软件成为了一门生意，出现了专业的软件开发工程师（Dev）。

随着计算机的成本不断下降，尤其是以 IBM PC 为代表微型计算机（ MicroComputer ）开始普及。企业也开始大规模使用计算机进行办公。

由于软件开发人员数量仍然很少，加之需求很旺盛，专业的软件开发人员成本依然高昂。

最开始的时候，软件仅仅通过磁盘拷贝进行流传，某些介绍计算机或者软件的杂志开了先河。程序员通过磁盘向杂志社投稿，杂志社通过变卖杂志和软件获利。

由于软件的边际生产成本几乎是 0，所以渐渐有人把销售软件变成了一门生意。随着软件的扩展，当初为个人目的（Personal Purpose）所编写的软件渐渐的开始走通用化的路线，慢慢形成了软件产品。

接着有了专门从事软件开发的公司，并逐渐成为一个产业。并且有了软件开发工程师（Developer，简称 Dev）这个职业。

微软的成功是软件开发专业化的代表

在这个时期，开发软件仍然是很专业的事情，企业的 IT 部门要想开发软件的代价十分高昂。因此，大部分单位，组织和企业通过购买的形式获得软件。

IT 部门逐渐成为了负责信息化采购以及软硬件基本操作培训的部门。此外，由于信息化发展加速，各行各业软件层出不穷，加之软件企业越来越多，IT 部门不得不通过更广泛的学习了解技术的变化。

企业级定制化软件时代——企业级应用的快速发展，出现了专业的系统维护工程师（Ops）。

随之带来的问题是：无论企业买来多少软件，企业的信息化需要仍然无法被满足。一台台电脑成为了企业的信息孤岛，解决了信息的分析和存储问题最多实现了无纸化办公。没有让部门间的信息有效的流动起来。

大型企业最先发现这些问题并且给出了最初的解决方案，使得企业级软件开发和系统集成（System Integration）慢慢成为了一个热门的领域。

企业级软件系统最大的特点是通过计算机网络解决了企业内部的信息孤岛。但这样的系统无法在 PC 上运行需要专业的工作站，服务器以及网络设备。而这些设备的管理就理所当然的成为了企业 IT 部门的职责。

Ops 需要管理很多的设备和应用

随着软硬件技术的发展，特别企业级应用开发的经验不断积累，设备的采购成本和软件的开发成本进一步降低。

大型 IT 厂商开始瞄准企业级应用市场，尤其是 IBM，Oracle 和 EMC 推出了相应的产品。

使得软件定制开发的成本不断下降。加之随着开发人员越来越多，开发成本逐渐降低，于是出现了企业定制化软件开发，出现了 MIS 和 ERP 这样的应用以及 J2EE 这样的企业级软件开发框架。

在这个过程中，IT 运维的概念逐渐产生，维基百科上是这样定义 IT 运维（IT Operations）的：

IT Operations is responsible for the smooth functioning of the infrastructure and operational environments that support application deployment to internal and external customers, including the network infrastructure; server and device management; computer operations; IT infrastructure library (ITIL) management; and help desk services for an organization.

翻译成中文就是：

IT 运维的责任是要为内部和外部客户的应用部署提供平滑的基础设施和操作环境，包括网络基础设施，服务器和设备管理，计算机操作，ITIL 管理，甚至作为组织的 IT 帮助中心。

对于企业的 IT 部门来说，工作就不仅仅是维护计算机和网络这些设备了。还要包括运行在上面的软件系统，尤其是定制化的企业级软件产品。

因此在定制化企业级软件交付从乙方交付给甲方的时候就需要一系列的技术审查以确保质量，这就使得原本不需要关心软件是如何开发的企业 IT 部门提出了更高的要求。

他们必须提升专业水准以应对这样的变化。同时需要重新思考整个 IT 部门的服务管理和设计。

随着 IT 部门知识和服务专业度的提升，促生出了了 ITIL（Information Technology Infrastructure Library，信息技术基础设施库）这样的最佳实践库，也使 “系统维护工程师”（Ops）更加专业化。

在这个时期，Dev 和 Ops 的矛盾，主要是由 Dev 所代表的乙方和 Ops 所代表的甲方在定制化软件产品交付质量上的矛盾。

三、敏捷软件开发时代——应对频繁变更的挑战

随着企业级软件开发日趋完善和成熟，形成了以 RUP（Rational Unified Process，Rational 统一软件开发过程）为代表的方法论。

RUP 描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目。

后来，互联网企业的繁荣着实闪瞎了世界的眼睛。没有人想到原本用来进行国防和科研的广域网居然可以带来这么大的商业价值。

互联网创业公司的成功不断的颠覆了很多人习以为常的事情，特别是 IT 产业。

首先，相较于最多万人的用户访问规模，来自互联网的千万级甚至是亿级的访问规模是企业级应用不曾遇到过的。这对软件开发，主机管理，网络架构都带来了很大的挑战。

其次，企业级应用和互联网应用面对的问题是不一样的。根据 “康威定理”：设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。

相较于有着清晰的等级和部门分工的组织来说，互联网产品的沟通结构更加复杂。

此外，互联网应用由互联网企业自开发自维护。虽然从表面上看没有了甲方和乙方的对立。

但开发和运维相互分离的工作流程和考核方式却沿用了下来，职责上的对立依然存在：

• Dev 的工作是给应用系统增加新的功能 / 修复软件的 Bug，这一系列价值的产生是通过应用系统变更实现的。

  一般的组织会用代码 / 功能的贡献数量作为 KPI 作为考核的依据，以激励 Dev 的工作产出。

• Ops 的工作则是让应用系统保持稳定和高性能，即最大化缩短宕机时间并能够提升应用系统的性能，并以这两者作为 Ops 的 KPI 的考核指标。

  以激励 Ops 通过维护工作使应用系统能够按照预期稳定的产出价值。

而市场环境的瞬息万变和资本的集中化使得互联网软件产品的生存状态十分脆弱：

• 一方面，快速变化的市场难以预测。因此，基于经验的重量级软件开发方法不再适用。取而代之的是强调适应性，拥抱变化的敏捷方法。

  互联网软件必须通过频繁增加 / 修改功能来提升自身对市场的适应程度。

• 另一方面，互联网软件的变更给带来的风险和损失都是难以度量的。

  因此，互联网软件有更加严格的交付标准，需要做更多的质量保证。

  而基于经验的系统运维实践并没有给出足够的方法以应对这种挑战。

因此，在这个时期，Dev 和 Ops 的矛盾主要是面向适应性的敏捷软件交付和面向经验性的传统运维之间的矛盾。

那么，如果将敏捷的文化和原则引入运维，会如何？

DevOps简介

DevOps 是一个完整的面向 IT 运维的工作流，以 IT 自动化以及持续集成（CI）、持续部署（CD）为基础，来优化程式开发、测试、系统运维等所有环节。

DevOps 的概念

DevOps 一词的来自于 Development 和 Operations 的组合，突出重视软件开发人员和运维人员的沟通合作，通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

DevOps 是为了填补开发端和运维端之间的信息鸿沟，改善团队之间的协作关系。不过需要澄清的一点是，从开发到运维，中间还有测试环节。DevOps 其实包含了三个部分：开发、测试和运维。

换句话说，DevOps 希望做到的是软件产品交付过程中 IT 工具链的打通，使得各个团队减少时间损耗，更加高效地协同工作。专家们总结出了下面这个 DevOps 能力图，良好的闭环可以大大增加整体的产出。

历史变革

由上所述，相信大家对 DevOps 有了一定的了解。但是除了触及工具链之外，作为文化和技术的方法论，DevOps 还需要公司在组织文化上的变革。回顾软件行业的研发模式，可以发现大致有三个阶段：瀑布式开发、敏捷开发、DevOps。

DevOps 早在九年前就有人提出来，但是，为什么这两年才开始受到越来越多的企业重视和实践呢？因为 DevOps 的发展是独木不成林的，现在有越来越多的技术支撑。微服务架构理念、容器技术使得 DevOps 的实施变得更加容易，计算能力提升和云环境的发展使得快速开发的产品可以立刻获得更广泛的使用。

好处是什么？

DevOps 的一个巨大好处就是可以高效交付，这也正好是它的初衷。Puppet 和 DevOps Research and Assessment (DORA) 主办了 2016 年 DevOps 调查报告，根据全球 4600 位各 IT 公司的技术工作者的提交数据统计，得出高效公司平均每年可以完成 1460 次部署。

与低效组织相比，高效组织的部署频繁 200 倍，产品投入使用速度快 2555 倍，服务恢复速度快 24 倍。在工作内容的时间分配上，低效者要多花 22% 的时间用在为规划好或者重复工作上，而高效者却可以多花 29% 的时间用在新的工作上。所以这里的高效不仅仅指公司产出的效率提高，还指员工的工作质量得到提升。

DevOps 另外一个好处就是会改善公司组织文化、提高员工的参与感。员工们变得更高效，也更有满足和成就感；调查显示高效员工的雇员净推荐值（eNPS:employee Net Promoter Score）更高，即对公司更加认同。

快速部署同时提高 IT 稳定性。这难道不矛盾吗？

快速的部署其实可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且，DevOps 小步快跑的形式带来的变化是比较小的，出现问题的偏差每次都不会太大，修复起来也会相对容易一些。

因此，认为速度就意味着危险是一种偏见。此外，滞后软件服务的发布也并不一定会完全地避免问题，在竞争日益激烈的 IT 行业，这反而可能错失了软件的发布时机

为什么 DevOps 会兴起？

为什么会继续火下去？

条件成熟：技术配套发展

技术的发展使得 DevOps 有了更多的配合。早期时，大家虽然意识到了这个问题的，但是苦于当时没有完善丰富的技术工具，是一种 “理想很丰满，但是现实很骨感” 的情况。DevOps 的实现可以基于新兴的容器技术；也可以在自动化运维工具 Puppet、SaltStack、Ansible 之后的延伸；还可以构建在传统的 Cloud Foundry、OpenShift 等 PaaS 厂商之上。

来自市场的外部需求：这世界变化太快

IT 行业已经越来越与市场的经济发展紧密挂钩，专家们认为 IT 将会有支持中心变成利润驱动中心。事实上，这个变化已经开始了，这不仅体现在 Google、苹果这些大企业中，而且也发生在传统行业中，比如出租车业务中的 Uber、酒店连锁行业中的 Airbnb、图书经销商 Amazon 等等。能否让公司的 IT 配套方案及时跟上市场需求的步伐，在今天显得至关重要。

DevOps 2016 年度报告给出了一个运维成本的计算公式：
停机费用成本 = 部署频率 * 版本迭代失败概率 * 平均修复时间 * 断电的金钱损失

来自团队的内在动力：工程师也需要

对于工程师而言，他们也是 DevOps 的受益者。微软资深工程师 Scott Hanselman 说过 “对于开发者而言，最有力的工具就是自动化工具”（The most powerful tool we have as developers is automation）。

工具链的打通使得开发者们在交付软件时可以完成生产环境的构建、测试和运行；正如 Amazon 的 VP 兼 CTO Werner Vogels 那句让人印象深刻的话：“谁开发谁运行”。（You build it, you run it）

实现 DevOps 需要什么？

硬性要求：工具上的准备

上文提到了工具链的打通，那么工具自然就需要做好准备。现将工具类型及对应的不完全列举整理如下：

• 代码管理（SCM）：GitHub、GitLab、BitBucket、SubVersion
• 构建工具：Ant、Gradle、maven
• 自动部署：Capistrano、CodeDeploy
• 持续集成（CI）：Bamboo、Hudson、Jenkins
• 配置管理：Ansible、Chef、Puppet、SaltStack、ScriptRock GuardRail
• 容器：Docker、LXC、第三方厂商如 AWS
• 编排：Kubernetes、Core、Apache Mesos、DC/OS
• 服务注册与发现：Zookeeper、etcd、Consul
• 脚本语言：python、ruby、shell
• 日志管理：ELK、Logentries
• 系统监控：Datadog、Graphite、Icinga、Nagios
• 性能监控：AppDynamics、New Relic、Splunk
• 压力测试：JMeter、Blaze Meter、loader.io
• 预警：PagerDuty、pingdom、厂商自带如 AWS SNS
• HTTP 加速器：Varnish
• 消息总线：ActiveMQ、SQS
• 应用服务器：Tomcat、JBoss
• Web 服务器：Apache、Nginx、IIS
• 数据库：MySQL、Oracle、PostgreSQL 等关系型数据库；cassandra、mongoDB、redis 等 NoSQL 数据库
• 项目管理（PM）：Jira、Asana、Taiga、Trello、Basecamp、Pivotal Tracker

在工具的选择上，需要结合公司业务需求和技术团队情况而定。（注：更多关于工具的详细介绍可以参见此文：51 Best DevOps Tools for #DevOps Engineers）

软性需求：文化和人

DevOps 成功与否，公司组织是否利于协作是关键。开发人员和运维人员可以良好沟通互相学习，从而拥有高生产力。并且协作也存在于业务人员与开发人员之间。

出席了 2016 年伦敦企业级 DevOps 峰会的 ITV 公司在 2012 年就开始落地 DevOps，其通用平台主管 Clark 在接受了 InfoQ 的采访，在谈及成功时表示，业务人员非常清楚他们希望在最小化可行产品中实现什么，工程师们就按需交付，不做多余工作。

这样，工程师们使用通用的平台（即打通的工具链）得到更好的一致性和更高的质量。此外，DevOps 对工程师个人的要求也提高了，很多专家也认为招募到优秀的人才也是一个挑战。

DevOps 的采用现状

哪些公司在用？

DevOps 正在增长，尤其是在大企业中：调查发现，DevOps 的接受度有了显著提高。74% 的受访者已经接受了 DevOps，而去年这一比例为 66%。目前，在 81% 的大企业开始接受 DevOps，中小企业的接受度仅为 70%。

那么具体而言都有些公司在采用 DevOps 呢？Adobe、Amazon、Apple、Airbnb、Ebay、Etsy、Facebook、LinkedIn、Netflix、NASA、Starbucks、Target（泛欧实时全额自动清算系统）、Walmart、Sony 等等。

他们怎么实施的？

首先，大企业正在自下而上接受 DevOps，其中业务单位或部门（31%）以及项目和团队（29%）已经实施 DevOps。不过，只有 21% 的大企业在整个公司范围内采用了 DevOps。

其次，在工具层面上，DevOps 工具的用量大幅激增。Chef 和 Puppet 依然是最常用的 DevOps 工具，使用率均为 32%。Docker 是年增长率最快的工具，用量增长一倍以上。Ansible 的用量也有显著增加，使用率从 10% 翻倍至 20%。