Python运维脚本核心要点与最佳实践

写Python运维脚本这事儿，我见过太多人踩坑。去年有个团队，监控脚本跑了半年才发现内存泄漏，每次执行后残留进程像滚雪球一样把服务器拖垮。问题出在哪？他们直接用了os.popen却没关文件描述符，这种细节才是区分"能跑"和"能扛"的关键。

异常处理不是try-except全覆盖

很多人写脚本喜欢套个巨大的try-except块，捕获所有异常然后打印"出错了"。这等于把问题埋进沙子里。更务实的做法是做分层降级：网络超时重试三次，权限不足立即告警，磁盘满则切换备用路径。Paramiko的SSH连接尤其要注意，未关闭的transport对象会在后台吃光句柄配额，生产环境曾见过单台机器被拖出"Too many open files"的惨案。

# 反模式：裸奔的异常处理
try:
    risky_operation()
except Exception as e:
    print(f"错误: {e}")  # 信息丢失，无法追溯

# 更可靠的写法
from functools import wraps
import logging

def resilient(max_retry=3):
    def decorator(func):
        @wraps(func)
        def wrapper(*args, **kwargs):
            for attempt in range(max_retry):
                try:
                    return func(*args, **kwargs)
                except ConnectionError as ce:
                    if attempt == max_retry - 1:
                        logging.error(f"连接失败: {ce}")
                        raise
                    time.sleep(2 ** attempt)  # 指数退避
        return wrapper
    return decorator

配置硬编码是技术债的温床

脚本里写死路径、密码、阈值，三个月后就没人敢动。成熟的方案是用分层配置：环境变量 > 配置文件 > 代码默认值。敏感信息走vault或k8s secret，别往git里塞。有个取巧的做法——用pydantic的BaseSettings，一行代码搞定.env加载和类型校验，比手写configparser清爽得多。

日志要"说人话"，更要"说机器话"

运维脚本的日志是双刃剑。纯文本方便人读，但想接入ELK做聚合分析就抓瞎。推荐结构化日志打底，再套个可读的formatter。Python的structlog库值得投入，它能同时输出JSON给下游系统和带颜色的控制台文本。关键指标务必单独埋点：执行时长、影响行数、资源峰值，这些数据是后续优化的弹药。

测试？当然要做，但得聪明地做

别指望给运维脚本写unittest覆盖率90%，ROI太低。聚焦边界场景：磁盘只剩1%时备份脚本会不会炸？目标进程不存在时监控循环会不会空转？用pytest的tmp_path fixture模拟文件系统，用responses库劫持HTTP请求，这些工具能让测试跑得飞快。真正硬核的是混沌测试——随机kill掉脚本进程，验证它能否从中断处恢复，而不是留下半拉子锁文件。

写到最后想泼点冷水：Python在运维领域的统治地位并非不可撼动。Go编译后的单二进制文件部署更干净，Rust的内存安全对长驻服务更友好。但Python的生态厚度（尤其是Ansible、SaltStack的积淀）短期内难以替代。务实的策略是混合架构——编排层用Python快速粘合，性能瓶颈处埋进Rust扩展。脚本写得再漂亮，能解决实际问题才是硬道理。