最近几年,由于负责的范围的变化。工作逐渐从某个IT领域或者部门,开始关注到整个IT体系的运转和管理。中间也遇到不少困难,同时也有机会去从更高的层面去学习和实践IT治理。文章主要是总结一下我对DevOps相关的理解和认识。

为什么会有DevOps,解决了什么问题:

  1. 现代企业其实都是通过IT系统进行管理和运营的,在变化迅速和竞争激烈的领域,IT系统的新需求数量越来越多,软件发布的频率越来越高,不少互联网公司24小时内会发布几十个到上百个release到生产环境。与此同时,业务对IT服务和系统的稳定性和质量的要求也在不断提高。如何高效稳定地开发并上线新的业务功能,同时提供高质量的IT服务,关系到企业竞争能力的强弱,关乎商业价值的实现。
  2. 开发团队和运维团队在传统的的企业IT部门中是两个独立的团队。他们的构成和人员背景差异非常大,软件开发团队通常擅长于设计和开发软件功能,算法,他们希望能够尽可能多和快得完成客户或产品部分的需求。而运维团队通常把完成的软件部署到生产环境,负责监控和解决软件系统运行时的问题,希望的是系统的稳定地运行,他们竭尽一切需要达到SLA的标准。

关于测试团队:Test这个环节通常会有专门的测试团队负责,在很早期的时候,测试团队和开发团队也是分开的。不过自从敏捷开发流行以后,测试团队的成员就已经被看做开发部门的一部分了,这也部分归功于微软的贡献,他们当时新发明了SDET(软件开发测试工程师)这个概念,以表明测试工程师也是开发人员。他们写测试用例,进行功能和压力测试,同时需要懂得一些开发技术并拥有自动化测试的能力。开发人员对自己的代码质量也要负责,需要写自己负责模块的单元测试代码,软件开发人员之间需要交叉进行代码review。

下面的DevOps图相信很多朋友都见过了,当然这个图也有不同的变化版本。通过这个图来看,开发和运维团队衔接的最关键环节在Release-Deploy这三个步骤。而这一部分是否能够做得好,直接关系到DevOps在整个IT部门实施的成败。这一部分现在的主要解决方案就是CI/CD-持续集成和持续发布。DevOps不只是一个方法论,其涉及到整个IT团队文化的调整,多种新观念新方法论的实践以及现代化运维工具的应用这三个方面。

DevOps两大流派

对于DevOps问题的解决上,其实分成了两大流派。让我们来探讨一下这两派的观点和适用范围。

传统IT公司的DevOps解决方案,代表 - AWS,IBM...

从传统的运维模式转变到更加灵活和高效的DevOps模式。IT部门还是保持传统的人员配置和工作技能,但是在合作,实践和工具的应用上有很多方向的实践转变。

IT部门文化的转变

开发和运维部门必须打破传统的界限,需要共同承担软件系统运行的稳定性和性能上的责任和义务。运维团队有权利去拒绝没有达到生产环境准入标准的Release。开发和运维之间,测试和运维之间充分的透明度和沟通机制。最好能够在在一起办公,或者至少部分运维团队成员和开发团队成员坐在一起。能够容忍错误的发生,当错误的发生时,不要立刻责罚,而要通过分析,找到根本原因,并通过持续的改进来做好系统的强壮性和避免人为错误造成严重的系统故障。

技术和方法论层面的变革
  • 微服务的应用: IT系统应该逐渐从monolithic的模式转向微服务的模式,这样不同功能/模块的开发和发布能够相对独立,不同的敏捷团队可以更加快速地迭代和测试,同时交给运维团队的发布包的粒度更小,出问题后对整个系统影响更小。同时采用新的运维工具可以无感知逐渐升级微服务,迅速恢复或者回滚故障的微服务。

  • CI&CD:持续集成和持续交付,这个概念其实提出的很早。但是直到最近几年才开始被主流的业界接受。传统的软件发布频率往往是以周或者月为单位进行的。在很多情况下这已经不能满足业务快速迭代的要求,同时也越来越不适应快速迭代的敏捷开发模式。而且这种大粒度的集成和发布(通常一段时间的许多变更会在一个发布中上生产环境)出现问题的可能性和影响都比较大。 而持续集成和持续交付的粒度小到开发人员每一次代码的提交。一旦完成代码提交就会触发构建并执行自动化测试脚本和单元测试,同时测试团队的成员也会收到通知进行测试确认。一旦通过就能够自动发布到stage环境进行最后的UAT确认,接着在运维团队确认后自动发布到生产环境。这种小颗粒的集成和发布其实降低了每一次发布的风险。同时给开发和运维团队提供了一个快速沟通和协作的流程。另一方面,CI/CD也保证了开发环境,测试环境和生成环境的代码高度得一致性,这给定位和解决问题带来了便利。

  • Infrastructure as Code: 如今的IT基础架构都运行在虚拟化的平台-共有或者私有云上,从网络,存储到计算能力都是可以同过软件来配置的。这给到基础设施团队和运维团队部署新的服务和计算资源的效率和能力极大得提升。

  • 持续监控和记录:通过监控和日志分析统计实时监控所有系统的运行状态,在出现问题前预警,甚至自动干预和解决,提高整个运维的稳定性和效率。让团队关注在最有可能出问题的环节和系统,提前准备和预防。

