很多故障，最早不是从 CPU 高、内存满、Pod 重启开始暴露的。
它们最早暴露在业务结果里：订单量突然下降，支付成功率开始抖动，在线用户数异常下滑，登录成功率低于平时水平，设备在线率持续降低，交易报单量不符合日内规律。
这些信号一旦出现，业务方和技术方都会紧张。原因很简单：它们不只是“系统有点异常”，而是“用户正在受到影响”。
但很多团队的监控体系，恰恰缺少这一层。底层资源监控很多，服务指标很多，日志和 Trace 也不少，大盘铺满了屏幕，告警规则配了几千条。事故发生时，大家仍然要先问一句：这到底有没有影响业务？
如果这个问题回答不出来，监控体系就还没有真正进入业务稳定性阶段。
业务健康指标的价值，是把“技术异常”与“真实业务影响”连接起来。Flashcat 里的北极星、灭火图和 SLO，正好对应这条链路的三个环节：北极星负责发现真故障，灭火图负责定位技术原因，SLO 负责衡量稳定性目标是否达成。
业务故障不是 CPU 高
CPU 高当然可能是故障信号，但它不是业务故障本身。
同样是 CPU 高，有些场景只是批处理任务在跑，有些是流量正常增长，有些是某个服务陷入死循环，还有些已经导致用户无法下单。
技术指标告诉你系统局部发生了什么。业务指标告诉你用户和业务是否真的受到影响。两个视角都重要，但顺序不能反。
如果团队只从底层技术指标出发，就容易遇到四个问题：
告警太多，但不知道哪个最影响业务。
技术指标正常，不代表业务正常。
业务方和技术方没有共同语言。
复盘很难关联业务不可用时长、核心指标损失和 SLO 配额消耗。
所以，业务健康指标不是替代技术监控，而是故障发现的上层入口。先判断业务是否异常，再沿着系统对象向下定位原因。
什么样的指标适合做北极星指标
不是所有业务指标都适合放进稳定性监控。留存率、复购率、客单价、广告转化率当然重要，但它们通常受运营、市场、产品策略影响很大，不一定能在分钟级反映技术故障。
稳定性场景里的北极星指标，需要满足五个条件：
和核心用户体验直接相关。
可以被持续量化。
足够实时，最好分钟级或更短。
具备前瞻性，能在故障扩大前暴露风险。
能被技术故障影响。
电商系统的实时下单量、支付成功率，社交平台的在线用户数，视频业务的首帧加载时长，证券系统的报单量和行情延迟，制造业系统的设备在线率，都能直接反映服务是否可用。
北极星指标的本质不是“公司最看重的经营指标”，而是“最能代表业务连续性的实时健康指标”。
从用户关键路径反推指标
设计业务健康指标，不应该先问“我们现在有什么数据”，而应该先问“用户最不能失败的动作是什么”。
电商系统里，最不能失败的是浏览、加购、下单、支付。出行业务里，是发单、接单、派单、完单、支付。游戏业务里，是登录、在线、匹配、对局、充值。制造业系统里，是设备在线、数据采集、指令下发、生产任务执行。证券系统里，是行情订阅、报单、成交回报、结算任务。
把这些动作列出来以后，再设计两类指标。
第一类是结果指标。它回答“业务结果是否正常”，比如实时订单量、支付成功量、在线用户数、设备在线率、报单成功量。结果指标适合作为核心北极星指标。
第二类是过程指标。它回答“业务流程卡在哪一步”，比如登录成功率、商品详情请求量、库存请求成功率、支付回调成功率、派单量、指令下发成功率。过程指标适合作为辅助指标。
一套好的业务健康指标，通常是“少量核心北极星指标 + 一组关键过程指标”。核心指标用于发现真故障，过程指标用于缩小业务环节，技术指标用于定位系统根因。
维度不要太少，也不要失控
业务健康指标不能只有一个总数。总订单量下降很重要，但事故现场更需要知道影响范围：是全站都下降，还是某个地区下降？是所有客户端都下降，还是只有 App 新版本下降？是所有支付方式失败，还是只有某个三方通道失败？是全部用户受影响，还是某个租户、渠道、灰度环境受影响？
所以，指标设计要带上关键维度。常见维度包括业务线、地区、渠道、客户端、版本、租户、门店、设备类型、支付通道、环境、集群、机房等。
但维度不能无限加。用户 ID、订单号、TraceID、SessionID 这类高基数字段，不适合做北极星常态维度。它们更适合用于日志检索或下钻，而不是生成大量业务健康曲线。
一个实用判断是：这个维度能不能帮助值班人判断影响面？如果能，就值得进入业务健康指标。如果只是为了“以后可能用到”，就先不要放进北极星。
北极星是故障发现入口，不只是业务大屏
很多团队会把业务指标做成大屏。这很好，但还不够。大屏主要解决展示问题，北极星要解决的是故障发现和响应入口问题。
在 Flashcat 里，北极星用于管理业务或系统的核心指标。一个首页卡片通常对应一个业务线或 IT 系统；业务线下面有图表；图表里关联一个或多个指标。
指标可以来自 MySQL 订单表、网关日志、时序库、JSON API 或已有监控系统。进入北极星指标池以后，指标可以被不同图表复用，也可以按业务线组织。
更重要的是，北极星支持异常检测和告警：
有明显周期规律的 ToC 业务，用智能预测判断偏离。
日常规律稳定的指标，用同环比检测发现异常。
绝对边界明确的指标，用阈值检测。
采集链路本身，用数据中断检测。
普通大屏让你看见指标。北极星要让指标变成故障入口。
北极星发现异常后，必须能下钻到灭火图
发现业务异常只是第一步。真正的问题是下一步看哪里。
比如支付成功率下降，可能是支付接口错误率上升，可能是支付服务依赖的 Redis 异常，可能是数据库连接池打满，可能是第三方支付通道超时，也可能是刚发布的版本引入了业务校验问题。
如果北极星只告诉你“支付成功率异常”，值班人仍然要靠经验去翻日志、Trace、仪表盘和发布记录。这条路还是慢。
更好的方式，是把北极星指标下钻到灭火图。在 Flashcat 里，北极星图表可以配置下钻到对应的灭火图节点。配置后，图表右上角会展示下钻标识；相关灭火图卡片正常时是绿色，异常时会变红。用户可以从北极星直接看到关联卡片状态，并跳到灭火图继续分析。
北极星回答“业务是否异常”。灭火图回答“哪些观测对象异常”。下钻规则回答“沿着什么路径看指标、日志、链路和事件”。
以电商支付成功率下降为例，北极星可以下钻到支付接口、支付服务、订单服务、库存服务、MySQL、Redis、Kafka、第三方支付通道、相关机房和网关卡片。如果这些卡片里有对象飘红，值班人就能先看最可疑对象。如果卡片都正常，排查可以转向业务规则、运营配置、第三方返回码或数据统计口径。
业务指标和技术对象之间必须有这条桥。否则北极星只是看板，灭火图只是技术图，两者没有形成故障闭环。
SLO 把一次次异常变成稳定性管理
北极星适合发现故障，SLO 适合管理目标。北极星关心“现在有没有异常”，SLO 关心“一个周期内服务质量是否达标”。
比如支付系统可以设定月度可用性目标 99.95%。这个目标不是一句口号，它应该落到可计算对象上。
在 Flashcat 里，SLO 报表可以基于灭火图卡片的健康状态计算。灭火图卡片每分钟都会计算健康度，飘红代表该分钟不达标，飘绿代表该分钟达标。SLO 报表把这些分钟级状态汇总起来，计算目标周期内的达标情况、未达标时间和剩余配额。
这比事后手工统计事故更可靠。一个核心接口、一项微服务、一个 DB 集群、一个业务系统，都可以对应灭火图卡片或卡片组。当这些对象在周期内频繁飘红，SLO 报表就能反映真实稳定性水平，并导出不可用时间段，用于复盘、月报和治理。
持续治理链路应该是：北极星发现真故障，灭火图记录对象健康状态，SLO 统计周期内质量目标，复盘再反过来调整指标、阈值、卡片规则和下钻路径。
一个电商系统的指标设计示例
假设要为一个电商系统设计业务健康指标，可以按四层拆。
第一层，核心北极星指标：实时下单量、实时支付量、支付成功率、核心接口成功率、核心接口 P99、GMV 或支付金额分钟级趋势。这些指标回答业务是否整体正常。
第二层，过程辅助指标：登录成功数和成功率、商品详情请求量和成功率、加购请求量、库存查询成功率、优惠券核销成功率、订单创建成功率、支付回调成功率、退款申请成功率。这些指标帮助判断异常卡在哪个业务环节。
第三层，影响面维度：客户端类型、App 版本、城市或地区、渠道、支付通道、租户或业务线、机房、环境、集群。这些维度帮助判断事故范围。
第四层，技术对象映射：下单接口映射到接口层灭火图卡片；订单服务、支付服务、库存服务映射到微服务层卡片；MySQL、Redis、Kafka、Elasticsearch 映射到组件层卡片；网关、DNS、CDN、机房网络映射到基础设施层卡片；发布、配置变更、K8s 事件映射到事件墙。
这样设计以后，事故现场路径会变得清楚：北极星发现支付成功率偏离预测区间，图表下钻标识变红，值班人进入灭火图，看到支付接口和第三方通道卡片飘红，再从支付接口卡片下钻到日志和 Trace，结合事件墙发现 10 分钟前该通道配置发生变更。处理完成后，SLO 报表记录不可用时段和配额消耗。
这不是多看一个大屏，而是把故障发现、影响判断、技术定位和稳定性管理串起来。
落地时不要一上来追求全量
业务健康指标建设最怕两种极端。一种是太粗，只放一个总订单量或总在线用户数，发现异常时仍然不知道影响哪个业务环节。另一种是太细，一开始就把所有接口、所有维度、所有业务字段都放进来，最后指标太多、告警太多，团队又回到噪音里。
更现实的做法是分阶段建设：
第 1 步：选一个核心业务线，比如交易、支付、登录、核心生产系统。
第 2 步：定义 3 到 5 个核心北极星指标。
第 3 步：补 5 到 10 个过程指标。
第 4 步：接入数据源并配置异常检测。
第 5 步：配置北极星到灭火图的下钻。
第 6 步：把关键对象纳入 SLO。
这一套跑通以后，再扩展到更多业务线。
什么时候说明设计有效
可以用几个问题来检验业务健康指标是否有效。
第一，业务异常发生时，北极星能不能比用户投诉更早发现？如果不能，说明指标实时性、检测方式或数据来源有问题。
第二，北极星告警出现时，业务方和技术方能不能立刻理解影响？如果告警只写“某指标异常”，但没人知道它意味着什么，就说明指标命名、业务语义和分组还不够清楚。
第三，下钻到灭火图后，能不能看到相关技术对象的健康状态？如果还要靠人手工猜服务名、查日志、问负责人，就说明北极星和灭火图没有真正连起来。
第四，故障复盘时，能不能导出不可用时间和 SLO 消耗？如果每次仍然靠人工估算影响时长，稳定性治理就很难量化。
第五，新人能不能按平台路径完成一次排障？如果只有资深同学知道该看哪些指标和系统，说明排障知识还在人的脑子里，没有沉淀到北极星、灭火图和下钻规则中。
这些问题比“接入了多少指标”更重要。业务健康指标建设的目标，不是让大屏更漂亮，而是让故障响应更快、更准、更可复盘。
结语：先定义真故障，再谈可观测性平台
可观测性平台的价值，不是接入更多数据源。数据源只是基础。真正重要的是：团队能不能用这些数据判断业务是否健康，定位技术对象是否异常，并持续衡量稳定性目标。
业务健康指标就是这件事的起点。北极星把订单量、支付成功率、在线用户数、设备在线率、报单量这类核心指标变成故障发现入口。灭火图把接口、服务、组件、基础设施组织成健康对象，并承接北极星下钻。SLO 把卡片健康状态转化为周期内的可用性目标和配额管理。
三者合在一起，Flashcat 才不只是一个监控平台，而是一套面向业务稳定性的可观测体系。
如果你正在设计业务健康指标，建议先选一个最核心的业务线，拿出最近三次真实故障复盘，逐个回答：
当时哪个业务指标最先异常？
这个指标现在有没有被分钟级监控？
它有没有异常检测和告警？
它能不能下钻到对应灭火图对象？
这些对象有没有进入 SLO 报表？
如果这些问题答不上来，下一步就不是继续堆大盘，而是先把北极星指标、灭火图下钻和 SLO 对象设计出来。
可以从一张业务健康指标模板开始，也可以预约一次业务稳定性方案评估，带上核心业务流程、现有指标列表和最近几次故障案例，一起梳理哪些指标适合进入北极星，哪些对象应该进入灭火图，哪些服务需要纳入 SLO。
