很多团队第一次建设灭火图，最容易从配置开始。
Prometheus 数据源怎么选？卡片规则怎么写？日志字段怎么映射？Trace 下钻怎么配？告警阈值设多少？模板能不能一键生成？
这些问题都重要，但它们不是第一步。
灭火图建设的第一步，应该是规划：这张图服务哪个系统？首页分几层？每层放什么对象？哪些对象应该变成详情卡片？哪些只适合做分组？卡片名称和标签怎么统一？异常发生时，值班人应该从哪里进入排查？
如果这些问题没有先回答，后面的规则配置很容易变成另一种监控堆叠：卡片很多，但层次混乱；指标很多，但不知道哪个对象异常；首页很满，但看不出影响范围；下钻很多，但参数对不上；告警很多，但不知道该谁处理。
灭火图的价值不是“把监控对象画出来”，而是把系统拆成可理解、可负责、可下钻、可告警、可回溯的观测对象。
所以，建设灭火图之前，先别急着写规则。先把空间、分层和观测对象设计好。
空间不是文件夹，而是稳定性责任边界
灭火图空间不能随便建。很多团队会按部门、项目、环境、团队或数据源建空间，这些方式有时能用，但不一定适合故障响应。
空间更应该代表一个稳定性责任边界。一张灭火图空间里的对象，最好满足几个条件：
事故发生时通常由同一组人协同处理。
接口、服务、组件、基础设施之间有明确排障路径。
能形成从业务入口到技术依赖的完整健康视图。
权限、规则维护、下钻维护、告警处理边界清晰。
所以，第一张灭火图不要一上来做“全公司可观测全景图”。更好的方式是选一个核心系统做试点，比如交易系统、支付系统、登录系统、核心生产系统、门店设备系统、证券报单系统。
这个系统要足够重要，值得投入建设；也要边界清晰，可以在两到三周内把主要对象和排障路径跑通。
灭火图通常不是从“大而全”开始成功的，而是从一个关键系统、一次真实故障路径、一个明确责任边界开始成功的。
分层决定首页能不能回答“哪里异常”
空间确定以后，下一步是分层。
分层是灭火图首页最重要的组织方式。它不是装饰性的分隔区，而是决定值班人打开首页时，能不能立刻理解系统健康结构。
常见的第一版分层，可以从四层开始：
功能接口层：用户入口是否正常。
微服务层：承载业务逻辑的服务是否正常。
标准组件层：核心依赖是否正常。
基础设施层：系统底座是否正常。
这个分层符合多数线上系统的排障习惯：先看业务入口有没有问题，再看哪个服务承载了问题，再看依赖组件是否异常，最后看底层基础设施是否波动。
四层不是唯一答案。有些系统可以增加业务指标层，把订单量、支付成功率、在线用户数放到更上层；有些系统可以增加外部依赖层，比如支付、物流、短信、地图、云 API；数据平台可以增加数据链路层，把任务、Topic、作业、数据表作为关键对象。
分层没有标准答案，但有一个判断标准：每一层都必须帮助值班人判断影响范围和下一步方向。如果某一层只是因为“看起来整齐”才存在，它大概率不该放在首页。
首页卡片应该代表对象集合，不是单个指标
分层下面是首页卡片。首页卡片经常被误用。
有些团队把每个接口、每个实例、每个 Pod 都放到首页，结果首页很快变成资源清单。灭火图首页应该给人全局判断，不应该把所有细节铺出来。
首页卡片更适合代表一组观测对象：
功能接口层：业务系统、入口域名、业务模块，如电商系统、支付系统、开放 API。
微服务层：服务组、业务域、核心服务，如订单服务、支付服务、库存服务。
标准组件层：组件类型或组件集群，如 MySQL、Redis、Kafka、订单 MySQL。
基础设施层：基础设施区域或能力，如生产 K8s 集群、DNS、CDN、网关。
首页卡片的粒度要控制。太粗，飘红后仍然不知道哪里有问题；太细，首页会失去总览能力。
比较好的首页卡片满足三个条件：业务或技术含义清楚，下层对象数量可控，责任边界明确。看到“支付服务”“订单 MySQL”“生产 K8s 集群”，值班人应该能大致判断它是什么、下钻到哪里、由谁处理。
首页卡片不是为了展示所有对象，而是为了让异常能层层上浮，让值班人从全局进入局部。
详情卡片才是真正的观测对象
灭火图里最关键的是详情卡片。详情卡片是最底层的观测对象。
一张详情卡片应该对应一个具体实体：一个 API 接口，一个微服务 deployment，一个 MySQL 实例，一个 Redis 集群，一个 Kafka Topic，一个外部支付通道，一个 Kubernetes 节点池，一条网络链路，一个设备分组。
详情卡片上有健康指标、异常条件、标签、负责人和下钻路径。所以详情卡片的粒度非常关键。
粒度太粗，排障会停在半路。比如一张详情卡片叫“数据库”，里面混了 MySQL、Redis、Kafka，它飘红时值班人仍然不知道哪个组件异常。
粒度太细，排障会被噪音淹没。比如每个容器实例都建一张核心业务告警卡片，一个服务滚动发布就可能产生大量状态变化。
一个实用判断是：这个对象飘红后，是否可以直接进入排查和处理？这个对象是否有稳定负责人？如果答案是肯定的，它适合做详情卡片。否则，它可能只是标签、分组或下钻维度。
详情卡片不是技术粒度越细越好。它要落在“可观测、可负责、可处理”的粒度上。
分组卡片用于收敛，不要滥用
分组卡片是首页卡片和详情卡片之间的组织层。它可以嵌套多层，但不建议一开始设计得太复杂。
分组卡片适合收敛大量同类对象：接口按业务模块分组，服务按 namespace 分组，MySQL 按集群分组，Redis 按业务用途分组，Kafka 按 Topic 类型分组，Kubernetes 工作负载按 namespace 或应用分组，设备按区域、门店、产线分组。
分组的目的不是让结构更复杂，而是让值班人能从异常范围逐步缩小到异常对象。
比如首页看到“MySQL”飘红，进入后先看到“订单库集群”“支付库集群”“商品库集群”；支付库集群飘红，再进入具体实例或节点；最后下钻到慢查询、连接数、复制延迟和日志。
分组卡片有一个简单原则：如果这一层能帮助判断影响范围，就保留；如果只是为了和组织架构或资源命名对齐，却不能帮助排障，就先不要加。
第一版灭火图，宁愿层级少一点，也不要让路径过深。
第一版不要追求覆盖所有对象
很多灭火图建设项目失败，不是因为产品能力不够，而是第一版范围太大。
团队一开始就想把所有系统、所有服务、所有组件、所有主机、所有接口都放进来，结果很快卡住：数据源不统一，标签不规范，接口命名不一致，阈值没人确认，负责人不清楚，下钻字段对不上，告警群不知道怎么配。
第一版灭火图应该收敛。建议选择一个核心业务链路，比如电商下单支付链路。
第一版可以只覆盖下单接口、支付接口、订单服务、支付服务、库存服务、订单 MySQL、支付 Redis、订单 Kafka Topic、生产 K8s 集群、网关和 DNS、第三方支付通道。这些对象足够构成一条完整排障路径，不需要把所有低频接口、后台任务和边缘组件都纳入第一版。
第一版的目标不是完整，而是跑通闭环：
从北极星或告警发现异常。
进入灭火图看到异常对象。
从对象下钻到指标、日志、Trace 和事件。
能通知正确负责人。
能在复盘时回看时间轴和 SLO。
这个闭环跑通以后，再扩展对象范围。
规划对象时要同步规划标签
灭火图建设里，标签比很多人想象得更重要。卡片标签是下钻规则的基础。
下钻规则通过标签匹配目标卡片，再把标签值注入日志查询、Trace 查询、仪表盘变量或外部 URL。如果标签一开始没设计好，后面下钻会非常痛苦。
比如服务卡片只有名称，没有 service_name、namespace、cluster。下钻到日志时，日志字段叫 app；下钻到 Trace 时，字段叫 service.name；下钻到仪表盘时，变量叫 service；Kubernetes 里 deployment 又叫另一个名字。字段不能映射，用户就会从卡片跳到一个空白查询页面。这不叫下钻，只是跳转。
规划对象时要同步规划标签。常见标签至少包括业务线、系统名、服务名、环境、集群、namespace、deployment、实例地址、组件类型、组件集群、接口域名、接口路径、负责人或团队。
不同对象类型需要不同标签：
接口卡片：域名、路径、方法、业务动作。
服务卡片：service、namespace、cluster、env。
MySQL 卡片：address、cluster、role、db_name。
Redis 卡片：cluster、instance、role。
Kafka 卡片：cluster、topic、consumer_group。
网络卡片：region、az、source、target、carrier。
标签不是为了好看。它们决定后续能不能批量生成卡片、批量配置下钻、批量配置告警和做 AI 分析。
卡片名称给人看，标签给系统用
卡片名称和标签不要混为一谈。
卡片名称是给人看的，应该清楚、稳定、有业务含义。“提交订单”比 /api/v1/order/create 更容易理解，“支付提交”比 /pay/submit 更适合值班群，“订单服务”比 order-svc-prod-a 更清楚。
但系统查询不能只依赖中文名称，所以标签要保留机器可用的原始字段：
path=/api/v1/order/create
service_name=order-service
address=10.0.1.5:3306
cluster=order-db-prod
namespace=prod-order
一个常见做法是：卡片名称使用业务可读名称，卡片标签保留技术字段，卡片别名用于把规则生成的原始名称改成更清楚的展示名。
不要为了让首页好看，把技术字段全部改掉；也不要为了保持技术原样，让值班人面对一堆没人能立刻理解的路径和实例名。
灭火图是给人排障用的，但它必须有机器可用的结构化信息。
健康指标要少而准
规划观测对象时，还要同步规划健康指标。很多团队会把能查到的指标都放进卡片，让卡片变成小型仪表盘。
灭火图详情卡片不是 Dashboard。卡片指标的职责是判断对象是否健康，并给出最小必要解释。更完整的指标细节，应该通过下钻进入仪表盘。
每类对象建议先选 3 到 5 个核心健康指标：
接口：请求量、成功率、错误率、响应时间。
服务：请求量、错误率、响应时间、实例可用数、重启或异常退出。
MySQL：可用性、连接数、慢查询、复制延迟、磁盘空间。
Redis：可用性、内存使用率、命中率、延迟、连接数。
Kafka：Broker 状态、生产速率、消费速率、消费堆积、ISR 状态。
Kubernetes 工作负载：Ready 副本数、重启次数、CPU / 内存、Pod 状态、探针失败。
健康指标要能解释“为什么这张卡片飘红”。如果一个指标不能影响排障判断，就不要放在卡片上。先把关键指标放准，再通过下钻补全细节。
异常条件要表达真实不健康
健康指标确定以后，要设计异常条件。异常条件决定详情卡片是否飘红，这一步不能随便套模板。
同样是成功率，小流量接口和高流量接口不一样；同样是 P99，登录接口和离线查询接口不一样；同样是流量下降，夜间低峰和白天高峰不一样；同样是 Pod 重启，单实例服务和多副本服务不一样。
异常条件的目标不是让卡片永远绿色，也不是让所有轻微波动都飘红。它要表达真实需要关注的不健康状态。
设计异常条件时，可以从几个问题开始：
这个对象最怕什么故障？
这个故障多久才值得触发？
这个对象有没有周期规律？
无数据是否代表异常？
接口最怕成功率下降、流量归零、响应时间升高；服务最怕错误率升高、实例不可用、依赖超时；数据库最怕不可用、连接打满、慢查询激增、复制延迟；消息队列最怕堆积、Broker 异常、消费停滞；网络最怕丢包、延迟、可达性失败。
异常条件要和对象语义绑定，不要用一套阈值覆盖所有对象。第一版可以先保守一点，让卡片飘红尽量代表真实异常，再逐步调优灵敏度。
负责人和责任边界要尽早写进卡片
灭火图不只是给 SRE 看，它也是故障协作工具。所以对象负责人要尽早明确。
即使第一版不把所有通知规则都做细，也应该在规划阶段明确：这个接口由谁负责？这个服务由哪个团队负责？这个数据库集群由谁维护？这个网络链路由哪个平台团队处理？这个外部依赖由哪个业务团队对接？
没有负责人，卡片飘红只是信息。有了负责人，卡片飘红才能变成行动。
责任边界还会影响空间和分层设计。如果一个空间里有太多无关团队的对象，告警规则会很难配置。如果一个首页卡片下面混了多个团队负责的对象，飘红后也很难分派。
灭火图不是单纯的架构图，而是稳定性响应图。
第一版规划可以按一张表完成
不要把灭火图规划做成很复杂的文档。第一版用一张表就够。
建议至少包含这些字段：
对象类型：接口、服务、组件、基础设施、外部依赖。
所属分层：功能接口、微服务、标准组件、基础设施。
首页卡片：电商系统、订单服务、MySQL、生产 K8s。
分组路径：订单域、支付域、订单库集群、prod namespace。
详情卡片：提交订单、支付提交、order-service、order-db-01。
核心健康指标：流量、成功率、P99、连接数、慢查询、Ready 副本数。
异常条件：成功率低于 95% 连续 3 分钟、P99 超过 2 秒。
关键标签：service_name、namespace、cluster、path、address、topic。
下钻目标：日志检索、Trace、服务仪表盘、MySQL 仪表盘、事件墙。
负责人和告警接收方：交易研发、支付研发、数据库团队、SRE、平台团队。
这张表填完，灭火图建设就已经完成了最重要的一步。后续卡片规则、下钻规则和告警规则，只是在把这张表产品化。
从手工规划到规则生成
规划完成以后，再进入规则配置。灭火图推荐通过卡片规则生成卡片，而不是手工逐个创建。
线上系统会变：接口会新增，服务会扩容，实例会迁移，Pod 会重建，组件会扩缩容，命名会调整。如果卡片靠手工维护，很快就会和真实系统脱节。
卡片规则的核心是：从数据源中筛选元信息，基于元信息组织卡片路径，为详情卡片配置健康指标，设置异常条件，并按周期更新卡片。
比如从网关日志里筛选接口域名和路径，生成接口卡片；从 Prometheus 里筛选 Kubernetes deployment，生成服务卡片；从 MySQL Exporter 指标里筛选实例地址和集群，生成 MySQL 卡片；从 APM 或 Trace 数据里筛选服务名，生成服务或接口卡片。
这就是为什么前面要先设计标签。规则生成依赖标签，下钻匹配依赖标签，告警覆盖新增对象也依赖规则和标签。如果数据源里没有这些元信息，就要先做数据治理，而不是硬写规则。
第一张灭火图的验收标准
第一张灭火图建完以后，不要只看“卡片数量”。卡片数量多，不代表建设成功。
可以用几个问题来验收：
首页能不能在 30 秒内看出系统健康状态？
最近几次事故涉及的接口、服务、组件、基础设施对象是否覆盖？
卡片飘红是否有真实含义，常态下不大量误红，故障时不能不红？
卡片是否有稳定标签，能下钻到日志、Trace、仪表盘和事件？
卡片名称是否让值班人看得懂？
详情卡片飘红后，分组卡片和首页卡片是否能反映影响范围？
能不能从异常卡片完成一次排查？
负责人和告警接收方是否明确？
如果这些问题回答得上来，第一版灭火图就算跑通了。后续再扩大对象范围、优化阈值、补充下钻和接入 SLO。
常见错误
最后列几个常见错误。
第一，把灭火图做成资源清单。所有主机、所有 Pod、所有接口都铺出来，但没有业务层次，首页很满，故障时仍然不知道先看哪里。
第二，把灭火图做成大盘目录。卡片只是跳转到各种仪表盘，没有自己的健康指标和异常条件，灭火图就失去了对象健康判断能力。
第三，空间边界太大。一个空间承载太多不相关系统，导致权限、负责人、告警和下钻都混乱。
第四，分层按工具而不是按排障路径。比如 Prometheus 一层、日志一层、Trace 一层，这是数据源视角，不是故障响应视角。
第五，卡片粒度不稳定。今天按服务建，明天按实例建，后天按接口组建，没有统一粒度，后续规则和告警难以维护。
第六，标签缺失。卡片能显示，但无法稳定下钻，用户还是要手工复制服务名、时间范围和实例地址。
第七，第一版范围过大。还没跑通一个系统，就试图覆盖全公司，结果每个系统都只做了一半。
这些错误都不是工具问题，本质上是建模问题。
结语：灭火图先规划对象，再配置规则
灭火图建设的第一步，不是接数据源，也不是写 PromQL，而是把系统拆成观测对象。
空间定义稳定性责任边界。分层定义首页判断路径。首页卡片承接对象集合。分组卡片帮助缩小范围。详情卡片表达具体观测对象。标签支撑规则生成和下钻。健康指标和异常条件定义对象是否健康。负责人和告警规则把异常变成响应。
这些设计清楚以后，卡片规则、下钻规则、告警规则和 SLO 报表才有基础。
如果你正在准备建设第一张灭火图，建议先不要打开配置页面。先拿一个核心系统，和业务研发、SRE、平台团队一起回答：
这个空间服务哪个系统？
首页分几层？
每层有哪些首页卡片？
哪些对象要做详情卡片？
每类对象的健康指标是什么？
异常条件代表什么故障？
卡片需要哪些标签？
从卡片下钻到哪里？
卡片飘红后谁负责？
这些问题回答完，再开始创建空间和卡片规则。
