如何用 SLO 报表管理核心服务可用性

极客资料网推荐如何用 SLO 报表管理核心服务可用性这篇文章给大家，欢迎收藏极客资料网享受知识的乐趣

很多团队说自己在做稳定性治理。真正落到日常工作里，往往还是事故复盘：系统出故障，开会，写原因、影响和改进项；过一阵子，又出故障，再开会。这当然比什么都不记录要好，但它还不是治理。它只是把事故写进文档。

稳定性治理要回答的是更难、也更持续的问题：核心服务这个月到底可用多久，哪些接口消耗了最多不可用时间，错误预算还剩多少，哪些对象没有造成大事故却一直短时间抖动，下个月应该先治理哪条链路、哪个服务、哪个组件。复盘文档很难回答这些问题，因为它天然面向已经发生的事故，而不是持续变化的风险状态。

这些问题必须被持续计算。

Flashcat 的 SLO 报表做的就是这件事：把灭火图卡片的健康状态，转成核心服务可用性管理的计算机制。换句话说，它不是再做一个漂亮的月报页面，而是把“服务是否健康”变成“一个周期内是否履约”。

SLO 不应该只写在文档里

很多团队其实都有 SLO。核心支付链路 99.95%，订单系统月可用性 99.9%，登录服务季度可用性 99.95%，核心数据库全年不可用时间不超过 100 分钟。这些数字通常出现在稳定性制度、SLA 协议、年度 OKR 或复盘模板里。问题在于，它们经常没有和真实的监控对象打通。

服务什么时候算不可用？一分钟抖动算不算？接口成功率低于多少开始扣配额？数据库卡片飘红是否要计入服务不可用？灰色无数据是正常、异常，还是采集问题？维护窗口是否排除？如果这些规则没有产品化，SLO 就会变成会议里的数字。事故发生后，团队再讨论这次要不要扣配额、扣多少分钟、算哪个系统、算哪个团队。

这种方式能勉强运转，但成本高，而且结果不稳定。Flashcat SLO 报表的思路更直接：先在灭火图里把服务、接口、组件这些观测对象建成卡片；再用卡片健康状态判断每一分钟是否达标；最后把分钟级状态汇总成周、月、季、年的 SLO 报表。

SLO 不再是一张单独维护的管理表。它建立在灭火图对象和健康度之上。

先选 SLO 对象，而不是先设目标值

做 SLO 报表，第一步不是填 99.9% 还是 99.95%，而是选对象。在 Flashcat 里，SLO 对象就是被选入 SLO 报表的灭火图卡片。它可以是底层详情卡片，也可以是分组卡片。这一步决定了后面所有数字是否可信，因为 SLO 管的不是一个抽象系统名，而是一个可计算、可追溯、能下钻的对象。

以电商系统为例，第一批 SLO 对象可以是：

• 下单接口
• 支付接口
• 登录接口
• 订单服务
• 支付服务
• 库存服务
• MySQL 订单库
• Redis 库存缓存
• 支付链路分组

不同对象适合不同层级的 SLO。接口 SLO 衡量用户入口体验，比如下单接口成功率、支付接口耗时、登录接口可用性。服务 SLO 衡量研发团队负责的服务质量，比如 order-service、payment-service、user-service。组件 SLO 衡量平台或中间件团队负责的基础能力，比如 MySQL 集群、Redis 集群、Kafka 集群。分组 SLO 则适合表达一条链路，比如“支付链路”分组下包含支付接口、支付服务、支付数据库、第三方通道卡片。只要任意关键对象飘红，用户支付体验就可能受到影响，分组就可以被认为不达标。

对象选错了，后面的 SLO 都会失真。对象太粗，报表可能看起来达标，但局部接口长期抖动会被掩盖；对象太细，报表会被大量低价值对象拖住，治理焦点反而变散。第一版不要贪大，先覆盖最关键的 10 到 30 张卡片，让 SLO 报表先成为核心服务治理工具，而不是全量资产统计表。

SLI 要体现在卡片健康条件里

