上线前全绿，某天凌晨调用方突然大批量拿不到密钥，签名失败、解密失败、接口 5xx 一起涌上来，这时候最怕的是乱试。这篇不解释 KMS 是什么，而是给你一套从调用侧往内收的排查顺序：先分清是网络、鉴权、配额还是服务端故障，再决定是重试、降级还是切备用通道，最后补上监控与演练。
上线前全绿，某天凌晨调用方突然大批量拿不到密钥，签名失败、解密失败、接口 5xx 一起涌上来。这时候最怕的不是故障本身，而是有人凭直觉先去重启、先去改配置，把一次可控的抖动扩成一次真事故。下面这套顺序是给你照着走的：先分清症状属于哪一类，再决定是重试、降级还是切备用通道。
文章不解释 KMS 是什么，默认你已经在值班。要提醒一句：任何单一手段都有不适用的时候，比如静态密钥缓存这种兜底，在需要合规审计、密钥必须按时轮换的场景里就不能用。每一步都先问「这一步的失效边界在哪」，再动手。
先把症状分类，别急着重启
同一句「KMS 不可用」，底下可能是四件完全不同的事。分类错了，后面所有动作都是白费力气，甚至会把影响面扩大。先从调用方日志入手，把错误形态、时间戳、目标、耗时这几项凑齐，再谈处理。
| 症状形态 | 典型表现 | 先看哪里 | 别急着做 |
|---|---|---|---|
| 连不上 | 超时、连接被拒 | DNS、出口 IP、证书、代理 | 不要反复重启调用方 |
| 连上了但鉴权失败 | 4xx 鉴权类错误 | 凭证有效期、权限策略变更 | 不要临时放宽权限 |
| 鉴权通过但被限流 | 调用频率被打满 | 配额、并发连接数 | 不要无脑加重试 |
| 服务端内部错误 | 5xx、区域性波动 | 官方状态页与公告 | 不要在本地瞎改配置 |
- 确认影响面：单实例、单可用区，还是所有调用方集体失败，这决定你先降级还是先扩容量
- 记录关键字段：请求时间戳、目标域名或 IP、错误码、耗时，缺这几项后面基本靠猜
- 区分「一开始就报错」和「跑了一段时间才报错」，前者偏配置，后者偏容量或资源泄漏
- 把第一次报错的时间点标出来，回头对变更记录时最有用
由外向内五步定位
排查顺序很关键：从离你最近的调用侧往里收，而不是一上来就怀疑服务端。由外向内能让每一步的结论都可验证，也避免你改了一堆东西最后不知道是哪一项起了作用。下面给的是顺序，不是并行清单。
- 第一步：网络链路查 DNS 解析对不对、有没有代理或安全组变更、证书是否过期。团队里最常见的其实是证书和出口 IP 白名单被改，顺手看一眼就能排除。
- 第二步：鉴权查凭证是否被轮换、权限策略是否收窄、使用的身份是否还在有效期。权限类变更往往在几个小时前就已生效，症状滞后出现，容易误判成突发故障。
- 第三步：配额与限流区分是调用频率被打满，还是并发连接数被卡住。前者要削峰或错峰，后者要调连接池和超时，应对手段不一样。
- 第四步：服务端状态看官方状态页与公告，确认是不是区域性故障。是的话就别折腾自己这边了，重点是降级和告知业务方。
- 第五步：动配置回滚最近一次变更，一次只改一个变量，改完立刻验证。不要同时改三个地方，那样等于把下一次排查的线索也删了。
恢复动作与降级设计
恢复到可用，和恢复到「看起来可用」是两件事。短期动作按代价排序执行，代价小的先做；降级方案要提前想清楚它在什么条件下会失效，否则只是把故障藏起来，等下一次更大规模地爆。
- 先摘除故障节点，再调大重试退避，最后才考虑切备用区域或备用密钥通道
- 重试要有上限和抖动，无脑重试是 KMS 故障里最常见的二次伤害，容易把限流变成雪崩
- 静态密钥缓存、本地加密兜底只在业务能接受短时密钥不轮换时成立；涉及合规审计、密钥必须按周期轮换的场景不适用
- 降级路径本身要被监控，否则你不知道自己是在降级还是在静默丢数据
- 每次降级都设超时和自动回切条件，避免故障恢复后流量还挂在备用通道上
具体到配额是不是被打满、当前各通道的延迟表现如何，别凭经验估，去站内页面核对当时的数字：/tools/speed-test 能帮你把多条通道的实际表现摆在一起看。
长期防护：监控、演练与变更纪律
故障过去之后，真正决定你下次是「半小时恢复」还是「熬一整夜」的，是平时有没有把这些准备做出来。监控不是越多越好，先把四个指标做准，再谈扩展。
| 必配指标 | 看它能回答什么 | 告警阈值怎么定 |
|---|---|---|
| 调用成功率 | 整体是否可用 | 按业务容忍度定，不抄默认值 |
| P99 延迟 | 是否在恶化但没报错 | 结合业务超时设置反推 |
| 限流拒绝数 | 容量是否到顶 | 贴近配额上限前就要预警 |
| 密钥获取失败数 | 影响多少真实业务 | 按失败量级分级告警 |
- 把证书、白名单、权限策略这三类变更纳入变更评审，它们是最容易引发不可用的源头
- 定期做故障演练：人为断开一条链路，看降级是否真的生效、告警是否真的响、值班同学能否按预案操作
- 保留一份不依赖线上系统的应急手册，KMS 挂了的时候你未必查得到线上文档
- 演练后要写一句「哪一步卡住了」，下次演练就盯那一步
- 把各通道的可信度信息定期过一遍，去 /sites 看当前收录与检测情况
常见问题
KMS 报不可用，第一件事应该做什么？
先确认影响面和报错形态，再动手。看是所有调用方都失败还是个别实例，是连不上还是鉴权失败。单实例失败先隔离，全局失败先查官方公告和证书、白名单这类近期变更。跳过这步直接重启或重试，很容易把小故障放大成雪崩。
能不能直接加缓存把密钥存本地扛过去？
要看业务和合规要求。缓存能扛短时的读取故障，但会带来密钥轮换延迟和失效范围扩大的风险。如果你们有审计、等保或行业合规要求，这类兜底通常不被接受。可以缓存，但要设短 TTL、加开关，并明确记录降级期间的行为。
怎么判断该等官方恢复还是自己切备用通道？
看两点：官方是否已确认故障并给出预计恢复时间，以及你们的业务能否撑到那个时间点。已确认且时间可接受就等，同时做好降级；未确认或时间不可控，就按预案切备用区域或备用密钥源，并记录切换时间点，方便事后复盘。
