标准答案
- 先说明 P99、错误率、CPU、event loop lag、Task/线程、内存和连接池指标。
- 区分计算热点、阻塞库、取消失效、连接泄漏、下游慢和重试放大。
- 止血可以限流、降级、隔离 executor、回滚或重启异常 worker，但要保存任务和业务状态。
- 修复后验证并发、尾延迟、资源释放、重复副作用和数据对账。
题目解析
复述事故时先讲用户影响和时间线，再讲证据：P99、错误率、CPU、RSS、event loop lag、线程/Task 数、连接池等待和下游延迟。在默认带 GIL 的 CPython 构建中，同一解释器里的 Python 字节码不能由多个线程并行执行，但 I/O 等待和部分释放 GIL 的 C 扩展是另一种情况；free-threaded 构建还要单独核对扩展兼容和锁成本，因此不能用“有 GIL”直接解释所有延迟。
asyncio 通过协作式切换运行，某个 Task 执行长时间 CPU 计算或同步阻塞调用时，同一事件循环上的请求都会受影响。多进程可以利用多个核心，但会增加内存、连接池、部署和数据共享成本；多线程适合一部分阻塞 I/O，却仍要考虑共享状态和下游容量。
完整的事故答案还要说明止血动作及其副作用：限流、隔离执行器、暂停重试、降级或回滚如何保护下游，未完成任务如何恢复，写操作如何幂等。最后用压测、监控和数据对账证明修复确实消除了尾延迟和重复副作用。
常见误区
- 误区：一句“Python 有 GIL，所以只能多进程”解释所有并发问题。改正：区分 Python CPU、I/O、C 扩展、事件循环阻塞和下游资源瓶颈。
- 误区：事故中只重启实例，不保留现场。改正：先记录时间线、栈、资源和请求样本，再采取有边界的重启或回滚止血。
- 误区：只谈取消和重试，不说明业务幂等。改正：说明任务恢复、重复副作用、幂等键或对账如何闭环。