很多故障最早不是从 CPU 高、内存满、Pod 重启开始暴露的，而是从业务结果里暴露的。订单量突然下降，支付成功率开始抖动，登录成功率低于平时水平，在线用户数异常下滑，设备在线率持续降低，证券报单量偏离日内规律。这些信号一出现，业务方和技术方都会紧张，因为它们不是“某个资源有点异常”，而是用户正在受到影响。
但很多团队的监控体系恰好缺少这一层。底层资源指标很多，服务指标很多，日志和 Trace 也不少，大盘铺满了屏幕，告警规则配了几千条。真正事故发生时，大家还是要先问一句：这到底有没有影响业务？
如果这个问题回答不出来，可观测性体系就还没有真正进入业务稳定性阶段。业务故障不是 CPU 高，CPU 高只是可能的技术信号。SRE 需要北极星指标，是因为稳定性治理必须先判断业务是否健康，再沿着系统对象下钻到技术根因，而不是永远从主机告警开始。
技术指标、服务指标、业务指标不是同一层
技术指标回答系统局部状态，比如 CPU、内存、磁盘、网络、连接数、GC、Pod 重启、数据库慢查询、Redis 连接数、Kafka 堆积。这些指标很重要，但它们不直接等于业务影响。同样是 CPU 高，可能只是批处理任务在跑，也可能是流量正常增长，也可能是服务陷入死循环并已经影响用户。
服务指标回答服务质量，比如接口请求量、成功率、错误率、P95/P99 延迟、可用实例数、依赖调用耗时、超时率。这一层比资源指标更接近用户体验，但仍然需要判断业务语义。一个内部管理接口错误率升高，和支付回调接口错误率升高，影响完全不同。
业务指标回答业务结果，比如订单量、支付成功率、登录成功率、在线用户数、GMV、设备在线率、报单成功量、行情延迟。这一层最适合做故障发现入口，因为它直接反映用户关键动作是否成功。业务指标异常，不一定能直接告诉你根因，但它能告诉你这次问题是否值得进入事故响应。
这三层不能互相替代。只有技术指标，团队会被大量底层告警牵着走；只有业务指标，发现异常后不知道往哪里查；只有服务指标，业务方和技术方仍然可能对影响范围理解不同。更合理的路径是：业务指标发现真故障，服务指标缩小业务环节和服务范围，技术指标定位资源、组件和依赖根因。
什么指标适合做北极星
不是所有业务指标都适合做稳定性北极星。留存率、复购率、客单价、广告转化率当然重要，但它们通常受运营、市场、产品策略影响很大，不一定能在分钟级反映技术故障。稳定性场景里的北极星指标，需要满足几个条件。
第一，和核心用户体验直接相关。电商系统的下单量、支付成功率，社交平台的在线用户数，视频业务的首帧加载时长，证券系统的报单量和行情延迟，制造业系统的设备在线率，都能直接反映服务是否可用。第二，可以持续量化。指标可以来自数据库、日志、时序库、埋点或外部 API，但不能停留在“用户感觉变慢”这种描述。第三，足够实时。稳定性监控需要分钟级甚至更短周期，天级报表适合经营分析，不适合故障发现。
第四，能被技术故障影响。如果一个指标主要由市场投放、节假日或促销策略决定，技术系统异常不一定影响它，那它就不适合作为稳定性北极星。第五，有稳定的业务语义。指标口径要能被业务和技术共同理解，比如“支付成功率”到底按支付请求、支付订单还是支付回调计算，失败是否包含用户主动取消，统计窗口是多少。口径不清，告警来了也会先争论数据是否可信。
北极星指标的本质，不是“公司最看重的经营指标”，而是“最能代表业务连续性的实时健康指标”。
从用户关键路径反推指标
设计北极星指标，不应该先问“现在有什么数据”，而应该先问“用户最不能失败的动作是什么”。电商系统里，最不能失败的是浏览、加购、下单、支付；出行业务里，是发单、接单、派单、完单、支付；游戏业务里，是登录、在线、匹配、对局、充值；企业 OA 里，是登录、页面访问、流程发起、审批提交；制造业系统里，是设备在线、数据采集、指令下发、生产任务执行；证券系统里，是行情订阅、报单、成交回报、结算任务。
把关键动作列出来以后，可以按三层设计指标。第一层是少量核心北极星指标，用来回答业务是否整体正常，比如实时下单量、支付成功率、在线用户数、设备在线率、报单成功量。第二层是过程指标，用来回答业务流程卡在哪一步，比如登录成功率、商品详情请求量、库存请求成功率、支付回调成功率、派单量、指令下发成功率。第三层是技术映射指标，用来回答应该下钻到哪些系统对象，比如接口成功率、服务错误率、数据库慢查询、缓存超时、消息堆积、网关 5xx。
这三层的关系要清楚。核心北极星指标负责发现真故障，过程指标负责缩小业务环节，技术映射指标负责连接灭火图、日志、Trace 和事件。只看核心指标，发现异常后还要拆；只看过程指标，指标太多会噪声化；只看技术指标，又容易丢掉业务影响判断。
阈值、同环比和异常检测要按指标类型设计
业务指标比资源指标更难设阈值，因为它们经常有周期性。支付量在白天和凌晨不一样，工作日和周末不一样，大促和平时不一样，证券报单量还会有明显日内曲线。简单写一个固定阈值，很容易误报或漏报。
对边界明确的指标，可以用阈值。比如支付成功率低于 98%、登录成功率低于 99%、设备在线率低于某个水平、行情延迟超过某个值。这类指标适合用绝对边界，因为业务能接受的底线比较清楚。
对有明显周期规律的指标，可以用同环比或智能预测。比如当前订单量和昨天同一时间、上周同一时间相比是否异常；在线用户数是否偏离历史趋势；支付量是否低于预测区间。同环比和预测不是为了显得智能，而是为了尊重业务曲线本身的规律。
对采集链路本身，要做数据中断检测。很多业务指标来自数据库、日志、API 或埋点，一旦采集失败，页面可能只是不更新，但团队实际已经失去故障发现能力。北极星指标不只要监控业务，也要监控自己是否还在可靠上报。
维度设计也要克制。业务线、地区、渠道、客户端、版本、租户、门店、设备类型、支付通道、环境、集群、机房等维度，可以帮助判断影响面。用户 ID、订单号、TraceID、SessionID 这类高基数字段，不适合做北极星常态维度，更适合用于日志检索和下钻。一个实用判断是：这个维度能不能帮助值班人判断影响范围。如果不能，就不要轻易放进北极星。
从业务异常下钻到系统对象
北极星发现异常只是第一步，真正的价值在于下一步能否顺着业务影响下钻到系统对象。比如支付成功率下降，可能是支付接口错误率上升，可能是支付服务依赖的 Redis 异常，可能是数据库连接池打满，可能是第三方支付通道超时，可能是某个机房网络抖动，也可能是刚发布的版本引入了业务校验问题。
如果北极星只告诉你“支付成功率异常”，值班人仍然要靠经验去翻日志、Trace、仪表盘和发布记录。这条路还是慢。更好的方式，是把北极星指标下钻到灭火图。北极星回答业务是否异常，灭火图回答哪些观测对象异常，下钻规则回答沿着什么路径看指标、日志、链路和事件。
在 Flashcat 里，北极星用于管理和监控核心业务指标，可以从时序数据源、日志数据源、数据库表或外部 API 计算指标，并支持智能预测、同环比、阈值、数据中断等检测方式。北极星图表可以关联到对应灭火图节点，业务指标异常时，值班人可以看到相关卡片状态并继续下钻。
灭火图则把接口、微服务、标准组件、基础设施组织成健康对象。支付成功率下降时，相关对象可能包括支付接口、支付服务、订单服务、库存服务、MySQL、Redis、Kafka、第三方支付通道、网关和机房网络链路。如果某些卡片飘红，异常会从底层上浮，值班人可以先看最可疑对象；如果卡片都正常，排查方向可能转向业务规则、运营配置、第三方返回码或数据统计口径。
事件墙补上“刚才变了什么”。从业务异常到灭火图，再到日志、Trace 和事件墙，路径才完整。没有这条路径，北极星只是业务大屏；有了这条路径，北极星才成为故障发现入口。
FlashAI 的位置：压缩证据，不替人下结论
FlashAI 可以进入这条链路，但边界要说清楚。AI 不应该被描述成替代 SRE、一键给出根因的工具。更合理的定位是：在北极星、灭火图、日志、Trace 和事件墙已经组织好上下文的前提下，FlashAI 帮人收集证据、压缩上下文、执行可审计调查步骤，人负责判断、授权和改进承诺。
比如北极星检测到下单成功率下降，灭火图里 order-service、订单库、下单接口几张卡片飘红。FlashAI 可以读取相关卡片状态，下钻到指标、日志、链路和事件墙，整理出错误集中在哪个服务、慢调用集中在哪个阶段、异常前是否有发布或配置变更。但根因是否成立、是否回滚、是否扩容、是否通知业务，仍然需要人确认。
这也是为什么业务指标、灭火图和事件墙的建设比单独采购 AI 能力更重要。上下文质量越高，AI 越能给出有证据的分析；上下文散乱，AI 很容易给出通用建议。
落地时不要一上来追求全量业务指标
业务健康指标建设最怕两个极端。一种是太粗，只放一个总订单量或总在线用户数，发现异常时仍然不知道影响哪个业务环节。另一种是太细，一开始就把所有接口、所有维度、所有业务字段都放进来，最后指标太多、告警太多，团队又回到噪声里。
更现实的做法是分阶段建设。第一步，选一个核心业务线，比如交易、支付、登录、核心生产系统、门店设备、证券报单。第二步，定义 3 到 5 个核心北极星指标，它们必须能代表真故障，并被业务和技术共同认可。第三步，补 5 到 10 个过程指标，围绕用户关键路径补齐关键环节，不为展示堆指标。
第四步，接入数据源并配置异常检测。指标可以来自数据库、日志、时序库或外部 API。规律性指标用智能预测或同环比，边界明确指标用阈值，采集链路做数据中断检测。第五步，配置北极星到灭火图的下钻，每个核心指标都要能关联到对应技术对象。第六步，把真正需要承诺稳定性的接口、服务、组件或系统纳入 SLO，用周期内达标率、未达标时间和剩余配额推动持续治理。
验收标准：能不能先判断业务影响
业务健康指标设计得好不好，不看大屏是否漂亮，也不看指标数量是否足够多。可以用几个问题验收。
第一，业务异常发生时，北极星能不能比用户投诉更早发现。第二，北极星告警出现时，业务方和技术方能不能立刻理解影响范围。第三，下钻到灭火图后，能不能看到相关接口、服务、组件和基础设施对象的健康状态。第四，从异常对象进入日志、Trace 和事件墙时，是否能自动带上业务、服务、接口、环境和时间窗口。第五，故障复盘时，能不能把业务影响、技术对象、事件线索和 SLO 消耗放在一起讨论。第六，新人能不能按平台路径完成一次排障，而不是依赖资深同学口头指路。
如果这些问题答不上来，下一步不是继续增加底层告警，而是先把业务健康指标、灭火图对象和下钻路径设计出来。
总结：先定义真故障，再谈技术根因
SRE 需要北极星指标，不是为了做更好看的业务大屏，而是为了让故障响应从业务影响开始。底层资源指标不能直接代表业务影响，服务指标也需要业务语义解释。真正可用的路径应该是：北极星发现业务异常，过程指标缩小业务环节，灭火图定位系统对象，日志和 Trace 提供证据，事件墙解释变化，SLO 记录周期内稳定性目标。
下一步可以很小：选一个核心业务线，下载业务健康指标设计模板，拿最近三次真实故障反推当时最早异常的业务指标、应关联的灭火图对象、需要下钻的日志和 Trace、应该进入事件墙的变更事件。先把一个业务链路跑通，再扩展到更多系统。
