画出调用依赖图并标注故障传播路径
在白板或工具里画出核心服务之间的调用关系。每条调用标注三个信息：是同步还是异步、超时时间、有没有重试。
在图上用红色标出"如果这个服务挂了，哪些上游会受影响"。沿着红色路径往上走，直到走到用户入口。这条路径就是故障传播链。
完成标准：能指出系统中最长的那条故障传播链，并且知道链上每个节点的超时配置。如果有节点没设超时或者超时设成了 60 秒——这就是第一个要改的地方。
给最脆弱的调用加熔断器
从故障传播链上找到最容易出问题的那个节点——通常是最慢的、最不稳定的、或最近出过故障的下游服务。
给这个调用加 Circuit Breaker。配置三个参数：错误率阈值（超过多少比例触发熔断）、熔断持续时间（断开多久后尝试恢复）、半开状态的探测请求数（恢复时先放几个请求试试）。
起步配置建议：错误率 50%、熔断 30 秒、半开放 3 个探测请求。上线后根据实际情况调。
同时写好降级逻辑——熔断之后返回什么。可以是缓存数据、默认值、或明确的错误提示。不要返回 null 或空对象让调用方猜。
完成标准：熔断器上线后，手动关掉下游服务，上游在 2 秒内切到降级路径而不是等超时。
隔离共享线程池
检查核心服务是否有多个下游调用共享同一个线程池的情况。如果有——这是一个慢接口就能拖垮所有接口的结构性隐患。
拆成独立的线程池或信号量。每个下游调用有自己的并发上限。一个下游慢了只消耗自己的配额，不影响其他下游的请求。
线程池大小的计算：并发量 = QPS × 平均响应时间。比如某下游 QPS 100、平均响应 200ms，需要 20 个线程。在此基础上加 50% 余量，设成 30。
完成标准：关掉一个非核心下游服务后，其他下游的响应时间和可用性不受影响。
给高频写入加回压
如果系统有"生产者产生消息、消费者处理消息"的环节，检查生产者和消费者之间是否有背压机制。
没有的话，加一个有界队列作为缓冲。队列满了时生产者被阻塞或收到拒绝信号——不是无限堆积。
队列大小的设定：队列容量 = 消费速率 × 可接受的最大延迟。比如消费者每秒处理 1000 条、可接受延迟 10 秒，队列设成 10000。超过这个量，生产者应该收到反压信号。
完成标准：在生产速度超过消费速度 3 倍的压测下，系统内存使用量稳定在预设范围内，不会 OOM。
调整超时配置为级联安全
检查整条调用链上的超时配置。一个常见的错误是每层都设 30 秒超时——A 等 B 等 C，如果 C 卡了 30 秒，A 要等 30+30=60 秒。
正确的配置原则：外层超时 > 内层超时之和。如果 C 超时 5 秒，B 超时设 8 秒（留余量），A 超时设 12 秒。
同时检查重试配置：重试次数 × 单次超时 不能超过上层的超时时间。否则还没重试完上层就超时了，重试白做。
完成标准：在最深层服务完全不可用时，最外层用户在 15 秒内能拿到明确的错误响应而不是一直转圈。