SRE SLO On-Call 流程机制 系统稳定性

 当严选遇上SLA/SLO https://mp.weixin.qq.com/s/jVZq8TyOzaIO0Xk--88wXw

当严选遇上SLA/SLO

图片

图片

 


你肯定听到过“我的服务一个季度能做到99.99%的可用率”、“我能做到3个9”、“我能做到5个9”之类的话，其背后的SLA/SLO到底是一套什么样的理论？为何在那么多国内外大型互联网公司广泛使用？严选在2年前也引入SLA/SLO并建设落地，将之用作一个线上质量和稳定性的保障手段。本文将给大家分享一下严选的SLA/SLO建设旅程，以及落地后给严选带来了哪些价值。

1 前言

你肯定听到过“我的服务一个季度能做到99.99%的可用率”、“我能做到3个9”、“我能做到5个9”之类的话，这都什么意思？背后其实就是SLA/SLO，是一套用于科学衡量产品线上质量的方法论，在Google SRE团队的大力倡导（book1、book2）下在运维界传播甚广，被国内外大型互联网企业、云厂商、金融企业所广泛使用。严选在2年前决定引入SLA/SLO，经过半年多时间的系统开发后便推广到技术中心全部业务服务去落地运营，将SLA/SLO用作一个稳定性保障手段，帮服务发现线上隐患，保障服务在线上环境的可用率，获益匪浅。2 快速扫盲SLA/SLO方法论里有好几个专业术语，老司机知道其含义，但为了照顾萌新读者，这里做一下简单扫盲（不展开详细介绍）。2.1 SLIService Level Indicator，指一个可量化的服务指标，简称指标。常见如：
  • Latency（请求响应的延迟时间，严选内部常用rt代称之，rt=ResponseTime）
  • Error（请求的错误响应率，严选内部常用5xx代称之，其实定义上还包括了各种exception）
  • Throughput（吞吐量）
  • Accuracy（准确性）
  • Freshness（实时性）
  • ……
指标有很多，但企业应根据自己的技术框架和实际诉求去选择最适合的2~5个黄金指标即可。黄金指标不是越多越好。2.2 SLOService Level Object，指服务为某个黄金指标设置一个期望的运行状态，并指定阈值，简称目标。常见如“请求延迟不大于300ms”、“5xx错误率小于0.5‰”等。多条SLO规则之间是相互独立，无因果无依赖关系的，任一不满足则意味着该服务出问题。SLO是量化线上质量的关键，它是用来回答一个服务到底“什么时候叫做挂了”的根本依据，也是可量化可统计的依据所在。2.3 Downtime也叫服务宕机时间或者不可用时间，指一个服务处于不可用状态的总时长。何谓“不可用状态”？没错，就是任意一条SLO不达成。一条请求SLO不达成，处理这条请求（从接收到请求到处理结束）所花费的时间长度就是一份Downtime。Downtime就是俗称的“我的服务挂了x分钟”的时间长短，服务的Downtime越长则直接表明该服务的线上生产环境表现越差。人无完人，金无足赤，服务不可能365天一直不挂，Downtime不可能一直为零，但要求不能超过某条线，那就是SLA。2.4 SLAService Level Agreement，一个服务对外承诺的最低可用率，由一个评定周期和一个可用率目标组成。如“每季度要达到99.99%”，其中“季度”就是所选定的评定周期（通常是月、季度、半年度、年度这四种自然周期），而“99.99%”就是所选定的可用率目标（常见有99%（2个9）、99.9%（3个9）、99.95%（3.5个9）、99.99%（4个9）、99.999%（5个9）等，5个9是互联网行业的一道坎，几乎是最高标准了，金融等特殊行业才可能会要求做到更高）。对于一些付费的商业产品，其SLA承诺通常还伴随着一份惩罚性的赔偿协议（可能是钱、代金券、服务时长、服务等级、等方面的赔偿），表示当达不到事先的可用率承诺，用户可以索取什么什么样的赔偿。这类有法律效应的带着赔偿性条款的SLA最常见于各类云服务厂商，如ASW、ECS、轻舟等。2.5 EBError Budget，错误预算，指服务在一段时间内最多可容忍多长时间的Downtime。是的，你可能想到了，EB就等于1减去SLA再乘以评定周期并换算成时间单位。一旦服务挂了产生Downtime，就会开始扣减EB预算，EB扣光就等于跌破SLA。前面为什么说“5个9”几乎是互联网行业最高标准？因为99.999%意味着你的服务在一年内最多宕机不超过5分钟！平均到每个季度也只有77秒，这是很有挑战的，对一家企业的故障监控、报警响应、故障恢复等系统都有极高要求，假如不能降低MTTR时间，充分控制Downtime发生，那EB就会被耗光。当然，EB本质上是一种预算，你可以去花，但不能花光，也尽量别去花。同时，EB零损耗和EB未耗尽都是义务，不会有奖励性措施。有些公司在实践EB时，将之定义为Allowed Failures（允许失败的最大次数），这就不是一个时间概念（挂了多少秒），而是一个数量概念（挂了多少个请求）。但本质没变，都是一种预算，在你设置好SLA时就确定了的一种预算，也都是一种你可以去花但尽量别花更别花光的预算。对于连续好几个周期都出现EB零损耗的产品，有些企业也会认为是有问题的，会在不通知产品负责团队的前提下突然对产品发起压力测试或者故障注入，试探服务是否真的健壮。从这些术语解释中，你应该可以隐约感受到这套SLA/SLO方法论为什么可以科学量化服务/产品的线上质量的基本原理了吧？概况地说，就是服务可以实现给自己预先设定好一个可用率承诺（SLA）并对外宣告，同时设置一些SLO作为监控规则，系统自动跟踪服务在线上环境的真实表现，一旦表现违反了某条SLO则开始计算Downtime并用于扣减EB。EB扣减越多，SLA就从100%开始往下掉，直至EB扣光，那么很遗憾，你这个周期的SLA就不达标了。

