200 个服务凭据轮换：如何做到"先验证可用、再下线旧凭据"不出事故？

【背景】 我负责一家做 SaaS 的公司安全加固，约 200 个微服务（Java/Go 混合，K8s 1.28 自建集群，无云账号）。最近做完一轮凭据盘点，发现三类"长寿命凭据"仍然大量存在：

1. 第三方 API Key（对象存储、短信网关、支付回调签名）——约 60 个，分散在 30+ 服务，有的写死在代码里，有的挂在 K8s Secret；
2. 数据库账号密码——部分服务还在用"共享超级账号"，一个账号被 8 个服务复用；
3. 内部服务间的静态 token——历史遗留，无过期时间。

【现象 / 卡点】 我们计划分两个季度把这些凭据全部轮换到"一服务一凭据 + TTL 自动轮换"。但卡在一个非常具体的点：轮换窗口怎么保证不出事故。

• 第三方 Key 的旧值在下线前，我们无法确认"哪些服务还在真实调用它"——调用链路是动态的，服务间还有异步消息；
• 数据库共享账号拆分成独立账号后，旧账号要保留多久才能安全下线？保留期内如何审计"还有谁在用"？
• 内部静态 token 一旦双跑（新旧并存），网关侧怎么区分"谁还没切过来"，而不是靠人肉催？

【已尝试的排查】

• 查过 Vault、K8s Secret 的访问日志，但只能看到"谁拉取过"，看不到"谁还在使用"；
• 网关侧有请求级审计，但内部服务间调用走 service mesh，没有统一的凭据维度日志；
• 想过"灰度下线旧凭据 + 告警兜底"，但没有具体的落地步骤参考。

【期望得到的答案形态】 希望有实际做过大规模凭据轮换的朋友，能给出具体的：

1. 轮换窗口设计（双跑时长、下线判据、回滚预案）；
2. "识别残留使用方"的技术手段（日志、代理、探针，任选其一并给配置示例）；
3. 第三方 Key 与内部 token 的差异化处理策略；
4. 踩过的坑（尤其"以为下线了、其实还有人用"的场景）。

谢谢，有实操经验的请优先，纯理论方案就不必了。