DevOps技术栈介绍

由来

　　DevOps（Development和Operations的组合词）是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。——维基百科

　　DevOps是一种文化转变，或者说是一个鼓励更好地交流和协作（即团队合作）以便于更快地构建可靠性更高、质量更好的软件的运动。而目前对 DevOps 有太多的说法和定义，不过它们都有一个共同的思想：“解决开发者与运维者之间曾经不可逾越的鸿沟，增强开发者与运维者之间的沟通和交流”。

DevOps 可以用一个公式表达：

文化观念的改变 + 自动化工具 = 不断适应快速变化的市场

其核心价值在于以下两点：

更快速地交付, 响应市场的变化。

更多地关注业务的改进与提升。

为什么需要DevOps

　　当今世界改变的速度已与过去不同，而每当经历一个颠覆性的技术革命时，都给这个世界带来了深刻的变化，大数据、云计算、人工智能、VR/AR和区块链等新兴技术推动着世界不断变化，如何应对这样一个VUCA时代，让我们能够在环境变化的时候快速响应呢？

 

V=Volatillity（易变性）是变化的本质和动力，也是由变化驱使和催化产生的

U=Uncertainty（不确定性）缺少预见性,缺乏对意外的预期和对事情的理解和意识

C=Complexity（复杂性）企业为各种力量，各种因素，各种事情所困扰。

A=Ambiguity（模糊性）对现实的模糊，是误解的根源，各种条件和因果关系的混杂。

产品迭代

　　一开始的时候就设计好了产品最终的效果，然后按照零部件一步步迭代生产，其步骤可以用下图所示：

 

现实的产品迭代中却是这样的，对话如下：

用户：我平时上下班都是走路，每天都要走五公里，好辛苦，有没有办法帮我设计个工具，解决下我的痛点。

我们思考了下，觉得这个不是很难嘛，可以试下，于是我们讨论 -> 设计 -> 开发 -> 测试 -> 交付给用户了一个滑板。

用户：这个滑板不好操控，可以给我加个扶手吗？

然后我们按照用户新的需求，生产了个滑板车。

用户：滑板车得滑着走，能不能让我可以骑着走的。

我们继续改进产品，生产了个自行车。

用户：自行车还得登着走，路程远了也很累。

我们又继续优化，把它变成了电瓶车。

用户：电瓶车倒是解决了的需求，不过就是不太安全，能再优化下产品吗？

经过各种努力我们最后生产出了一辆漂亮的小轿车交付给了用户，终于让用户满意了。

现实中的用户其实一开始并不知道自己想要什么，但是直到看到了我们的产品，他才知道自己不想要什么。

即让现实的产品迭代是如此曲折和反复的，那我们有没有办法快速交付价值、灵活响应变化呢？答案就是DevOps，它是面向业务目标，助力业务成功的最佳实践。

产品的迭代需要DevOps，那么技术的革新更加促进了DevOps的快速发展和落地实施，下面让我们一起看一下技术又是如何支持产品的迭代而不断革新地呢？

技术革新

　　在以前的系统中业务单一、逻辑简单、用户量少，项目团队的规模一般在 10~30人。而现在的系统要面对不同用户的定制化推荐等，互联网连接着人与人、人与物、以及物与物，业务也变得越来越复杂，功能越来越多，如果整个系统耦合在一起，则必定会牵一发而动全身，导致系统维护起来相当困难。

因此IT技术架构也随着系统的复杂化而不断地变化革新，从早期所有服务的All In One发展到现在的微服务架构、从纯手动操作到全自动化流程、从单台物理机到云平台，下图展示了IT技术革新的变化：

 

现在DevOps已经成为发展的趋势了，那它又是怎么实现落地的呢？

如何实现DevOps

其实DevOps核心思想就是：“快速交付价值，灵活响应变化”。其基本原则如下：

高效的协作和沟通；

自动化流程和工具；

快速敏捷的开发；

持续交付和部署；

不断学习和创新。

 

然而这些基本原则又是如何与项目研发息息相关的呢，也就是它们在我们的开发过程中的各个环节是如何体现的？

 

• 敏捷管理：一支训练有素的敏捷开发团队是成功实施DevOps的关键。

根据康威定律：软件团队开发的产品是对公司组织架构的反映。

