Devops的“定义”

近些年来，DevOps在我们身边出现的频率越来越高了，各种大会上经常出现DevOps专场，企业的DevOps转型看起来迫在眉睫，公司内部也要设计和开发DevOps平台，这么看来，DevOps无处不在。
那DevOps到底是什么呢， 好像从来没有人能说清楚。
我们先来看看维基百科对DevOps的定义：

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

其实看了维基百科的定义后，估计也没谁能看懂到底是在说什么。
其实，DevOps的秘密就来源于他的名字所代表的两种角色---开发和运维
这两种角色之间究竟有什么问题呢？我们从软件工程诞生以来所经历的三个重要发展阶段说起

瀑布式开发模式

瀑布模式

瀑布模型

瀑布式开发模式将软件交付过程划分成几个阶段，从需求到开发、测试和运维，它的理念是软件开发的规模越来越大，必须以一种工程管理的方式来定义每个阶段，以及相应的交付产物和交付标准，以期通过一种重流程，重管控，按照计划一步步推进整个项目的交付过程。

可是，随着市场环境和用户需求变化的不断加速，这种按部就班的方式有一个严重的潜在问题。

软件开发活动需要在项目一开始就确定项目目标、范围以及实现方式，而这个时间点往往是我们对用户和市场环境信息了解最少的时候，这样做出来的决策往往带有很大的不确定性，很容易导致项目范围不断变更，计划不断延期，交付上线时间不断推后，最后的结果是，即便我们投入了大量资源，却难以达到预期的效果。

敏捷式开发模式

敏捷模式

敏捷开发模型

敏捷的核心理念是既然我们无法充分了解用户的真实需求是怎样的，那么不如将一个大的目标不断拆解，把它变成一个个可交付的小目标，然后通过不断迭代，以小步快跑的方式持续开发。

与此同时，将测试工作从研发末端的一个独立环节注入整个开发活动中，对开发交付的内容进行持续验证，保证每次可交付的都是一个可用的功能集合，并且由于质量内建在研发环节中，交付功能的质量也是有保障的。

敏捷是一种更加灵活的研发模式，但是并不会直接提升团队的开发速度，敏捷之所以更快，根本原因在于持续迭代和验证节省了大量不必要的浪费和返工。

DevOps模式

DevOps模式

于是，活在墙的另一端的运维团队成了被拉拢的对象。这些在软件交付最末端的团队始终处于一种“背锅”的状态，他们也有改变的意愿，所以 DevOps 应运而生，也就是说，DevOps 最开始想要打破的就是开发和运维之间的对立和隔阂。

该模式强调一个运维和开发不断沟通的能力环，在开发阶段我们沿袭敏捷的开发模式，在运维阶段，我们强调自动化的运维，并不断讲已经上线的产品中的问题反馈给开发，以进行问题修复。

Develop和Operation的历史问题

开发和运维人员素来就被一种叫做部门墙的隐形之墙所隔离，这种问题由来已久，

原因1：开发和运维的目标不一致，开发的目的是不断的增加新功能，不断完善需求，不断发布新版本，总之对于开发来说，唯一不变的就是变化，但是，对于运维来说，首要的问题是要求稳，因为一切问题的来源都是变化。

原因2：两个角色所在的部门考核标准不一样，对于开发来说，新开发一个需求考核就递增一点，是个累加的过程；而对于运维来说，即使将发布工作做的极致，起点也只是0，因为，这本来就是运维应该做的，一旦出了问题，便会从0开始递减，是个递减的过程。

DevOps定义

DevOps 是通过平台（Platform）、流程（Process）和人（People）的有机整合，以 C（协作）A（自动化）L（精益）M（度量）S（共享）文化为指引，旨在建立一种可以快速交付价值并且具有持续改进能力的现代化 IT 组织。

Devops的生命周期

DevOps能力环

1.Plan

需求阶段，无论该需求来自客户的新需求还是BUG修改，这是触发整个Devops流程的起点，因此，作为Devops团队，开发团队需要把运维团队作为首要干系人，在进行开发之前获取他们的意见，比如运维人员可能会对日志文件的类型和结构提出建议。

2. build

