北极星系统落地步骤
从业务线划定、指标选取、指标池与图表配置，到异常检测与告警策略、大屏；与灭火图分工及常见陷阱说明。
目标：完成核心业务线的北极星指标梳理、入池、可视化与告警闭环，使「真实故障」能被稳定发现，并驱动值班与处理流程。
步骤一：确定北极星业务线（首页卡片）
业务线通常对齐企业内的业务组织或核心系统边界（如电商、视频、出行），并明确业务负责人 / GM 等对口角色。北极星落地建议由稳定性团队牵头，业务方参与指标选取与验收。
实践建议
- 先选一条成熟、流量稳定的核心业务线试点；待流程跑通再复制到其他业务线。
- 不建议用尚不成熟、指标趋势噪声大、难以解释波动的业务线做首批试点，否则智能检测与告警难以发挥价值。
产出：试点业务线范围、对口业务与研发/ SRE 联系人。
步骤二：梳理北极星指标（与灭火图分工）
在「指标池」中沉淀的应是业务或核心功能层面的原子指标，来源可为 MySQL/Oracle、Prometheus、日志分析等已接入数据源。
选取原则（建议每条候选指标自检）
- 业务/产品负责人能否不依赖技术解释读懂含义？
- 指标异常是否直接意味着业务受损或核心功能不可用？
- 指标在合理聚合后是否仍有明确业务含义（而非仅反映某台机器、某个实例的局部状态）？
三项均为「是」，再进入北极星；任一项为「否」，优先考虑灭火图卡片或其它观测视图。
toC / 高流量：优先「量」类——订单、支付、GMV、在线用户、关键页面 PV/UV 等。
toB / 低频系统：在「量」不稳定时，优先核心 API 成功率（去噪后）、关键流程拨测、批处理结果等「是否可用」类指标。
与灭火图的分工
- 主机与容器资源、中间件实例级 QPS/延迟、JVM、泛化错误日志计数等，更适合在灭火图按观测对象组织，用于定位与止损决策辅助。
- 「请求成功率」若作为北极星指标，需区分场景：若业务方仍无法从成功率直接理解业务影响，或成功率噪声大（重试、限流、攻击流量等），则更适合放在灭火图；对 toB 核心功能，经治理的成功率/拨测可作为北极星 SLI。
指标可一次性梳理后集中配置，也可先落地少量最关键指标，再迭代扩展。
产出：业务线级北极星指标清单、数据来源与负责人。
步骤三：配置业务线与指标池
- 新建业务线（首页卡片）：作为图表、告警、大屏的容器；后续多数配置依赖业务线已存在。
- 在指标池中创建北极星指标：从数据源计算或采集生成可复用的时序指标。
- 在业务线下新建图表并绑定指标：选择展示形态（折线、柱状、蜂窝、表格等），从指标池选择一条或多条指标。
业务线中的可用性配额 / SLO 可在初阶先留空，待告警与复盘机制成熟后再启用（见「SLA 管理实践」）。
产出：业务线已创建、指标已入池、核心图表已绑定指标并可稳定出数。
步骤四：开启智能检测与告警策略
北极星告警由异常检测与告警策略串联：检测产出事件，策略决定是否通知、通知谁、等级与时段等。
异常检测
- 智能预测：指标入池后系统会学习趋势（通常需一定时间窗口）；上线初期请重点校验数据正确性与连续性，再依赖预测类异常。
- 同环比：可作为兜底，多数场景可采用平台推荐默认参数。
- 阈值：对 0~100% 等有明确物理边界的指标尤为适用。
- 数据中断：核心指标建议开启，避免「无数据静默」。
检测参数在控制台中调整后可结合预览观察效果，关注连续触发次数、容忍度等，减少漏报与误报。
告警策略
- 多数业务线可先配置一条共享策略，再按图表/指标粒度打开需要告警的检测类型与等级。
- 对告警时段、接收组、等级要求差异大的个别指标，可单独配置策略。
不宜强行告警的情况：指标离散、趋势不稳定、人工难以判断阈值时，宁可仅作观察视图，避免「狼来了」稀释北极星信噪比。
产出：核心业务图表完成检测配置；告警策略与通知规则已关联；值班路径可稳定接收并响应告警。
步骤五（可选）：大屏与运营机制
在指标与告警稳定后，可为业务线启用北极星大屏（气泡图、地图等），用于重保与 NOC 场景；并结合「最佳实践」建立保障群、电话/IM 通知、与发布系统的联动止损等机制。
推荐端到端顺序（小结）
将一条业务线从 0 到 1 拉起时，建议顺序为：指标入池 → 业务线 → 图表并绑定指标 → 异常检测 → 告警策略（含通知规则）→ 大屏与运营。其中检测参数建议在界面中结合曲线反复校验后再放量通知。
若出现「告警未触发、图表无数据、检测过于敏感」等问题，可从告警策略沿链路向上回溯至指标池与数据源，逐项排查配置与数据连续性。