• 人与人之间的交流很复杂，每个人的精力是有限的，因此当问题很复杂，需要协调地去解决时，需要将组织划分进而提高沟通效率。
• 团队成员工作的系统设计依赖于成员之间的沟通，管理人员可以调整划分模式，实现团队之间的不同沟通方式，这也会影响系统的设计。
• 如果子系统有清晰的外部通信便捷，那么就可以有效地降低通信成本，响应地设计将更加适合和有效。
• 需要不断优化一个复杂的系统，并容错性和故障恢复率的帮助下进行优化，不要期望大而全面的设计或架构，因为它们的开发以迭代的方式发生。

以下是一些具体的实践建议：

• 利用一切手段提高通信效率，如Slack、Github和Wiki，且只与相关人员进行沟通，每个人和每个系统必须有明确的职责，在遇到问题时，知道该找谁去解决。
• 在MVP模式下设计一套系统，以迭代的方式优化及验证，并确保系统的弹性。
• 采用与系统设计相一致的团队，以扁平化和以业务为基准的方式去简化团队，每个小团队之间必须有对应负责的模块，避免模糊的界限，以免在发生问题时互相推卸责任。
• 要做小而美的团队，人员数量的增加会降低效率以及加大成本，亚马逊CEO Jeff Bezos有个一个经验法则：如果两个披萨对于一个团队来说不够，那么这个团队就太大了。一般来说，一家互联网公司的产品团队由7到8个人组成（包括前端和后端测试、交互和用户体验师，一些人可能身兼数职）。

在查看以下微服务标准时，我们可以很容易地看到微服务与康威定律之间的密切关系：

• 由分布式服务组成的系统
• 企业部门的业务线
• 开发优秀的产品
• Smart endpoints and dumb pipes
• DevOps
• 容错
• 快速发展

所以根据公司情况调整组织结构是首要条件，它将直接影响到需求、设计和开发阶段的效率、以及沟通的成本。

• 持续交付部署：实现应用程序的自动化构建、部署、测试和发布。
• 通过技术工具，把传统的手工操作转变为自动化流程，这不仅有利于提高产品开发、运维部署的效率，还将减少人为因素引起的失误和事故，提早发现问题并及时地解决问题，这样也保证了产品的质量。下图展示了DevOps自动化的流程：

 

• IT服务管理：可持续的、高可用的IT服务是保障业务正常的关键要素，它与业务是一个整体。
• IT服务管理（ITSM）直接影响产品运营的整个生命周期，传统的IT服务管理（像ITIL）在生产中做的非常好了，但是它对于DevOps来说又显得过于繁琐，所以有必要为DevOps创建一个只关注业务持续性的ITMS，它只需要很少的必要资源来为相应的业务提供服务，ITMS更多地从业务角度考虑了。
• 精益管理：建立一个流水线式的IT服务链，打通开发与运维的鸿沟，实现开发运维一体化的敏捷模式。
• JIT（Just In time）：JIT用一句话描述就是消耗最少的必要资源，以正确的数量，生产和运送正确的零件。在这种模式下工作，可以最大程度上降低库存，防止过早或者过度生产。大多数公司更倾向用库存来避免潜在的停线风险，而丰田却反其道而行之。通过减少库存“逼迫”对生产中产生的问题做及时且有效的反应。当然JIT这一模式对解决问题的能力是相当大的考验，在能力不足的情况下，会有相当大的断线风险。Jidoka（Build in quality）：自动化， TPS/精益生产渴望生产的过程控制能像“人”一样智能，在第一时间就异常情况下自动关闭。这种自动停机功能可以防止坏件流入下游，防止机器在错误的生产状态下造成损坏，也可以让人更好的在当前错误状态下进行故障分析。当设备能够做到自动分析故障时，就可以将监管机器的“人”真正解放出来，做到对人力成本的节省。 
•  

而精益软件开发是精益生产和实践在软件开发领域的应用，总结为如下七条原则：

• 消除浪费
• 增强学习
• 尽量延迟决定
• 尽快发布
• 下放权力
• 嵌入质量

1. 全局优化

精益管理贯穿于整个DevOps阶段，它鼓励主动发现问题，不断的优化流程，从而达到持续交付、快速反馈、降低风险和保障质量的目的。接下来让我们看看DevOps具体的实现方法。

实施DevOps的具体方法

• 建立快速敏捷团队

根据之前介绍的康威定律，我们可以看下目前公司中的项目团队结构是怎么的，如下图所示：

 

目前大多数IT互联网公司普遍的分层结构，它们一般分为七大部门：产品策划、设计美术、前端工程师、后端工程师、测试工程师、运维&DBA和市场运营等。各部门之间天然的形成了沟通障碍墙，相互之间主要以邮件和会议的形式沟通，效率低下、需求变更困难、很难快速响应市场变化和持续交付高品质的产品。