开发/构建阶段，该阶段需要开发人员开发和运维团队也要保持密切的沟通，对于开发进度，单元测试的执行等，构建工具的使用，持续集成等运维人员也需要有所了解

3. Test

测试阶段，测试方案的规划，使用什么测试工具，是否使用自动化测试等（有一种新的Taas服务，将测试作为一种基础服务提出），都需要跟开发和运维沟通。

4. Release

该阶段主要是对新版本的上线做的一系列准备，例如release之前需要对该版本支持的平台版本进行确认，测试结果进行确认，安全检查等报告进行核实，确保上线之前最后一套手续的完整性

5. Deploy

部署阶段，部署工具的使用，部署方案的制定（A/B部署，金丝雀部署等），以及回滚方案的确认，确保在服务不受影响的情况下，顺利将新版本发布。

6. Operation / Monitor

运维阶段，对于已经上线的服务做一系列的性能监控（CPU , Memory等），日志分析，执行系统及软件的例行审计，执行备份，对操作系统的更新补丁升级，优化系统性能等，并及时发现监控过程中的问题，以及搜集来自于客户的问题清单，并将此作为下次版本更新的需求。

总 结： Devops生命周期是一个环形结构，它不会以项目上线为终止，而是不断会搜集来自于客户的需求，以对整个软件服务做不断的更新以及优化，这种结构就要求Devops整个流程的高效性。

二 Devops实现

一般软件开发过程可以分成：持续开发、持续测试、持续集成、持续交付、持续部署和持续监控等部分

2.1持续开发

持续开发是DevOps 软件不断开发的阶段。
与瀑布模型不同的是，敏捷开发中软件可交付成果被分解为短开发周期的多个任务节点，在很短的时间内开发并交付。
这个阶段包括编码和构建阶段，并使用Git和SVN等工具来维护不同版本的代码，打包代码到可执行文件中，这些文件可以转发给自动化测试系统进行测试。

2.2持续测试

在这个阶段，开发的软件将被持续地测试bug。
对于持续测试，使用自动化测试工具，如Selenium（wen自动化测试工具）等。这些工具允许质量管理系统完全并行地测试多个代码库，以确保功能中没有缺陷。
在这个阶段，使用Docker容器实时模拟“测试环境”也是首选。一旦代码测试通过，它就会不断地与现有代码集成。

2.3持续集成

持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起

持续集成

2.4持续交付

在持续集成的基础上，将集成后的代码部署到预生产环境中（production-like environments），完成单元测试后，把代码部署到连接数据库的Stanginx环境中更多的测试，以及时发现可能产生的问题。如果代码没有问题，可以继续手动部署到生产环境中。

持续交付

2.5持续部署

它是将代码部署到生产环境的阶段。
在这里，我们确保在所有服务器上正确部署代码。 如果添加了任何功能或引入了新功能，那么应该准备好迎接更多的网站流量。 因此，系统运维人员还有责任扩展服务器以容纳更多用户。
由于新代码是连续部署的，因此配置管理工具可以快速，频繁地执行任务。 Puppet，Chef，SaltStack和Ansible是这个阶段使用的一些流行工具。容器化工具在部署阶段也发挥着重要作用。 Docker和Vagrant是流行的工具，有助于在开发，测试，登台和生产环境中实现一致性。 除此之外，它们还有助于轻松扩展和缩小实例。

持续部署

2.5.1部署策略

• 1.蓝/绿部署
  蓝绿部署就是为应用准备两套一模一样的环境，一套是蓝环境，一套是绿环境，每次只有一套环境提供线上服务。这里的蓝和绿，只是用于区分两套环境的标志而已。在新版本上线时，先将新版本的应用部署到没有提供线上服务的环境中，进行上线前验证，验证通过后就达到了准备就绪的状态。在发布时间点，只要将原本指向线上环境的路由切换成另外一套环境，整个发布过程就完成了。

  一般来说，这种方式的实现成本比较高。因为有两套一模一样的环境，只有一套用于真正地提供线上服务。为了减少资源浪费，在实际操作中，另外一套环境可以当作预发布环境使用，用来在上线之前验证新功能。另外，在这种模式下，数据库普遍还是采用同一套实例，通过向下兼容的方式支持多个版本的应用。

