DevOps实践一:DevOps概述 - 知乎

标签: | 发表时间:2019-10-03 16:17 | 作者:
出处:https://zhuanlan.zhihu.com

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(二维码自动识别)

相关 [devops 实践 devops] 推荐:

DevOps实践一:DevOps概述 - 知乎

- -
DevOps系列文章包含了本人在工作中的实践和认知理论,现总结并分享出来,希望能够给“迷你型”团队在DevOps上的实践提供一个“反面教材”和可行性建议. 本系列主要包含以下文章(过程中可能也会有所更改):. DevOps实践一:DevOps概述. DevOps实践二:持续集成、持续交付和持续部署.

DevOps最佳实践(200711)

- - 人月神话的BLOG
今天准备谈下DevOps过程最佳实践以及DevOps支撑平台建设中的一些思考. 在前面文章里面我就已经谈到了传统企业IT架构转型或企业数字化建设需要解决两个方面问题. 其一:业务层面,重点是中台规划和建设. 其二:技术层面,重点是云原生解决方案,包括了微服务,DevOps和容器云. 当然,如果你是传统的软件开发框架技术,或者传统的基于虚拟机的PaaS平台也可以上DevOps实践,但是我们更加推荐的还是基于微服务和容器云技术来实践DevOps.

再谈DevOps实践和价值(12.11)

- - 人月神话的BLOG
今天再谈下DevOps过程实践和实际的收益价值问题. 对于DevOps先引用网上的一段总结如下. 这里我们先分析一下DevOps是什么. 大部分人对DevOps的解释都是从这个单词直译过来的就是开发运维一体化,其实这样理解很片面. 其实我们不难从Patrick提出DevOps的过程得出结论,DevOps的精准解释应该是通过敏捷的软件开发与敏捷的运维管理相结合达到业务的快速、灵活响应,也就是DevOps = Dev Agile Ops Agile.

让DevOps起作用

- - InfoQ cn
根据Neil Garnichaud在Dr. Dobb’s上发表的文章《 究竟什么是DevOps》,想要频繁地发布高质量的软件,首先需要弄清如何使开发人员、QA人员和运营人员在一起协同工作. 在软件公司里,特别是在开发基于云的网络应用, 而又缺少有才华的、合格的员工的公司中,压缩的时间进度和最低限度的QA是压力的根源.

【DevOps进行时】持续交付广义流水线探索 – 农行DevOps实践之路

- - DevOps 博客
持续交付流水线是DevOps落地的重要工程实践,但是业界普遍把持续交付流水线建设等同于CI/CD,很多人觉得部署好Jenkins,配置个自动化job,能编译,能部署,能跑自动化测试就搞定了. 其实真正的持续交付流水线远不仅仅是这些内容,它应该包括从需求/创新的提出,到功能架构设计,计划跟踪,开发编码,编译打包,测试验证,投产上线,再到将实现的功能让用户使用起来的全过程.

对DevOps实践的一些思考01(1.15)

- - 人月神话的BLOG
最近1到2年的博客文章,我谈微服务架构的比较多,而专门谈DevOps的比较少,包括对DevOps支撑平台和DevOps实践的一些关键点思考. 19年准备对DevOps这块进行深入的了解和实践. 在18年12月11日,当时写过一篇对DevOps实践价值的思考,其中的重点是在谈DevOps,容器云和微服务架构框架的三元一体化.

中小团队基于Docker的devops实践 - 掘金

- -
笔者所在的技术团队负责了数十个项目的开发和维护工作,每个项目都至少有dev、qa、hidden、product四个环境,数百台机器,在各个系统之间疲于奔命,解决各种琐碎的问题,如何从这些琐碎的事情中解放出来. devops成了我们不二的选择. 文章是基于目前的环境和团队规模做的devops实践总结,方案简单易懂,容易落地且效果显著.

对DevOps流水线设计的优化和改进实践(201014)

- - 人月神话的BLOG
对于DevOps过程支撑平台,我在前面已经写过相应的文章. 在整个DevOps平台的建设过程中可以看到持续集成和持续交付始终都是平台的一个重要内容. 而在整个持续集成和交付过程中,流水线设计又是相对关键的一个内容. 通过流水线设计可以很灵活的通过可视化配置的方式,将我们软件持续集成中涉及到的编译构建,打包,部署,代码检查,测试,环境迁移等各种活动编排在一起,形成一个自动化执行的完成流程.

DevOps在证券互联网研发中的应用与实践

- - DockOne.io
近些年金融科技在证券行业发挥的作用越来越重要,运用金融科技赋能业务发展,通过个性化服务构建护城河,将金融科技与业务创收和降本增效相结合开始成为证券从业人员所关注的问题,如何提升研发交付效率、小步快跑、快速迭代是所有证券行业科技研发团队共同关心的话题. 敏捷为快速迭代提供了理论思想和方法指导,DevOps为敏捷落地提供了补充和工具支持.

DevOps,你真的了解吗?

- - IT经理网
与大数据和PRISM(NSA的监控项目之一),DevOps(开发运维)如今是科技人士挂在嘴边的热词,但遗憾的是,类似圣经,每个人都引用DevOps的只言片语,但真正理解并能执行的人极少. 根据CA的一项 调查,45%的受访者并不了解DevOps的含义,其余则有17%认为DevOps只不过是炒作. DevOps如今几乎成了创新的同义词,但其原本的含义却在业界的流传中被人们弃之脑后.