我们会按照业务功能划分团队，建立沟通群组，设置产品负责人（一个策划人员）、Scrum Master（我们一般选择测试人员担任，测试驱动开发模式）和开发者团队（前端工程师、后端工程师、测试各一名），最后的组织结构和系统架构如下图所示：

一个高效的敏捷团队是DevOps能落地的保障，那么自动化流程就是保证产品快速交付和持续部署的有效机制。

• 实现自动化的流程
• 

 

• 提交：工程师将代码在本地测试后，提交到版本控制系统，如 Git代码仓库中。
• 构建：持续整合系统（如Jenkins CI），在检测到版本控制系统更新时，便自动从Git代码仓库里拉取最新的代码，进行编译、构建。
• 单元测试：Jenkins完成编译构建后，会自动执行指定的单元测试代码。
• 部署到测试环境：在完成单元测试后，Jenkins可以将应用程序部署到与生产环境相近的测试环境中进行测试。
• 预生产环境测试：在预生产测试环境里，可以进行一些最后的自动化测试，例如使用Appium自动化测试工具进行测试，以及与实际情况类似的一些测试可由开发人员或客户人员手动进行测试。
• 部署到生产环境：通过所有测试后，便可以使用灰度更新将最新的版本部署到实际生产环境里。
• Trello
• Teambition
• Worktile
• Tower

技术栈

敏捷管理工具

以上工具使用大同小异，选择一款适合自己团队的就好。

产品&质量管理

• confluence
• 禅道
• Jira
• Bugzila

其中confluence和禅道主要是产品的需求、定义、依赖和推广等的全面管理工具；而Jira和Bugzilla是产品的质量管理和监控能力，包括测试用例、缺陷跟踪和质量监控等。目前使用Jira较多。

代码仓库管理

• Git
• Gitlab
• Github

Git是一个开源的分布式版本控制系统；Gitlab和Github是用于仓库管理系统的开源项目，它们使用Git作为代码管理工具，并在此基础上搭建起来的web服务。

开发流程规范

Git Flow

Git Flow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。Git Flow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。Git Flow模型如下图：

Github Flow

Github Flow是Git Flow的一个更简单的替换方案，它只有一个feature分支和一个master分支，简单而干净。Github Flow模型如下图：

Gitlab Flow

GitHub Flow认为你可以通过合并feature分支直接把代码部署到线上。Gitlab Flow模型如下图：

自动化构建脚本

• Gradle
• Maven
• SBT
• ANT

目前主要使用Gradle和Maven，而Gradle是一个基于Apache Ant和Apache Maven概念的项目自动化构建工具。它使用一种基于Groovy的特定领域语言(DSL)来声明项目设置，抛弃了基于XML的各种繁琐配置。面向Java应用为主。当前其支持的语言限于Java、Groovy、Kotlin和Scala。

虚拟机与容器化

• VMware
• VirtualBox
• Vagrant
• Esxi
• Docker
• Kvm

VMware和VirtualBox是最常用的虚拟机，支持非常多的平台，而Vagrant是构建在虚拟化技术之上的虚拟机运行环境管理工具。通过Vagrant可以方便实现的对虚拟机的管理，包括建立和删除虚拟机、配置虚拟机运行参数、管理虚拟机运行状态、自动化配置和安装开发环境必须的各类软件、打包和分发虚拟机运行环境等。

Esxi是VM的一款虚拟化产品

KVM（Kernel-based Virtual Machine）是一个开源的系统虚拟化模块，它需要硬件支持，如Intel VT技术或者AMD V技术，是基于硬件的完全虚拟化，完全内置于Linux。

Docker是一个开源的应用容器引擎，它让开发者可以打包他们的应用以及依赖包到一个可移植的容器中，然后发布到任何流行的Linux机器上，也可以实现虚拟化。

VM管理与容器管理

• OpenStack
• Kubernetes

OpenStack是一个旨在为公共及私有云的建设与管理提供软件的开源项目。它不是一个软件，而是由几个主要的组件组合起来完成一些具体的工作。OpenStack由以下五个相对独立的组件构成：

lOpenStack Compute(Nova)是一套控制器，用于虚拟机计算或使用群组启动虚拟机实例；

lOpenStack镜像服务(Glance)是一套虚拟机镜像查找及检索系统，实现虚拟机镜像管理；

