阿里妹导读:稳定性目前不再局限于大促时的保障和平时的稳定性轮值,越来越体系化。本文基于作者在业务团队工作过程中的沉淀,以及在盒马两年SRE的实战经验,从稳定性心态、监控体系、故障应急体系、资源体系、大促保障机制、日常保障机制等几个层面,就如何做好SRE的工作进行了分享。
文末福利:阿里巴巴零售云事业部全渠道团队招聘啦~
low:完全不懂,觉得稳定性就是做别人安排好的一些表格和梳理,不知道自己该做啥,稳定性好low。
烦:各种重复的会议,做好了是应该的,做不好就是责任,很烦很焦虑。
知道该做什么,但是累:各种报警和风险,每天需要担心,想要不管又过不了自己心里那关;大促时候天天熬夜,各种压测,最终自己累得够呛。
发现结合点:发现在采用系统化思维之后,稳定性与系统自身的结合变得紧密,稳定性成为一种基线,找到了稳定性中的关键点和重点。
主动驱动:发现线上业务和线下业务的稳定性差别,理解并主动调整在不同业务团队采取的稳定性策略,探究在稳定性中的自动化、工具化,系统化建立稳定性机制。
形成体系:形成稳定性体系化思考,明确稳定性每一个点在业务团队大图中的位置,探究系统弹性建设。
必须选择负责任的人
负责任是第一要素,主动承担,对报警、工单、线上问题、风险主动响应,不怕吃苦;一个不负责任的人,遇到问题与我无关的人,边界感太强的人,难以做好稳定性的工作。
原则上不要选择新人
对于团队leader而言,“用新人做别人不愿意做的工作”,这个决定比较容易做出,但是这也相当于是把团队的稳定性放在了一定程度的风险上,用新人做稳定性,其实只是用新人占了稳定性的一个坑而已。新人不熟悉业务,不了解上下游,最多只能凭借一腔热血,对业务和系统感知不足,容易导致线上风险无法被快速发现、故障应急无法迅速组织。
不要用过于"老实"的人
这里的“老实”的定义是不去主动想优化的办法,不主动出头解决问题,但是很能吃苦,任劳任怨,也很能忍耐系统的腐烂和低效;这样的人平时很踏实,用起来也顺手,但是却无法主动提高系统稳定性,有的时候反而会给系统稳定性造成伤害(稳定性就像大堤,不主动升级,就早晚会腐烂)。
给资源
稳定性从来不只是稳定性负责人的事情,而是全团队的事情,稳定性负责人要做的是建立机制,主动承担,但是稳定性意识,要深入到团队所有人脑子里,稳定性的事情,要能够调动团队一切资源参与。
给空间
做稳定性的人,往往面临一个尴尬场景:晋升困难,主要是因为在技术深度和业务价值两个方面,很容易被挑战,对于业务团队,一定要留给做稳定性的人足够的思考和上升空间,将稳定性与团队的技术架构升级、业务项目结合起来,共同推动。经过集团安全生产团队的推动,目前在阿里,SRE已经有了自己专门的晋升体系。
区分责任
当出现故障时,区分清楚责任,到底是稳定性工作没有做到位,还是做到位了,但是团队同学疏忽了,还是说只是单纯的业务变化。
开发:了解业务 -> 定位问题 -> 排查问题 -> 解决问题
SRE:了解业务归属 -> 快速定位问题范围 -> 协调相关人投入排查 -> 评估影响面 -> 决策恢复手段
尽快告知当前告警已经有人接手,是谁接手的,表明问题有人在处理了(这一步叫“响应”)。
组织人员,快速定位问题,告知问题初步定位原因。(这一步叫“定位”)
初步影响范围是什么?给出大致数据。(这一步方便后面做决策)
有哪些需要老板、产品、业务方决策的?你的建议是什么?(这一步很关键,很多时候是:两害相权取其轻,你的评估和建议,直接影响老板的决策)
当前进展如何,是否已经止血?(这一步是“恢复”,要给出“进展”,让决策者和业务方了解情况)
稳定性意识
日常值班机制
报警响应机制
复盘机制
故障演练机制
故障奖惩机制
大促保障机制
梳理。主动梳理团队的业务时序、核心链路流程、流量地图、依赖风险,通过这个过程明确链路风险,流量水位,时序冗余;
治理。主动组织风险治理,将梳理出来的风险,以专项的形式治理掉,防患于未然。
演练。把风险化成攻击,在没有故障时制造一些可控的故障点,通过演练来提高大家响应的能力和对风险点的认知。这一点将在后面详述。
值班。不能仅仅为了值班而值班,值班不止是解决问题,还要能够发现风险,发现问题之后,推动上下游解决,减少值班中的重复问题,才是目标。
报警。除了前面说过的主动响应之外,还要经常做报警保险和机制调整,保证报警的准确度和大家对报警的敏感度。同时也要做到不疏忽任何一个点,因为疏忽的点,就可能导致问题。
暖曰:“ 王独不闻魏文王之问扁鹊耶?曰:‘子昆弟三人其孰最善为医?’扁鹊曰:‘长兄最善,中兄次之,扁鹊最为下。’魏文侯曰:‘可得闻邪?’扁鹊曰:‘长兄于病视神,未有形而除之,故名不出于家。中兄治病,其在毫毛,故名不出于闾。若扁鹊者,镵血脉,投毒药,副肌肤,闲而名出闻于诸侯。’魏文侯曰:‘善。使管子行医术以扁鹊之道,曰桓公几能成其霸乎!’凡此者不病病,治之无名,使之无形,至功之成,其下谓之自然。故良医化之,拙医败之,虽幸不死,创伸股维。”
——《鶡冠子·卷下·世贤第十六》
做扁鹊大哥:在系统健康时发现问题
做扁鹊二哥:在系统有隐患时发现问题
做扁鹊:在系统发生问题时快速解决问题
常常思考产品和系统哪里有问题,如何优化,如何体系化?
常常思考有没有更好的办法,有没有提高效率的办法?
常常思考如何让稳定性本身更加有价值,有意义?
数据驱动:包括日志标准化和错误码标准化,能够对日志和错误码反馈的情况进行量化。
数据对账:包括上下游对账、业务对账,能够通过对账,保障域内数据校准。
轨迹跟踪:包括变更轨迹和数据轨迹,目标是实现数据的可跟踪,和变更的可回溯、可回滚。
数据化运营:主要是将稳定性的指标量化,比如工单解决时间、工单数、报警数、报警响应时间、故障风险数、代码CR量,变更灰度时长等,通过量化指标,驱动团队同学建立量化意识,并且能给老板一份量化数据。
对于稳定性新人,一定要优先考虑如何响应问题,而不是如何解决问题。
稳定性从来都不是简单的,他的关键,是要做细,这需要细心和耐心。
稳定性不是一个人的事情,要团结团队内的同学,上下游的同学。
(1)3张图
系统间依赖图(也包括业务时序,熟悉业务流程),参考5.4节系统依赖梳理方法。
流量地图(知道上下游系统,团队内系统的流量关系和流量水位,也同时把控系统架构),参考5.3节流量地图。
系统保障图(知道稳定性保障的步骤和打法),参考5.2节作战地图。
(2)3张表
机器资源表(做到占用多少资源,了然于胸,团队需要时能拿得出来),参考第4章资源管控。
异常场景应急表(出现问题时知道怎么应对,演练知道哪里容易出问题),参考3.2节故障场景梳理。
业务近30日单量表(知道哪些业务影响大,哪些业务是重点),参考6.1节黄金链路治理。
|
|
|
|
|
|
|
|
|
|
|
|
在服务方面没有异常(我把服务错误造成的用户体验,也认为是服务异常)。
在数据上没有出错(我把订单超时等体验,也认为是数据出现了偏差)。
在资金上没有资损(走了兜底逻辑,且按照业务可接受的预定范围兜底造成的损失,不算资损,如兜底运费)。
最核心业务入口的qps、rt、错误数、成功率,从这个维度可以看到入口流量的大小和相应时间,成功率。这一点,是在知道入口的健康情况。
错误码top N,这个维度可以看到系统运行过程中最核心的错误,快速直观定位问题原因(这个需要打通上下游错误码透传)。这一点,是在快速知晓问题出在哪里。
按业务维度(业务身份、行业、仓储、地区等,根据实际需要决定)分类统计计算的单量、或分钟级下单数量,用于确定核心业务的单量趋势。这一点,只在知道自身业务的健康情况。
核心下游依赖接口、tair、db的qps、rt、错误数、成功率,需要注意的是,这个一般比较多,建议只放最核心、量最大的几个。这一点,是在知道下游依赖的健康情况。
其他影响系统稳定性的核心指标,如限单量,核心计数器等,根据各个团队的核心来决定。这一点,是在个性化定义关键影响点的监控情况。
推送到手机的报警,如电话、短信报警。
推送到钉钉的报警,如报警小助手、报警。
对于系统监控报警,采用范围报警,比如load,设置集群内超过N %且机器数大于M的机器load都升高了才报警。毕竟对于一个集群而言,偶尔一台机器的load抖动,是不需要响应的。
对于业务报警,一定要做好同比,不但要同比昨天,还要同比上周,通过对比确认,对于一些流量不是很大的业务来说,这一点尤其重要,有些时候错误高,纯粹是ERROR级别日志过度打印,所以只要相对于昨天和上周没有明显增加,就不用报警。
对于qps、rt等服务报警,要注意持续性,一般来说,要考虑持续N分钟,才需要报警,偶尔的抖动,是不用报警的。当然,对于成功率下跌,异常数增加,一般要立即报出来。
复合报警,比如一方面要持续N分钟,一方面要同比昨天和上周,这样来减少一些无需报警的情况。
根据需要设置报警的阈值,避免设置>0就报警这种,这种报警没有意义,一般来说,如果一个报警,连续重复报10条以上,都没有处理,一般是这个报警的通知级别不够,但是如果一个报警,重复10条以上,经过处理人判断,不需要处理,那就肯定是这个报警的阈值有问题。
首先当然是要监控治理,做到监控准确,全面,然后按照前面说的,控制报警数量,集中报警群,做到可控、合理。
然后像刷抖音一样,隔三差五(一般至少1个小时要有一次)刷一下报警群,如果报警群里的新增条数在20条以内,问题一般不大,刷一刷就行。
如果突然一段时间内报警陡增,就要看一下具体是什么问题了,小问题直接处理,大问题分工组织协调。
消防群中的问题,要及时同步到团队中。
值班群中的工单,需要关注,并有一个初步的判断:是否是大面积出现的业务反馈,是否有扩大的隐患。
尽量增加无故障时间
尽量缩短出故障后的恢复时间
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
对于系统性故障注入(load、cpu、fullGC、线程池等),直接套用集团的mk注入即可。
对于服务型故障注入(下游异常、超时,接口超时、限流),mk也有比较好的支持。
对于订单异常型故障注入,要自主开发较好的错误订单生成工具,注入异常订单,触发故障报警。
对于调度、积压型故障注入,要关注schedulex、异步消息的故障注入方式,同时防止积压阻塞正常订单影响真正的线上业务。
冷静。作为SRE,首先不能慌,没有什么比尽快定位和止损更重要的事情。
拉电话会议同步给大家信息。记住,在出现故障时,没什么比电话会议更加高效的沟通方式了。
参考前面1.4.1节中的SRE人员快速响应流程,在电话会议中同步给大家:
组织大家按照故障场景梳理的应对方案进行应对,如果没有在故障场景列表中,一定要组织最熟练的人员进行定位和恢复。
故障过程中,对外通信要跟团队和老板统一评估过再说;
处理故障过程中,要随时组织同学们进行影响数据捞取和评估,捞出来的数据,要优先跟老板、业务熟练的同学一起评估是否有错漏。
在处理完故障后,要及时组织复盘(不管GOC是不是统一组织复盘,内部都要更加深刻的复盘),复盘流程至少包括:详细的时间线,详细的原因,详细的定位和解决方案,后续action和改进措施,本次故障的处理结果。
不能嘲笑别人,看笑话。
不能当没事人,高高挂起,要检查自身。
不能话说的太满,比如说我肯定没故障。
限于篇幅,以上是本文的上半部分,下半部分作者将分享大促保障机制、日常稳定性机制、弹性建设及价值建设方面的内容,同学们可点击“阅读原文”继续阅读~
团队招聘
阿里巴巴零售云事业部全渠道团队诚招精英(层级不限,开发 or SRE),共同建设面向商家的零售解决方案。
我们是谁
我们是阿里巴巴零售云事业部-技术部-全渠道团队,主要承接零售云的全渠道线上线下一体化业务。目前是新零售建设的关键时期,也是国内2B业务蓬勃发展的重要时期,我们根植于阿里云,打造面向商家的全新业务模式,定制商家需要的新零售服务系统,面向弹外提供商业化零售解决方案。
要做什么
我们目前承接新零售模式下多个商家的全渠道业务,在系统打造上精耕细作,希望能为您提供在商家协调、服务定制、SaaS化、高可用架构、行业标准化等方面的工作空间,共同探索在商家长期陪伴、多版本、行业标准化和定制化、降本提效等方面的产品化方法。
我们作为一只商业化技术团队,也将提供更多的接触商家的机会、深入了解各个行业特点的机会、以及弹外和阿里电商体系完全不一样的玩法机会。同时,我们也在深耕SRE建设,同步招聘有志于SRE之路的人才。
有什么要求
只要你有工作热情,希望体验新零售、精细化零售业务模式下的新鲜刺激。
只要你想探索除2C模式电商以外的其他零售商业可行性,了解弹外零售业务的特点。
只要你有系统隔离、领域设计、高可用、提效降本、业务产品化经验或者对上述这些感兴趣。
或者对面向商家的商业化、新零售业务、标准制定感兴趣。
仅面向研发技术同学或SRE同学,要求有3年以上Java开发经验,有SaaS企业开发经验或国内大型互联网开发经验者优先。
工作地点
阿里巴巴杭州西溪园区
如何联系
邮件您的简历至:yinggang.zg@alibaba-inc.com
还在烦恼不知道怎么学Java?手上一堆技术书籍却无从下手?本书作者根据多年开发经验,倾心五年沉淀,为广大初学者提供一个完整的Java学习路径,从头开始给你一个体系化的学习方案,并附成神导图。
识别下方二维码,立即下载吧!