接手陌生機器的盤點：先讀清楚它在跑什麼

Fri, 03 Jul 2026 00:00:00 +0000

這篇處理的情境跟本系列其他篇相反：機器已經裝好、已經在跑，裝它的人可能已離職、可能只留下一句「都在上面了」。系列主線教你把一台空機器變成能跑活的機器；這篇教你把一台「不知道在跑什麼的機器」變成「盤點清楚、敢動手維護的機器」。對照 infra 樹，這篇是拿到雲端帳號的第一天的 OS 層對等篇——那篇盤點的是雲端帳號裡有什麼資源，這篇盤點的是單一台 Linux 機器裡有什麼狀態。

核心紀律只有一條：盤點期間只讀不改。這跟診斷心法的「讀權威狀態」是同一個紀律的不同應用——診斷是出問題後讀狀態找根因，盤點是還沒出問題時讀狀態建立現況清單。改動留到盤點完成、你能回答「這台機器停掉會影響誰」之後。本篇所有指令都是唯讀查詢，照著跑不會改變機器狀態；少數需要 root 權限的會標明。

盤點的產出是一份清單，建議直接開一個文字檔邊查邊記。這份清單之後會變成把機器收斂進版本控制的依據——terminal 捲動紀錄留不住，清單留得住。

這台是什麼機器

盤點的第一層是機器的身分：發行版、架構、實體還是虛擬、活多久了。這層決定後面每一步用什麼指令——套件管理器、服務管理方式、log 位置全由發行版決定，判讀邏輯見平台與發行版差異的判讀地圖。

1cat /etc/os-release        # 發行版與版本
2uname -a                   # kernel 版本與架構（x86_64 / aarch64）
3systemd-detect-virt        # 虛擬化偵測：kvm / vmware / none（實體機）
4uptime                     # 活多久、負載
5hostnamectl                # 主機名與上面幾項的整合視圖

uptime 的天數是一個重要訊號：跑了四百天的機器代表它從沒被重開驗證過——上面的服務能不能在重開機後自己回來，沒人知道。這會影響你後面對「開機自啟清單」那段的重視程度。

誰能進來

第二層是存取面：有哪些帳號、誰有 sudo、誰的 key 被授權登入。接手的機器上常有前人留下的帳號與 key，這些是你動手維護前必須知道的存取路徑——不知道誰能進來，就無法判斷一個改動是不是「只有你會做」。

 1# 有登入 shell 的帳號（排除 nologin / false 的系統帳號）
 2grep -vE '(nologin|false)$' /etc/passwd
 3
 4# 誰有 sudo：主檔 + drop-in 目錄都要看（需要 root）
 5sudo cat /etc/sudoers
 6sudo ls /etc/sudoers.d/ && sudo cat /etc/sudoers.d/*
 7
 8# 每個真人帳號的 SSH 授權 key
 9cat ~/.ssh/authorized_keys
10sudo cat /home/*/.ssh/authorized_keys
11
12# 最近誰登入過
13last -20

authorized_keys 每行結尾的 comment（通常是 user@hostname）是判斷 key 主人的線索。無法對應到在職人員的 key 記進清單——盤點期間先不刪，但接管後的第一批改動應該包含輪替它們。sudoers 的 NOPASSWD 條目也記下來：它可能是前人為無人值守任務設的，判斷它還需不需要存在的依據見讓機器跑無人值守的長任務對這個取捨的展開。

跑什麼服務、誰開機自啟

第三層是這台機器的「工作內容」：現在跑著哪些服務、重開機後哪些會自己回來。這兩份清單常常對不上，而對不上的地方就是接手後的地雷。

