DevOps文化 & SRE实战分享平台

0%

在每个开发(Dev)和运维(Ops)心中都应该存在一个DevOps SRE的梦


文章声明:此文基于木子个人实操+理论撰写
生产环境:职业生涯
论证耗时:7year
撰文耗时:3h
校文耗时:1h
问题关键字:DevOps,SRE


前述

一直有朋友和木子说,你这博客标题是“DevOps文化 & SRE实战分享平台”,但前面分享的都似乎与DevOps&SRE关系不大,能不能详细聊聊DevOps&SRE?于是便有了这篇文章。
正如同“每个故事里都有一个胖子”一样,在每个开发(Dev)和运维(Ops)心中都应该存在一个DevOps&SRE的梦。有同学可以会问为什么不是DevOps,而是SRE了?DevOps和SRE是目前相对热门的开发、运营文化及技术实现,两者之间有着很高的相似度,如下图所示,两者是一个存在相互重叠的现行趋势学科,是一个多层级的复合型人才需求(根据企业的不同定位及需求,木子觉得SRE可以更大概论的扩充到DevOps全域)。在工业4.0的时代,类复合型人才更加紧缺,怎么使用DevOps的思维快速推动工业4.0智能智造的发展,也是一个值得我们思考的问题。

image-20200118153707445
早期有很多同学会把SRE视为和DevOps是两种不同的实践方式,必须在其中选择一种方式来执行,其实这个是错误的。如果把DevOps比作是水果,SRE比作是香蕉,那么结果就是香蕉是一种水果,但水果并不是香蕉。请永远记住:
SRE is a DevOps(香蕉是一种水果)
DevOps is NOT a SRE(水果不是香蕉)
DevOps 并不是一个工作职称,SRE才是。就像我们去菜市场买菜一样,我们不会和老板说我要买青菜,而会和老板说我需要买上海青或者小白菜一样。
如果要用软件工程师的思维来总结DevOps与SRE之间的关系,那就是:

1
class SRE implements DevOps

当然你会发现在一些招聘平台上,不乏一些大厂在招聘DevOps工程师或者SRE工程师,这就是中国特色,国内一些企业从DevOps的文化层级抽象出了DevOps工程师这个职位。
那么到底SRE是什么?SRE和DevOps有什么相同与不同点了?早在2018年初的时候,Google工程师就在一系列的视频中尝试去解答这些问题,希望能够有效减少社区之间的意见分歧,有兴趣的同学可以去油管查找对应视频。而对于两者之间的区别,我们可以通过五个DevOps理论与SRE实践来进行说明:

DevOps SRE
减少团队与部门之间的孤岛 在整个产品周期内使用与开发团队相同的工具和技术栈,并分享所有权
接受故障,视故障为开发周期内的一个基本元素 导致故障的可能性限定在一个指定值范围内
实施渐进式变革,逐步改变 鼓励团队降低排除故障的成本[平均修复时间(MTTR)],达到快速交付的目的
擅用工具和自动化 相同技术
度量一切 将所有指标数据化,可用性、运行时间、停机时间等等

站在今天,回看2013年自己在DevOps的实践之路,其实在当时木子不仅仅只是关注于DevOps,更多的是希望能够帮助企业实现数字化转型,只是当时的情况不允许。就如同4G不出抖音必挂是一个道理,每一个物类的产生,都必须有其自然生长的规律及周边环境的培育。得益于2013年的坚持,让我在2019年的SRE道路上可以走得更远、更长,虽然我还并不是一个完全合格的SRE,但至少为企业降低了上百万的运营成本,并在企业内部推动DevOps文化的建设,因而获得年度最佳技术创新奖。当然这并不是为了炫耀什么,而是想说DevOps文化体系的建设与SRE方法的实践,对于企业来说是一个不错的方向。
因试图通过一篇文章能够说清楚DevOps及SRE(基本是不太可能的),所以篇幅可能有一些长,希望能够帮助各位同学找准自己未来的定位与方向。

什么是DevOps?

