先让问题可见

服务出现超时的时候，第一反应往往是调大线程池或延长超时时间。但如果没有请求耗时、依赖耗时和错误类型这些基本信号，任何调整都只是猜测。

我更习惯先补齐三件事：统一的 trace id、按依赖拆分的耗时指标，以及能够关联到业务上下文的结构化日志。

把恢复路径写进设计里

稳定性不是让系统永远不出错，而是让错误发生时影响范围可控。超时、重试、熔断和降级应该是一条完整的路径，而不是散落在各个调用点的 if 判断。

对于幂等的读请求，可以设置有限次数的指数退避重试；对于写请求，则优先通过幂等键和状态机保证重复执行不会造成额外副作用。

Result handleCommand(String idempotencyKey, Command command) {
    return idempotencyStore.find(idempotencyKey)
        .orElseGet(() -> executeAndStore(idempotencyKey, command));
}

留下一份能复用的复盘

一次故障真正的价值，来自它是否降低了下一次故障的排查成本。记录时间线、触发条件、观测信号和最终修复，让复盘成为团队可以反复使用的工程资产。