SLO 需要 SLI。SLI 是衡量服务质量的指标，但在 Flashcat 灭火图里，SLO 报表不是重新写一套 SLI 规则，而是复用卡片健康状态。这意味着，SLI 必须先体现在卡片的健康指标和异常条件里。

以下单接口为例，卡片可以关注请求量、成功率、P99 响应时间。异常条件可以是成功率小于 99%、P99 大于 3 秒，或者核心时段请求量异常下降。当卡片在某一分钟飘红，这一分钟就视为不达标；没有飘红，就视为达标。

Flashcat SLO 报表的计算粒度是 1 分钟，和灭火图卡片健康度的计算粒度对应。这样做的好处很现实：故障发现、告警、排查和 SLO 统计使用同一套对象、同一套规则。团队不用在告警系统配一套阈值，在大盘里看另一套指标，在 SLO 工具里再维护第三套判断逻辑。

代价也很清楚：卡片健康条件必须可信。如果卡片经常误飘红，SLO 会被误扣；如果阈值太宽，真实不可用进不了 SLO；如果核心卡片长期灰色，SLO 报表也很难让人信任。所以在创建 SLO 报表前，先把灭火图卡片调到相对稳定：常态绿色，真实异常飘红，灰色状态有解释，下钻路径能查到证据。

SLO 报表是稳定性治理的上层结果，不应该建立在不可信的卡片上。

目标周期决定治理节奏

Flashcat SLO 报表可以设置目标周期：周、月、季、年。不要随便选，目标周期本质上是在定义治理节奏。

周 SLO 适合短周期试点。比如一个系统刚接入灭火图，卡片阈值还在调整，团队希望每周看一次达标情况。它反馈快，但波动也大。月 SLO 适合大多数团队的稳定性运营，每月看核心服务可用性、未达标 TopN、不可用时间段和剩余配额，用来做月度 review 和治理排期。季 SLO 适合业务线或平台团队做阶段性治理，比如一个季度内支付链路、订单链路、中间件集群的稳定性目标是否达成。年 SLO 更接近 SLA 或年度稳定性目标，比如全年 99.95%，全年故障配额约 262.7 分钟。

第一版建议从月周期开始。周周期容易被一次短抖动放大，年周期又太慢，等年底才发现配额消耗过快，治理窗口已经过去了。月度 SLO 刚好能把技术指标转成管理动作。

目标值不要一开始定得太漂亮

SLO 目标值最常见的问题，是拍脑袋。一上来写 99.99%，看起来很有追求。但如果系统过去真实可用性只有 99.5%，这个目标只会带来两个结果：第一，永远不达标，团队很快失去感觉；第二，大家开始争论哪些异常不应该算。

SLO 目标值应该结合业务重要性、历史表现和治理能力来定。不是所有对象都必须 99.99%。支付链路可能需要 99.95% 或更高，普通查询接口 99.9% 可能就够，内部管理接口不一定要纳入第一批 SLO，批处理任务则可能更适合按任务成功率或延迟窗口管理。

一个更稳妥的方法是先回看历史：

• 过去 30 天，核心卡片实际飘红多少分钟？
• 这些飘红里，多少是真故障，多少是阈值误判？
• 按 99.9% 计算，月度不可用配额大约是 43.2 分钟。
• 按 99.95% 计算，月度不可用配额大约是 21.6 分钟。
• 按 99.99% 计算，月度不可用配额大约是 4.32 分钟。

看到这些分钟数，团队对目标值会清醒很多。99.99% 不是口号，它意味着一个月只有几分钟可以犯错。如果组织响应、变更控制、自动化回滚、灰度能力、容量治理都还没跟上，目标写得再高也没有意义。SLO 的目标不是让数字好看，而是让团队围绕错误预算做取舍。

理解两个达标率：卡片达标率和完全达标率

Flashcat SLO 报表里有两个容易混淆的指标：卡片达标率和完全达标率。

卡片达标率看的是统计区间内，有多少 SLO 卡片达标。比如报表里有 20 张核心接口卡片，其中 18 张在本月达到了 99.9%，卡片达标率就是 90%。它回答的问题是：有多少对象各自达成了目标？

