用途
Monitoring & Observability 是一个可观测性工作技能，适用于当核心问题是“我们手上有什么信息包、这个系统应该注意到什么、什么情况应该打断人工”时。它的目标不是输出一份 Prometheus / Grafana / Datadog 教程，而是规范化信息包、选定一个主要可观测性模式、定义最小可用的信号计划，并在工作转向调试、性能调优、发布执行或分析报告之前，把相邻工作分流出去。
何时使用
- 新服务、worker、API 或多服务系统在发布前需要健康信号、告警、仪表盘或 SLO 式覆盖。
- 现有技术栈已有仪表盘、告警或遥测，但信任度低，需要做保留/修复/删除/新增的审查。
- 团队需要在选择供应商或后端细节之前，决定要埋点、关联、保留或采样的内容。
- 数据、营销、分析或管道工作需要新鲜度、模式、量级或血缘监控，而不是又一次人工信任检查。
- 游戏或实时运营工作需要崩溃、会话、构建或发布事件可见性，但不涉及引擎性能分析器解读。
- 跨职能可靠性需求横跨后端、产品/运营、营销管道和游戏实时运营，且下一个负责人尚不明确。
何时不使用
- 信息包主要是日志，任务是找到第一个可操作的失败点 → log-analysis。
- 任务是针对代码缺陷或回归的复现 → 隔离 → 验证 → debugging。
- 测量已存在，主要任务是命名瓶颈或调优 → performance-optimization。
- 主要任务是发布执行、晋升、回滚或部署后排序 → deployment-automation。
- 工作是 LLM 专用追踪、评估或提示可观测性 → langsmith。
- 工作是 Unity/Unreal/Godot 帧时间捕获解读 → game-performance-profiler。
- 任务是在已整理好的 BigQuery 数据上做纯仪表盘/报告呈现 → looker-studio-bigquery。
使用方式
该技能按以下步骤执行：
-
框定信息包：在推荐工具之前，记录最小可用的接收陈述，包括 surface（服务/API、worker/队列、数据/管道、仪表盘/审查、游戏/实时运营、混合、未知）、请求类型（新设置、审查/审计、事件跟进、迁移、发布就绪、未知）、当前信息包、用户/业务影响、归属。
-
从接收信息包开始：使用 references/intake-packets-and-route-outs.md，选择用户当前实际拥有的信息包类型：服务/可靠性包、遥测基础包、数据/管道包、审查/审计包、游戏/实时运营包、尚无可用包。输出为 Intake Packet 小节，包含当前包、是否足够及原因、下一步需收集的缺失上下文。规则：如果当前信息包已经能缩小下一步决策，不要强行做供应商比较或遥测栈重写。
-
选择一个主要可观测性模式：从 references/modes-and-boundaries.md 中选择一个主要模式：service-reliability、telemetry-foundation、data-pipeline-observability、game-liveops-visibility、review-gap-audit、unknown-needs-better-packet。规则：一个主要模式，可选一个次要模式；不要把发布遥测、陈旧仪表盘审计、崩溃可见性和通用埋点混在一个答案里。
-
命名核心监控问题：在列出工具或指标之前，说明系统必须回答什么。好的例子如“用户可见的 API 痛点会在客户报告之前触发告警吗？”“我们是否知道周一增长仪表盘何时陈旧、为何陈旧、谁负责修复？”“发布事件崩溃能否按构建/平台分组，并在社交报告激增前升级？”“当前告警是否把响应者指向一个有用的仪表盘/运行手册，而不是三个嘈杂症状？”避免“设置更好的监控”这类模糊表述。
-
构建一个最小信号计划：使用 references/telemetry-rollout-matrix.md。针对所选模式，定义仪表盘/告警路径必须回答的主要问题、证据面（指标、日志、追踪、黑盒检查、崩溃工具、新鲜度检查、血缘视图）、立即告警 vs 稍后工单 vs 仅仪表盘阈值、每个告警或仪表盘族的负责人、仅前 1–3 个实现切片。规则：先对症状告警再对内部原因告警；同一事件优先一个清晰告警而非多个栈层告警；保持标签有界，高基数细节推入日志/追踪；当告警期望人工行动时包含运行手册/仪表盘链接；当告警投递可能静默失败时，把元监控视为一等公民。
-
明确分流：当工作性质转变时移交。常见分流包括：根因日志取证 → log-analysis；正确性优先的回归搜寻 → debugging；瓶颈诊断或调优 → performance-optimization；发布执行/部署后回滚路径 → deployment-automation；LLM 追踪/评估/提示可观测性 → langsmith；KPI 解读/利益相关者证据摘要 → data-analysis；BigQuery 支持的仪表盘呈现层 → looker-studio-bigquery；引擎性能分析器解读 → game-performance-profiler。
-
返回可观测性简报：输出 Observability Brief，包含 Scope（surface、请求类型、接收信息包、主要模式、置信度）、Core Monitoring Question、Signal Plan（指标/检查、日志/追踪/崩溃上下文、仪表盘/视图、告警策略）、Ownership（主要负责人、次要负责人）、First Implementation Slice（1–3 项）、Route-outs。
示例
- 发布前的新 API：输入“我们下周发布新 API，告诉我该埋点什么、什么该告警。”预期：归类为 service-reliability，使用当前发布/就绪包，定义 RED/黄金信号问题加黑盒覆盖、告警阈值和一个最小落地切片。
- 增长仪表盘总是陈旧：输入“我们周一早上的增长仪表盘一半时间都是陈旧的，我们需要可观测性，而不是又一次电子表格检查。”预期：归类为 data-pipeline-observability，覆盖新鲜度/模式/量级/血缘/归属，并区分仪表盘信任检查与 KPI 解读工作。
- 审查/差距审计：输入“我们有大量告警和仪表盘，但没人信任它们。哪些该保留、哪些该删除？”预期：归类为 review-gap-audit，使用告警/仪表盘清单，产出保留/修复/删除/新增决策，并指出嘈杂告警、无主面板和缺失的元监控。
- 分流到发布执行：输入“我们刚部署完，需要带健康检查的分步回滚/晋升清单。”预期：把执行工作流分流到 deployment-automation，同时可选地指出少数重要的部署后可观测性问题。
- 分流到日志取证：输入“这是故障日志，找根因。”预期：不作为主要工作流，分流到 log-analysis，仅在识别出第一个可操作失败后提出可观测性跟进建议。
最佳实践
- 从信息包和核心监控问题开始，而不是供应商。
- 保持一个主要模式和一个最小实现切片。
- 对症状告警，而不是对每个可能原因告警。
- 明确归属、运行手册和仪表盘链接。
- 把陈旧数据/管道信任视为一等可观测性工作。
- 把游戏实时运营可见性与引擎性能分析器解读分开。
- 保持审查/审计诚实：死仪表盘和嘈杂告警应被删除，而不仅仅是记录。
- 当前门边界变化时，同步紧凑的发现面。
限制
该技能不用于日志根因分析、代码调试、性能调优、发布执行、LLM 追踪评估、游戏引擎性能分析或 BigQuery 仪表盘呈现，这些工作应分流到对应技能。具体支持的供应商、价格、平台或效果信息暂未提供。