SRE 实战手册
15
15
1.0x
00:00/00:00
登录|注册

05 | 案例:落地SLO时还需要考虑哪些因素?

你好,我是赵成,欢迎回来。
前面几节课,我们按照层层递进的思路,从可用性讲到 SLI 和 SLO,再到 SLO 所对应的 Error Budget 策略。掌握了这些内容,也就为我们建设 SRE 体系打下了一个稳固的基础。
今天,我用一个电商系统的案例,带着你从头开始,一步一步系统性地设定 SLO,一方面巩固我们前面所学的内容,另一方面继续和你分享一些我在实践中总结的注意事项。

案例背景

我先来给你介绍下电商系统案例的基础情况,框定下我们今天要讨论的内容范围。
一般来说,电商系统一定有一个或几个核心服务,比如要给用户提供商品选择、搜索和购买的服务等。但我们知道,大部分用户并不是上来就购买,而是会有一个访问的过程,他们会先登录,再搜索,然后访问一个或多个商品详情介绍,决定是放到购物车候选,还是选择物流地址后直接下单,最后支付购买。
这条从登录到购买的链路,我们一般称之为系统的核心链路(Critical Path),系统或网站就是依靠这样一条访问链路,为用户提供了购买商品的服务能力。
至于电商系统的其它页面或能力,比如网站政策、新手指导、开店指南等等,这些对用户购买服务不会造成太大影响的,相对于核心链路来说,它的重要性就相对低一些。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文介绍了在落地SLO时需要考虑的因素,以电商系统为例,详细介绍了确定核心链路、设定SLO的原则以及验证核心链路SLO的方法。首先,通过全链路跟踪找出核心链路,确定核心应用和强弱依赖关系。在设定SLO时,需要考虑核心应用和非核心应用的不同要求,以及强弱依赖关系。验证核心链路的SLO可以通过容量压测和混沌工程。容量压测可以验证容量目标是否可以达成,并在极端场景下验证限流降级策略是否生效。整体而言,本文提供了实践中的注意事项和建议,为读者提供了落地SLO的实际操作指南。文章还提到了混沌工程的应用和系统验证的时机选择,强调了在保证业务正常运行的前提下进行系统验证的重要性。最后,文章留下了一个思考题,鼓励读者根据不同的业务场景分享特殊因素的考虑。文章内容丰富,为读者提供了全面的落地SLO实践指南和思考启示。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《SRE 实战手册》
新⼈⾸单¥29
立即购买
登录 后留言

全部留言(12)

  • 最新
  • 精选
  • leslie
    老师在课程中讲到了生产压测,其实压测同样可以放在测试环境或者非核心业务中去测试;这其实就是结合DevOps方面的知识。之前学习时有被推荐此书,不过精力有限尚未来的及去增加书库。 DevOps/敏捷讲的是突出效果必然要用典型系统:SRE的不少操作完全可以反其道而行之;故而个人意志觉得DevOps和SRE是互补的,如何合理使二者发挥功效这其实是我们一直要努力去探索的。

    作者回复: 感谢你的分享和建议。 测试环境也可以做压测,特别是一些大型核心系统,做线上压测时可以在测试环境上提前做几次,先看下效果。 但是测试环境最大的问题是,数据量是没有线上那么大,模型也没有那么精准的,所以最有效的办法还是线上。 关于DevOps和SRE的关系,后续我会在答疑篇中分享一下。

    2020-03-30
    8
  • 自行车
    很有启发,为公司部署了很多监控系统和告警策略,但是总感觉大部分的告警都是无用的,现在想想就是没有制定明确的slo,感谢老师

    作者回复: less is more,一定要选择有用的和关键的指标

    2020-04-01
    5
  • 摇滚诗人M
    游戏(吃鸡)业务: 1.核心链路:登录,玩家组队及匹配,道具购买(非核心链路,但是对公司收益直接影响,故也应保障),进行游戏,游戏结算(经验值等)。 2. 除了valet维度的SLO,还需招募人员,内测游戏中的各种场景下可能出现的bug。(bug budget) 3. 压测,混沌工程同样适合。(特殊节日预演)

    作者回复: 很好的回顾了我们本节课程的内容,学以致用。

    2020-03-29
    5
  • lyonger
    期待老师分析全链路跟踪的相关实践。😬

    作者回复: 可以看我第一门课里相关的章节,也可以自己在其它专栏中找一下对应的内容。因为这部分内容讲的比较多了,我就不再这个专栏中赘述了。

    2020-03-28
    2
    3
  • soong
    电商类应用,比较明显的限制因素,是像大促活动一类!对于ToB的SaaS类应用,月末、月初的结转、盘点,也是一个相对集中的时间点,对于这些时间点上的保障和策略要非常清晰!

    作者回复: 没有问题,时间周期只是一个参考,本质上还是根据自己的业务特点来。

    2020-04-02
    2
  • 小炭
    很难想象现在的传统企业应用运维碰到故障就是重启。

    作者回复: 但是重启有时候往往是最有效的解决方案,实战中,怎么有效怎么来。

    2020-11-07
    1
  • 旭东(Frank)
    感觉现在的运营评判标准都是靠个人感觉,也没有SLO,连主线业务都没有确定清晰,搞什么都是东施效颦

    作者回复: 没有标准的时候,每个人都是靠感觉,这就非常不可控,所以标准很关键。

    2020-04-03
    1
  • Sports
    给力,运维需要系统的学习
    2020-03-29
    2
  • 怀揣梦想的学渣
    我对混沌工程这部分感到困惑。文中提到“对于一个模拟策略上线实施,一定是在一个隔离的环境中经过了大量反复验证,包括异常情况下的恢复预案实施,确保影响可控之后,在经过多方团队评审或验证,才最终在线上实施。”。这样和现有的灾难演练有什么区别呢,现有的灾难演练,就是模拟故障,然后进行抢救,经过几年的模拟,老员工不看手册都能默写有哪些故障。甚至不排查问题都能熟练操作应多措施。但面对未知的突发问题,还是不能应对,依旧存在时长不可控的抢修。 我对这部分感到困惑,我以前以为混动工程就是引入不确定的因素,让内部在混乱中发现问题,不断打补丁完善整体。
    2023-06-16归属地:山东
  • Marx
    slo需要区分强弱依赖: 1. 核心应用对非核心应用弱依赖(自动降级) 2. 非核心应用对核心应用弱依赖(可限流) 3. 核心应用对核心应用强依赖(共享错误预算)
    2023-05-29归属地:上海
收起评论
显示
设置
留言
12
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部