答案先说
FlashAI 巡检日报的目标，不是每天多发一封邮件，而是把“人工打开灭火图看一眼”变成可重复、可审计、可跟进的稳定性治理流程。
最短落地路径：
- 先选一个核心空间。
- 确认灭火图对象、健康度和下钻规则可用。
- 在 FlashAI 对话窗里手动跑一次巡检。
- 调好提示词和 HTML 报告结构。
- 再创建智能定时任务，用 cron 每天执行。
- 把日报发给值班 SRE、系统 Owner 或治理负责人。
为什么巡检要围绕灭火图
如果让 AI 直接巡检大量指标，报告通常会很散：指标很多，结论很多，但不知道该先处理什么。
灭火图更适合作为巡检入口，因为它已经把系统建模成观测对象：
接口
服务
数据库
缓存
消息队列
Kubernetes 节点
网络链路
FlashAI 沿着对象、健康状态和下钻路径分析，比直接从指标海洋里捞结论更稳定。
一份有用的日报应该回答什么
| 问题 | 日报应该输出什么 |
|---|---|
| 昨天整体健康吗 | 最近 24 小时健康概述、异常时间段、恢复情况 |
| 哪些对象值得关注 | 异常卡片清单，按分层、对象类型、持续时间或严重程度聚合 |
| 异常是否有关联 | 可能传播链，例如数据库慢查询 -> 服务等待 -> 接口成功率下降 |
| 哪些是隐患 | 趋势抬升、反复抖动、长期灰色、SLO 配额消耗 |
| 下一步谁处理什么 | 阈值调整、下钻规则补齐、容量评估、研发排查、告警治理建议 |
日报不是“昨天有几张卡片飘红”的统计邮件。它要帮助团队决定今天应该处理什么。
先在对话窗里跑通一次
不要一上来就创建定时任务。先在 FlashAI 对话窗里手动跑一次，验证报告质量。
基础提示词：
请巡检空间 spacex 的灭火图最近 24 小时的情况，
生成 HTML 格式的巡检日报，包含：
- 整体健康概述
- 异常时间分布
- 异常卡片清单，按分层聚合
- 可能的根因分析
- 隐患问题列表
- 治理建议
并通过邮件发送到 sre@corp.com。
如果只想先验证内容，不要发邮件，可以先去掉最后一句。等报告结构稳定后，再加邮件投递。
创建 FlashAI 智能定时任务
入口：
AI 配置 -> 定时任务
常见配置：
| 配置项 | 建议 |
|---|---|
| 任务名称 | 写清对象和周期，例如 每日灭火图巡检-spacex |
| cron 表达式 | 每天 09:00 用 0 9 * * * |
| 绑定大模型 | 选择已接入 Flashcat、上下文和 Agent 能力足够的模型 |
| 提示词 | 使用对话窗里已经验证过的提示词 |
| 投递方式 | 在提示词中明确 HTML 报告和收件人 |
常用 cron：
每天 09:00：0 9 * * *
工作日 09:00：0 9 * * 1-5
每 8 小时一次：0 */8 * * *
每周一 09:00：0 9 * * 1
日报、周报和告警汇总要拆开
不要用一条任务覆盖所有目标。任务越大，报告越长，也越难调优。
| 任务类型 | 时间范围 | 重点 |
|---|---|---|
| 日报 | 最近 24 小时 | 异常卡片、抖动对象、灰色卡片、当天治理建议 |
| 周报 | 过去 7 天 | 反复问题、健康趋势、治理优先级 |
| 告警汇总 | 上周告警事件 | Critical TopN、误报、抖动严重规则 |
| 建设 review | 按月或按周 | 灭火图、北极星、告警、仪表盘、下钻规则建设进度 |
知识库会影响报告质量
FlashAI 能读灭火图状态和下钻数据，但业务解释质量取决于它是否理解系统。
建议在知识库补充：
系统架构和核心链路
核心对象的业务重要性
常见故障模式和处理 SOP
报告输出要求
负责人或团队边界
示例：
spacex 空间观测电商交易系统。
核心链路：用户下单 -> order-service -> MySQL 订单库 -> Kafka 订单消息。
下单接口、支付回调、订单库主库属于 P0 对象。
MySQL 订单库慢查询增加时，优先检查最近发布、慢 SQL TopN 和连接池等待。
知识库不是为了让报告更长，而是让 FlashAI 更像熟悉系统的 SRE。
巡检日报的前提是灭火图质量
AI 不能替代对象建模。配置巡检日报前，灭火图至少要满足：
| 前提 | 要求 |
|---|---|
| 对象覆盖 | 核心接口、服务、数据库、组件已有卡片 |
| 健康度可信 | 该绿的绿，真异常稳定飘红，灰卡能解释 |
| 下钻可用 | 卡片能跳到指标、日志、链路、事件或仪表盘 |
| 事件接入 | 发布、配置变更、Kubernetes 事件、告警事件尽量接入 |
| 权限完整 | 定时任务能访问目标空间、数据源和相关对象 |
如果灭火图本身不可信，日报只会把不可信的数据自动汇总出来。
报告应该发给谁
自动发送不是目的，被阅读、被跟进、被治理才是目的。
| 报告 | 推荐收件人 |
|---|---|
| 每日灭火图巡检 | 值班 SRE、系统 Owner |
| 组件层巡检 | 数据库、中间件、平台团队负责人 |
| 告警 TopN 汇总 | 告警治理负责人 |
| SLO 周报 | SRE 负责人、业务系统负责人、研发负责人 |
| 建设 review | 平台团队和业务线技术负责人 |
如果日报里有治理建议，建议在值班交接或团队例会里固定过一遍。
常见错误
提示词太模糊。
“帮我巡检一下”不够。要写清楚空间、时间范围、输出格式、重点对象和投递方式。
未经验证就挂定时任务。
先在对话窗里跑一次，确认报告符合预期，再复制到定时任务里。
报告范围太大。
一个任务覆盖太多空间、对象和时间窗口，输出容易泛化。先从一个核心空间开始。
只看日报，不做治理。
同一批卡片连续一周出现但没人处理，巡检就变成形式。
忽略灰色卡片。
长期灰色通常意味着采集、数据源、规则或对象生命周期有问题，日报里应该单独列出。
把截图推送和 AI 巡检混为一谈。
截图推送适合快速看到现场。FlashAI 巡检适合生成结构化分析报告，两者可以配合，但不是同一件事。
落地顺序
- 选一个核心空间。
- 检查灭火图质量。
- 在知识库补充系统背景。
- 在对话窗里手动跑一次巡检。
- 调提示词，明确时间范围、分层范围、报告结构和治理建议。
- 生成 HTML 报告并手动验证。
- 加上邮件投递，小范围试运行。
- 创建智能定时任务，每天自动执行。
- 观察任务状态、耗时、邮件送达和内容稳定性。
- 把日报纳入值班交接和周度治理节奏。
