核心要点摘要
- Flashcat SLO 报表把灭火图观测对象健康状态转成周、月、季、年维度的服务可用性管理机制。
- SLO 对象应先从核心接口、核心服务、核心组件和关键链路分组中选择，不应一开始覆盖所有资产。
- SLI 要体现在灭火图观测对象健康条件里，卡片是否飘红会直接影响 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。只要这套流程跑起来，稳定性治理就会从“事故后复盘”往前走一步，变成“持续看配额、持续看风险、持续推动改进”。
FAQ
Q1：Flashcat SLO 报表里的 SLO 对象是什么？ A：SLO 对象是被选入 SLO 报表的灭火图观测对象，可以是接口、服务、组件，也可以是表达关键链路的详情分组。对象选择决定后续达标率、不可用时间和错误预算是否可信。
Q2：为什么创建 SLO 报表前要先校准灭火图观测对象？ A：Flashcat SLO 报表复用卡片健康状态。如果卡片误飘红，SLO 会被误扣；如果阈值过宽，真实不可用不会进入 SLO；如果长期灰色，报表证据也会变弱。
Q3：月度 SLO 为什么适合作为第一版周期？ A：周周期反馈快但容易被短抖动放大，年周期反馈太慢。月度 SLO 更适合把技术指标转成稳定性 review、治理排期和发布风险评估。
Q4：排除时间段应该怎么使用？ A：排除时间段适合计划维护、演练、客户已确认停服升级等事先明确的场景。它应该有规则和记录，不应该作为事后修报表的工具。
