readiness 门禁改成「P99 < 阈值持续 60s」之后，怎么证明它真能拦住冷启动？staging 复现不了冷启动，有没有可落地的验证手段与阈值标定方法？

顾清和-224

引用 #20 K8s 探针三件套：liveness / readiness / startup 我踩过的坑与默认值建议 #189 HPA 扩容后那 30 秒冷启动窗口，P99 抖动到底该谁兜底

先给结论：门禁"拦住了多少"这件事，本质是把"门禁通过时刻"与"真实接口 P99 恢复时刻"做时间对齐的审计问题——你现在缺的不是门禁逻辑，而是一条独立于 kubelet 的观测通道。下面按你三个诉求分别给可复现做法，都能落进 1 个迭代。

1. 生产验证手段：选「canary 单副本慢启动」，代价最小、信号最干净

三种方案对比（按推荐序）：

方案 A（推荐）：canary 单副本 + 注入慢启动

做法：发版时用 strategy.canary 先起 1 个副本（或临时 maxSurge=1, maxUnavailable=0 且把其余 3 副本打 readinessGate 的容忍标签让它们先接流），对这个副本注入延迟：-XX:+AlwaysPreTouch 关掉 + 在 main 里 Thread.sleep(8000) 模拟 JIT 预热期；
观测：kubectl describe pod 看 Ready 时间戳 vs 该副本实际开始接流时间（从 endpoints 事件流抓），差值就是门禁"拦住的时长"；
信号干净度：只影响 1/4 流量，SLO 预算消耗约 25%，回滚成本 = kubectl delete pod，不需要改代码、不需要 staging；
关键前提：合成端点必须走真实 service 层（见下文保真度校验），否则你验证的是"端点通了"而不是"JVM 热了"。

方案 B：摘除合成端点模拟失效

做法：发版前用 sed 把 readiness 探针 URL 改成一个故意超慢的 /slow-health（内部 Thread.sleep(120) 后返回 200），观察门禁是否真的拒绝 Ready；
优点：直接验证"门禁失效"这条链路；
缺点：改镜像、要走一次 CI，且只覆盖"端点异常"一种失效模式，不覆盖"端点正常但绕开 JIT 热点"这种更隐蔽的失效。

方案 C：发布前主动 kill 单副本

信号最脏：kill 会触发其他 3 副本流量重分布，P99 尖峰里混入了"流量放大"和"JIT 冷"两个因素，你没法归因到门禁本身，不推荐用于验证门禁，只推荐用于验证整体弹性。

2. 阈值标定：用「历史冷启动尖峰分位数」反推，不要拍

核心思路：阈值 = 你愿意容忍的冷启动最坏 P99，不是稳态 P99 的倍数。

可复现步骤：

采历史数据：拉最近 30 天所有滚动发布窗口（maxSurge 副本从启动到 Ready 的那段），每 1s 一个 P99 采样点，导出 CSV；
算分位数：
- spike_p50 = 所有冷启动窗口 P99 的 50 分位数（典型冷启动水平）；
- spike_p95 = 95 分位数（最坏 5% 冷启动）；
- 你现在的 50ms 阈值如果低于 spike_p50，说明门禁会频繁误拦（低峰期样本不足时更明显）；如果高于 spike_p95，说明门禁拦不住最坏情况；
定阈值：取 spike_p75（75 分位数）作为 P99 阈值——含义是"75% 的冷启动都能通过这个阈值，25% 的会被拦"，这个比例你可以按业务容忍度调；
定持续时长：从同一批数据里找"P99 首次低于阈值后，又在 60s 内反弹超过阈值"的比例（即"假通过率"），如果 > 5%，把持续时长从 60s 拉到 90s 或 120s；如果 < 1%，60s 够用；
低峰期兜底：不要靠"放宽阈值"，而是加 min_sample——合成压测端点内部维护一个滑动窗口（比如 10s），如果窗口内样本数 < 200（即 QPS < 20），直接返回 503 拒绝 Ready，宁可拖长发布也不接受低样本下的"统计显著性不足"的通过。

合成端点保真度校验（关键）：

合成端点必须调用与真实 API 完全相同的 service 方法（同一个 OrderService.create()，不是简化版），只是把"写库/发消息"这些副作用用 shadow flag 跳过（if (shadowMode) return;）；
验证方法：在 staging 同时开合成端点和真实 API（打同一个下游），对比两者 P99 的相关系数（Pearson r），如果 r < 0.8，说明合成端点没有覆盖 JIT 热点路径，需要检查是否绕过了某个 @Transactional 或 @Cacheable 注解；
这条校验本身可以做成一个 CI 测试：每次发版前在 staging 跑 10 分钟，断言 r >= 0.8，防止有人改了 service 层但忘了改合成端点。

3. 静默失效兜底：加一条独立于 kubelet 的观测通道

你现在的问题是：kubelet 只报 probe failed，没有"差多少才通过"，而且如果探针逻辑本身有 bug（端点正常但绕开 JIT），没有任何信号能发现。解法是加一条影子探针：

架构：

[真实 API] ──┐
             ├──→ [P99 采样器] ──→ [指标库]
[合成端点] ──┘
                        │
                        ▼
              [影子探针]（独立进程，读指标库）
                        │
                        ▼
              [独立日志流] ──→ [告警规则]

具体做法：

影子探针：一个独立 sidecar 进程（或 DaemonSet），每 5s 读一次指标库里的"合成端点 P99"和"真实 API P99"，如果 synthetic_p99 < 50ms 但 real_p99 > 80ms（即门禁会通过，但真实接口还没热），写一条 gate_mismatch 事件到独立日志流；
告警规则：gate_mismatch 事件出现即告警（不需要持续 N 分钟，单次就够），这是"门禁本该拦但没拦"的直接信号；
审计日志：每次 readiness 状态翻转（NotReady → Ready 或反向）时，在应用侧打一条结构化日志：{ts, pod, synthetic_p99, real_p99, sample_count, duration_s}，这条日志不经过 kubelet，直接写日志库，回看时能对齐"门禁通过时刻"和"真实 P99 恢复时刻"的差值；
失效自检：在 staging 加一个混沌测试：故意把合成端点的 P99 阈值从 50ms 改成 500ms（模拟"阈值被误调松"），观察影子探针是否告警，验证告警链路本身是通的。

一句话总结

门禁可验证性 = 独立影子探针（观测通道） + 合成端点保真度校验（防止绕开 JIT） + 历史分位数反推阈值（防止拍脑袋），三者缺一不可。你现在缺的是第一条（独立观测通道），补上之后，"拦住了多少"这个问题就能用数据回答了。

readiness 门禁改成「P99 < 阈值持续 60s」之后，怎么证明它真能拦住冷启动？staging 复现不了冷启动，有没有可落地的验证手段与阈值标定方法？

背景

现状与卡点

已尝试

期望得到的答案形态

1. 生产验证手段：选「canary 单副本慢启动」，代价最小、信号最干净

2. 阈值标定：用「历史冷启动尖峰分位数」反推，不要拍

3. 静默失效兜底：加一条独立于 kubelet 的观测通道

一句话总结