Python运维脚本中异常处理的最佳实践？

凌晨三点被电话叫醒排查故障，结果发现是脚本因为一个不起眼的网络超时直接崩溃退出，连个错误日志都没留下——这种痛苦，经历过的人自然懂。运维脚本和普通开发代码最大的区别在于：它们往往在无人值守的环境下运行，面对的是千奇百怪的网络环境和系统状态。一个健壮的运维脚本，异常处理甚至比核心业务逻辑更重要。

拒绝"裸奔"的宽泛捕获

很多初级运维工程师喜欢用 except Exception: 一把梭，觉得这样省事。殊不知这种做法简直是掩耳盗铃。当脚本悄无声息地吞掉了关键错误，你不仅失去了排查问题的机会，更可能让系统处于不可预知的状态。正确的做法是精确捕获具体的异常类型。比如网络请求，应该分别处理连接超时、DNS解析失败、HTTP状态码错误等不同场景，而不是笼统地归为"网络问题"。

让错误信息"会说话"

捕获到异常后，直接打印 str(e) 是远远不够的。一个优秀的运维脚本，应该能在报错时提供完整的上下文信息：哪台主机出了问题？当时正在执行什么操作？关键的输入参数是什么？这些信息对于后续的故障排查至关重要。建议构建结构化的错误日志，包含时间戳、主机名、操作类型和原始错误栈，这样无论是人工排查还是接入日志分析平台，都能事半功倍。

try:
    conn.execute("rm -rf /data/backup")
except paramiko.SSHException as e:
    logger.error(f"[{host}] SSH连接中断，备份失败: {e}", 
                 extra={"host": host, "operation": "backup"})

重试机制的艺术

运维脚本面对的外部环境充满了不确定性，网络抖动、服务暂时不可用是家常便饭。遇到这类临时性故障，直接报错退出显然不够优雅。引入指数退避的重试机制，能大幅提升脚本的鲁棒性。但重试不是无脑循环，需要设置最大重试次数、合理的等待时间，以及区分哪些错误值得重试、哪些应该立即失败。比如文件权限错误就别重试了，重试一万次也是白搭。

资源清理的底线思维

脚本异常退出时，最怕的就是留下烂摊子：临时文件没清理、数据库连接没释放、锁文件没删除。这些问题积累下来，轻则磁盘空间告急，重则导致后续脚本执行失败。try...finally 或 with 上下文管理器不是摆设，它们是保障系统干净整洁的最后一道防线。特别是涉及远程操作时，确保连接一定会关闭，否则僵尸连接会把服务器端口耗尽。

异常处理做得好，凌晨三点睡得着。