对于布道者而言,DevOps是一种文化和转型。对于工程师而言,DevOps是一套敏捷工具和技术集的实现。对于领导者而言,DevOps则是一种方法论。对于HR而言,DevOps只是一个职位。不同人对其定位不同,关键在于你自己怎么理解,站在什么位置去思考这个问题。
本质上来说,DevOps是Development和Operations的一个组合词。它是一种文化理论的框架性输出,在整个产品或服务开发生命周期中,开发与运维或者说运营管理人员之间相互协作的价值体现。这种模式或方法可以改变人与人之间对于工作的看法,并重视团队内部技能的多样性。DevOps鼓励实施SOP流程标准化(其中我们会发现由于工业革命在互联网革命之前,所以很多现行的互联网标准或体系都是从工业体系中演变而来),以加快业务收益的回报率。其通过自动化“软件交付”和“架构变更”的流程,实现从计划、编码、构建、测试、发布、部署、运行、监控于一体的一站式解决方案,使得发布、构建、测试、软件能够更加地快捷、频繁和可靠。它是一套理论体系,但我们可以从其中抽象出其可实践的方法,即SRE。
DevOps解决了原本开发和IT运营团队在传统模式下,分散的工作流之间频繁通信和持续实时协作所带来的高昂沟通成本、管理成本、低能低效。它通过组织工作流的方法用能够实施敏捷计划和实践(例如持续集成,持续交付和基础架构自动化)的多学科整合,取代原本孤立的开发和IT运营团队,以达到应用程序及服务的快速交付。
image-20200118153723285
技术社区使用各种术语来描述DevOps的本质。它是一种文化,一种运动,一种哲学,一套实践以及使用工具软件来实现自动化和改进管理体系的方法论。不管您如何描述它,DevOps文化其中所融入的敏捷开发和精益思想,让我们更加注重服务和质量。既然我们说到它是一种文化,那它究竟是怎样的一种文化呢?其核心本质在于CALMS,而CAMLS分别代表5个英文单词的缩写。

  • Culture
  • Automation
  • Lean&Agile
  • Measuring everything
  • Sharing

1)Culture[文化]

DevOps 是一种文化。传统开发模式每个阶段的人员,可能只专注自己的部分,但在整个产品成型的过程中,并不是只要把自己的部分做好就OK,是需要我们在每个阶段都适当沟通分工合作的,而DevOps就是为此而设计的。它真正的核心正是文化,强调建立人与人之间的合作、责任以及分享的精神文化。

2)Automation[自动化]

自动化是开发团队最重视的问题,而在整个产品生命周期中测试与部署也是造成delay不容忽视的一环,正是因为这种信息与部门之间的孤立,造成了产品层的delay。而自动化(CI、CD)则更好的解决了此问题,不但可以减少开发、测试、运维人员之间沟通落差造成的问题,更加可以在开发与应用整合上更加快捷、迅速。

3)Lean[精益开发]&Agile[敏捷开发]

正因为DevOps涵盖精益开发(Lean)和敏捷开发(Agile),因此我们完全可以套用精益开发的七大核心思想及敏捷开发的12个基本原则。
精益开发七大核心思想:

  1. 消除浪费——Eliminate Waste
  2. 建立质量——Build Quality In
  3. 创造知识[增强学习]——Create Knowledage[Amplify Learning]
  4. 延迟决策——Defer Commitment[Decide as Late as Possible]
  5. 快速交付——Deliver Fast[Deliveras Fast as Possible]
  6. 尊重他人[放权他人]——Respect People[Empower the Team]
  7. 整体优化[着眼全局]——Optimize Whole[See the whole]

敏捷开发12个基本原则:

  1. 最高优化级是客户的满意度。(Highest priority is customer satisfaction)
  2. 欢迎更改需求。(Welcome changing requirements)
  3. 持续交互。(Frequent delivery of software)
  4. 业务人员与开发人员全天候合作。(Business people & developers cooperating daily)
  5. 围绕有动力的人员构建项目。(Build projects around motivated people)
  6. 面对面的沟通是最好的。(Face-to-face conversation is best)
  7. 通过工作软件衡量进度。(Progress measured by working software)
  8. 可持续发展的步伐。(Sustainable development pace)
  9. 持续关注卓越技术。(Continuous attention to technical excellence)
  10. 简单性。(Simplicity)
  11. 自组织团队。(Self-organizing teams)
  12. 定期反思和适应。(Regular reflection & adaptation)