3 系统建设

SLA/SLO是一套方法论，本身只是一套理论，并没有标准实现。因此，在不同企业的实际落地会不完全一样，因为不同企业的业务模式和管理诉求会有差异。这没问题。就像老师布置作业要求画猫，每个学生交上来的作业肯定不会完全一样，有黑猫，有白猫，“能抓到老鼠的，就是好猫”。那么，在决定将SLA/SLO理论引入到严选之后，严选是怎么样去设计的呢？又是怎么样去建设系统的呢？ 

3.1 原始理论的本土化

在遵循SLA/SLO理论主体的前提下，严选本土化时先做了下面一些“量身定制”（可以理解为一些conventions/overwrites）：
  • 选定最适合严选的SLI，考虑到严选（电商）核心业务的技术实现都是各式各样的Webapp在线服务（主站、活动、交易、供应链、分销、等，主要基于HTTP和RPC协议），黄金指标选定了Latency（rt）和Error（5xx）这两个。为何是这两个？rt变大就是接口响应变慢了，5xx变多就是接口功能异常了，这二者都将导致本服务的服务质量和调用方体感的直接下降，是衡量HTTP&RPC的最佳黄金指标。
  • SLO规则是要求每个严选微服务为服务整体和本服务1~10个核心业务接口（很多公司的SLO实践只支持针对服务整体而不支持对接口粒度配SLO的）的2个黄金指标分别都配置上去。假如一个微服务有5个核心接口，那么它将配置上1×2+5×2=12条SLO。SLO的阈值需要经过充分推演和评审，并且不能超过某条基线，如L1服务的接口响应时间不能超过2秒（否则用户体感会很差）。图片
  • EB选择宕机总时长的形式（时间预算），而不是失败请求总量（数量预算）。由系统每天凌晨自动遍历本服务前一天的全部请求（时间上覆盖365×7×24，周末/夜间/节假日亦包含），每一个请求都计算一遍SLO，任一SLO不满足则标记该请求为异常请求。待前一天全部异常请求都找出来后，将它们在一个自然天的[00:00:00.000, 23:59:59.999]时间轴上垂直去重（确保同一个请求不会被多次计算，也确保发生多个异常请求的同一时刻只被算为一份）后计算出当天一共产生了多长时间的Downtime（当天里最少0毫秒，最多24小时），用于扣减EB。
  • SLA的评定周期仅开放月和季度两个可选（系统实现其实是支持了周、月、季度、年等多种自然周期，但周和年不开放出来），SLA可用率目标则限定在[80%, 99.999%]区间内有限的几个离散值可选，不允许设置92.3%这种“奇奇怪怪”的SLA。要求L1服务的SLA不得低于L2，以此类推，服务等级越高，要求设置越高的SLA承诺。每个微服务必须为自己设置SLA，SLA一旦设置好了就意味着本周期的EB总预算是确定不变的了，修改SLA也是下个周期才生效。每天系统在自动扣减好EB之后，会判断其本周期SLA是否已经不能达成。
  • 定期发送服务周报和产品月报邮件，向研发运维团队告知统计数据、达成情况和一些明显异常，定期组织复盘。SRE和服务/产品负责人也将参照这些数据作为决策依据（如服务拆分、线上扩容等）。同时，革命不能完全靠主动，需要探索SLA不达成的一些惩罚性措施（如发布增加审批人等）。
  • 要求严选全部L1-L3 HTTP服务（都是重要服务，L1是重中之重）都设置SLA和SLO，并且必须有准出评审（研发+运维+负责人），不能随便配，随便改。
  • 考虑到系统不成熟等阶段性原因，向服务开放EB申诉功能，如生产环境全链路摸高压测可能会导致服务线上变慢或者出现5xx报错，进而产生Downtime（因为严选是直接压线上，接口变慢变5xx是可能被真实用户感知到的，是真真切切的线上质量下降）。