运维工具的应用

下图列出的是DevOps各个环节的常用工具。代码的版本管理是Git(Git应该算是一统天下了,其他的版本工具基本都已经很边缘化了)构建工具每种语言都不同,下图里列的是Java相关的构建工具Maven和Gradle。在整个DevOps工具库中最重要和关键的工具必然是CI&CD工具,这是CI/CD在DevOps的核心地位决定的。CI&CD最流行的工具的就是Jenkins了,功能强大而且是开源软件。通过持续集成和交付,真正串联起了开发,测试和运维团队,通过工具和流程让三个团队能够协同工作。其次我觉得是自动化部署工具也非常重要,让运维团队能够迅速发布和创建标准环境。这些工具有Chef,Puppet和Ansible。总体来讲,我觉得Ansible是比较推荐的工具,第一是能够很好的和Docker一起结合使用。另外一点是Ansible采用的是Push模式去部署应用环境,不需要在其他节点上安装任何Agent程序,灵活性很高。

顶级互联网公司SRE派,代表 - Google

两本指导手册,可以在这个网站免费看。在 https://landing.google.com/sre/ 有Google总结的很多关于SRE相关的信息和资源,可以作为参考。这也是是谷歌力推的运维团队的模式。不过这种模式也只有类似Google这样的“豪门”公司可以采用。我阅读了那个网站的介绍,并大概看了两本指导手册,发现SRE就是事实上谷歌的运维团队。但是谷歌本身有着极高的准入标准,哪怕是运维团队的成员也是以SDE的能力和标准来招聘的,其SRE团队成员中软件工程师和系统工程师各占一半。他们通常会以软件工程的思维去处理运维问题,做一些自动化的流程,编写工具提高运维效率和系统稳定性,甚至能够直接去review开发团队提交的代码。SRE团队和产品,开发团队基本处在平等的地位,甚至相比之下还有些许特权。他们不但可以直接拒绝不符合运维要求的版本,甚至可以在某些情况下退出运维的工作,交给原来的开发团队。

谷歌制定了一套标准,还整出了SLI,SLO和SLA三种系统运维指标,其中SLO是由SRE制定的。一旦开发出来的系统达不到SLO(service level objective),SRE团队会要求开发团队必须将主要精力放在增强稳定性上。为此他们还发明了一个名词叫Error Budget,就是说一个系统能够有一定的错误余量(原因是只要是人类做的东西总是有可能会出问题~~~),如果某时间段的Error Budget被用完了,那么这个系统的最优先级任务将不再是新功能开发和上线,而是保证其质量和稳定性,直到其Error Budget再次恢复为正。

我们其实可以看到,与其说SRE是运维人员,还不如把他们归类为专注于系统性能和稳定性的软件工程师团队。这种用软件工程师团队覆盖运维工作的做法,在成本上和实际的企业文化上可能并不是所有公司都能够采用的。不过如果有能力采用这种模式的公司,我觉得还是应该尝试一下。

最后引用Google自己的一句话作为结尾吧,

这句话其实说出了谷歌团队心目中的SRE和DevOps的关系,

class SRE implements interface DevOps

对本文格式不满意可以访问原文地址https://www.rockysky.tech

