第 3 章 Shell 脚本与 Python 自动化：高频问答、脚本优化、错误处理、实战案例
本章梳理 Shell 与 Python 脚本在面试中的核心考查点：错误处理策略、性能优化思路、以及自动化场景设计。所有问答均基于真实大厂面试题提炼，附回答框架与避坑提醒。
面试问题 1：Shell 脚本中如何实现可靠的错误处理？
| 面试官考察点 | 是否具备生产环境脚本编写经验；能否预判常见异常并设计降级策略。 |
|---|
| 回答框架 |
- 设置
set -e 和 set -u 让脚本在出错时立即退出。
- 使用
trap 捕获 ERR/EXIT 信号，执行清理或记录日志。
- 对关键命令检查返回码，并配合
|| 或 if 实现分支处理。
- 输出标准化的日志格式（时间戳 + 级别 + 信息）。
|
|---|
| 简短示例回答 | 我会在脚本开头执行 set -euo pipefail，然后通过 trap 'log_error $LINENO' ERR 捕获每行错误。对于可能失败的命令（如 curl），使用 if ! curl ...; then echo "失败" >&2; fi 单独处理，确保不会阻塞整体流程。 |
|---|
| 可能追问 | 如果要用 trap 同时处理多个信号怎么办？set -e 在管道中的表现？如何实现错误恢复（重试）？ |
|---|
| 避坑提醒 | ⚠ 不要滥用 set -e 导致隐蔽错误；管道命令建议加 || true 避免误退出；日志中必须包含行号便于排查。 |
|---|
面试问题 2：如何优化一个执行缓慢的 Python 脚本？
| 面试官考察点 | 是否具备性能分析和优化方法论；能否区分 I/O 瓶颈和 CPU 瓶颈。 |
|---|
| 回答框架 |
- 使用
cProfile 或 timeit 找出热点函数。
- 区分 I/O 密集型（用多线程/异步）和 CPU 密集型（用多进程/C扩展）。
- 优化数据结构：List 转 Set、字典代替遍历、使用
collections.deque。
- 减少不必要的函数调用、循环内避免重复计算。
- 利用内置函数（如
map、filter）和第三方库（如 pandas 向量化）。
|
|---|
| 简短示例回答 | 先用 python -m cProfile slow.py 定位到瓶颈在文件读写，于是改用 io.BufferedReader 并按行缓存；同时将循环中的正则预编译为 re.compile，最终耗时降低 70%。 |
|---|
| 可能追问 | 多线程与多进程的适用场景？GIL 对性能的影响？用 asyncio 时要注意什么？ |
|---|
| 避坑提醒 | ⚠ 优化前先做测试，避免过早优化；多线程 I/O 注意文件锁；异步代码中不要阻塞事件循环。 |
|---|
面试问题 3：写一个自动化部署脚本，你会如何设计？
| 面试官考察点 | 设计能力、模块化思维、异常处理、幂等性意识。 |
|---|
| 回答框架 |
- 分阶段：环境检测 → 备份 → 推送包 → 部署 → 健康检查 → 回滚策略。
- 每条命令增加返回码校验，失败时记录日志并停止/重试。
- 使用配置文件管理服务器列表和参数，避免硬编码。
- 脚本支持
--dry-run 模式预览执行。
|
|---|
| 简短示例回答 | 我会用 Python 写一个 deploy.py，借助 fabric 库远程执行；先校验本地包完整性，再备份目标目录，同步文件后执行启动命令，最后用 requests 轮询健康检查端点；若失败自动调用回滚脚本。 |
|---|
| 可能追问 | 如何保证幂等性？如果只有 3 台机器可用，如何控制并发？日志怎么统一收集？ |
|---|
| 避坑提醒 | ⚠ 不要在脚本中直接修改生产环境；所有敏感信息（密码、密钥）通过环境变量或 secrets 管理；部署前一定要模拟验证。 |
|---|
📁 项目案例：大规模服务器日志自动采集与清洗系统
| 业务背景 | 公司管理 200+ 台 Linux 服务器，每天产生 50GB+ 应用日志，需要实时采集、去重、清洗后写入 Elasticsearch 用于监控分析。 |
|---|
| 规模指标 | 200 台服务器，日均日志量 50GB，目标延迟 ≤5 分钟。 |
|---|
| 技术栈 | Shell + Python 3 + rsync + logrotate + Elasticsearch + crontab + systemd timer |
|---|
| 核心难点 |
- 网络波动导致采集丢包或重复
- 大量小文件造成 inode 压力
- 清洗规则变更时需热加载
|
|---|
| 面试高频追问 |
- 如何保证采集的可靠性（端到端确认）？
- 日志切割策略怎么设计？
- 如果 ES 集群挂了，采集到的日志怎么暂存？
- 如何监控采集脚本本身是否正常运行？
- 为什么选择 rsync 而不是 scp？
|
|---|
| 可迁移回答话术 | “在类似场景中，我会先设计幂等性采集：采集脚本记录已传输的文件偏移量，重拾时从断点开始；同时采用双缓冲目录，写入完成后再移入采集队列。对于清洗逻辑，利用 watchdog 监听规则文件变化实现热加载。监控方面，在 crontab 中额外发心跳到独立的健康检查 API。” |
|---|
💡 面试加分技巧：在回答脚本相关问题时，主动提及“幂等性”、“自愈”、“可观测性”三个关键词，能明显提升技术成熟度。例如：“我设计的脚本在重跑时不会产生重复数据；在执行中能自动重试临时故障；并提供详细日志和 metrics 供监控。”