在明确了上述本土化定义之后，一份《严选线上质量规范》及配套的一些子规范、接入指引和最佳实践就水到渠成，呼之欲出了。图片

3.2 基于严选DevOps的系统实现

没有严选DevOps工具链建设，这套严选SLA/SLO理论设计将沦为空话，无从落地。在丰富的严选DevOps技术项目建设成果中，对SLA/SLO最终得以从纸面走入现实最最重要的系统是：
  • CMDB：明确了产品/服务定义，明确了服务编码（如yanxuan-xxx）和服务等级（L1-L3、未定级）、明确了各角色负责人、等等，大大减轻SLA/SLO规范的术语定义成本和沟通成本。
  • APM：提供了服务运行时的丰富指标的自动化收集，最主要就是Java应用基于javaagent所捕获的请求真实数据，如一个请求当时的路径是什么（Path可对应到接口）、哪里来怎么来（Trace）、要去调用哪个服务、发生在什么时间、rt时间多少（具体到毫秒）、响应码是多少（200/4xx/5xx）、是否有抛出异常（Exception）、等等，系统里有了这些数据，SLO的判断才有从谈起。
  • 数仓/计算：每天的海量的APM数据和大量的严选微服务的接入，都带来了巨大的SLO计算成本，一天的计算体量大约是7+亿（一天APM请求数量） × 700+（个微服务） × 10（每个微服务平均配10条SLO），这么大的计算量必须要求APM请求数据接入数据仓库并配以大数据平台的离线计算框架，只有这样才跑得动SLO的自动化计算。
  • 用户界面：入口放在服务治理平台SNest上，用户可在此配置SLA、配置SLO、EB速算表、查看达成情况、EB申诉、等等，主要是平台统一收口，降低接入和使用成本，并通过页面交互来确保一些规范约束点的有效落地（如L1服务SLA不得低于99.9%）。
图片

3.3 主要成果

理论建设有了规范，系统开发有了工具，现在酒酿出来了，别浪费在巷子里，接下去就是运营工作，要到严选技术部门的各个业务板块去布道推广，落地下去。

经过1年时间，这套SLA/SLO工具在建设完成后便推广落地到了700多个webapp微服务上：
  • 微服务做出了SLA承诺：“我这个服务每季度可以做到百分之多少的可用”。这是产品负责人对服务自己的一种要求，同时也是对调用方做出的一种承诺；
  • 微服务设置上了一批SLO规则：“我这个服务/这个接口的rt不会大于多少毫秒”、“我这个服务/这个接口的5xx错误率不会大于万分之几”。同理，对服务来说，对内是一种要求（代码足够优化，部署上足够健壮），对外是一种承诺（调用方设置超时参数，评估降级等决策时可参照）。
  • 微服务日常管理和运营：利用SLA和SLO报表，定期复盘，可以发现线上有哪些性能隐患，有依赖风险，有拆分需求，有扩容诉求，等等。