快速理解DevOps概念和意义-兼谈SRE的更多相关文章

  1. 炒了8年的概念,到底该如何理解DevOps这个词?

    什么是DevOps及误区 DevOps概念从2009年提出已有8个年头.可是在8年前的那个时候,为什么DevOps没有迅速走红呢?即便是在2006年Amazon发布了ECS,微软在2008年和2010 ...

  2. 到底该如何理解DevOps这个词

    炒了8年的概念,到底该如何理解DevOps这个词? 转载本文需注明出处:EAII企业架构创新研究院,违者必究.如需加入微信群参与微课堂.架构设计与讨论直播请直接回复公众号:“EAII企业架构创新研究院 ...

  3. 从代码的视角深入浅出理解DevOps

    对于DevOps的理解大家众说纷纭,就连维基百科(Wikipedia)都没有给出一个统一的定义.一般的解释都是从字面上来理解,就是把开发(Development)和运维(Operations)整合到一 ...

  4. 垃圾回收机制GC知识再总结兼谈如何用好GC(转)

    作者:Jeff Wong 出处:http://jeffwongishandsome.cnblogs.com/ 本文版权归作者和博客园共有,欢迎围观转载.转载时请您务必在文章明显位置给出原文链接,谢谢您 ...

  5. 字符编码那点事:快速理解ASCII、Unicode、GBK和UTF-8

    原作者:阮一峰(ruanyifeng.com),现重新整理发布,感谢原作者的无私分享. 1.引言 今天中午,我突然想搞清楚 Unicode 和 UTF-8 之间的关系,就开始查资料. 这个问题比我想象 ...

  6. [转帖]十分钟快速理解DPI和PPI,不再傻傻分不清!

    十分钟快速理解DPI和PPI,不再傻傻分不清! https://baijiahao.baidu.com/s?id=1605834796518990333&wfr=spider&for= ...

  7. zw版·Halcon与delphi(兼谈opencv)

    zw版·Halcon与delphi(兼谈opencv) QQ群 247994767(delphi与halcon) <Halcon与delphi>系列,早两年就想写,不过一方面,因为Halc ...

  8. 快速理解web语义化

    什么是Web语义化 Web语义化是指使用恰当语义的html标签.class类名等内容,让页面具有良好的结构与含义,从而让人和机器都能快速理解网页内容.语义化的web页面一方面可以让机器在更少的人类干预 ...

  9. 快速理解高性能HTTP服务端的负载均衡技术原理(转)

    1.前言 在一个典型的高并发.大用户量的Web互联网系统的架构设计中,对HTTP集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案.HTTP负载均衡的本质上是将Web用户流量进行均衡减压,因此 ...

随机推荐

  1. Visual Studio 2017 安装心得

    既然VS2017已经发布了,就想安装一下试试,先卸载VS2015, 网上有个完全卸载的东东,https://github.com/Microsoft/VisualStudioUninstaller/r ...

  2. java编程思想札记一

    1. 访问权限中尤其注意protected,它包含了包访问权限,只要是同一个包里的,就能访问到protected成员.   2. 后期绑定:被调用代码直到执行时才能确定,编译阶段只保证调用方法存在和类 ...

  3. Mysql库、表、记录的基本操作

    库的操作 ---> 类似于文件夹 - 增: 创建数据库: create database db1; 创建带字符集的数据库: create database db2 charset=utf8; - ...

  4. 【题解】PKUWC2018简要题解

    [题解]PKUWC2018简要题解 Minimax 定义结点x的权值为: 1.若x没有子结点,那么它的权值会在输入里给出,保证这类点中每个结点的权值互不相同. 2.若x有子结点,那么它的权值有p的概率 ...

  5. Shell one

    1.shell的运算符包括:算术运算符.关系运算符.布尔运算符.字符串运算符.文件测试运算符 1.1原生bash不支持简单的数学运算,但是可以通过其他命令来实现,例如 awk 和 expr,expr ...

  6. linux入门系列5--新手必会的linux命令

    上一篇文章"linux入门系列4--vi/vim编辑器"我们讨论了在linux下如何快速高效对文本文件进行编辑和管理,本文将进一步学习必须掌握的linux命令,掌握这些命令才能让计 ...

  7. CI框架获取post和get参数_CodeIgniter使用心得

    请参考:CI文档的输入类部分: $this->input->post()$this->input->get() -------------------------------- ...

  8. AD19覆铜与边框间距设置方法

    转载请注明出处,并附带本文网址https://www.cnblogs.com/brianblog/p/9894867.html, 由于高版本AD不能将机械层直接转变为KEPP OUT LAYER层,所 ...

  9. 如何优雅的用策略模式,取代臃肿的 if-else 嵌套,看这篇就够了

    经常听同事抱怨,订单来源又加了一种,代码又要加一层if-else判断,光判断订单来源的if-else就好几百行代码,代码我都不想看了,相信很多同行都有过这样的感受! Java的二十几种设计模式背的滚瓜 ...

  10. 网站 cache control 最佳实践

    推荐阅读: 2020年软件开发趋势 高并发案例 - 库存超发问题 负载均衡的分类及算法 异地多活架构 Postman 的替代品来了 有时,当第二次访问网站时,看起来比较怪,样式不正常. 通常,是因为 ...