线上python服务出问题应先稳日志、查资源、验依赖、复现隔离——核心是快速止血与精准归因；优先分析近5–10分钟error/warning日志，关注底层异常类型、重复错误行及trace_id上下文，同步检查cpu、内存、线程、fd等资源瓶颈，验证外部服务、配置、数据变更一致性，并通过预发环境复现或临时debug日志定位问题。
线上 Python 服务出问题，别急着重启，先稳住日志、定位异常点、验证影响范围——核心是“快速止血 + 精准归因”。
看日志：从 ERROR/WARNING 入手，顺藤摸瓜
日志是第一现场。优先查最近 5–10 分钟的 ERROR 和 WARNING 级别日志，注意时间戳对齐（尤其跨服务调用时）。重点找：
• 堆栈中最底层的异常类型（如 ConnectionRefusedError、KeyError、TimeoutError）
• 频繁重复出现的错误行（可能是循环触发或上游重试导致）
• 日志中带 trace_id 或 request_id 的上下文，方便串联完整链路
建议用 grep -A 5 -B 2 "ERROR" app.log | tail -n 50 快速截取关键片段；若用 ELK 或 Loki，直接按 level + service + time 过滤。
查资源：CPU、内存、线程、连接数是否见顶
很多“逻辑错误”其实是资源瓶颈引发的连锁反应：
• CPU 持续 >90%：可能死循环、正则回溯、未释放的协程（如 asyncio.run() 在循环里反复调用）
• 内存持续上涨：检查是否有全局缓存未设上限、循环引用、日志/响应体过大未流式处理
• 线程数暴涨：常见于同步阻塞调用堆积（如 requests 同步请求无 timeout）、数据库连接池耗尽后新建线程等待
• 文件描述符（fd）打满：Python 默认限制常为 1024，大量短连接或未 close 的文件/Socket 会触达上限（lsof -p PID | wc -l 可查）
验依赖：外部服务、配置、数据变更是否同步生效
约 40% 的线上故障源于“环境不一致”：
• 检查依赖服务（DB、Redis、HTTP API）是否可连通、响应变慢或返回格式变更（比如 JSON 字段突然为 null）
• 确认配置中心下发的参数（如超时时间、开关状态）是否已热更新，有没有被本地 config.py 覆盖
• 查数据库表结构或索引是否刚变更（如字段改 NOT NULL，但代码未补默认值）
• 如果刚发版，用 git diff HEAD~1 -- config/ 或 pip list --outdated 快速比对变更点
复现与隔离：缩小范围，避免盲目改代码
不要在线上修代码。先尝试在相似环境复现：
• 用出问题的请求参数（curl 或 Postman）调用预发/测试环境接口
• 若无法复现，加临时 debug 日志（如 logging.info(f"before_xxx: {vars()}")），用 logrotate 或动态日志等级（如 Python 的 logging.getLogger().setLevel(logging.DEBUG)）控制输出量
• 对疑似模块做最小化隔离：注释非关键分支、mock 外部调用、启用 feature flag 关闭新逻辑
关键是让问题“稳定出现”，而不是靠概率抓包
不复杂但容易忽略。