lOpenStack对象存储(Swift)是一套用于在大规模可扩展系统中通过内置冗余及容错机制，以对象为单位的存储系统，类似于Amazon S3；

lOpenStack Keystone，用于用户身份服务与资源管理以及

lOpenStack Horizon，基于Django的仪表板接口，是个图形化管理前端。

 

简单的说，kubernetes是管理container的工具，openstack是管理VM的工具。

container可以运行在物理机上，也可以运行在VM上。所以kubernetes不是需要openstack的支持。但对于云计算来说，很多IasS都通过openstack来管理虚拟机。然后用户可以在这些虚拟机上运行docker，可以通过kubernetes进行管理。

持续集成（CI）&持续部署（CD）

• Jenkins
• Hudson
• Travis CI
• CircleCI

Jenkins是一个开源软件项目，是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能，它的前身为Hudson。

Travis CI 是目前新兴的开源持续集成构建项目，它与jenkins很明显的区别在于采用yaml格式，简洁清新独树一帜。

CircleCI是一个为web应用开发者提供服务的持续集成平台，主要为开发团队提供测试，持续集成，以及代码部署等服务。

自动化测试

Appium

Appium是一个移动端的自动化框架，可用于测试原生应用，移动网页应用和混合型应用，且是跨平台的。可用于IOS和Android以及firefox的操作系统。

Selenium

Selenium 测试直接在浏览器中运行，就像真实用户所做的一样。Selenium 测试可以在 Windows、Linux 和 Macintosh上的 Internet Explorer、Mozilla 和 Firefox 中运行。

Mock测试

Mock测试就是在测试过程中，对于某些不容易构造或者不容易获取的对象，用一个虚拟的对象来创建以便测试的测试方法。这个虚拟的对象就是Mock对象，Mock对象就是真实对象在调试期间的代替品。Java中的Mock框架常用的有EasyMock和Mockito等。

消费者驱动契约测试

契约测试是一种针对外部服务的接口进行的测试，它能够验证服务是否满足消费方期待的契约。当一些消费方通过接口使用某个组件的提供的行为时，它们之间就产生了契约。这个契约包含了对输入和输出的数据结构的期望，性能以及并发性。而PACT是目前比较流的消费者驱动契约测试框架。

自动化运维工具

• Ansible
• Saltstack
• Puppet
• Chef

IT运维自动化是指将IT运维中日常的、大量的重复性工作自动化，把过去的手工执行转为自动化操作。自动化是IT运维工作的升华，IT运维自动化不单纯是一个维护过程，更是一个管理的提升过程，是IT运维的最高层次，也是未来的发展趋势。下图为常用自动化运维工具对比：

名称	Ansible	Saltstack	Puppet	Chef
开发语言	Python	Python	Ruby	Ruby
架构	无client	C/S	C/S	C/S
协议	SSH	SSH/ZMQ/RAET	HTTP	HTTP
二次开发	支持	支持	不支持	不支持
通信验证	是	是	是	是
加密	SSL	AES	Openssh
配置文件	Yaml	Yaml	Ruby语法格式	Ruby语法格式
Web UI	支持（商业版本）	支持	支持	支持
命令执行	支持	支持	不支持（配置模块可支持）
任务执行顺序	顺序	顺序	非序列

 

监控管理工具

• Zabbix
• Open-falcon
• Nagios
• Cacti
• ELK

Zabbix

Zabbix是一个基于WEB界面的提供分布式系统监视以及网络监视功能的企业级开源解决方案。

Open-falcon

Open-Falcon 是小米运维部开源的一款互联网企业级监控系统解决方案。

Nagios

Nagios是一个企业级的开源IT监控工具，可以对网络、服务器、应用进行全面的监控。

Cacti

Cacti是一个完整的网络图形解决方案，旨在利用RRDTool的数据存储和图形功能。Cacti提供了一个快速轮询器，高级图表模板，多种数据采集方法和用户管理功能。

ELK 日志分析系统

ELK Stack是开源日志处理平台解决方案。它由日志采集解析工具 Logstash、基于 Lucene 的全文搜索引擎 Elasticsearch、分析可视化平台 Kibana三部分组成。

云监控（如Amazon CloudWatch）

Amazon CloudWatch 是一项针对 AWS 云资源和在 AWS 上运行的应用程序进行监控的服务。您可以使用 Amazon CloudWatch 收集和跟踪各项指标、收集和监控日志文件、设置警报以及自动应对 AWS 资源的更改