复盘会议必须聚焦问题拦截而非追责，会前需备好可复现traceback、明确时间窗口和最小复现路径；记录须写清故障环节、未拦截原因及卡点方案；验证要跑真实流量并监控重试等副作用。
怎么开才不变成甩锅会
复盘会议不是为了找出谁写的 bug，而是让下次同类型问题能被更早拦截。关键动作是：会前必须有可复现的 traceback、明确的 error 时间窗口、以及至少一个最小复现路径（哪怕只是 curl 命令或一段 requests 调用）。没有这些，会议直接暂停。
常见错误现象：“线上 500 了，大家看看日志？”——这种开场等于没开。日志得先定位到具体服务、实例、时间点，再切片分析。
实操建议：
- 主持人提前用
grep -A 5 -B 5 "Exception" /var/log/app.log提取上下文，贴进会议文档 - 要求每个涉及模块的负责人带一行能复现问题的
python -c "import xxx; xxx.do_something()" - 禁用“我觉得”“可能是因为”，只说“我查了
redis-py==4.6.0在连接超时后不会重试，timeout=2时触发了未捕获的ConnectionError”
哪些信息必须写进复盘记录
不是记谁说了什么，而是记清楚「故障链路里哪个环节失效了、为什么没挡住、下次怎么卡住」。重点不是 what，而是 where failed + why not caught。
立即学习“Python免费学习笔记（深入）”；
使用场景：后续有人遇到类似 TimeoutError，能直接搜到这份记录，对照检查自己是否也漏了 try/except 或配置了过短的 socket_timeout。
实操建议：
- 必须包含：出问题的函数名（如
cache.get_user_profile()）、调用方（如api/v1/order）、依赖服务（如redis://prod-cache:6379） - 必须标注当时生效的配置项，比如
settings.CACHE_TIMEOUT = 30，而不是只写“缓存超时” - 避免模糊描述：“数据库慢” → 改成“
PostgreSQL 14执行SELECT * FROM orders WHERE status='pending'平均耗时从 80ms 升至 2.4s”
怎么判断是不是真改好了
上线后没报错 ≠ 问题修复。Python 线上问题常有“表面恢复、底层恶化”的情况，比如把 requests.get() 包了一层重试，但没设 backoff_factor，结果下游服务被打挂。
性能 / 兼容性影响：加了 retrying 或 tenacity 后，要确认异常类型是否覆盖全，比如 ConnectTimeout 和 ReadTimeout 是两个不同异常，漏一个就白加。
实操建议：
- 验证阶段必须跑真实流量片段，不能只靠单元测试。例如用
tcpdump抓包，确认重试间隔符合预期 - 检查监控曲线：修复后
http_status_code_5xx下降，但同时观察http_client_retry_count是否突增——如果是，说明问题只是被掩盖了 - 在
requirements.txt里锁死版本，比如tenacity==8.2.3，避免 CI 自动升到9.x引入行为变更
为什么开发者总在复盘里沉默
不是不想说，是问题一上来就聚焦在“谁改的代码”，而不是“哪段逻辑缺乏防御”。Python 的动态特性让很多错误只有运行时才暴露，比如 getattr(obj, field_name) 中的 field_name 来自用户输入，没人会在 PR 里意识到它可能为空。
容易踩的坑：把复盘做成代码审查，盯着 if not x: 没加 else，却忽略上游传来的 x 根本没做类型校验。
实操建议：
- 每次复盘固定留 5 分钟，专门问：“这段逻辑如果输入是
None、空字符串、超长字符串、负数，会怎样？” - 把
pydantic.BaseModel或dataclass的校验失败日志接入告警，而不是等AttributeError再追 - 上线前强制跑一遍
python -m py_compile和mypy --check-untyped-defs，不是为了 100% 类型安全，而是把明显松散的边界暴露出来
最常被跳过的一步：复盘记录里没写清楚「下次同类问题发生时，第一眼该看哪个指标、哪个日志关键字、哪个配置项」。那下回还得重新翻三遍 journalctl -u gunicorn。
