业务健康指标怎么设计：北极星指标、SLO 和故障发现入口
业务健康指标不是普通大屏。用北极星发现真实业务异常，用灭火图定位技术对象，用 SLO 管理稳定性目标，才能把可观测性接到业务影响。
分类：产品技术
汇总 Flashcat 博客中归属于 产品技术 分类的文章，方便按内容类型连续阅读产品实践、客户案例和可观测性方法。
产品技术 分类文章
自研告警平台还要不要继续维护？成本、能力和风险对比
自研告警平台是否还值得维护，不能只看研发和服务器成本。本文从业务语义、On-call 闭环、通知分派、降噪、权限审计、数据分析、迁移路径和总拥有成本评估取舍。
MTTA 和 MTTR 怎么算？如何用指标管理故障响应效率
MTTA 和 MTTR 不能单独解释故障响应效率。拆开认领、恢复、响应比例、中断次数、响应投入和告警 TOP，才能定位 On-call 链路到底慢在哪里。
SkyWalking / Jaeger / ARMS 已经有了，还需要统一可观测平台吗
本文讨论已有 SkyWalking、Jaeger、ARMS 等 APM 系统后，为什么仍然需要统一可观测平台，并从链路追踪边界、服务拓扑、灭火图对象模型、跨系统下钻、Flashcat APM 和建设路径说明 APM 与统一可观测平台的关系。
云监控、Zabbix、Prometheus 告警如何统一接入一个平台
本文介绍如何把云监控、Zabbix、Prometheus、Grafana 和自研监控的告警统一接入 Flashduty，从专属集成、共享集成、路由规则、标签规范、Pipeline 清洗、协作空间和治理数据构建统一告警响应层。
飞书、钉钉、企业微信里如何处理告警，才不会淹没在群消息里
本文介绍如何在飞书、钉钉、企业微信中治理告警通知，从群机器人、应用卡片、故障状态、分派认领、升级策略、作战室和标签治理出发，把 IM 告警从群消息升级为可追踪的故障响应。
日志系统不只是检索：如何用日志报表把 Logs 变成 Metrics + Tracing
本文介绍如何用日志报表把结构化日志转成可持续观测的指标，并保留回到日志原文和 Trace 的路径，帮助团队从日志检索升级到趋势分析、维度定位、BubbleUp 和灭火图联动。
Zabbix / 老监控系统如何平滑演进到现代可观测平台
从 Zabbix 和老监控系统平滑演进到现代可观测平台的迁移路线，覆盖存量资产盘点、并行运行、Prometheus/OpenTelemetry 指标标准化、日志链路补齐、对象健康视图、告警入口、事件墙、SLO、巡检和老系统下线条件。
可观测性平台怎么选：开源组合、自研平台和商业平台的边界
本文从目标、团队能力、事故现场、长期成本和稳定性治理出发，比较开源组合、自研平台和商业可观测平台的适用边界，帮助企业选择更适合自己的可观测性建设路径。
Flashcat POC 验收清单：如何判断一体化可观测平台是否真的有价值
本文提供一套更贴近真实故障场景的 Flashcat POC 验收清单，帮助企业从数据复用、灭火图对象模型、下钻路径、告警闭环、业务指标、事件墙、SLO 和 FlashAI 判断一体化可观测平台是否真正有价值。
夜莺 v9 AI：给每个 SRE 配一个 7x24 在线的资深副驾驶
夜莺 v9 把团队最资深 SRE 的经验装进了系统：告警真假判定从 20 分钟缩到 2 分钟、告警事件分析、自然语言一句话搭起监控、19 个开箱即用 Skill 还能写出贴合自己场景的 Skill，而且数据可以完全不离域。本文系统介绍夜莺 v9 的 AI 能力、五大场景与安全边界。
如何为一个电商系统建设灭火图：接口、服务、组件、基础设施四层模型
以典型电商系统为例，说明如何按功能接口层、微服务层、标准组件层和基础设施层建设灭火图，让故障现场能快速判断影响范围和下一步排障路径。
Flashcat vs Grafana + Prometheus + ELK：差异不在数据展示，而在故障处理路径
对比 Flashcat 与 Grafana、Prometheus、ELK 等开源可观测性组合，说明真正差异不在数据展示能力，而在围绕故障发现、定位和恢复的一体化处理路径。
BigPanda 的价值不在会聊天，而在把告警风暴变成可调查事故
BigPanda 的 AI SRE 路线不是让大模型直接猜根因，而是先把多源告警、变更、拓扑、历史事故和工单知识聚合成可调查、可分派、可自动化的 incident，再让 AI 做解释、分诊和 L1 自动化。
AI Agent 框架怎么选？不要先看热度，先看你到底要控制什么
AI Agent 框架选型指南：不要先看热度，而要看控制权、状态恢复、流程编排、RAG 数据层、云生态、评测和生产可控性，再决定 LangGraph、ADK、OpenAI Agents SDK、LlamaIndex、Haystack、Pydantic AI、Mastra 或 CrewAI。
告警太多怎么办？从规则治理到告警响应平台的完整方法
本文介绍告警太多时不能只靠删规则或调阈值，而要从事件、告警、故障分层出发，同时治理告警源头、聚合抑制静默延迟、建设 On-call 响应流程，并用 MTTA、MTTR、压缩率等指标持续衡量效果。
Sentry 的 AI RCA 不在运维大屏，而在把生产错误直接修成 PR
分析 Sentry Seer 的 AI RCA 路线：以 production issue 为入口，结合 stack trace、runtime context、代码库、Root Cause Analysis、自动修复和 PR 流程，把根因分析推进到可审查的代码交付。
可观测性的 AI-Ready 之路：为什么 AI 需要灭火图这样的上下文
AI-Ready 可观测性不能只依赖大模型能力，更需要用灭火图组织对象、健康状态、拓扑关系、指标、日志、Trace、事件、下钻路径和知识库，让 FlashAI 基于完整上下文进行分析、巡检和操作。
从一张飘红卡片到根因定位：Flashcat 灭火图下钻怎么工作
本文介绍 Flashcat 灭火图下钻如何把异常卡片、标签、日志、Trace、仪表盘、上下游卡片和事件串成故障分析路径，帮助团队从发现异常快速收敛到根因定位。
为什么监控大盘越做越多，故障时还是不知道先看哪里
监控大盘解决的是数据展示，不一定解决故障决策。复杂系统需要围绕观测对象组织健康状态、下钻路径、告警和 AI 上下文。