1# 現在在跑的服務
2systemctl list-units --type=service --state=running
3
4# 開機會自啟的（不只 service，也含 socket / timer）
5systemctl list-unit-files --state=enabled
6
7# 各使用者層的 user unit（--user 屬於各帳號、root 看不到全部）
8systemctl --user list-units --type=service --state=running
9ls /home/*/.config/systemd/user/ 2>/dev/null

兩份清單的差集各有含義。在跑但沒 enable 的服務，重開機就消失——它可能是有人手動 systemctl start 起來忘了 enable，也可能本來就該臨時。enable 了但沒在跑的服務，代表它啟動失敗過或被手動停掉，systemctl status 看它最後的狀態與退出原因。

systemd 之外還有一塊盲區：直接被人手動跑起來、或掛在終端機多工器 session 裡的長期進程。ps aux 全列太吵，用兩個角度收斂：

1# 不是從 systemd 起的長期進程：看父進程鏈
2ps -eo pid,ppid,user,etime,comm --sort=-etime | head -30
3
4# 有沒有掛著的 tmux / zellij / screen session（要逐一以各使用者身分查）
5tmux ls 2>/dev/null; zellij list-sessions 2>/dev/null

etime（運行時長）長但不在 systemd 清單裡的進程，多半是手動起的。掛在多工器 session 裡的服務是最脆的一種——機器重開就沒了、也沒有任何監控。判斷一個進程「活著」與「由誰提供」的精確方法（pgrep 的比對陷阱、busctl 查註冊表），見程序、服務與狀態怎麼判。

排程任務藏在哪

第四層是排程：機器在沒人操作的時段自己做什麼。排程任務散落在多個落點，漏看一個就會在某天凌晨被一個「不知道哪來的」任務嚇到。

 1# systemd timer（現代發行版的主要排程方式）
 2systemctl list-timers --all
 3
 4# cron：每個使用者各有一份 + 系統層多個目錄
 5sudo ls /var/spool/cron/ && sudo crontab -l -u    # 逐一查每個使用者
 6cat /etc/crontab
 7ls /etc/cron.d/ /etc/cron.daily/ /etc/cron.weekly/ /etc/cron.monthly/ 2>/dev/null
 8
 9# at 佇列（少用但存在）
10atq 2>/dev/null

每條排程記三件事：跑什麼、多常跑、失敗了會怎樣。第三件通常沒有答案——cron 任務失敗預設只寄 local mail、沒人會看。這是接管後值得優先補的洞，補法見下面「有沒有在監控自己」段。

對外開了什麼

第五層是網路面：哪些 port 在聽、對誰開放。listening port 清單是「服務清單」的交叉驗證——一個在聽 port 的進程如果不在你前面盤出的服務清單裡，就是盤點有漏。

1# 在聽的 TCP / UDP port 與對應進程（-p 需要 root 才看得全）
2sudo ss -tlnp
3sudo ss -ulnp
4
5# 防火牆狀態：依發行版可能是其中一種
6sudo nft list ruleset 2>/dev/null | head -50
7sudo iptables -L -n 2>/dev/null | head -30
8sudo ufw status 2>/dev/null; sudo firewall-cmd --list-all 2>/dev/null

判讀時把 listen address 分成三類：127.0.0.1 只服務本機、0.0.0.0（或 *）對所有介面開放、特定 IP 只綁那個介面。對外開放又不認得的 port 優先查——ss -tlnp 輸出的進程名回頭對服務清單。防火牆四個指令會有幾個查無結果，這正常：發行版各用不同框架，有輸出的那個才是這台在用的。

裝了什麼

第六層是套件面：哪些是刻意裝的、哪些繞過套件管理器直接放進系統。這份清單是之後重建這台機器的素材——模組八的 bootstrap 套件清單假設你知道要裝什麼，接手的機器上這份「要裝什麼」得反向盤出來。

 1# Arch：明確安裝的（排除被依賴帶進來的）
 2pacman -Qe
 3# Debian / Ubuntu
 4apt-mark showmanual
 5
 6# 繞過套件管理器的落點
 7ls /usr/local/bin/ /opt/ 2>/dev/null
 8
 9# 語言層的全域安裝
10pip list --user 2>/dev/null; npm ls -g --depth=0 2>/dev/null

/usr/local/bin 與 /opt 是重點：套件管理器查不到來源的執行檔，只能靠檔名、--version、跟 strings 猜用途。這些手放的檔案在重裝時最容易遺失——記進清單時同時記「它被哪個服務或排程用到」，孤兒檔案接管後可以清。

設定與 secret 落在哪

第七層是設定面：改過哪些系統設定、secret 放在哪裡。這層決定「這台機器能不能被重建」——服務跟套件都能重裝，改過的設定跟 secret 沒盤到就永遠丟了。

 1# /etc 下最近被改過的檔案（排 mtime、抓人為改動的痕跡）
 2sudo find /etc -type f -mtime -365 -newer /etc/hostname 2>/dev/null | head -30
 3
 4# systemd unit 的 drop-in 覆寫（前人客製服務行為的常見落點）
 5sudo find /etc/systemd/system -name "*.conf" -path "*.d/*"
 6
 7# 常見 secret 落點（唯讀列出、內容先不看）
 8ls -la /home/*/.env /home/*/*/.env 2>/dev/null
 9ls /home/*/.ssh/ /root/.ssh/ 2>/dev/null
10ls /home/*/.config/rclone /home/*/.aws /home/*/.docker 2>/dev/null

/etc 的 mtime 掃描是啟發式——套件更新也會動 /etc，輸出要人工過濾，但它能把「前人改過設定」的範圍從整棵樹縮到幾十個檔案。家目錄的 dotfile 另外看一件事：ls -la ~ | grep '\->' 檢查有沒有 symlink 指向某個 repo——有的話代表前人用 stow 之類的工具管理過設定，找到那個 repo 等於找到大半份文件。secret 的判讀與收斂策略（哪些能進 repo、哪些只能佔位）見同步策略與 secret 管理。

有沒有在監控自己

第八層是監控面：這台機器的服務掛掉時，有沒有人會知道。接手的機器常常答案是「沒有」——前人肉眼盯著，前人走了就沒人盯。

1# 各服務有沒有掛 OnFailure 告警鉤子
2systemctl show sshd -p OnFailure
3for u in $(systemctl list-unit-files --state=enabled --type=service --no-legend | awk '{print $1}'); do
4  echo "$u: $(systemctl show "$u" -p OnFailure --value)"
5done
6
7# 有沒有對外心跳（heartbeat timer、healthcheck 打點）
8systemctl list-timers | grep -iE 'heart|health|canary'

輸出全空代表這台機器掛了不會通知任何人。盤點階段先記錄現況；接管後從最簡單的 OnFailure + 推播建起——至少把 sshd 掛上，它掛了機器就失聯。整套從零建法見服務掛了怎麼自動知道。

盤點完之後

清單在手，用一個問題檢驗盤點品質：「這台機器現在消失，我能靠這份清單把它重建出來嗎？」 答不出來的段落回去補。能答之後，接手工作分兩條線走：

收斂進版本控制：把盤出來的套件清單、設定改動、服務定義逐步收進 repo，讓機器狀態從「只存在於這台機器上」變成「可從 repo 重現」。這是模組零講的心智模型應用在接手情境——差別在素材從盤點來、不是從零設計。
補監控與補文件：監控空白的服務掛 OnFailure、無人知道的排程補失敗告警、盤點清單本身放進 repo 當文件。

機器在雲端的話，OS 層盤完還有帳號層——這台 instance 是誰開的、掛在哪個 VPC、security group 開了什麼，見 infra 的接手維運模組。盤點過程中發現已經在壞的狀態（服務起不來、連線異常），從盤點模式切到除錯模式，入口是診斷心法。

Inventory on Tarragon