Google那套SRE你还敢用吗?谁说SRE本质是个懂运维的资深开发?丨话题接力

dbaplus社群 2022-06-17 15:50:38
本文部分内容依据史军艇老师和刘昊老师的〖deeplus直播:话题接力丨云原生下的SRE进化之路〗线上分享演讲内容整理而成。(文末有回放的方式,不要错过)

 

十多年前,Google提出SRE这一概念并开始应用,随着大型互联网系统的出现,以及云原生技术的发展,近几年SRE实践逐步在国内受到广泛关注和探索。区别于传统运维,SRE被提出了更为极致的稳定性及性能需求。但事实上,目前业界在SRE上的实践还相对匮乏,各行各业对SRE的职责划分也不尽相同,在初期落地过程中也存在着很多误区……本次专题讨论,希望通过汇集多位SRE专家的研究成果和实践积累,给大家进一步明确SRE的职能和发展方向,提供可参考、可落地的SRE体系建设实战经验。

 

为此,dbaplus社群邀请到浙江移动 SRE架构师-史军艇、哔哩哔哩基础架构部 SRE体系负责人-刘昊、小米运维部 存储计算运维负责人-刘志杰,希望通过汇集三位SRE专家的研究成果和实践经验,给大家在云原生的SRE进化之路上,提供借鉴和启发。

 

三位嘉宾也一一例举了各自企业所做的一些SRE实践,给大家提供参考:

 

史军艇

 

SRE体系框架大同小异,其中包含架构设计、集成交付、测试、发布、变更管控、一体化监控、线上治理、后度量和复盘等部分。因为各个公司在组织架构、人员能力等方面不同,所以在SRE实践过程中存在差异。
 
SRE的核心在于落地工程能为公司带来的真正价值度。浙江移动近几年在SRE方向也进行了不少探索与实践,主要可概括为以下部分:
 
  • 架构盒子:全局架构基于区域、平面、渠道等维度建立模型,单系统架构基于C4模型;
  • 运营指挥中心:作为数字化调度的运营平台;
  • 盗梦平台:以混沌工程为底座,具备红蓝对抗、入网测评、架构“保鲜”等能力;
  • 应用多活平台:具备接入层、应用层、数据层、业务降级开关等全维度的多活要素,在不同级别的故障场景下,快速完成流量或开关切换,实现业务7*24保活;
  • 流量回放平台:集合各类自动化测试能力;
  • 一致性交付系统:开发无缝衔接,将架构标准、集成标准、测试、演练串接于一条交付流水线,实现标准化、一致性的系统交付;
  • SRE塔台:融合监控与操作,协同的一站式工作台;
  • ......

 

 
刘昊

 

SRE的体系构筑,业界的理解都很一致,无非就是团队构建和人员转型、On Call轮值、应急响应、容量规划、度量监控可观测性、混沌工程、交付和变更管控、业务协作机制(bp、prr机制)、大型活动保障等。
 
目前B站在这些方面都有所实践:
 
  • 可观测性的一系列平台,日志、链路追踪和指标监控;
  • 围绕业务应用的服务树,构造服务应用的全生命周期和服务画像,为周边系统提供服务的元信息和运行时上下文;
  • On Call排班系统;
  • 事件运营中心,实现稳定性度量指标的数字化、在线化运营,让应急响应、应急协同的过程靠平台来承载,拉通了故障发生先、发生中和解决后的各个场景的解决方案;
  • 混沌工程底座系统;
  • 团队内部运维同学的SRE转型。

 

 
刘志杰

 

小米的SRE体系围绕质量、成本、效率展开工作,在信息化建设的角度,我们的目标是成为业务解决方案专家,保障和助力业务健壮发展。
 
在质量和效率层面,整体在质量运营、变更管控、巡检保障、容量规划、接入层管理、服务可观测性、活动重保等多个方向进行工程化落地,如存储计算运维中台-轻舟Canoe、业务全链路监控-Aifault、质量运营指挥中心-MiGOC、快速排障系统-Horus、统一接入管理-Mife等;
 
在成本层面,SRE立足小米混合云的运维现状,依托现有的技术和运营能力,从Iaas/Paas/Saas多维度为业务提供降本支撑,细节很多在此不再赘述。值得一提的是,我们许多降本增效上的方案,也侧面推动了运维架构的演进,为整体的技术变革添上了浓墨重彩的一笔。

 

