全部文章

这一篇从空文件夹开始，把骨架立起来：虚拟环境 → Django 工程 → settings 逐段精讲 → 9 个 app → 核心数据模型 → 整站登录门禁 → 跑通第一个页面。 做完这一篇，你就拥有一个"需要登录、带健康检查、数据库就绪"的空平台。

需求清单有了，这一篇把它翻译成三样东西：一张数据流架构图、9 个 app 的职责边界、 一组关键设计决策（每个都带"为什么选它、放弃了什么"）。设计做到这个颗粒度就够了—— 剩下的细节交给开发时按需决定，过度设计和没有设计一样危险。

写代码之前，先把"我要做一个监控平台"这句话翻译成一张能指导开发的清单。 这一篇不写一行代码，但它决定了后面 11 篇代码的质量——需求想不清，代码全是还债。

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

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

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

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

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

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

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

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

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