DevOps的概念和实践并兼谈SRE

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

为什么会有DevOps，解决了什么问题：

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

下面的DevOps标准图相信很多朋友都见过了，其实通过这个图来看，开发和运维团队衔接的最关键环节在Test-Release-Deploy这三个步骤。

Test这个环节通常会有专门的测试团队负责，在很早期的时候，测试团队的成员就已经被看做开发部门的一部分的，这主要是微软的贡献，他们当时新发明了SDET这个词，以表明测试工程师也是开发人员。他们需要懂得一些开发技术并拥有自动化测试的能力。测试环节的最后步骤是UAT，由最终用户来完成和确认。发布和部署这两个阶段是开发向运维团队交接的过程。在很多公司中，运维团队和开发团队其实并不是被无差别对待的。开发团队通常离业务部门更近，需求是客户或产品部门提出的，他们都希望尽快得到开发完成的需求和功能。在交付的压力下，开发团队常常会把并不运维友好的组件和功能扔给运维团队，并希望他们能够尽快部署到生产环境上。开发和运维总是像有一堵无形的墙横梗其间，他们相伴相生，有时又互相伤害。

DevOps两大流派

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

传统IT公司的DevOps解决方案，代表 – AWS，IBM…

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

IT部门文化的转变

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

技术和方法论层面的变革

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

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

  

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

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

运维工具的应用

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

顶级互联网公司SRE派，代表 – Google

两本指导手册， 可以在这个网站免费看 。在 https://landing.google.com/sre/ 也有Google自己的很多关于SRE相关的信息和资源，可以作为参考。这是谷歌力推的运维团队的模式。不过这总模式也只有顶级互联网公司这样的“豪门”可以采用。我阅读了那个网站的介绍，并大概看了两本指导手册，发现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