02 | 系统可用性：没有故障，系统就一定是稳定的吗？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
SRE工程中系统稳定性的核心目标之一是衡量系统稳定性的方式。主要有两种方式：时间维度和请求维度。时间维度从故障角度出发对系统稳定性进行评估，通过计算系统的可用时长来判断系统的稳定性。而请求维度则通过统计成功请求占比来评估系统的运行状态。无论采用哪种方式，都需要考虑衡量指标、衡量目标和影响时长/统计周期这三个关键要素。这两种算法最终都会落脚到“几个9”上，而系统到底定“几个9”才算是稳定的，需要根据具体情况来进行评估。文章通过深入讨论系统可用性的衡量方式，为读者提供了对SRE工程中系统稳定性目标的深入理解和思考。同时，文章还掴出了三个因素，成本因素、业务容忍度和系统当前的稳定性状况，来帮助读者更清晰地认识到底应该定“几个9”这个问题。在SRE的实践中，应该选择哪一个呢？很明显，SRE会更多采用请求维度的统计方式，因为SRE关注的稳定性是系统的整体运行状态，而不仅仅只关注故障状态下的稳定性，在系统运行过程中的任何异常，都会被纳入稳定性的评估范畴中。
《SRE 实战手册》，新⼈⾸单¥29
全部留言(34)
- 最新
- 精选
- 春来草自青从业务部门的视角来看，状态码是多少他们是不关心的，他们关心的是业务是否真正的可用。比如，极端一点，状态码正常，但返回的内容不是预期的。 另外，如果业务不是需要7*24的，可用性指标应该是仅限定在业务开展期间。 有点扯远了……
作者回复: 很好的问题。从两个方面来看： 1、返回的业务内容不是预期的，这一点应该更多的是要QA来解决，这个本质是是功能问题，其实SRE是不需要关注这样的异常的。 2、如果可以做到内容不同，返回码不同，也可以做到稳定性的监控。比如对于一个用户登录应用，如果登录成功是200ok，验证码错误是1001，密码错误是1002，如果总是提示验证码错误，这种也是可以纳入到稳定性的监控指标中的。 关于第二个问题，7*24小时值守，这个看业务特点，比如对于证券类的应用，每天就是几个固定时段，所以没必要7*24小时。
2020-03-1922 
于加硕“标识系统稳定性指标” 我将这里的系统理解为一个服务，例如order这个服务，用于标识它稳定行指标有如下 基础设施层：物理设备，操作系统 应用层：全链路监控针对服务功能埋点监控 服务层：服务提供的rpc，http服务的表现 用户层：APM将从外部因素（用户视角）检测业务功能，收集各个区域/设备对业务的稳定性的表现 说到这里，我又感觉有点像立体化监控似的。 选择这些指标的判断标准是： 为什么我不能只关注http的状态呢？ 举个我自己例子，公司order.xx.com出现了问题，5xx超过2000次，这样的告警其实只是将故障的表象层告出来，业务不可用，一定会有5xx，但哪里引起的5xx？哪些告警是故障的表象层，哪些是故障点的告警，一时间难以区分，如果有一个自上而下的汇聚指标供我查看，我也许就能及时的定位到原因。在上面几个层级的指标中，经常是相互作用的，例如基础设施层宕机，会引起上面多个层级指标波动；用户层的流量激增又会带来下层的指标波动；APM中的外部因素——区域网络波动又会引起内部服务层指标499波动等。所以我个人觉得稳定性讲的是一整条请求链(从用户设备到IDC)的事，要解决稳定性就必须清楚的看到整个链路的情况，所以“标识系统稳定性指标”我选择这样几个层级。这是我的观点，希望老师指正。作者回复: 感谢你的非常详细地分析，你这里其实是针对我们可用性的内容又向下深入了一层，已经深入到了定位系统不问题的根因是什么。 关注系统可用性，我们通过几个关键指标就可以，但是深入定位根因，就像你说的，我们需要更加立体化的监控，甚至是AIOps的手段。 非常棒的分享。
2020-04-03411
leslie就像老师课程中所提及的三要素”成本因素、业务容忍度、系统当前的稳定性状况“。这三点无一不需要综合考虑，甚至有时都得考虑三者之间的比例。 个人在此之外会考虑”离散度“：确实有时觉得好像还稳定，可是离散度是否正常。记得老师的推荐的书籍中就提及过，"系统正常是系统异常的特殊情况";有故障才是是常态。没有故障且稳定说明大家都在做机械化重复操作，如何从故障和不稳定中找出问题才是根源。 老师在上一堂课中给出"建设演练/oncall->应急响应->复盘改进/oncall”我觉得就非常好的体现了SRE的理念。谢谢老师今天的分享，让我又享受在学习的过程之中。作者回复: 你的分享也非常用心，总能抓住很多关键点，很赞！
2020-03-188
OlafOO机器性能指标 应用层级指标 服务质量指标作者回复: 赞！
2020-03-207
大尾巴老猫请教一下，老师怎么看AIOPS，AIOPS对线上的业务来说，真的有（真实的）价值吗？作者回复: 要清楚，AIOps对业务本身是没有价值的，它是为运维服务的，所以它的价值更多的体现在运维层面。 体现在运维层面的哪里呢？就是问题发生前的预判、以及根因分析这些，因为在大规模分布式系统下，没有这个手段就没法处理问题。 但是AI要有两个要素，一个是算法，一个是数据，算法是靠数据训练的，这里算法不是问题，但是数据量是不是足够大就是问题，所以一定要业务体量足够大，资源规模足够大，产生的日志信息足够丰富，这时AIOps才有意义，如果只有几十几百台服务器的规模，业务体量也没有那么大的情况下，AIOps的作用是不大的。
2020-03-2135
爱吃鱼的猫稳定性还是要看应用的等级，核心应用可能会投入更多的资源和成本，从架构等多个方面做到更好的高可用，没必要为一个非核心业务投入太多资源作者回复: 非常正确！
2020-04-0923
Warm可用性指标，我觉得还需要区分下 1. 业务可用性，可以称之为“源站””，这里的统计指标最好给业务提供最大的灵活性，授权rd自身配置uei，请求方法，以及正常状态码。这里需要注意一个问题，有时候301/302/499也是错误码（比如为了友好提示5xx内部跳转，触发请求限流503），所以最好将body自定义内容作为判断指标。 2. 网络（用户）可用性。源站可用，不意味着用户也可用。可以通过监控班类的APM统计可用行指标和响应延迟（比如大于5s以上且5个节点，某某运营商线路丢包或者抖动等等）作者回复: 感谢你提供了用户可用性这个维度，从SRE角度，离用户越近的指标，越有价值。
2020-03-2223
foxracle系统可用性从用户角度来评价最直接，至少包括 1：能否访问到。这应该包括从用户操作到收到响应整个端到端的是否可用，对于用户最后一公里的不可控段也需要能感知和预警。 2：访问是否顺畅。响应时间是否异常作者回复: 从用户角度来评价，这个点把握的非常准确。
2020-03-1923
H.Z1. 系统层面：CPU、内存、磁盘IO、网络IO 2. 业务层面：网站返回状态码、接口返回时间 就想到这些作者回复: 总结地很好。可以看看后面两篇文章，看看有没有进一步的启发和思考。
2020-03-252
小圣简洁，清晰作者回复: 谢谢！看看能不能用简介清晰的几句话表达出来呢^_^
2020-03-192