dbaplus社群还搜集了一些SRE的痛难点,跟三位嘉宾一起探讨: 

 

Q1
Google最先定义了SRE,且提出了相应的一套方法论,但Google SRE方法能否复制在我们的实践当中?有哪些可取和不可取的地方?
 

 

史军艇

“不要把SRE当成是0-1的事物”

 

SRE最早是Google在2003年定义的一个岗位,最初它出现的主要目的是:解决“研发”和“运维”之间的矛盾,逐步演变为一种工程思维。后面有了Devops概念,SRE的使命就更加明确,除了研发外,需要一个新型的Ops团队,既保证配合研发高效迭代创造前端价值,又保证业务系统稳定运行创造后端价值。

 

Google、Netflix等公司在SRE上有了很优秀的实践经验,也同时抽象出了Google SRE方法论。对于国内企业,可以效仿或借鉴一些国外好的体系及方法论,毕竟那些顶级的互联网公司发展走在我们前面,也为我们少踩了很多坑。但是直接把方法论复制成实践步骤,那是两个维度的事情。谷歌的《The Site Reliability Workbook》这本书中有一个高度抽象的解释,“class SRE implements interface DevOps“。DevOps是文化或理念,SRE是这个理念下的一个具体实现类,各个公司根据自身组织差异、基础设施差异、市场经营环境差异,可以重写成适合自己的实现类。

 

举个例子,我了解到的有些企业为了快速组建SRE团队,就直接找了一些开发工程师,希望这些开发工程师具备所有的技能。这显然是不科学的。从我们公司自身的实践经验来说,SRE是一个体系,不断地运用体系后得出的工程生态圈,其中每一个工程都有相应的团队去实施,最后串联起来就是整个SRE。因为SRE并不是0-1的事物,而是沉淀了多年的传统运维经验,融合新型的软件工程的概念而来的,是0.5+0.5=1的事情。

 

 
刘昊

“Google的SRE实现路径在国内并没有想象中容易”

 

Google定义了SRE,对SRE团队的职责做了一定的描述,像稳定性改进、延迟优化、性能优化、效率优化、变更管理,监控、应急响应以及容量规划与管理,在《Google SRE谷歌运维解密》这本书里面做了大量的说明。

 

我相信大多数公司在初期落地SRE时,都是以SRE书里面的内容作为纲领,然后无脑上的,最后发现目标非常棒,非常正确,但是实现路径没有想象中那么容易。并且在国内的行业大环境下,一些目标真的很难实现,仅限于说说就好。

 

下面是我认为在实践过程中一些可取和不可取的点:

 

  • 可取

 

SRE里面的On Call轮值、应急响应、混沌工程和本身通过软件工程手段来解决运维问题是非常好的。我们在内部也都有相关平台落地,确实是给日常工作带来了很大便利,可以在业务快速增长的同时,控制团队规模不去线性增长,以及稳定性持续在一个高水位线上和科学可控的管理方法上。

 

  • 不可取

 

在具体实践上,我们觉得招聘软件工程师在slo、错误预算、prr(Prodcution Readiness Review)这三个方面是很难做到的。这里以招聘软件工程师作为SRE组成来看,Google在03年组建SRE团队时,有几个背景,一方面google规模没那么大,另一方面国外对于OPS、PE的定义更多是系统管理员,当时对于运维体系和模型的认知还没有如今这么清晰。因此,Google首选用软件工程师解决这个问题,这在当时没有什么问题。

 

另外,据我所知,GoogleSRE的边界、体系模型和运作方式也经历了多年的迭代和变化,并且在后续的经验积累下,形成的包括培养体系在内的体系都已经非常成熟这个时候,从Google的角度去看,确实可以用软件工程师做SRE。以国内的情况来讲,运维这一岗位产生时间本就较晚,现在的SRE更是如此。国内企业在人员配置情况、岗位职能定义等方面也与Google存在差异在这些大背景下,很多规模不够大的公司都不具备直接选用软件工程师作为SRE的能力,除去团队规模这一原因外,组织培养流程也是硬伤。

 

 
刘志杰

“注意背后技术水平和文化的差异

 

在16年Google SRE的概念引入国内后,就迅速得到了行业内众多工程师的关注。而近几年其热度不减,国内互联网的头部公司也纷纷设立了SRE的职位,可见SRE影响之深。

 

