Supervisor把崩潰重啟做成自動檔，運維凌晨3點終于能睡了

凌晨2點47分，你的WebApp又掛了。監控告警炸響，你從床上爬起來SSH登錄，手動重啟服務——這個月第幾次了？

有個老工具能把這套流程壓縮成5秒。它叫Supervisor，2004年誕生，比Docker還早9年，至今仍在無數生產環境值班。

Supervisor不是守護進程本身，而是"制造守護進程"的工廠。它像機場塔臺：飛機（你的應用）起降它不管，但飛機要是墜毀，它會立刻調一架新的頂上。

裝完即走：一條命令解決依賴

Debian/Ubuntu系直接apt：

apt install supervisor

裝完自動注冊為系統服務，開機自啟。沒有復雜的二進制下載，沒有版本沖突，包管理器幫你兜底。

核心組件就兩個：supervisord（后臺主進程）和supervisorctl（命令行遙控器）。前者盯梢，后者讓你隨時查狀態、啟停服務。

配置解剖：6行代碼定義"自愈"規則

假設你的WebApp已編譯好，先丟進系統目錄：

cp WebApp /usr/local/bin/

然后寫配置文件，路徑固定為/etc/supervisor/conf.d/webapp.conf：

[program:webapp] command=/usr/local/bin/webapp user=www-data autostart=true autorestart=true

關鍵就最后兩行：autostart=true讓機器開機自動跑，autorestart=true讓崩潰自動復活。user=www-data降權運行，避免應用被攻破后拿到root。

日志配置同樣重要。stdout_logfile和stderr_logfile分開存，各50MB上限、保留3個輪替文件。既防磁盤爆滿，又方便事后翻案。

生效流程：reread和update的區別

改完配置別急著重啟，Supervisor有熱加載機制：

supervisorctl reread —— 只掃描文件變化，不碰運行中的進程 supervisorctl update —— 真正應用變更，新增/刪除/重載配置

兩步分開的設計很產品經理思維：reread讓你預覽改動，確認無誤再update。線上環境改崩過配置的人都懂這有多救命。

最后啟動：supervisorctl start webapp，查狀態：supervisorctl status webapp。輸出格式跟systemctl幾乎一樣，遷移成本極低。

Supervisor和systemctl不是二選一。前者管應用層保活，后者管系統級服務。很多團隊兩者混用：Nginx走systemctl，自研WebApp走Supervisor，崩潰重啟策略更靈活。

有個細節很多人踩坑：Supervisor監控的是進程PID，如果你的應用fork出子進程后父進程退出，Supervisor會誤判為"已停止"然后瘋狂重啟。解決方法是配置startsecs=10，給足啟動緩沖期。

另一個隱藏技能是進程組（group）。把API服務、隊列消費者、定時任務寫進同一個group，可以一鍵啟停整組服務，部署時特別順手。

2019年Supervisor 4.0終于支持Python 3，社區一度以為項目已死。但它就像那些老舊的機場塔臺系統——不好看，不時髦，但航班（你的服務）從來沒掉下來過。

你的生產環境還在用手動重啟嗎？還是已經上了Kubernetes這類重型方案，卻為了一個小腳本也要寫20行YAML？