标签：系统运维 问题： 基础架构 ace 虚拟 恢复 时间 开始 分析
最近几年，由于负责的范围的变化。工作逐渐从某个IT领域或者部门，开始关注到整个IT体系的运转和管理。中间也遇到不少困难，同时也有机会去从更高的层面去学习和实践IT治理。文章主要是总结一下我对DevOps相关的理解和认识。
关于测试团队：Test这个环节通常会有专门的测试团队负责，在很早期的时候，测试团队和开发团队也是分开的。不过自从敏捷开发流行以后，测试团队的成员就已经被看做开发部门的一部分了，这也部分归功于微软的贡献，他们当时新发明了SDET（软件开发测试工程师）这个概念，以表明测试工程师也是开发人员。他们写测试用例，进行功能和压力测试，同时需要懂得一些开发技术并拥有自动化测试的能力。开发人员对自己的代码质量也要负责，需要写自己负责模块的单元测试代码，软件开发人员之间需要交叉进行代码review。
下面的DevOps图相信很多朋友都见过了，当然这个图也有不同的变化版本。通过这个图来看，开发和运维团队衔接的最关键环节在Release-Deploy这三个步骤。而这一部分是否能够做得好，直接关系到DevOps在整个IT部门实施的成败。这一部分现在的主要解决方案就是CI/CD-持续集成和持续发布。DevOps不只是一个方法论，其涉及到整个IT团队文化的调整，多种新观念新方法论的实践以及现代化运维工具的应用这三个方面。
对于DevOps问题的解决上，其实分成了两大流派。让我们来探讨一下这两派的观点和适用范围。
从传统的运维模式转变到更加灵活和高效的DevOps模式。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程序，灵活性很高。
两本指导手册，可以在这个网站免费看。在 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是运维人员，还不如把他们归类为专注于系统性能和稳定性的软件工程师团队。这种用软件工程师团队覆盖运维工作的做法，在成本上和实际的企业文化上可能并不是所有公司都能够采用的。不过如果有能力采用这种模式的公司，我觉得还是应该尝试一下。
这句话其实说出了谷歌团队心目中的SRE和DevOps的关系，
class SRE implements interface DevOps
对本文格式不满意可以访问原文地址https://www.rockysky.tech
标签：系统运维 问题： 基础架构 ace 虚拟 恢复 时间 开始 分析
原文地址：https://www.cnblogs.com/yangjian2006/p/12286847.html
