灭火图真正跑起来以后，最怕的不是卡片少，而是卡片不可维护。
手工建卡片，短期看很快：一个接口一张、一个服务一张、一个实例一张。系统一变，问题就来了：新对象没人补，旧对象没人删，阈值和标签开始漂移，下钻参数也不一致。
灭火图的推荐方式不是手工堆卡片，而是用卡片规则批量生成卡片。卡片规则解决四件事：
- 从数据源自动发现观测对象。
- 统一卡片路径、名称、标签、指标和异常条件。
- 让系统变化后卡片能周期更新。
- 给下钻、告警、SLO 和 FlashAI 留下稳定对象上下文。
一句话：卡片规则不是省时间的小工具，而是灭火图可维护性的基础。
先定义对象，不要先写查询
写规则前，先回答一个问题：这条规则要生成哪一类观测对象？
一条规则最好只服务一类对象，例如接口、微服务、服务实例、MySQL 实例、Redis 实例、Kafka Topic、Kubernetes Node、Kubernetes Pod、网络链路。
不要用一条规则同时生成接口、服务、数据库和主机。对象类型混在一起，后面的路径、名称、标签、指标、异常条件和下钻都会变含糊。
规则的第一原则是：一个对象类型，对应一套发现逻辑、一套路径结构、一套健康指标、一套异常条件。
元信息决定能不能批量生成
卡片规则首先要从数据源筛选对象元信息。很多团队只盯 PromQL 或查询语句，却忽略了标签治理，这是后续维护困难的根因。
不同对象至少要有稳定字段：
- 微服务：
service、cluster、namespace/env、instance/pod。 - MySQL：
cluster、address、role、instance。 - 接口：
http_host、request/route、method、status_code。 - Kubernetes：
cluster、namespace、node/pod/workload。
这些字段不是为了展示好看，而是卡片名称、路径、标签、指标查询和下钻参数的来源。
如果同一个服务在日志里叫 order-service，在 Trace 里叫 order，在 Prometheus 里叫 job=order-v2，规则也许能勉强生成卡片，但下钻一定会痛苦。必要时先用标签增强，把杂乱字段整理成稳定的对象元信息。
路径按排障组织，不按数据源组织
卡片路径应该服务排障，不应该服务工具分类。
不要做成：
Prometheus -> 指标 -> job -> instance
日志分析 -> 网关日志 -> request
Trace -> service -> operation
值班人关心的是系统、层次、对象和影响范围，不关心数据来自哪个工具。更好的路径是：
功能接口 -> 电商系统 -> $http_host -> $request
微服务 -> 订单服务 -> $cluster -> $service:$instance
标准组件 -> MySQL -> $cluster -> $role:$address
基础设施 -> Kubernetes -> $cluster -> $node
路径设计好了，新实例会自动进入正确分组，下线对象可以被清理，新集群接入后首页结构仍然一致。
名称给人看，标签给系统用
卡片名称要让人一眼知道对象是谁，但不要把所有标签塞进去。
不推荐：
prod-hz-cluster-a-namespace-order-service-pod-order-api-7d8f9c4-10.1.2.3
更推荐：
order-api / 10.1.2.3
POST /api/order/submit
order-mysql primary 10.2.1.5:3306
环境、集群、命名空间、Pod、owner、业务线等信息放到标签里，用于筛选、下钻、告警和 AI 分析。名称负责识别对象，标签负责系统联动。
指标要少，但必须能判断健康
灭火图卡片的第一职责是判断对象是否健康，不是展示所有数据。
第一版每类对象先放 3 到 5 个核心指标：
- 接口：流量、成功率、响应时间。
- 服务：请求量、错误率、延迟、实例存活、资源饱和度。
- 数据库：连接数、慢查询、QPS、延迟、主从状态。
- 缓存：连接数、命中率、延迟、内存使用率。
- 基础设施：可用性、资源水位、网络质量、关键组件状态。
判断标准很简单：这个指标能不能回答“是否影响业务”和“下一步往哪里查”。不能，就放到下钻仪表盘，不要放到卡片上。
异常条件要表达故障，不要表达波动
卡片飘红依赖异常条件。条件配得好，灭火图是故障入口；条件配得差，灭火图是噪音入口。
不要把所有指标波动都定义成异常。接口流量下降可能只是夜间低峰、活动结束或灰度调整；支付成功率下降、错误率持续升高、P99 明显升高，才更接近用户感知。
常见异常条件可以这样起步：
- 接口：成功率低于阈值，或 P99 超过阈值。
- 服务：错误率升高，或实例存活数低于期望。
- MySQL：连接数接近上限、慢查询激增、主从延迟过高。
- Kubernetes Node：节点不可用、资源持续高水位、磁盘压力异常。
不同对象不要强行套同一阈值。核心接口、普通接口、低频接口的容忍度不同，可以用 tier=core、tier=normal 等标签做差异化条件。
更新策略决定能不能长期维护
卡片规则不是执行一次就结束。它应该周期执行，持续发现新对象，并清理不再存在的对象。
重点看三个设置：
- 执行周期：Pod、服务实例、接口维度可以更频繁；数据库、网络链路、核心组件可以更稳定。
- 最大数量：这是规则边界保护。如果本来只想生成 50 个接口，突然生成 5000 个，说明筛选条件失控。
- 过期规则：临时 Pod 可以不匹配即删除；低频但重要的接口，不要因为短期无数据就误删。
目标不是“更新越快越好”，而是系统变化时灭火图能跟上，同时避免短暂数据缺失导致重要对象消失。
模板是起点，不是终点
标准对象优先用模板，例如 Kubernetes、MySQL、Redis。数据规范程度高的场景，可以用一键配置。非标准业务对象，例如核心接口、第三方依赖、专有中间件，再从零创建规则。
但模板不能替你理解业务。用模板创建后，至少检查：
- 卡片是否落在正确分层。
- 名称是否能被值班人理解。
- 标签是否足够支撑下钻。
- 指标是否能判断健康。
- 异常条件是否符合业务影响。
- 生成数量是否符合预期。
模板帮你快速开始，调优才让它真正可用。
卡片规则要和下钻一起设计
卡片规则生成对象，下钻规则把对象连接到指标、日志、Trace、仪表盘、工作流和其他卡片。这两件事不能分开设计。
创建规则时同时问四个问题：
- 这张卡片未来要下钻到哪里？
- 下钻目标需要哪些参数？
- 这些参数是否已经作为卡片标签存在？
- 目标数据源里是否有相同或可映射字段？
如果服务卡片要下钻日志，最好有 service、namespace、cluster、env。如果接口卡片要下钻 Trace，最好有 http_host、request/route、method。如果 MySQL 卡片要下钻仪表盘，最好有 address、cluster、role。
没有稳定标签，卡片只能飘红，却很难指导下一步排障。
能改规则，就不要改单卡
规则生成的卡片，后续调整优先回到规则上做。
直接改大量单卡会带来三个问题：
- 规则再次执行后，手工改动可能被覆盖。
- 同类对象开始配置漂移，有的阈值改了，有的没改。
- 无法沉淀成可导出、可复用的规则模板。
单卡配置只适合少量特殊对象，例如核心接口特殊阈值、外部依赖特殊下钻、特殊数据库实例说明。批量对象要回到规则里治理。
十个问题验收一条规则
不要只看“是否生成了卡片”。一条卡片规则至少回答这十个问题：
- 对象类型是否单一？
- 筛选条件是否准确？
- 生成数量是否符合预期？
- 卡片路径是否符合排障层次？
- 卡片名称是否能识别对象？
- 卡片标签是否完整？
- 指标是否能判断健康？
- 异常条件是否代表真实故障？
- 更新和过期策略是否合理？
- 下钻路径是否能用标签自动注入？
这十个问题回答不上来，说明只是生成了一批页面元素，还没有形成可维护的灭火图对象。
一套更短的建设顺序
如果要建设第一批卡片规则，按这个顺序来：
- 选一个核心系统，不要一开始覆盖全公司。
- 规划空间、分层和观测对象。
- 为每类对象定义必需元信息。
- 标准对象先用模板或一键配置。
- 业务对象再从零创建规则。
- 检查路径、名称、标签、数量和灰卡。
- 调优指标和异常条件。
- 基于卡片标签配置下钻。
- 配置告警和截图推送。
- 导出规则，沉淀成可复用模板。
第一批不要追求大而全。建议选接口、服务、组件、基础设施各 1 到 2 条规则，控制在 20 到 50 张详情卡片内，先跑通自动生成、健康判断、下钻和告警闭环。
最后
灭火图不是靠手工堆卡片成功的。
它靠对象建模成功，也靠规则化维护成功。
卡片规则决定了对象怎么发现、卡片落在哪里、叫什么、带哪些标签、用哪些指标判断健康、系统变化后怎么更新，也决定下钻、告警、SLO 和 FlashAI 能不能顺利工作。
所以不要把卡片规则当成一次性配置。
数据源变了，调规则。对象模型变了，调规则。阈值不准，调规则。路径不合理，调规则。下钻缺标签，还是调规则。
只有这样，灭火图才能从试点页面变成长期可信的故障定位入口。
