分类：架构与运维

先看成品，再决定要不要花时间跟着做——这是最负责任的学习方式。

脚本写完、测试过了，最后一公里是交付：同事的机器上没有你的目录结构，怎么让他一行命令用上你的工具？这篇讲 Python 标准库自带的答案——zipapp，把整个项目打成一个 .pyz 文件，拷贝即用。

运维脚本常被当成「跑一次就扔」的一次性代码，但现实恰恰相反：巡检、清理、守护脚本一跑就是几年，改一次阈值、换一个路径，都可能悄悄改坏一个你从没测过的分支。这篇给系列的监控脚本（01 篇的 monitor.py）补上测试防线，顺带演示完整的 TDD 流程——测试先写、先跑、先看它失败。

dev、staging、prod 三套环境，配置 90% 相同——端口、内存、域名、日志级别各不相同。新手做法是三份文件复制粘贴，改一个全局参数要改三处，漏一处就是一次「为什么测试环境好好的，一上线就挂」。

05 篇的 TCP 体检能回答「端口活着吗」，但回答不了「内存还剩多少」「那个进程跑起来没」。这些答案在机器里面，得登录进去看。

前几篇攒下的工具——日志分析、磁盘清理、健康检查——都有一个共同宿命：不能总靠人手敲。这篇讲定时调度，把「每天/每小时/每五分钟跑一次」交给机器。

一台机器用 01 篇的脚本盯，十台机器就不能一台一个窗口了。这篇写一个批量健康检查器：并发探测一批 host:port，几秒钟出一份体检报告——谁活着、谁挂了、挂的姿势是什么。

凌晨两点服务挂了，早上八点才知道——这种事故的根因不是服务太脆，而是没有东西在看着它。这篇写一个进程守护脚本：发现进程、观测指标、检测掉线、自动拉起，全流程走通。

磁盘满是最经典的运维事故：涨得慢、没人盯、爆发时整个服务跟着殉葬（日志写不进去、数据库落不了盘）。01 篇的监控负责「发现磁盘快满了」，这一篇负责「安全地清理」——重点是那个词：安全。

出事之后第一件事是查日志，但现实往往是：日志文件几个 G，文本编辑器打开直接卡死；findstr / grep 能搜，但「错误率多高」「哪个接口错得最多」这类统计问题就不是一行命令的事了。这篇就写一个流式日志分析工具：几个 G 的文件也能稳稳跑完，内存占用恒定。

运维日常里有一大类活儿，本质是「重复 + 有明确判断标准」：每天看一眼 CPU、内存、磁盘；日志满了要清；服务挂了要发现。这类活儿交给 shell 脚本也行，但 Python 有三个实在的优势：