我个人理解,之所以Google SRE得到大家青睐,除了有硅谷公司背书外,Google SRE更代表了一类体系化的工程实践,同时也传递了一种工程师文化的理念。不得不说,在某种层面上来讲,SRE确实重新定义了传统运维,SRE体系在质量、效率、协同等方面已经打磨得很成熟,比如使用SLO/SLA去度量系统稳定性这个基本盘,并作为跨团队协同的重要依据,在应急故障管理的多人协作流程,自动化上的一些演进思考等,非常值得借鉴和学习。

 

当我们在实际落地的时候仍需注意要结合企业实际情况,比如小米的SRE体系,是围绕着质量、成本、效率进行展开。在落地过程中,我们要注意不要过分神化Google SRE,应以开放和谨慎的心态去面对这一件“舶来品”,在取其精华的同时,更应该注意工程实践和工程师文化背后技术水平和企业文化的差异。

 

Q2
很多人认为:SRE本质就是一个懂运维的资深开发,如何解读这种说法呢?大家对SRE这一角色,普遍存在什么认知误区?
 
 
史军艇

“优秀的SRE需要集运维、开发、产品经理的能力于一体”

 

各大公司目前的SRE,如果细分的话,主要可以分为3大类,Infrastructure SRE、 Platform SRE 和 Business SRE,其中Infrastructure SRE主要负责最基础的硬件设施、网络,比较底层,一般都是很商业化的东西,动态性不强;Platform SRE提供中间件技术;Business SRE维护服务、应用、业务的正常运行,而这一类SRE是最偏向于我们说的传统业务开发的。

 

云原生时代下,SRE工作范畴,基本上除了纯业务研发外的所有活,都会深度参与。

 

开发的侧重点主要是在业务逻辑的实现、业务架构的主导,而SRE侧重的是技术架构,比如总体系统的分层模型怎么定,各层的技术方案怎么选,框架组件怎么用等。在我们公司,SRE实践了几年后,开发相比于之前还是省事了很多,项目立项完成后,SRE就会参与,包括架构方案、框架选型、集成方案等,SRE都是主导或者重要角色。所有开发可以专注于在“规范的地基上造房子”,做业务逻辑实现就可以。

 

SRE初期实践过程中,也踩过不少坑,第一支SRE团队主要还是以传统运维转型过来为多,虽然名字换了,还是很容易沉醉在日常事务中,他们对架构的理解以部署架构为主,思维很少有扩散到技术架构,更别说是业务架构,导致SRE和开发团队仍旧很少有共同语音。后面由于运维工具的盛行,公司会急着拉一些前后端的开发人员进入SRE,让他们主导运维转型,最终效果不佳,因为这些纯开发人员对生产系统运行的“战场”太陌生。很长一段时间,都是按需开发的模式。最终我们发现,在具备运维经验和研发能力的基础上,SRE身上还需要产品经理元素,衔接研发,要把业务架构中的某些通用逻辑,抽象出通用架构能力。衔接用户,会把系统稳定性当作一款产品去不断改良,精益求精。

 

云原生时代下的SRE 不仅需要 make things work,还要知道how things work。优秀的SRE除了运维功底之外,既是开发者,也是产品经理。

 

 
刘昊

“运维能力常常被忽视”

 

  • SRE本质就是一个懂运维的资深开发?

 

在某种意义上,我是认可SRE本质就是一个懂运维的资深开发这句话的,但是这里需要强调的是,一定是真正的懂运维这件事情。

 

我在团队里面经常讲,我们本质也是业务研发,只不过我们的业务范畴是运维这个领域。那这个问题也会引申出,一个好的研发是不是应该懂业务?

 

这个问题的答案也一定是要懂业务的,大家可以看看业务线的team leader和总监,每一个都是对自己所在业务领域有很深思考和建树的,因为只有这样才能通过技术去解决业务问题,产生大的业务价值和业务创新。

 

那再回到我们这个问题上,你只有真正的懂运维、理解运维,知道运维是从哪来?到哪去?这个时候如果你还是一名资深研发同学,那就可以通过研发的工程能力,帮助你快速解决运维业务领域的遇到的一些问题。

 

  • 大家对SRE这一角色,普遍存在什么认知误区?

 

在国内的实践来看,大家对于SRE的目标认同感是很强的,基本上运维也都很欣然接受这一个新的岗位描述,说高级一点,是找到了职业的价值感和自我的实现途径;说通俗一点,就是SRE听起来更有逼格,比叫运维厉害多了。

 

