上次线上出问题，影响范围是怎么扩散的
回想最近一次线上故障。一个服务出了问题，最终影响了几个服务？故障从发生到被隔离花了多久？
如果一个下游的问题在两分钟内扩散到了三个以上的上游服务——系统里没有有效的故障隔离。不是说你需要立刻上全套反应式架构，但至少需要知道故障传播链在哪里、在哪些节点可以断开。
你知道系统的真实承载上限吗
不是压测报告上那个峰值 QPS。而是：在什么负载下，系统能稳定跑 24 小时，P99 延迟不升、错误率不涨、内存不涨？
很多团队知道系统"最快能到多少"但不知道"最多能扛多久"。前者是冲刺速度，后者是巡航速度。线上跑的是巡航速度，不是冲刺。
如果你只有冲刺数据没有巡航数据，下一次压测的时候跑一个 4 小时以上的稳定性测试。
下游挂了之后你的服务返回什么
某个核心依赖突然不可用。你的服务返回的是什么？超时错误、500、还是一个降级后但仍然有用的结果？
如果答案是超时——你的服务在这种场景下对用户来说也等于挂了。有没有预案：返回缓存数据、返回默认值、返回明确的"该功能暂时不可用"？
预案不需要很复杂，但需要是预先写好的、上线前测试过的。故障发生时现写降级逻辑来不及。
你的重试策略是固定次数还是退避
检查系统里的重试配置。是"失败了立刻重试 3 次"还是"失败了等 1 秒重试、再失败等 4 秒重试、再失败等 16 秒重试"？
前者在下游慢的时候会产生重试风暴——3 倍的请求量打到已经扛不住的服务上。后者给下游留了恢复的时间窗口。
一行配置的区别，但在高负载下可能决定系统是慢还是死。
系统有没有"说不"的能力
当请求量超过处理能力的时候，系统会做什么？是所有请求都接进来然后全部变慢，还是对超出能力的部分快速拒绝？
全部接进来的结果是所有用户都不满意——每个人都等很久。快速拒绝超出部分的结果是大部分用户正常使用，少部分用户收到"稍后再试"。
后者的用户体验实际上更好。但实现它需要系统有显式的容量感知和准入控制——知道自己能处理多少，并且在超过时主动拒绝而不是被动崩溃。