完全达标率看的是统计区间内，所有卡片同时不飘红的时间占比。也就是说，在某一分钟，只要报表里的任意卡片飘红，这一分钟就不是完全达标。它回答的问题是：整个对象集合有多少时间处于全部健康状态？

这两个指标必须一起看。卡片达标率高，说明大多数对象各自达标；完全达标率低，说明系统整体经常有局部对象在抖动。这类情况很常见：20 张卡片每张都只是偶尔飘红，各自月度都达标，但它们分散在不同时间飘红，完全达标率就会很难看。

它暴露的是另一类稳定性成本：没有大事故，但小抖动很多。这种系统在复盘会上可能显得“本月无重大故障”，但用户体验会被不断的小波动切开。SLO 报表的价值，是把这类隐性成本摆到台面上。

剩余配额比当前值更能推动行动

很多团队看 SLO，只看当前值。当前 99.93%，目标 99.9%，看起来达标。但真正能推动行动的是剩余配额。剩余配额回答的问题是：在当前目标周期内，这个对象还能承受多少不可用时间？

如果一个服务当前值还达标，但剩余配额只剩 3 分钟，它已经处在风险边缘。这时继续做高风险发布，就应该更谨慎。如果一个接口已经用掉了大部分错误预算，团队就应该优先治理它，而不是等它月底正式不达标。

这也是 SLO 和普通可用率报表的区别。普通报表告诉你过去表现怎么样，SLO 报表应该帮助你决定接下来怎么做。比如剩余配额充足，可以按正常节奏发布；剩余配额紧张，暂停非必要变更；某对象连续两周消耗配额，进入专项治理；某团队负责的服务长期低配额，纳入月度稳定性 review。

错误预算不是用来惩罚团队的。它把“稳定性风险”变成一种可以讨论、可以管理的资源。

不可用时间导出适合复盘和月报

SLO 报表支持导出概览数据，也支持导出明细数据。明细数据里可以看到不可用时间段，比如 09:00 到 09:05。这对复盘和月报很有用。很多稳定性讨论最后都会卡在证据上：到底是哪几段时间不可用，每段持续多久，对应哪些卡片，当时卡片为什么飘红，有没有相关告警、日志、Trace、变更事件。

如果这些都靠人工回忆，月报会变成苦活。SLO 报表把不可用时间段导出来以后，团队可以按时间段回到灭火图卡片详情，查看当时的健康状态和下钻证据。

这里有个限制要注意：如果要点击达标率明细趋势图跳转到卡片详情，查看的时刻需要在灭火图时间轴范围内。超出时间轴范围，就无法查看对应时刻详情。所以 SLO 月报不要拖太久，每周或每月及时 review，证据还在，治理动作也更容易落地。

排除时间段要有规则

SLO 报表支持排除时间段。配置后，对应时间段会按可用处理。这个能力很必要，计划维护窗口、演练窗口、客户已确认的停服升级、某些非服务承诺时间段，不一定都应该计入 SLO 消耗。

但排除时间段也最容易被滥用。如果每次不达标都靠排除时间段解决，SLO 就失去治理意义。所以排除规则要提前说清楚：哪些维护可以排除，需要提前多久公告，是否需要业务确认，紧急修复导致的不可用能不能排除，排除记录是否进入月报。

建议把排除时间段当成稳定性治理制度的一部分，而不是事后修报表的工具。Flashcat 里周期时间和固定时间的排除逻辑也不同：周期时间配置后生效，历史数据不会重新计算；固定时间配置后生效，最近 3 个月内的历史数据会重新计算，通常需要等待一段时间。这类规则要让使用者知道，否则很容易误以为报表会立刻变化。

分组统计适合管理链路，不适合乱用

Flashcat SLO 报表既可以把单个卡片作为统计对象，也可以把卡片分组作为统计对象。按分组统计时，一个计算粒度内，分组内任意一张卡片飘红，分组就不达标；全部不飘红，分组才达标。

