SRE接手新业务首要工作:运维准入测试

秦晓辉@快猫星云 2023-03-24 05:06:10

如果接手的是一坨随时可能散架的破车,就算SRE有通天之能,也很难通过运维手段给变成布加迪威龙。接手的时候一定要做好准入测试!很多公司会有运维准入规范,但是通常缺少运维准入测试,导致了后续诸多背锅问题。

前言

你可能会遇到下面的问题:

  • 告诉研发做架构设计的时候要叫上运维做 review,研发经常忘记
  • 架构上明明有问题,业务方说时间要求紧迫,先上线再慢慢优化,导致运维捏着鼻子运维这些残次品,而且每次都这样
  • 明明是软件设计问题,出了问题首先要抓的是监控是否到位,运维响应是否及时,运维人员心里苦
  • 架构设计看起来是完善的,但是到了线上实际跑的时候,却没有按照预期的行为来,单机挂了服务就受影响

其实研发也不是要跟运维对着干,只是有些事情研发可能没想到,或者有些事情虽然想到了,但是迫于各方面的因素没有落地。

解法

你需要:运维准入测试!

如之前的文章所述,运维总监大概率是CTO Core团队成员,需要跟CTO达成这个流程要求,然后在Core团队例会上,由CTO颁布这个要求。让运维总监去推动平级的研发负责人,也不是不行,只是费劲,而且有些研发负责人未必配合,而CTO就是名正言顺管这事的,所以,在其位谋其政,请各位CTO不要尸位素餐。

逻辑拆解

因为有“运维准入测试”这个环节,而且是上线之前的必走流程,研发人员肯定希望一次性通过,所以会提前了解要测试哪些内容,有什么要求,会主动来找SRE咨询,这样SRE工作就好推了。

需要明确,如果过不了准入测试,就不能上线,除非研发负责人审批通过,CTO审批通过。当然,即使审批通过,残次品上线了,出了问题也需要研发OnCall,SRE辅助,即稳定性第一责任人变成了研发,SRE不背这个锅。

测试分功能测试、性能测试、稳定性测试、安全测试。SRE需要提供一个类线上环境,让研发把服务部署上去,QA提供功能测试报告、性能测试报告,这个性能测试报告是容量管理的重要依据。安全测试由专职的安全工程师来做,出具安全测试报告。稳定性测试则由运维人员来做,就是混沌工程,搞挂某个机器,把机器的CPU跑满、IO跑满之类的,看看服务是否受影响,是否可以自动恢复,恢复时长如何,是否需要提前制作预案。要做稳定性测试得有可观测数据,衡量服务的健康状况,这个过程中,顺便也就把服务的SLO定出来,相关的核心监控指标定出来,可观测性数据体系建立起来。

另外,生产环境其实也应该实施混沌工程,不定时搞点事情。一个是看是否能快速定位问题,可观测体系建立的如何,一个是看故障响应流程和及时性,以及预案完备性。

小结

其实,我倒不是要站在运维的角度难为研发。而是作为IT技术团队,要提供给业务方一个稳定可靠的技术产品,这些都是必备的。业务成功,大家才能成功,业务成功需要有靠谱的技术产品。说到底,大家都是栓在一条绳上的。

标签: SRE
« 上一篇:如何做好今天的运维
» 下一篇:夜莺V6.X架构介绍
快猫星云 联系方式 快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云 联系方式
快猫星云
OpenSource
开源版
Flashcat
Flashcat
FlashDuty
Flashduty