用途
该技能面向数据工程智能体，解决“智能体看不到生产信号就凭猜测修复”的问题。它把 MCP 服务器模板与安全的只读可观测性工作流配对，让诊断先于变更：不再盲目扩缩容集群、不再重跑因结构性原因 OOM 的作业、不再在未检查延迟的情况下改动 Kafka 消费者。
适用场景
- 诊断 Spark OOM、shuffle 倾斜或 stage 失败
- 在重放或修改消费者前检查 Kafka 消费者组延迟
- 审查 Airflow DAG 运行状态、任务时长漂移或失败重试
- 在重新开放下游消费者前验证数据仓库发布状态
- 为数据工程智能体搭建 IDE 集成的可观测性
注意：在事故分诊期间，除非明确批准并限定范围，不要使用 MCP 的写入能力执行破坏性修复。
工作流
-
为问题选择最小的 MCP 接口面：
- Spark 计划与 stage 指标：mcp/spark.mcp.json 或 mcp/databricks.mcp.json
- Kafka 延迟与 topic 元数据：mcp/kafka.mcp.json
- 编排运行状态：mcp/airflow.mcp.json
- 仓库检查：mcp/snowflake.mcp.json、mcp/bigquery.mcp.json 或 mcp/postgres.mcp.json
- 发布与作业元数据：mcp/dbt-cloud.mcp.json、mcp/github.mcp.json
-
先配置只读。来自 mcp/README.md：
- 用实际使用的 MCP 服务器二进制替换占位命令
- 将凭据限定为只读检查角色
- 设置允许列表（topic、catalog、schema）到最小必要范围
- 在依赖工具输出前，先在智能体会话之外验证连通性
-
建立诊断顺序，典型顺序为：
- 确认症状（延迟、失败率、新鲜度违规）
- 拉取实时元数据（消费者延迟、上次成功运行、stage 倾斜）
- 与 data-observability-and-sla-management 中的基线或 SLA 对比
- 在提出代码或基础设施变更前形成假设
- 当后续有行动时，将发现记录到事故或回填证据模板中
-
应用平台特定的调查模式：
- Spark OOM 或超时：检查 stage 分解、shuffle 读写字节、spill 指标和分区数；优先修复物理计划而非盲目扩容
- Kafka 延迟：检查每个分区的组延迟、DLQ 率和保留余量；在延迟根因分类前暂停重放
- 编排失败：检查任务日志、重试历史和上游传感器；不要在没有计划门控的情况下从单个红色任务触发大范围回填
- 加载 references/mcp-data-observability-patterns.md 获取工具到症状的映射
-
将可观测性与安全技能配对：
- 重放或修复：safe-backfill-and-replay-orchestration
- 流处理加固：kafka-resilience-and-schema-evolution
- 无服务器 Spark：spark-serverless-reliability-and-state-management
- 事故响应：incident-triage-and-pipeline-recovery
-
变更后闭环：在重新开放发布前，重新查询 MCP 信号以确认延迟恢复、运行成功或新鲜度恢复。
常见合理化借口与事实
- “仅凭日志就能推断问题。”——没有延迟、计划和运行元数据的日志会遗漏倾斜和消费者停滞等系统性原因。
- “MCP 访问应使用管理员凭据以提速。”——过度授权的令牌会在智能体建议大范围变更时扩大影响范围。
- “可观测性只属于值班人员。”——没有实时信号的智能体会以机器速度复制危险的猜测。
- “一个 MCP 服务器足以应对所有技术栈。”——多平台环境需要针对每个系统的专用模板，而非一个巨型连接。
危险信号
- 智能体在未查询实时信号的情况下提出基础设施或代码变更
- MCP 模板默认使用可写凭据
- Kafka topic 或仓库 schema 没有允许列表
- 延迟或运行失败被确认但未关联到负责人或 SLA
- 可观测性发现未链接到回填或事故证据
验证
- 选择了正确的 MCP 模板并验证为只读
- 在提出结构性变更前查询了实时信号
- 涉及重放或发布时，发现映射到具名安全技能
- 变更后信号确认恢复，才重新开放发布