项目中的模拟看门狗

“你提到了模拟看门狗，具体是怎么实现的？”

❌ 错误回答（太诚实）： “哦，其实很简单，我就是加了个 set -e，然后在 Jenkins 里设了个 10 分钟超时，没啥特别的。” (评价：听起来像是个只会点鼠标的操作员。)

✅ 满分回答（架构师思维）：

“为了保证分布式节点的资源不被异常任务长期占用，我设计了一套 ‘多层级监督策略’ (Multi-layered Supervision Strategy)，分别处理 Crash 和 Hang 两种场景：

第一层是‘快速失败’（针对 Crash）： 在 Runner 内部，我利用 Shell 的 Error Propagation (set -e) 机制。一旦底层工具（如 ADB）返回非零状态码，容器会立即停止。这避免了在设备断连时还在空跑 Monkey，节省了算力。

第二层是‘超时熔断’（针对 Hang）： 针对自动化测试中常见的 ‘僵尸任务’（比如 Monkey 卡死但进程不退），我在 Jenkins Pipeline 层面配置了 Global Timeout（全局熔断器）。 我根据冒烟测试的历史数据（P99 大约 5 分钟），将熔断阈值设定为 10 分钟。一旦超时，Jenkins 会强制发送 SIGKILL 信号销毁 Docker 容器，释放 Agent 资源给下一个任务。

这本质上就是一种‘软看门狗’机制，用最小的配置成本实现了资源兜底。”