蓝绿部署

特点是：全量部署，实现成本比较高

• 2.灰度发布

  灰度发布，也叫金丝雀发布。与蓝绿部署相比，灰度发布更加灵活，成本也更低，所以，在企业中是一种更为普遍的低风险发布方式。

  在生产环境的少量虚拟机上部署新的服务，并对特定用户开放。这些特定用户可能是随机采样的用户，也有可能是开发的成员等等。我们应该严格监控金丝雀，一旦发现错误，则应立即回滚。如果一段时间内运行正常，那么可以将其他机器一并升级为最新版本。

  1.为大部分用户的请求流向

  2.为金丝雀数据流向

灰度发布

特点是：金丝雀数目少于提供给Customer的服务器。

• 3.暗部署

  在生产环境中部署服务的两个不同版本，可能是新旧版本共存，或者两个新版本共存，要么呈现了不同的用户界面，要么呈现了不同的行为，测试用户的偏好。如果某个版本在业务量上（比如访问量等）呈现出更好的行为，那么整个版本就成为发布版本，另一个版本则作废。

暗部署

特点是：访问流量数目相同

总结：以上这三种低风险发布手段，如果应用规模整体不大，蓝绿部署是提升系统可用性的最好手段，比如各类 Hot-standby 的解决方案，其实就是蓝绿部署的典型应用。而对于大规模系统来说，考虑到成本和收益，灰度发布显然就成了性价比最高的做法。如果想要跑一些线上的测试收集真实用户反馈，那么，暗部署是一种不错的选择。

2.6持续监控

这是DevOps生命周期中非常关键的阶段，旨在通过监控软件的性能来提高软件的质量。这种做法涉及运营团队的参与，他们将监视用户活动中的错误/系统的任何不正当行为。

监控就是一种全量的测试。

常见的线上验证手段

-1.采用灰度发布、用户众测等方式，逐步观察用户行为并收集用户数据，以验证新版本的可用性是否符合预期。

这里的主要实践之一就是埋点功能。在互联网产品中，埋点是一种最常用的产品分析和数据采集方法，也是数据驱动决策的主要依据之一。它的价值就在于，根据预先设计的收集和监控数据的方法，采集用户的行为、产品质量、运营数据等多维度的数据。大型公司一般都实现了自己的埋点 SDK，根据产品设计需求，可以自动化地采集数据，并配置采集粒度；对于小公司来说，像友盟这种第三方统计工具，就可以满足绝大多数情况的需求了。

-2. 用户反馈。

除了自动化的采集数据之外，用户主动的反馈也是获取产品信息的第一手资料。而用户反馈的渠道有很多，公司里面一般都有用户运营和舆情监控系统，用于按照“关键字”等自动爬取各个主流渠道的产品信息。一旦发现负面的反馈，就第一时间进行止损。

3.使用线上流量测试。

• 将线上真实的用户流量复制下来，以实时或者离线的方式回放到预发布环境中用于功能测试。
• 使用只读的查询内容来验证搜索接口
• 按照倍数放大和缩小流量，以达到服务压测目的
• 可以自动比对线上服务和预发布服务的返回结果以验证相同的流量过来时，两个版本之间系统的行为是否一致

监控工具

这也可以通过使用专用监控工具来实现，该工具将持续监控应用程序性能并突出问题。
使用的一些流行工具是Splunk，ELK Stack，Nagios，NewRelic和Sensu。这些工具可帮助密切监视应用程序和服务器，以主动检查系统的运行状况。它们还可以提高生产率并提高系统的可靠性，从而降低IT支持成本。
发现的任何重大问题都可以向开发团队报告，以便可以在持续开发阶段进行修复。这些DevOps阶段连续循环进行，直到达到所需的产品质量。

DevOps生命周期工具

DevOps生命周期工具

Devops的价值

企业在应用了DevOps之后可以得到3个业务优势：
产品快速推向市场：缩短开发周期时间和更高的部署频率
提高质量：提高可用性，提高变更成功率，减少故障，等等
提高组织的有效性：将时间花在价值增加活动中，减少浪费，同时交付更多的价值至客户手中