我们一定要清楚两者之前最基本的区别,精益开发基础思想源自于消除浪费,而敏捷开发的初衷为应对变化,以不变因万变,不变的是体系、框架和实现,万变的是Code。精益可以说是一种比较完善的管理思想或理论,而敏捷可以说是一种做事原则或方法。

4)Measuring everything[度量一切]

DevOps理论确认了任何一切事物都可以被量化,并产生可度量值。DevOps主要专注于整个开发过程以及用户反馈,并对其过程进行记录、跟踪,并通过获得的反馈及结果持续改进。通过ITSM运维分析并遵循数据驱动的理念,来降低可预见的风险。

5)Share[分享]

DevOps是一种文化,文化正是透过人与人之间的互动产生的。可以分享的内容有很多,如经验、工具、数据、技术文档等都可以分享。例如上面所提到的度量值就可以分享给整个团队,让开发人员、测试人员甚至业务人员都可根据数据做出更好的决策分析。分享不仅仅只是一种文化,它还是增强团队透明度的一种方法。

DevOps人才分类

在这里我还需要重申一次,DevOps本质上是一种文化或者说管理思维的方法论。DevOps工程师的出现是具有中国特色社会主义的时代性产物。很多社区一直在讨论DevOps工程师,我们应该怎么进行分类以及怎么进行自我转型升级,下面就从技术维度来进行说明。
偏向于开发(Dev)的DevOps工程师:在整个产品的开发过程中,扮演软件开发的角色。他们日常工作的一部分是利用持续集成 / 持续交付(CI/CD)、共享仓库(Git/SVN)、云(KVM/OpenStack/公有云)和容器(Docker/K8S),但他们不负责整个基础架构的规划与实施,但他们了解基础架构,并且在成熟的环境中,能将自己的代码推向生产环境。偏开发的DevOps他们了解公司的开发技术栈,并对特定开发语言的构建、部署、故障排除有深入的了解,能够根据不同开发语言的特性进行资源需求的提前预警,并能够通过不同维度进行应用程序性能指标的监控与预警,并能提供诸如应用软件开发最佳实践支持之类的工作。
偏向于运维技术(Ops)的 DevOps 工程师:在整个产品的开发过程中,扮演着运维管理及SOP推广员的角色。他们了解软件的开发,但并不会把一天的重心放在构建应用上。相反,他们更多的支持软件开发团队实现手动流程的自动化,以提高开发人员的工作效率。还可能需要做遗留代码的分解,并通过自动化脚本来实现重复及频繁的工作,当然还需要进行基础架构的规划与实现,并教会开发团队如何利用 CI / CD,以及负责推行新型标准化流程的落地。偏运维的DevOps具有硬件、网络、存储、操作系统等技能,并且可以熟练地使用Shell、PowerShell、Python等自动化脚本语言。负责整个基础架构的实现与演进,并帮助解决整个基础架构组件可能遇到的问题。
DevOps专家: 他们精通Dev与Ops两项技能,并能够协助开发及运维的同事,解决技术上的难点。在他们可能不擅长某种开发语言或应用组件,但能够提供给他们一些解决问题的思路或方法,协助他们梳理思维逻辑,快速定位并解决问题。他们能及时了解IT行业中DevOps的最新信息并以践行。在一定的维度上DevOps专家已经达到了SRE或者说超越了SRE的水平。
通过上面不同技术维度的分解,我们对DevOps人才分类有了一定程度的了解,相信对入准备转型的同学应该会有一定的帮助。同时希望能够帮助到正在招聘的公司或企业,找准DevOps的定位,也希望能够帮忙到HR找到更加适合公司的人才。

DevOps过程中遇到的问题

任何事情并非一蹴而就的,DevOps亦是如此。对于新团队来说,DevOps并不是一个顺利的事情,DevOps转型所带来的对于团队的挑战,并不亚于造一颗原子弹,当然这里有一点夸张。但在一个团队内同时实施DevOps与开发转型(.Net Framework转.Net Core、Golang、Python)也并非一件容易的事情。因为DevOps与团队文化以及团队技术能力的变革息息相关,怎样在团队文化、团队技术能力与DevOps之间找到一个平衡点,逐步推进是对管理层及DevOps工程师的一个不小的挑战。作为过来人,送给正准备推行DevOps文化的同学一句最经典的话,“永远不要试图去改变一个人”这句话适应于两夫妻之间,同样适应于任何团队。

什么是SRE?