这很适合强依赖链路。比如支付链路，支付接口、支付服务、订单库、支付通道卡片，只要任意关键对象异常，用户支付体验都可能受影响。这时用分组统计更符合真实服务可用性。

但不要把一个很大的系统分组直接拿来做 SLO。比如“电商系统”下面有几百张卡片，只要任意一个低价值内部接口飘红，整个系统就不达标。这样的报表会很难看，也不一定有治理意义。分组统计应该用于表达强关联对象集合，比如下单链路、支付链路、登录链路、核心数据库集群、核心消息链路。

如果只是为了方便把很多对象圈在一起，不建议用分组 SLO。更好的方式是拆成多个报表：

• 核心用户入口一张
• 核心微服务一张
• 核心组件一张
• 核心链路一张

不同报表回答不同问题。

SLO 指标导出可以接入二次分析

Flashcat SLO 报表可以导出指标。它每 5 分钟计算一次，产生当前值和 5 分钟内不达标分钟数。开启导出报表指标后，这些指标会写入 Flashcat 内置时序数据库。

这适合更深入的稳定性运营。比如把 SLO 当前值放到北极星或大屏，对 SLO 燃烧速度配置告警，把不达标分钟数做团队维度统计，生成稳定性周报或月报，或者让 FlashAI 定时读取 SLO 报表和指标，输出治理建议。

第一版不一定要做。但当团队已经把 SLO 报表跑起来，下一步就应该考虑让 SLO 数据进入稳定性运营流程。不要让 SLO 页面只是偶尔打开看一眼，它应该进入每周巡检、每月 review、发布风险评估和复盘流程。

推荐的落地顺序

如果还没有用 SLO 报表，建议按这个顺序做。

第一，选一个核心系统。不要一开始覆盖所有业务线，先选订单、支付、登录、核心 API 这类业务影响清晰的系统。

第二，确认灭火图卡片已经可信。核心接口、服务、组件卡片要能稳定飘绿，真实异常能飘红，灰色状态有解释。

第三，选第一批 SLO 对象。建议 10 到 30 张卡片，优先选用户关键路径上的接口和服务。

第四，设置目标周期和目标值。第一版用月周期，目标值可以从 99.9% 或 99.95% 开始，不要一上来追求过高。

第五，运行一个完整周期。观察卡片达标率、完全达标率、未达标 TopN、剩余配额和不可用时间段。

第六，做一次 SLO review。不要只看数字，要逐个看未达标对象，确认是真故障、阈值问题、采集问题，还是维护窗口。

第七，补制度。明确排除时间段规则、错误预算消耗规则、月报输出规则、治理项跟踪方式。

第八，再扩大范围。等第一组对象跑顺，再加入更多服务、组件和链路分组。

这个顺序看起来慢，但更容易成功。SLO 报表不是一次性配置，它是稳定性运营机制。

最后，SLO 要服务治理，而不是服务汇报

SLO 报表最容易被做成汇报材料：月底截图，贴到周报或月报里。这当然有价值，但远远不够。真正有用的 SLO 报表，应该推动行动：哪个对象最消耗配额，就优先治理哪个对象；哪个服务剩余配额紧张，就控制它的发布风险；哪个接口经常短抖动，就检查阈值、容量和依赖；哪个分组完全达标率低，就拆开看链路里最脆弱的一环；哪个维护窗口经常被排除，就复盘维护方式是否可以无损化。

SLO 的目标不是证明团队做得好，也不是给事故扣分。它的目标是让稳定性变成一套可持续管理的预算。灭火图让你知道对象是否健康，SLO 报表让你知道这种健康状态在一个周期内是否达到承诺。

如果核心服务已经有灭火图卡片，下一步就应该创建第一张 SLO 报表。先选一组核心接口和服务，设一个月度目标，跑完一个周期，导出不可用时间段，做一次 review。只要这套流程跑起来，稳定性治理就会从“事故后复盘”往前走一步，变成“持续看配额、持续看风险、持续推动改进”。

文章来源:https://www.cnblogs.com/ulricqin/p/20418140
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！