严选业务板块的已定级微服务在经过充分的准出评审之后，配置上SLA和SLO后就算是正式接入了，接下去就是日常的运营工作，由系统每天自动计算服务的真实表现，量化出这些服务的线上质量。篇幅关系，这里晒几张关键截图（配以简单说明），对细节感兴趣的童鞋欢迎评论or私聊讨论。【截图1】9月份的SLA/SLO服务接入情况：共有783个服务，覆盖主站、用户、活动、交易、供应链、分销、客售、等业务板块，以及运维、数据分析、技术平台等一些基建板块，目前L1服务所设置的平均SLA为99.04%，L2为97.89%，L3为91.01%。图片【截图2】以供应链板块为例，该板块一共有83个微服务，其中82个已接入（接入率98.8%），其中78个服务的SLA可以达成（达成率95.1%），而4个服务的SLA不能按承诺去达成。说明这4个服务存在这样那样的问题（进一步去看每日SLO实测结果表）。【讨论题】那78个可达成的服务就一定没问题吗？请思考，评论区讨论。图片【截图3】以交易中台这个产品为例，EB损耗报表页可以看到每天都有损耗，但是经过2021年持续的专项优化整治之后，每日EB损耗曲线明显好转。图片【截图4&5】以某个具体的交易下单微服务为例，可以看到8月份的错误预算燃尽速度和预算余量，EB花太快（13号暴跌）可不是好事。图片图片【截图6】再以另一个具体的微服务为例，可以看到它配置了8条SLO，但每天都有一些SLO是不能达成的，因此每天都会带来EB损耗。图片【截图7&8】这是ic-basis服务（商品中心用于查询商品信息的一个L1重要后端微服务）的设置情况，可以看到该服务的SLA承诺是每个月做到3个9，目前（9月份）的错误预算余量还算可以（但7月和8月都跌破了，9月要努力）。另外，该服务设置上了6条SLO，服务整体的错误率（error）和延迟（rt）各一条，另外4条是给了业务接口。图片图片【截图9】服务在SNest上设置SLA时可以参阅的一份推荐原则和错误预算速算表。图片4 价值产出

4.1 统一术语，科学管理线上质量

在没有SLA/SLO的旧时代，不同团队对线上生产环境的质量高低的衡量和表述都有各自一套术语和尺度，“我没挂”、“昨天早上我挂了10%”不同人的理解是不一样的。如今，有了这么一套国内外大厂都认同且普世适用的SLA/SLO理论，就引入到严选来统一全员的认知：要衡量一个服务在生产环境的质量高低，就看它的SLA/SLO。用统一的术语来对话。同时，技术中心开发出一套用户无感知的自动化计算系统和简单易用的用户平台，再配以一系列标准规范和最佳实践指引，那么对严选业务服务来说，喝上SLA/SLO这口美酒的成本很低：在经过严谨且充分的评审和准出之后，就可以轻松配置生效，就可以用上这套科学的管理工具。

4.2 搅屎棍，暴露服务线上隐患

很多服务在接入之初很恐惧：“我的报表太难看了！怎么有那么多条SLO达成是红色的？怎么每天都有那么多Downtime产生？”。在严选内部，我们经常说“SLO就是一根搅屎棍”，只要服务的SLO配置合理，那么它在线上环境若真有shit存在（明面上肉眼可见的，或者隐藏很深难以发现的），都将被搅出来，要的就是这个效果，就是要让这些线上隐患暴露出来。SLO会告诉你存在问题，但不直接告诉你答案。当看到有shit被搅出来，你需要进一步去挖根因和制订优化方案。一个服务的线上质量出现抖动，最常见就是接口响应变慢或者接口直接5xx报错（最终都会体现为某条SLO无法达成，Downtime产生），那接口对应的用户下单，查询商品信息，支付等线上行为就可能遭殃（如用户端超时、报错或者空白页等）。此时，负责该服务的研发团队看到“不漂亮”的SLO报表，就要去深挖到底是什么原因导致的，是因为最近上线的新版本代码逻辑不够好？还是DB/Cache挂了慢了？还是流量暴涨容量不够（提示该扩容了）？还是调用侧的使用姿势不对（如下调单次POST的参数总个数限制）？还是其它原因？并抓紧修复问题消除隐患，免得第二天再继续有Downtime产生（继续扣减错误预算，增大跌破SLA的风险）。4.3 稳定性抓手，串一起看质量严选业务体量在持续发展，技术架构在经过微服务拆分之后，单个服务规模变小了，但服务数量激增，而且服务之间的调用拓扑关系越来越复杂。服务之间相互依赖，不再能独立工作，一荣俱荣，一损（容易）俱损。一个服务的线上质量要高，线上稳定性要有足够保障，那它所依赖的那些服务也非常关键。也就是说，在微服务时代，SLO表面看似是一个服务单体视角，其实是一整条调用链路的拓扑视角。举个例子，一个服务A强依赖于服务B/C/D，同时弱依赖于服务E/F/G/H，一旦服务A的某个接口SLO不能达成，那会倒逼研发团队去思考：
  • 对于B/C/D三个服务的超时参数是不是合理（此时就可以去看B/C/D的接口SLO所配的阈值了）？
  • 对于E/F/G/H四个服务是否有熔断机制？是否有自动预案？
  • 对于G和H这两个弱依赖是不是可以干脆异步化解耦掉？
  • 我这个服务A是不是太大该进一步微服务拆分成A1/A2/A3了？
  • 等等
