Day 02｜小團隊的第一版架構：先做得動，再做得大

決定自己做監控工具後，我打開空白文件，第一個問題不是「要用哪個框架」，而是「公司只有一兩個人維護，這套東西會不會太難養？」如果一開始就放進大型資料庫、訊息佇列和一堆服務，可能功能還沒完成，維護成本就先把人壓垮。因此第一版先把資料怎麼走畫清楚，再挑真正需要的技術。

整條路徑其實很直白：UI → Web Server → HeadlessRuntime → Monitor → WinRM／SSH／HTTP → Storage → UI／Notifier。Python 很適合處理 SSH、PowerShell 和檔案；Web 讓同事不用安裝；Electron 則讓 Windows 使用者有熟悉的桌面入口。

程式入口在 src/Monitor/main.py、headless_runtime.py 與 src/Electron/main.js。先切好責任，未來想換資料庫或加功能時才不會整個重來。

本篇學習重點

• 依小公司的設備與人力選擇不過度複雜的架構。
• 區分設定、儲存、監控、通知與介面的責任。
• 理解單機架構未來可以從哪些邊界逐步拆分。

重點程式碼：由入口組合各層

storage = FileStorage(ROOT)
monitor = Monitor(config, storage, Notifier(config.get("email"), storage))
runtime = HeadlessRuntime(config, storage, monitor, config_path)
server = start_web_server(
    (web_host, int(config.get("web_port", 8080))),
    monitor, config_path, runtime.settings_queue, runtime.refresh_queue,
)

入口只負責組裝，收集、排程、儲存與網頁服務仍各自維持單一責任。

程式碼運作方式

1. FileStorage 先建立統一的資料存取入口。
2. Monitor 接收設定、儲存層與通知器，負責真正的監控流程。
3. HeadlessRuntime 管理排程與背景工作，Web Server 則只負責 HTTP 頁面與 API。

這種寫法稱為組合根：依賴只在入口建立，各模組不需要自行到處建立彼此，因此較容易測試與替換。

實際使用範例

def main():
    config = load_config()
    storage = FileStorage(ROOT)
    monitor = Monitor(config, storage, Notifier(config.get("email"), storage))
    runtime = HeadlessRuntime(config, storage, monitor, CONFIG_PATH)
    server = create_server(config, monitor, runtime)
    server.start()
    runtime.run()

從這個簡化入口可以看到啟動順序，也能清楚指出每個物件的責任與生命週期。

實作時遇到的問題

初版曾把排程、資料收集與頁面回應寫在同一段流程裡。只要其中一台主機連線逾時，整個 Dashboard 就會跟著等待，看起來像程式當機。修復方式是把 Web Server、HeadlessRuntime、Monitor 與儲存層拆開，慢速收集工作改在背景執行。拆層後不只修掉卡頓，也讓我能分別測試各部分，遇到錯誤時更容易判斷問題落在哪一層。

今日心得

今天我確認，小公司的第一版不必龐大，但責任與資料流一定要清楚。下一篇會先整理公司有哪些機台，建立可信任的資產名冊。

連載頁
HardwareMonitor目錄

認識我們
聯繫我們