但是在真正的实践过程来看,其实差异还是蛮大的,特别是我在内部进行SRE转型实践指导,很多运维同学的软件工程能力提升和思维转变没有那么快。在运维工作中,大家应该都吐槽过研发同学怎么这么xx……

 

在自己转型时,自己在某种意义上就切换到了研发同学的角色,该犯的错一个都没少,并且因为缺少专业的教育背景和经验,初期的这条路子会走得更坎坷。像研发对于问题的抽象、解构一样,这个能力培养是需要一定时间的。

 

相信每家公司的运维系统都经常会被推倒重做,这个也是因为最初以为写写代码就好,做出一个平台就好,结果发现真正距离一个高质量、高扩展性和可迭代的某类运维系统差距还是挺大的。

 

大家在工作中应该都有用到K8sK8s作为云原生的基础设施,就是一个非常好的例子。通过软件的设计思想,对底层硬件设施抽象到了整个系统级别,这就是SRE思想的很好体现。我们通过K8s可以很方便的处理系统部署、调度、可观测和进行服务流量治理等工作。

 

最后还要补充一点:SRE还要具备一定的产品思维。因为不比业务研发是有产品的,相信很多公司的SRE、运维研发团队都是没有配备产品同学的。而SRE的平台又都是运营性质平台,不是你界面有了增删改查就ok的,这个时候对于一个SRE类产品、运维类产品的定位、设计和后期走向就至关重要。这一块的压力也同样转化到了SRE同学上面来,这个是Google书里面没有提到的一点。

 

另外我们也招过Google的同学,Google内部的系统也了解过,其实做得一般般,所以大家也不好神话和过度解读,更多的是把Google SRE书里面所提到的目标,结合自己的工作实践理解更透彻一些,这样会对自己的职业理解更有帮助。

 

最后总结一下,就是SRE实际上是一个有很高门槛,需要多领域有涉猎和积累的岗位。

 

 
刘志杰

“我认为SRE是懂开发的资深运维

 

虽然觉得不必太较真,但如果非要一个答案的话,我个人还是不太苟同。SRE其实是懂开发的资深运维。说到这个问题,让我想起来了前几年关于DevOps和SRE的一些讨论,我个人觉得无论DevOps还是SRE,其本质是研运一体化或深度结合。

 

在我们SRE体系落地过程中,一些Dev的需求有时会被SRE“叫停”,我们也偶尔也受到一些研发同学的质疑。我想说的是,其实Dev和SRE的目标是一致的,就是系统服务的健壮发展。Dev侧比较关注的是系统功能和性能的快速迭代,而SRE侧更关注系统的稳定和架构。SRE侧的”叫停“,并不是阻碍系统的发展,而恰恰是我们在为我们身后的椅子负责。我们近期也在不断摸索Error Budget等其他手段,去拉齐双方工作。

 

Q3

在实践SRE的过程中,各位老师的团队制定哪些准则来指导日常的运维工作?如何规划SRE工具链的建设,哪些能力项在目前需要着力发展?

 

 

史军艇

“三大体系及八大工程”

 

浙江移动为例,SRE后向协同研发,前向协同客户,我们有三大体系及八大工程,贯穿了架构工程、集成工程、测试工程、演练工程、布防工程、发布工程、线上防御工程到后度量整个生命周期。把全周期切割成了三大体系:故障抵御体系、上线发布体系和交付护航体系。近两年随着故障抵御体系的慢慢健全,我们不断地把触角往前移,重点在架构工程、测试工程、演练工程方向做了不少探索。

 

  • 架构工程

 

我们分为全局架构模型和局部单系统架构模型,统一承载在架构平台上。结合空间和渠道维度,全局架构模型可规划新入网系统落到“架构盒子”,规范异地多活、单元化、独立渠道AZ等标准。针对单系统,C4模型融合部署模型,提升硬件到代码的透视度,为上层工程做好基础,实现各系统分层架构感知,理清流量入口、外围依赖以及服务内调用。

 

  • 测试工程

 

自主研发了流量回放平台,以接口层业务日志流量为依托,通过实时流量归档,获得真实的业务场景和数据,经过流量预处理并按不同的策略形成分片流量,在测试时按需组装后再回放至待测环境进行大并发压力测试,无需人工设计和维护用例,大幅降低测试成本,实现测试边际效益最大化。平台适用从CI/CD到线上保障的全过程。

 

  • 演练工程

 