基本思路是：依赖服务是不可信的，一旦它们发生故障，我能否阻断故障，让故障不再向前传递，弱化掉我的调用方（和用户端）对故障的感知程度，甚至不要感知。有更多的服务做到这一点，整个产品就显得更加稳定了。 

4.4 敬畏生产环境

当整个技术部门都有了一致的理念和目标（都在追求SLA达成和SLO达成），这会促进各个技术职能（研发、测试、运维、等）都去敬畏线上生产环境，不断思考要强化哪些工作。尤其当团队决定在“SLA不能达成”时会触发一些惩罚性措施之后（如发布增加负责人审批卡点，推迟新功能研发（先提升稳定性再去码新功能），下调服务等级，等等），SLA/SLO就不再是一个建议性措施，而是一个强制性规范。最常见地，
  • 研发团队会更加重视提升代码质量，优化应用架构，优化参数配置，重视框架选型等工作，确保提供一份优秀健壮的代码；
  • 测试团队会重视提升测试质量，定期组织压力测试和故障演练，确保准出到线上环境的是一份高质量的代码制品；
  • 运维团队会更重视提升交付质量，日常操作合法合规，重视容量管理提前扩容，重视监控和巡检，确保线上机器和网络等基础环境是稳定的；
  • 技术委员会会促进零感知发布、异常监控、报警响应、故障恢复等DevOps能力的建设，合力缩短MTTR，并引导系统资源和团队资源向高SLA服务倾斜，优先保障高SLA服务；
5 局限性吹了那么多SLA/SLO的好，那么，这就是一颗银弹，无所不能了吗？不。任何一套理论和工具都有它的预设场景，在这个场景内它效率最佳，收益最高，出了这个场景圈子它的效力就大打折扣，甚至不适用而起反作用（事倍功半）。
  • 不是监控系统。有了SLA/SLO去度量线上质量，不代表你就可以忽视基建监控（硬件/系统/网络监控）、进程监控（APM/日志监控）、业务监控（多个服务多份数据共同组成一个业务行为），弃之不用。
  • 不是无所不能。理论上SLI全集很大，但具体到企业落地时黄金指标就只会选定有限的几个。严选只选了Latency和Error，不代表Throughput、Accuracy、Freshness等其它SLI就没用，只是在综合了技术现状、SLI指标收集成本、ROI等因素考虑之后没被选上而已。对于落选的SLI，就无法为之配置SLO规则，其对应的描述能力就无法用上。
  • 不一定被用好。在严选我们看到很多有着极高追求的服务：有2个服务给自己设置的接口RT阈值是2毫秒（你没看错，是2毫秒，不是20毫秒，也不是2秒）、有3个服务给自己设置的接口Error阈值是万分之1、有4个服务给自己设置的SLA是5个9（嗯，99.999%极限值），对于这些服务来说，随便发生一个网络抖动或者缓存抖动就可能导致守不住，但他们依然选择做勇士，敢于对自己提出高要求。但是，可能你也想到了，这套SLA/SLO的理论和工具里有些细节其实是存在人为操作空间的，如下单接口代码很差那我就故意不给它配SLO规则（我不说你不说，这个接口就漏过去），商品查询接口调用方可以接受500毫秒超时那我就得过且过（虽然我知道经过一定投入去优化是可以提升到200毫秒的，但500阈值对我来说更安全嘛），看到少量Downtime我就视而不见（反正一天只扣一点点，又没扣光我的整个EB预算），等等，这样种种的逃避/作弊行为都会妨碍这套工具的效用发挥到极致。尽管可以通过一些管理手段和规范流程来规避，但提高每位参与者的主动积极性和自觉性，这更重要。 

