灭火图系统落地步骤
从空间与分层划定、核心观测对象梳理，到卡片规则（模板优先）、下钻与告警、飘红治理与智能化巡检。
目标：选定试点空间与系统边界，完成灭火图 卡片规则 为主线的建设，使首页能反映全局健康态，并具备下钻、告警与后续 AI 诊断 所需的数据基础。
灭火图与北极星常见为 一对多：一条北极星业务线往往对应多个灭火图「系统」（如交易、中台、订单引擎等），需在组织上明确稳定性负责人与研发 / SRE 参与。
步骤一：确定展示范围与首页结构
- 按技术团队或系统边界划分灭火图首页上的 系统 / 首页卡片（如 B2C 交易系统、公共中台、地图服务等）。
- 设计 分层 顺序，使排障习惯与分层一致：常见自上而下为 接口 → 服务/容器 → 中间件 → 基础设施（底层故障往往向上传导，分层有助于快速判断影响面）。
- 明确与 北极星业务线 的关联（系统级或更细粒度关联），便于报警后在业务视图与技术视图之间切换。
产出：试点空间、分层与首页卡片清单、对口角色。
步骤二：梳理观测对象与数据来源
- 观测对象：核心 功能（接口） 与 模块（服务实例集合），按需扩展到中间件、基础设施等；建议先「少而精」，避免全量录入导致噪声。
- 数据来源：Prometheus 类、日志分析（如网关/报表）、Kubernetes、APM、Zabbix 等已接入数据源；可通过 API 与既有 CMDB / 资产系统联动，保持卡片与线上一致。
智能化前置：若计划使用 模板中心一键建卡，需保证数据源侧标签、命名与模板说明一致（模板 note 中常含标签语义、采集前置条件等重要提示，用模板前务必阅读）。
产出：核心功能/模块/组件清单、数据源与关键标签约定。
步骤三：配置卡片规则（推荐模板优先）
- 优先使用模板中心：按组件类型（如 MySQL、Redis、Kubernetes、Flashcat 微服务等）选择 匹配度 较高的模板，一键或半自动 upsert 为卡片规则，减少手写查询与标签筛选错误。
- 手写/调优规则：补充模板未覆盖的对象；在规则中配置分层名、首页卡片、分组、详情卡片命名及 健康指标、多阈值/异常条件、执行周期等。
- 日志类建卡：基于多维日志/网关报表等数据源时，走平台提供的 dimensions 类建卡流程，与纯 Prometheus 规则区分对待。
规则运行后会周期性生成 / 更新 详情卡片，形成可飘红的最小单元。
产出：卡片规则覆盖核心路径；首页与详情页出现预期卡片。
步骤四：配置下钻规则与告警规则
- 下钻规则：为关键详情卡片配置跳转到 大盘、日志、Trace、事件墙 等；模板生成的微服务 / K8s 类卡片常已带 预置下钻，可按实际再增补。
- 告警规则：对需要推送的关键卡片配置灭火图 告警规则 与通知策略，使「飘红」与 可行动通知 衔接（通知渠道依赖全局告警与媒介配置）。
产出：从卡片可一键进入常用分析视图；重要异常可触达值班。
步骤五：飘红阈值治理与常态化运维
- 上线后结合真实流量与故障案例 微调异常条件，避免过严导致满屏红、过松导致迟报。
- 理想经验：北极星已报业务异常时，相关灭火图路径上应能 看到相应飘红；北极星正常时，灭火图不应长期虚假飘红（需区分「真实异常」与「阈值不合理」）。
产出：阈值与业务/容错匹配，灭火图可作为可信的全局健康视图。
步骤六：启用智能化能力（建议卡片与数据稳定后）
在详情卡片与指标数据稳定后，可体系化使用：
- 异常卡片 AI 分析：在异常时刻对详情卡片触发 智能诊断，获取平台生成的根因结论，并与指标、日志交叉验证。
- 时间轴回溯：对故障时段做分钟级 历史状态 对齐，结合变更、发布记录（如事件墙）缩短 MTTR。
- 巡检报告（进阶）：按时间轴抽取异常时段与严重卡片，必要时叠加 AI 结论，汇总为周期性治理建议（报告形态与发送方式以当前产品能力与组织规范为准）。
端到端顺序小结
卡片规则（ template 优先）→ 下钻规则 → 告警规则 → 阈值治理 → AI /时间轴/巡检。
若出现「首页不红但业务已受损」，多为对象未纳入卡片或阈值过松；若「常红无事故」，优先审视异常条件与数据采集连续性。
