DevOps实践一：DevOps概述 - 知乎

0. 前言

DevOps系列文章包含了本人在工作中的实践和认知理论，现总结并分享出来，希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议。

本系列主要包含以下文章(过程中可能也会有所更改)：

• DevOps实践一：DevOps概述
• DevOps实践二：持续集成、持续交付和持续部署
• DevOps实践三：如何构建面向应用的CMDB系统
• DevOps实践四：如何打造持续交付系统
• DevOps实践五：监控系统与持续交付系统的联动
• DevOps实践六：运维标准化体系的建设
• DevOps实践七：微服务架构与DevOps
  

1. DevOps 的产生

人类曾有长达250万年的时间靠采集及狩猎维生，并不会特别干预动植物的生长情形。直立人、匠人或是尼安德特人都会采集野无花果、猎捕野绵羊，但不会去管究竟无花果树该长在哪，羊该在哪片草地吃草，又或是哪只公羊该跟母羊交配。

这段话摘录自《人类简史》，之所以引入这段话，是因为运维技术的发展也可以类比到人类的发展史。运维在很长的时间内，都是在靠“人肉”来提供运维能力，即使是发展到现在，依然如此。虽然国内外有很多大公司，在这方面已经走在前沿并且输出了一些实践经验，但是运维进化的过程还有很长一段路要走。毕竟这世界上，更多的是小公司、小团队。

2009年，Patrick Debois发起了一个名为DevOpsDays的会议，始于比利时，现已经传播到多个国家。术语DevOps现在已经在多种情况下使用。Bass, Weber和Zhu提出的定义是：

DevOps是一组旨在保证高质量的同时，减少将更改提交到系统和将更改放入正常生产之间的时间的实践。

通俗点来说，DevOps的目的在保证高质量的同时减少发布流程的总耗时。然而， 这一点真的这么重要吗？

2. 为什么需要DevOps？

我相信几乎所有的开发、测试、运维都听过敏捷软件开发，有的公司也是采用这种模式来进行产品的快速迭代，以此验证产品的可行性，快速抢占市场、拿到更多投资；或提供更多的功能给用户使用；或修复软件Bug解决用户的抱怨。快速迭代意味着产品需要频繁的部署上线，这也就意味着研发、测试、运维团队必须克服这种频繁上线带来的诸多问题：研发质量低；测试不充分，上线后Bug层出不穷；运维上线部署慢、跟不上研发的节奏，经常由于环境、配置等问题导致应用不能正常提供服务等等等等。

一方面公司希望快速将产品交付给用户使用，另一方面技术人员又害怕这种快速交付，毕竟越快越容易出问题，而且压力大(身上背了很多锅)。

正是在这种背景下，DevOps应运而生。为研发、测试、运维团队提供了理论性指导。

3. DevOps模式定义

AWS对DevOps模式做了一个完整的定义，我个人也是倾向于此：

DevOps集文化理念、实践和工具于一身。可以提高组织交付应用程序和服务的能力。与使用传统软件和基础设施管理流程相比，能够帮助组织更快的发展和改进产品。这种速度使组织更好的服务其客户，并在市场上高效的参与竞争。

DevOps文化的宗旨就是为了消除团队之间的壁垒。因此，DevOps的文化理念决定了开发、测试、运维团队不再是一个孤立的团队。彼此之间需要增强合作，成为一个高效的团队。

通过DevOps的定义我们可以一窥其优势：

• 快速交付
• 可靠性
• 增强团队合作
• 规模

这些优势会在后续文章中不断地体现出来。

4. 应用发布流程

在介绍DevOps实践时，我们需要先探讨一下应用发布流程。我简单的画了一个图：

有的公司可能还有预发布环境，但是该图应该能反应大部分公司的整个发布流程。

5. DevOps实践

由于DevOps是一种跨职能(开发、测试、运维)的工作模式，不是一个单独的DevOps工具，因此DevOps作为工具时，它包含了多个工具，形成了一个完整的工具链。结合个人经验，这里先做一个简单的概括，后续文章会将这些进行详解介绍。

对照上面的发布流程中，我举出每个环节所使用的常用工具：

• 代码仓库，用于存储程序源文件的地方。如：GitLab，Github
• 构建，这是一个持续集成工具，用于编译、打包程序，运行单元测试 如：Jenkins
• 测试，提供有关业务风险反馈的连续测试工具。 如：Selenium
• 发布，快速上线部署，自动化发布。这里我是自研，后续文章会做一个介绍。
• 配置，基础架构配置和管理。如 SaltStack
• 监控，应用监控、基础监控，帮助运维快速定位问题。如：Zabbix, OpenFalcon

上面这些工具，结合业内提出的概念，按照发布流程进行组合，可以概括为以下四点：

• 持续集成

软件发布流程的构建和单元测试阶段。这是由开发者提交变更到代码仓库后自动触发。

• 持续交付

对持续集成的补充，在单元测试完成后，自动部署到测试环境/生产环境。持续交付的中心模式是部署流水线，本质上讲就是一个应用程序从构建、测试、到发布这整个过程的自动化实现。

• 持续部署

持续交付在最后上线阶段需要人工干预，持续部署不需要。持续部署就是在没有明确批准的情况下自动发生。

• 监控

实时获取应用状态和环境状态，异常发生后运维能作出快速反应。

如果对持续集成和持续交付不太理解的，可以参考下面这种图，再对照我上面的应用发布流程图，应该能很快理解：

如果理解了持续交付，可能会有一种持续交付和DevOps是同一个事物的错觉，实则不是。引用维基百科的一段描述作此说明：

Continuous delivery and DevOps have common goals and are often used in conjunction, but there are subtle differences.
While continuous delivery is focused on automating the processes in software delivery, DevOps also focuses on the organization change to support great collaboration between the many functions involved.
持续交付和DevOps有共同的目标，并且经常结合使用，但存在细微差别。虽然持续交付的重点是自动化软件交付流程，但DevOps还专注于组织变更，以支持所涉及的众多功能之间的良好协作。

对此我解读为：持续交付是DevOps的一个子集，是DevOps的一个实践经验。

备注：DevOps于2009年提出，持续交付于2010年提出。

6. 总结

本章主要讲述了DevOps的产生背景，以及一个基本的概念。最后概述性的介绍了DevOps的实践，并列举了一些工具。本章只是开端，一篇理论性的文章也很难让人明白到底什么是DevOps。后面会将个人的一些实践经验进行一个总结，希望能够让读者大致明白我所理解的DevOps。之所以称之为“我所理解的DevOps”，是因为在实践中，我并不是完全遵循了这些理论性指导，个中缘由我会在后面的文章中进行阐述。但我们的重点是在于让软件快速交付、解决运维工作中的痛点，不是吗？我一直坚信，理论是对我们行为模式的指导，并不一定需要完全遵从。

——————————————————分割线————————————————————欢迎大家关注我的公众号： OneAndZero

http://weixin.qq.com/r/0i5OVh-ERUI6rVs193vA(二维码自动识别)