很多可观测性 POC，最后都会变成一场功能点打勾：能不能接 Prometheus，能不能查日志，能不能看 Trace，能不能画仪表盘，能不能发告警。
这些要验证，但不应该成为验收核心。
一体化可观测平台真正要证明的是：真实故障发生时，它能不能让团队更快发现问题、更快判断影响面、更快找到根因、更快恢复服务。
所以 Flashcat POC 的原则很简单：
不要用功能清单验收平台，要用故障场景验收平台。
先选一条真实业务链路
POC 不要从玩具系统开始，也不要一上来接全量数据。
选一条业务重要、团队平时确实会排障的链路即可，例如下单支付、登录、核心 API、内部发布链路或网关到数据库的关键路径。
这条链路至少要包含：
业务入口：接口、页面、任务或核心 API
应用对象：微服务、Job、网关或消费者
依赖组件：数据库、缓存、消息队列、搜索服务
基础设施：主机、容器、Kubernetes 工作负载或网络链路
业务指标：订单量、成功率、P99、在线用户数等
POC 的核心问题不是“Flashcat 能不能展示一台机器的 CPU”，而是“Flashcat 能不能围绕这条链路建立一张可用于故障响应的健康视图”。
8 个关键验收项
1. 数据能否接入并复用
验收重点不是接入一个数据源，而是已有观测数据能否进入上层场景。
至少验证三件事：
指标、日志、链路、事件是否能稳定查询
已有 Prometheus、ELK、SkyWalking 等系统是否能低成本集成
这些数据是否能被仪表盘、灭火图、北极星、SLO 和 FlashAI 复用
如果数据只能在孤立页面里查询，那只是接入成功。能被排障路径复用，才算进入平台。
2. 灭火图是否建出对象模型
Flashcat POC 的关键不是画一张好看的图，而是把系统拆成可观测对象。
建议按四层验收：
功能接口层：登录、下单、支付、查询订单
微服务层：订单服务、支付服务、库存服务
标准组件层：MySQL、Redis、Kafka、Elasticsearch
基础设施层：主机、容器、网络、DNS、CDN
验收时看四个问题：卡片是否代表真实对象，健康状态是否由关键 SLI 决定，上层状态能否聚合下层异常，卡片能否通过规则批量生成。
静态展示图价值有限。可运行、可下钻、可随系统变化更新的对象模型，才是灭火图的价值。
3. 下钻路径是否能串起排障流程
数据在同一个平台里，不等于排障路径已经打通。
设计一个现场动作即可：
从一张异常卡片出发
不复制粘贴字段
不查外部文档
不问资深同学“这个服务该看哪里”
看一线值班人能否在 3-5 次点击内进入有效排查页面
有效下钻要带着时间、请求、资源和业务对象上下文跳转到日志、Trace、仪表盘或事件页面。否则只是换了一个入口。
4. 告警是否和排查入口闭环
告警验收不能只看能不能发企业微信、飞书或钉钉。
更重要的是：告警发出去以后，收到的人能否直接进入排查路径。
合格结果应该是：
告警消息包含异常对象、异常指标和关键趋势
点击详情能进入对应北极星或灭火图页面
点击 AI 分析能触发 FlashAI 读取相关上下文
同一个异常条件不需要在多个系统重复维护
恢复后能回到同一个对象确认状态变绿
这才是告警、排查、治理闭环。
5. 业务指标能否成为故障发现入口
只看 CPU、内存、磁盘、Pod，POC 很容易变成传统监控升级。
至少选 2-3 个核心业务指标放进北极星，例如订单量、支付成功率、下单接口 P99、登录成功率、消息处理成功率。
验收标准很直接：
北极星能否表达业务健康
业务异常能否触发告警
能否从北极星下钻到灭火图继续定位技术根因
真实事故往往先体现在业务指标上，而不是 CPU 高。
6. 事件墙是否能解释异常原因
故障根因经常和变更有关：代码发布、配置变更、数据库变更、Kubernetes 调度、云平台事件、运营活动、流量切换。
POC 不需要接入所有事件，但至少要接一类真实变更事件。
验收时看异常前后十分钟：有没有关键变更，事件能否按业务线和环境筛选，能否和指标、告警、灭火图异常放在同一时间语境里分析。
注意边界：事件墙不是告警垃圾桶。更适合放变更事件、云平台事件、容器事件和关键运营事件。
7. SLO 和历史回溯能否支撑治理
POC 不能只看当下红绿，还要看故障之后能不能复盘、月报和持续治理。
可以选择支付接口、订单服务、订单库、Redis 集群等核心卡片作为 SLO 对象，设置月度目标，例如 99.95%。
需要验证：
每个对象当前达标率
哪些对象不达标
不达标发生在哪些时间段
剩余错误预算还有多少
是否能从异常时段回到灭火图时间轴查看当时状态
能回溯历史、统计 SLO、跟踪治理动作，平台才进入稳定性管理。
8. FlashAI 是否基于上下文分析
验收 AI 不能只看会不会聊天。
好的场景是：让某个灭火图卡片出现异常，从卡片上的 AI 分析发起，观察 FlashAI 是否能读取关联指标、日志、链路和事件，并指出异常对象、异常时间、相关依赖、可能原因和建议动作。
如果回答只是“建议查看日志和数据库”，价值有限。
如果它能把支付成功率下降、Trace 数据库调用变慢、连接数打满、异常前配置发布串起来，才是 POC 应该追求的效果。
POC 最后交付什么
一个合格的 Flashcat POC，不应该只交付功能截图。
建议交付五样东西：
一套真实系统的数据接入结果
一张可运行的灭火图
一组下钻规则
一次故障演练记录
一份治理建议
其中故障演练最重要。最好模拟一次接口成功率下降、服务错误率升高、数据库慢查询增加或消息堆积，记录从发现异常到定位根因用了多久，沿途点了哪些入口，哪些环节还需要补规则。
判断 POC 成功的标准
我会用一句话判断 Flashcat POC 是否成功：
当一个真实异常出现时，一线值班人能不能从业务影响出发，沿着 Flashcat 给出的对象、状态、下钻、事件和 AI 分析路径，把问题定位到一个具体原因或明确的下一步动作。
如果可以，POC 就有价值。
如果不可以，即使功能清单全部打勾，也只能说明平台安装成功、数据接入成功，还不能说明可观测性建设成功。
启动 POC 的第一步，不是接全量数据，而是选一条关键业务链路，定义验收故障场景，然后围绕这条链路建设灭火图、下钻路径、北极星指标、告警闭环、事件墙、SLO 和 FlashAI 分析。
范围越清楚，验收越真实。验收越真实，POC 越不容易变成一场功能演示。