浙江移动结合纸牌推演和混沌演练,对每项架构点做反脆弱的失效影响分析(FEMA)和优化,确保项目入网前基本完成重点风险的提前布防布控。同时,基于沙箱环境,开展日常的红蓝对抗演练,确保始终对运维各类应急预案的反腐治理能力。“盗梦”演练平台实现故障注入及多维度编排功能,并融合了架构评级、自动化演练及红蓝对抗的能力,可助力企业高水平完成演练治理一体化。

 

 
刘昊

“三大准则+三大能力项建设”

 

  • 在实践SRE的过程中,各位老师的团队制定哪些准则来指导日常的运维工作?

 

在SRE实践的过程中,我们在团队内部在几年来也沉淀了很多准则,通过这些准则来知道日常的工作。具体的准则如下:

 

  • On Call准则。On Call轮值不仅是SRE,更是各个团队的重要职责,这项任务的目标是保障服务的可靠性和可用性。在具体的OCall工作中,OCall同学一旦接受到报警信息,工程师必须确认(ack),OCall工程师必须及时定位问题,并且尝试解决。必要的话可以联系其他团队,或者升级(escalate)请求支援。在OCall工作的安排上,需要有主OCall、副OCall人值班,或者关系密切的团队相互作为副 OCall,互相值班,共同分担工作压力。在任何一个生产环节时间,包括事件根源分析、事件处理,以及事后总结,至少需要6个小时。每次轮值周期最多只能产生两个紧急事件,否则要触发轮值。每个工程师每个月至少要参与OCall一次,最好两次,保证有足够多的生产环境操作经验;

 

  • 应急响应准则。该准则主要分了4块:优先止损、及时通报、故障排查和复盘总结。在优先止损中,处理故障的目标是减轻影响并尽早将服务恢复到先前的状态;在处理过程中,若10分钟内仍无法恢复或没有明确可行的恢复方案,应立刻考虑止损。常见的止损手段诸如降级、限流、切量、回滚、重启和扩容等。此阶段不需要去定位问题的根因,切记;在故障通报中,关注点是以有效的方式协调团队的响应工作,并确保响应者和故障相关团队之间的信息流通。故障发生时,将有效的信息及时同步给你的领导和相关团队至关重要。这里要注意以下几点:1、务必及时通报故障信息,因为你看到的影响可能不是故障的全部;2、及时通知到你的上级和相关团队,有利于问题的快速解决和正确处理;3、问题涉及多团队时,应拉起专项讨论群,同时在值班群定期同步事件进展:发生了什么事情(哪几件事情)?每件事情分别产生了哪些影响?每件事情当前处于什么阶段、预计什么时候恢复?每件事情接下来需要谁做什么?等等;在故障排查中,故障涉及方、当日值班人应主动牵头故障的处理和协作。

     

  • 在“优先止损”的前提下,提供如下信息供进一步定位:1、已被引流(生产流程已切走)的故障节点;2、系统快照(KernelDump、JavaDump等);3、日志(详细的系统日志、应用日志等);4、监控(系统层、应用层,历史的趋势数据、和SAR细粒度的精细数据;5、链路追踪(跨组件间的 Trace、血缘 等)。最后复盘总结方面,对问题的总结是成长的最快方式。对事不对人、吸取故障的经验、以点概面地去解决隐患。这里要关注的3个要点是聚焦深度分析问题和广度评估隐患、多方商讨改进方法和制定落实改进计划。在故障结束后,由主要责任人或指定同学牵头梳理故障过程。故障报告编写应包含“事件上下文”、“关键事务的细节”、“明确可执行的计划人和时间点”,并定期回溯待改进事项。

 

 

  • 变更管理准则。专业机构调研:90%的故障都出自于变更。管理变更对于日常安全生产至关重要,所以需要做到提前准备、适时操作、事后观测、降低风险。常态化变更包含内部主动计划内变更和外部计划内变更。在时间上,我们定义了变更窗口期,诸如规避业务高峰和特殊日期。在变更阶段上,细分变更的前中后,并且在每个阶段都有对应的变更平台和更细化的变更操作SOP,在具体落实变更操作钱进行double check,确保变更内容的一致性。

     

  • 如何规划SRE工具链的建设,哪些能力项在目前需要着力发展?

 

做了这么久的SRE工具链和平台,我绝对对于一个公司比较重要的几块能力:可观测性、混沌工程,这些我就不讲了,因为业界讲得很多,并且这个也成公司技术标配了。

 

  • 以应用为核心的CMDB,互联网公司一般叫做服务树。通过服务树来组织服务、业务和组织的关系,维护应用相关核心元信息;

     

  • OCall系统。维护好组织、业务、职能和人的元信息,确保出问题能够找到对的人,并且非值班同学不会被骚扰。这个也是达成Google所说的50%时间的利器;

     

  • 事件运营。像故障处理中经常提到的MTTR和MTBF,这些稳定性的指标如何去运营和控制提升,都需要有平台承载,通过平台将应急响应、应急协同、进展实时同步、故障覆盖等一系列事情都给串起来,避免让公司一个超级兵驱动所有事情。

 

 
刘志杰

“提倡走技术运营路线

 

说到准则可能偏鸡汤一些,我觉得SRE最重要的践行工程师文化,对事不对人。同时保持团队内开放包容的氛围,是让整个团队富有活力和战斗力的关键点之一。在日常运维工作中,我们提倡走技术运营路线,也建议大家使用大数据技术和自动化方案,支撑存储计算SRE体系,这样我们既是使用方又是管理员,何乐而不为。

 

在小米存储计算的SRE体系中,为了闭环存算服务的生命周期,我们结合存算服务自身的特点,打造了存储计算运维中台-轻舟。我们基于数仓体系构建的一套运维数据集市,为服务整体的可观测性提供有效的数据支撑。与此同时,我们在自研发布系统Minos的基础上,定制了发布系统2.0版本,在可视化集群管理的同时,也融入了低代码和任务编排的特点,解决了诸多运维痛点。在数据和发布之上,我们也构建了容量管理、巡检管理、机器故障管理等多个自动化CO模块,提升整体运维效率。

 

Q4

SRE的核心职能是保障线上服务的稳定性,但同时也对其提出了效率和成本的要求,如何平衡三者之前的关系?各位老师在实践中是如何度量评估的?

 

 

史军艇

“稳定性是衡量三者的基本”

 

SRE关心的指标,总结起来就是以稳定性为基础,把成本和效率做到最佳(降本增效):
 
稳定性:直接体现的就是MTTR和MTBF,当然细化后会有很多指标,自上而下分层,可以分为业务层、应用服务层、paas层、基础设施层。业务层焦在最终用户业务的可用性、性能方面,比如访问量、业务办理成功率、业务办理耗时等;应用服务层主要包含延迟、流量、错误和饱和度四大黄金指标;paas层偏向于基础组件以及容器云平台的控制面指标;基础设施更偏向底层,硬件、云IaaS、网络等。
 
成本:通过资源使用总量,单位资源的使用率做成本分析,依据分析做容量规划。
 
效率/效益:以运营视角、市场维度去评价架构优化后的成效。和成本相辅相成,集成效率、发布效率、系统运行效率、需求上线效率。

 

 
刘昊

“稳定第一,综合综效,不断创新”

 

稳定性、效率和成本,不论是现在SRE还是之前的运维,都是老生常谈的三个大目标。首先稳定性一定是SRE的核心职责所在,这个从SRE的名字上就可以看出。其次,从SREOn Call轮值和工程思维来看,我们需要通过工程化能力,其实也就是平台化能力来进行自动化,进而提升交付、变更等方面的效率。
 
最后一点就是成本,企业经营目标、团队价值,特别是SRE这种团队不属于营收团队,除了稳定性之外,我们需要通过成本的降低来体现团队的价值,像我们今年的大目标就是降本增效。
 
关于这三者的关系,在我看来他们即是独立的,又是互相依存的。比如容量规划、容量管理,即牵扯成本,又牵扯稳定性。在管理的过程中,如何高效的去管理各类资源的容量,更快速地引导SRE、研发、预算财务等角色参与进来开展工作,这都牵扯到了三块。
 
那再比如内部的各个变更平台,以作业为例,为了避免人工变更的低效和变更隐患带来的高风险,通过作业平台来进行管控,那这在一定程度上,即提高了变更效率,又提升了产线稳定性,还降低了人力成本。
 
其次,在优先级上面的话,也是一个动态平衡的关系。我以应用来举例,我们应用做了服务分级,那L0的高优先级服务,自然可以投入更多资源,确保日常的一个低水位线和更大的人力投入。而L3的低优先级服务,在配套的人力和资源方面都会有所减少。
 
同样,像服务等级这种服务画像属性,也是指导我们日常工作的一个关键因素。

 

 
刘志杰

“降本增效的前提是要保障服务质量

 

我个人理解,首先SRE要站在企业发展的角度去看待三者之间的关系,并且需要灵活调整,通常商业场上的事情是瞬息万变的,而技术发展相对滞后。比如当公司业务高速发展,这时候需要在质量的基础上适当上调效率的优先级,成本略微下调,当然一定要注意并不是完全不计成本;当公司业务稳步提升,需要精细化治理的时候,我们需要在质量的基础上适当上调成本的优先级。

 

其次,在小米存储计算SRE体系中我们为质量、成本、效率都定制了核心指标。用来辅助我们日常运维工作的决策。

 

  • 质量:通常我们以SLO作为质量关键指标,针对HDFS、HBase、MQ等分布式系统,我们基于Request-based模型,使用独立的Canary去计量的每个服务/集群的可靠性;

     

  • 成本:我们借助公司的云式账单模型并自建了存算运维数据集市,可度量服务任意时间维度的成本概况,做到服务/集群成本了然于胸;

     

  • 效率:我们在自研的运维中台-轻舟上,为发布管理、容量管理、机器管理等运维功能模块定义了多维度效能指标,助力我们高效运维。

 

最后我想说,关于质量、成本和效率三者并不是非黑即白的,我觉得为三者相辅相成的,在自动化提升效率的同时也会提升系统质量,也会带来降本效果。而在降本的时候,我们需要尤其关注和打磨服务质量,保障质量指标维持在均线之上。

 

Q5

业务团队应该如何支持稳定性SRE人员?在故障复盘、容量规划、业务协同、SLI/SLO/SLA等方面,需要对大家提出怎样的要求?如何构建SRE稳定性运营意识?

 

 

史军艇

“业务团队应该支持走完SRE的标准化体系”

 

企业中SRE的组织架构适配完成后,把SRE体系做起来,团队的分工和能力也会随之上来,业务团队往往离不开SRE,因为从项目立项开始,基本所有事项都是和SRE共同完成的。比如组件选型、框架的非功能适配、性能压测、标准化集成部署、演练验收等,这些工作都是一个优质项目中不可缺的步骤,业务团队应该支持走SRE的标准化体系,也是为了后面线上运行做前置条件。因为这样走完后,上线后业务团队也会很省事。大家的软件认知是同一水位的。所以从我个人经历来看,感觉业务团队对SRE的支持不用刻意去规划,是由SRE主动后双方自然而然就会达到的一种平衡。

 

为什么前面说优秀的SRE不仅是一个开发者,还是一个产品经理。这个产品经理必须是以客户为中心的,用运营的理念去引导整个团队的价值驱动。比如在日常方面,做好故障复盘的运营,其实复盘过程中除了技术bug的分析之外,都会有用户影响的关联。另外,对于容量规划、SLI/SLO/SLA等方面,都可以结合成本/效率的角度,融入到运营日报机制中去。这样整个团队的运营意识也会有很大的提升。

 

 
刘昊

“业务团队本身就离不来SRE”

 

  • 业务团队应该如何支持稳定性SRE人员?

 

业务团队同学如何更好配合SRE通过做好稳定性运营工作,这里更多是共识和分工。大家需要对稳定性的目标以及达到这一目标的路径、方法、行为有共识,然后是在各块具体工作上的详细分工,再接下来才是分工之间的配合。比如研发更关注的业务架构、代码质量、技术改造、服务治理这些相关职责,其次是度量监控、应急响应和服务治理这些会和SRE有更密切关联的行为。

 

基于这些,也就要求业务侧需要有一个懂稳定性的人,然后作为接口人去和SRE同学在工作上有更多交互。因为公司的规模上来之后,我们SRE同学再去做业务稳定性工作的时候,不可能说要去和每个研发都进行沟通,这块很困难。如果在业务团队有这样的一个角色之后,就可以把SRE的目标更清晰的传递到业务团队,并且在日常的执行上能够落实更彻底,阻力更小,能够达到双赢甚至多赢的结果。

 

具体方面的话,我以故障复盘这一场景,来分享下研发和SRE的分工和合作模式:

 

故障复盘的话,更多是一个标准和流程的事情,这块完全可以靠平台化来去覆盖和保障。从流程机制上讲,比如一个case发生之后多久需要进行复盘,复盘要达到一个怎样的目标,内容填写的细致程度,故障时间线、处理过程、隐患阶段、待办项产生等,这一些目标要求和对应的具体填写标准,SRE要写哪些,研发同学要写哪些都是需要协商好的。

 

这里的话,有四个点可以具体在谈一下。

 

  • 一个是要让业务能够认识到复盘的价值,能够通过复盘去挖掘和暴露出日常工作中的不足点、项目架构的隐患点。这样业务会更愿意、更深度去配合搞这个事情。具体的例子比如,做复盘的时候,业务团队的team leader都不参与,那这样一线的同学肯定会懈怠,对case的整改粒度也一定不会下达到位。

     

  • 除了找到事故发生的 root cause,还需要从中发现存在的隐患,而不是 case by case 的解决问题,复盘的目的是阻止类似的事情再次发生,必要的时候,可以引入业务、产品、技术共同解决。

     

  • 故障复盘不能演变为批斗会,变成一个追责的过程,这样很容易导致参与复盘的各业务方陷入互相指责、洗脱责任的怪圈,从而忘记了复盘的根本目的,并且浪费大量时间,引起不必要的内耗。只要是参与复盘的人,都是有责任在身上的,需为将来的故障负责,如果类似事故再次发生,或者没有在复盘中发现应该发现的隐患,参与的人都难辞其咎。

     

  • 复盘结果要避免惩罚为目的 —— 除非违反了规章制度(底线,不排除有些是恶法,但不在讨论范围内)。否则甩锅、不作为的氛围会日渐滋生,自省有担当和有作为的个人或者团队,很容易成为吃亏的一方。

 

通过看一个公司的事故复盘,能够发现这个公司各个团队组织文化和技术氛围的一个缩影情况。

 

  • 如何构建SRE稳定性运营意识?

 

SRE稳定性运营意识,我理解是一种可以面对各种复杂工程的稳定性提升保障时思考意识。这个意识的组成也就是上面的我说的这些,像应急响应、度量监控、容量规划、变更控制、轮值和协同等。这些意识的形成,我以内部一个实习生的心态演化来举例:

 

  • low:完全不懂,觉得稳定性就是做别人安排好的一些表格和梳理,不知道自己该做啥,稳定性好low;

     

  • 烦:各种重复的会议,做好了是应该的,做不好就是责任,很烦很焦虑;

     

  • 知道该做什么,但是累:各种报警和风险,每天需要担心,想要不管又过不了自己心里那关;大促时候天天熬夜,各种压测,最终自己累得够呛;

     

  • 发现结合点:发现在采用系统化思维之后,稳定性与系统自身的结合变得紧密,稳定性成为一种基线,找到了稳定性中的关键点和重点;

     

  • 主动驱动:发现线上业务和线下业务的稳定性差别,理解并主动调整在不同业务团队采取的稳定性策略,探究在稳定性中的自动化、工具化,系统化建立稳定性机制;

     

  • 形成体系:形成稳定性体系化思考,明确稳定性每一个点在业务团队大图中的位置,探究系统弹性建设;

 

 
刘志杰

“站在业务的角度,拉齐共识

 

多团队协作实际上是SRE体系落地过程中绕不开的一个课题。不同团队的工作目标和方向都是不同的,而SRE的目标是为了助力业务健康有序发展。

 

在SRE工作开展之前最重要的就是站在业务角度,拉齐共识。实际上在目前的工作中对这点感触还是比较深的,当业务团队和SRE团队目标拉齐,并持有利他心态,能够站在对方角度思考问题和开展工作时,真的会做到相互成就、共同成长。

 

SRE实际上是一个非常综合性的职业,除了运维、开发的基本功外,还需要在产品管理和项目管理上有所涉猎。因此在应急响应、故障复盘、容量规划等工作开展时,SRE需要纵观全局,并且以解决方案专家的客观视角对待每个问题。

 

经常有人问我怎么才能成为优秀的SRE,如何才能做好SRE的稳定性工作。除了上面我们提到的点以外,优秀的SRE一定要有入局者的思维,在做到方法论和实践的有机结合更是重中之重。

 

最后引用曾国藩的一句话与君共勉:躬身入局,挺膺负责,乃有成事之可冀。

 

特别鸣谢

 

 

图片

 

延伸阅读:

 

点击此处回看本期直播

活动预告