“一切皆代码,指标可量化,应用能自治,系统可自愈。”是每一个SRE应该深入骨髓的思想。对于SRE团队来说,存在一系列的规则参与到整个产品的生命周期管理,不仅只是生产环境,还包括开发团队,测试团队,客户等等。SRE团队负责可用性、延迟、性能、效率、监控、变更管理、紧急响应和容量规划。
SRE不仅仅需要具有软件开发能力及自己的一技之长,还需要对编程语言、数据结构、算法、性能优化等有足够的了解,且对于计算机硬件、网络技术、操作系统、数据中心等管理有自己的研究,另外对于中间件、数据库等也需要有独到的见解。
SRE基于企业本身的条件来创建产品,在满足用户需求的情况下,达到最佳的成本优化,在节能降费的同时,提高客户的满意度。比如:要你构建IaaS层基础架构,你可以用商业的VMware vCenter Datacenter,也可以用开源的OpenStack或KVM,其本质上都可以满足需求,而在企业自身条件有限,财力支出有限的情况下,SRE可以更好的做出选择。当然这仅仅只是一个举例,SRE不仅仅只是完成这些基础工作,更多的致力于产品本身。利用可用性和可靠性标准推行业务前进的方向,有助于最大程度地减少故障并减少时间的浪费。从而减少因故障花费在人力、资源组织上的成本。SRE致力于寻求最大化吞吐量并最小化运营成本的解决方案,通过部署可预测和预防性的维护程序,来消除宕机时间,并减少停机时间。
正因为SRE要求的全面性,很难找到合适的SRE工程师。因为在开发、系统、运维、硬件、团队协作等软硬性技能方面的需求,对于招聘要求也会更高。另外由于SRE是一门现行跨多学科的综合性学科(这也是工业4.0的难点所在),因此在整个行业内如何建立和管理SRE团队目前来说行业标准和信息都很有限,毕竟很多大厂也还在摸索当中。另外它需要强大的管理层的支持,才能够突破一些非常规的东西,而这也恰恰是一个难点之一。

SRE根据不同的职位给出不同的度量标准。对于工程师、PM和客户来说,整个系统的可用性以及该如何评级都有不同的呈现方式。如果无法制定出可运行时间的度量标准,开发团队往往会将稳定性视为一个潜在的问题,这个也就造成的后续部门或团队之间的消耗,这也是为什么SRE会产生的原因。SRE确保公司内的任何一个人(包括:CEO、CTO、CIO、VP、运营团队、开发团队等等)都知道系统的可用性及服务故障恢复时间等,以确保在出现任何问题的时候,可更好的按照既定指标协助处理。
SRE会和所有相关人员去沟通,决定出SLIs( Service Level Indicators)、SLOs(Service Level Objectives)、SLAs(Service Level Agreements)等各项重要指标,这也是衡量一个SRE工程师是否合格的重要指标之一。

1)SLIs

SLIs:定义了系统与响应时间相关的技术指标。例如:响应时间、每秒最大吞吐量、每秒最大请求量等等。我们需要将这些指标转化为比率或平均值。

2)SLOs

SLOs:与相关部门沟通,得到一个系统可用时间区间,并期望系统能够在既定的SLIs技术指标区间内运行。比如说:1万并发,1ms的响应时间等等,对应指标也可以作为业务代码编写、测试的一个重要标准,并将其贯穿于整个产品的生命周期。如果无法衡量一个系统的运行时间及可用度的话,是非常难以维持线上系统的持续运行的,常常会造成运维团队处于救火的状态。

3)SLAs

SLAs:虽然这个指标不是SRE每天需要关注的数字,但是作为一个线上服务提供商,SLA不仅仅只是对客户的承诺,也是在整个产品的开发周期内需要考虑的一个重要指标,允许停机时间、业务切换逻辑、风险与容错范围等都需要考虑在其中。
DevOps提出任何问题都可以被度量,而SRE则从SLIs、SLOs、SLAs三个层级,将其量化成可操作的数据,这也就是为什么我们前面说class SRE implements DevOps的原因之一。

SRE人才分类

从Google的实践来看,Google的SRE团队由50%的软件工程师和50%的网络系统硬件工程师组成。从定位上来说,目前国内DevOps与SRE工程师的区别不大,所以可以参考DevOps人才分类,只是需要强调的一点是,国内对于DevOps的定位还是更多的偏向自动化,而SRE更加关注的是服务本身。

