/health 端点该查多深？浅探活还是深探活，你们怎么划这条线

背景

做了 10 年嵌入式，早期写 MCU 固件时"健康"这件事是被看狗强制定义的：主循环喂狗成功 = 活着，喂不上 = 复位。边界极其干净——只看"进程/主循环还在不在跑"，不替它检查外设寄存器、DMA、总线有没有挂。

搬到容器化之后，这条线突然模糊了。K8s 的 liveness 探针打到我的 /health，而 /health 里到底该 return 什么，团队里从来吵不清。我见过至少三种做法：

• 浅探活派：/health 只查"进程没 panic、event loop 还在转"，依赖全挂也照样 200。理由是 liveness 只该回答"要不要重启"，依赖抖动是 readiness 和熔断的事，混进来等于让探针替业务做容量决策。
• 深探活派：/health 要查 DB 连接池、Redis、关键下游 RPC，任何一个超时就 503。理由是"进程活着但所有依赖都断了"的 Pod 留着也是白留，不如让 K8s 直接拉走重来。
• 中间派：拆成 /livez（进程级）+ /readyz（依赖级）两个端点，探针分开打。这是文档推荐姿势，但真落地时大家又会在"下游偶发 200ms 抖动算不算 not-ready"上继续吵。

我的倾向

我站中间派，但有一条硬规则：liveness 永远不查依赖，只查进程是否还能服务；依赖健康一律交给 readiness + 客户端熔断。理由有三：

1. liveness 失败的后果是强杀重启，这是最重的动作，必须只对应"进程已不可逆坏掉"这一种情况（死锁、OOM 边缘、event loop 卡死）。依赖抖动是可逆的，不该触发最重动作。
2. 浅探活 + 客户端熔断，能区分"这个 Pod 坏了"和"这条下游链路抖了"——深探活会把两种完全不同的故障源都翻译成"重启这个 Pod"，而重启根本修不好下游。
3. 嵌入式里的类比：看门狗管 CPU 主循环，总线错误由中断和驱动兜底，从不把"外设没响应"也交给看门狗复位整个芯片。职责分层不是偷懒，是避免一个信号承载过多语义。

想听大家

• 你们线上 /health 到底查了几样东西？依赖检查的超时阈值怎么定，才不会被正常抖动误杀？
• 有没有团队踩过"深探活把下游抖动放大成连环重启"的坑？
• 冷启动慢的服务，startup 探针的 failureThreshold 你们一般给多大、怎么算的？

欢迎贴你们真实的探针配置和踩坑记录，越具体越好。