用途
本技能适用于数据管道必须以“服务”形式运营、而非仅作为代码执行的场景。它帮助智能体定义“健康状态”是什么样的，以及团队如何知道系统偏离了该状态。
适用时机包括：
- 上线或加固生产数据产品
- 定义新鲜度或完整性 SLA
- 改进告警与异常检测
- 增加运维元数据与健康可见性
- 减少噪声大、低信号的事故响应
- 设计带有明确告警与恢复证据的韧性演练
工作流程
1. 定义服务承诺，包括：
- 新鲜度 SLA
- 完整性预期
- 可接受的延迟
- 负责人与升级路径
2. 识别健康信号，常见信号包括：
- 运行成功率
- 任务时长漂移
- 数据量异常
- 模式漂移
- 消费延迟
- 数据新鲜度
3. 设计可执行的告警。 告警应路由到能够采取行动的人，并带有足够上下文以便快速排查。
4. 采集运行元数据与失败上下文。
5. 评审告警质量。 噪声告警与缺失告警同样会损害信任。
6. 当恢复行为重要时，将健康信号与韧性演练配对。 当团队必须证明受控故障下的重启、重试、积压或故障转移行为时，加载 references/data-resiliency-testing-patterns.md。
常见合理化与事实
- “调度器已经会告诉我们失败了。”——任务失败本身并不能衡量数据是否陈旧、不完整或错误。
- “告警越多越安全。”——告警疲劳会让真实事故更容易被漏掉。
- “业务方发现问题会告诉我们。”——这意味着在团队察觉之前，系统已经失败了。
危险信号
- 没有指定负责人或升级路径
- 新鲜度被假设但未被测量
- 告警触发时没有运行上下文或影响线索
- 存在异常检测但没有响应手册
验证清单
- SLA 与所有权已定义
- 存在针对新鲜度、完整性和可靠性的健康信号
- 告警可执行且路由正确
- 运行元数据支持快速诊断
限制
资料未提供具体的实现代码、工具依赖、安装命令、收费或价格信息，也未提供各信号的具体阈值与实现方式。