DevOps & SRE之间的区别

通过上面的DevOps与SRE的介绍,相信各位同学对DevOps与SRE有了一个基础的认识。DevOps旨在帮助IT部门以敏捷和高效的方式推进团队发展。它在运维团队和开发团队之间建立健康的工作关系,使每个人都能看到他们的工作如何影响彼此。
SRE和DevOps都是解决生产运营管理需求的方法。但是,这两者之间的差异是非常显着的:DevOps提出问题并将其分发给Dev来解决(可以不了解或基础了解业务逻辑),而SRE则是发现问题并解决其中的一些问题(必须了解相关业务逻辑及实现方式)。DevOps团队通常会选择更为保守的方法,而SRE在保持稳定的生产环境的同时,对推动快速变更和软件更新更有信心。
Google SRE 工程副总裁(Ben Treynor)推荐的另一种有趣的方法与SRE的专业性和效率密切相关,他允许SREs在不同项目之间互动,并允许SREs转移至产品开发领域,更好的了解产品本身的属性。由于两个团队的工作相似,因此这些过渡有助于Ops团队更好地了解产品和代码,并将Dev团队带入生产环境以帮助他们理解其挑战。这极大地促进了团队气氛。并让Dev团队处理了5%的运维工作,这增加了SRE团队的动能和效能。
SRE工程师负责在部署后监视应用程序或服务,确保所有可以自动化的地方都实现自动化,以增强系统的运行状况和可用性。DevOps工程师负责从一开始就执行开发自动化愿景,从项目开始到实现。
DevOps和SRE在开发过程中具有共同点。DevOps工程师在培养文化和系统方面处于最高位置,该系统可在开发过程中自动执行构建等任务。SRE是DevOps的补充,因为它体现了DevOps的理念,并通过既定的规则来度量业务的自动化运维。

DevOps & SRE 必备知识点

说了这么多,可能很多同学都有一个疑问,DevOps&SRE工程师到底应该具备怎么样的技能,通过下图相信各位可以了解一个大概,为此木子特地绘制了一张DevOps&SRE工程师应该具备哪些技能的图谱,可能不是很全面或存在错误的地方,但应该可以反馈大部分的技能需求。
image-20200118153741448

从上图我们可以看到DevOps&SRE工程师对技能需求还是蛮高的,当然上图只是体现了表层实现的技能需求,涉及到业务底层的实现就要求更高了,包括数据结构、算法、内核等等。

公司对于DevOps & SRE的认知与定位

很多公司管理层将DevOps视为成本,而不是收入来源。他们将DevOps人员当作可互换的对象,拒绝投资DevOps人员平衡工作所需的资源。除了缺乏支持之外,DevOps人员可能还做着脏活累活,成为背锅侠。从公司管理者的角度来说,如果你没有能力从现有员工内部培养出优秀的DevOps工程师,那么就该多问自己几个为什么了。对于真正要招聘DevOps或SRE工程师的团队,在面试时,我们需要问清楚雇主“谁对生产业务中断负责”。如果回答是DevOps或SRE工程师,那你就需要多考虑一下了。如果他们说整个产品团队,那么至少他们对DevOps&SRE有了清晰的认识,出了问题不会只想找人背锅,这样的团队才更适合自身的发展,以及企业的成长。

写在最后

不过理想是丰满的,现实是残酷的。毕竟不是每一个公司都叫Google,Google的SRE可能比我们绝大多数公司的软件工程师写的代码还牛,比网络工程师还懂网络技术,比系统工程师更懂Linux,比业务运维工程师更擅长业务逻辑梳理。
从目前各大招聘平台上看到的关于DevOps&SRE的职位,都没有能够很好的描述DevOps&SRE工程师的职责和工作范围,可见现实并不像我们想像的那么美好。部门之间的隔阂,权力的斗争可能也是阻碍DevOps文化推行的一个重要因素之一。改变需要我们不停的前进与推动,正如特区目标的三个阶段一样。
关于DevOps&SRE木子就写到这里,如果你有任何其它的想法与不同意见,欢迎在下方评论区留言,我们相互沟通与讨论。

坚持原创技术分享,您的支持与鼓励,是我持续创作的动力!