6 小结

当前，SLA/SLO在严选的实践方兴未艾，今年还有很多工作正在开展，譬如高危EB专项整治、重点业务域达成和问题复盘、L1服务SLO规则准出评审、等。本文一方面是向大家推广SLA/SLO这套理论，另一方面也是对严选的落地情况和阶段性成果的一份总结。抛砖引玉，分享出来供大家参考，最好是能引发一些讨论，碰撞想法，让SLA/SLO系统能建设得更好，让SLA/SLO工具能更充分地发挥作用。

7 扩展阅读

  • Google SRE团队的经验分享：
    • Chapter 2 - Implementing SLOs：https://sre.google/workbook/implementing-slos/
    • Chapter 4 - Service Level Objectives：https://sre.google/sre-book/service-level-objectives/
  • 虎牙SRE团队的经验分享：
    • 虎牙直播的SRE实践与思考：https://www.sohu.com/a/218480103_411876
    • 解密SRE的六种能力及虎牙运维实践：https://blog.csdn.net/weixin_33915554/article/details/88706020
  • 一些云厂商官网的SLA承诺：
    • 亚马逊云主机ASW：https://aws.amazon.com/cn/compute/sla/
    • 阿里云主机ECS：https://help.aliyun.com/document_detail/64695.html
    • 阿里云短信服务：https://help.aliyun.com/document_detail/63935.html
    • 阿里云对象存储OSS：https://help.aliyun.com/document_detail/60175.html

本文由作者授权严选技术团队发布

开篇词｜SRE是解决系统稳定性问题的灵丹妙药吗？ https://time.geekbang.org/column/article/212686

这两年，近距离地接触了很多不同类型、不同规模的企业 IT 团队，我发现他们为了提升用户价值的交付效率，都在积极采用微服务、容器，以及其他的分布式技术和产品，而且也在积极引入像 DevOps 这样的先进理念。这些公司选择了正确的架构演进方向和交付理念，效率自然是提升了一大截。这样的情况，是不是也发生在你的公司、发生在你自己身上？这时候你会发现，效率提升了，但挑战紧跟着也来了：在引入了这么多先进的技术和理念之后，这种复杂架构的系统稳定性很难得到保障，怎么办？这个问题其实不难回答，答案就是 SRE。这几年业界对 SRE 的关注越来越多，大家也几乎达成了共识，Google SRE 就是目前稳定性领域的最佳实践。也可以说，SRE 已经成为稳定性的代名词。

 

DevOps核心是做全栈交付，SRE的核心是稳定性保障，关注业务所有活动，两者的共性是：都使用软件工程解决问题;
DevOps的诞生是由于互联网商业市场竞争加剧，企业为减少试错成本，往往仅推出最小可行产品，产品需要不断且高频的迭代来满足市场需求，抢占市场(产品的迭代是关乎一整条交付链的事)，高频的迭代则会促使研发团队使用敏捷模式，敏捷模式下对运维的全栈交付能力要求更严格，则运维必须开启DevOps来实现全栈交付；因为不断的迭代交付(也就是俗称的变更)是触发故障，非稳定性根源，而互联网产品/服务稳定性缺失会造成用户流失，甚至流到竞争对手那里， 因此关注业务稳定性也变得十分重要，SRE由此诞生。希望看完赵老师的课程后对理论能有所提升。

 

比如，你想要找到建设 SRE 体系的切入点，最好的办法就是建立稳定性的标准化。有时你会和周边团队就稳定性问题产生一些争执，说到底就是因为你们没有达成共识的、统一的衡量标准。Google SRE 已经给我们提供了很好的标准化手段，也就是 SLO。你看，这个问题不就得到解决了吗？

我会把 SLO 作为引入 SRE 的切入点，因为它就相当于我们稳定性标准化的基础。同时，SLO 也是稳定性保障的共识机制，有了这个共识，我们才能更好地管理稳定性，消除掉来自周边团队的很多不理解和不认可。

关于建设 On-Call 的流程机制，我给你分享了我自己团队的“On-Call 关键 5 步法”，咱们再一起复习一下：

posted @ 2020-04-07 00:03  papering  阅读(1021)  评论(0)  编辑  收藏  举报