Tools mentioned in this article
Open the browser-based tool while you read and try the workflow immediately.
那種似曾相識的恐懼感
「嘿，我們是不是在 API 伺服器前面又加了一台 RabbitMQ 啊？」
當團隊裡比較資淺的成員在會議上不經意地指出這點時，我整個人背脊都涼了。貼在我們內部 Wiki 上的架構圖正冷冷地看著我，上面那鮮明的「最後更新時間」竟然停留在半年前。
老實說，基礎架構是每天都在變動的東西。今天在這邊加一個 Redis 快取，明天在那邊多個反向代理。但是，要打開笨重的圖形軟體，拖曳小方塊圖示，痛苦地對齊箭頭，匯出成 PNG 檔，再上傳到 Wiki… 這整個過程的阻力實在太大了。每個人都想著「我待會一定會把這張圖更新」，但結果當然是誰也沒去做。
渴望「架構圖即程式碼 (Diagram as Code)」
為了解決這個「永遠都會過期」的系統架構圖問題，我把目光轉向了 Mermaid.js。「架構圖即程式碼」的概念簡直是開發者的夢想：你只要打幾行字，將它提交到 git，一張漂亮的架構圖就會像施了魔法般自動產生。
但要在本地環境做到這點還是有些脾氣要克服。試圖撰寫複雜的巢狀結構（像是將 EC2 畫在 VPC 裡面，而 VPC 又包在 AWS Cloud 區域之類的）需要去學一套不是那麼直覺的語法。以前我寫好程式碼後，還得等 PR 預覽部署完畢，才發現我畫的箭頭全指向了反方向。
看著架構圖在敲鍵盤間自動成形
「我只是想要打字，並且看著螢幕另一邊的系統圖能夠即時、滑順地建立起來而已。」
這個完全出於私心的願望，催生出了這款「基礎設施架構圖產生器」。
在打造這項工具時，我最大的鐵律就是：零伺服器傳輸。基礎架構配置說穿了就是公司的金庫設計圖，我絕對不可能讓你把這份機密貼到一個會把資料送到某台隨機伺服器（即使那是「我自己」的隨機伺服器）的工具上。因此，我強制將整個圖形渲染引擎全部塞進瀏覽器端本地的 JavaScript 裡。
如果你現在對更新基礎設施文件感到恐懼，試試看在這個工具裡寫一點程式碼吧。看著架構圖瞬間就定位，會帶給你一種詭異卻非常滿足的「終極架構師力量」的錯覺。
最後能持續下去的，是「輕量」
做完之後我更加確定一件事：架構圖會過期，原因不在於語法難，而在於「更新很麻煩」。只要中間夾了一道儀式——打開笨重的工具、重新排列圖示、匯出、再上傳——人們就會選擇「待會再說」，而那個「待會」永遠不會來。
所以這個工具的首要目標變成了「想到的瞬間就打開，五秒內就能改好」。節點名稱保持簡短，線只畫主要流向，節點超過十個就依角色拆成多張圖。這種程度的輕量，才是真正能持續下去的關鍵。一張雖然粗糙但持續更新的圖，勝過半年前那張完美的圖——持續更新的那張，才能拯救半年後的你。
常見問題
不懂 Mermaid 語法也能使用嗎？
可以。你只要逐一加入節點與連線，Mermaid 程式碼就會在背後自動生成。不需要記語法也能畫出架構圖，並且可以把生成的程式碼直接複製到 GitHub 的 README。
我輸入的基礎架構會被傳送到外部嗎？
不會。渲染完全在你本地的瀏覽器內完成。由於把公司的基礎架構配置送到外部伺服器風險太高，這個工具從一開始就設計成資料絕不離開你的電腦。
畫好的圖能在 GitHub 的 README 顯示嗎？
可以。GitHub 原生支援渲染 Mermaid 流程圖，因此你能以「文字」而非「圖片」的方式管理架構圖，並像程式碼一樣在 Pull Request 中追蹤變更。
節點很多的大型架構圖該怎麼畫？
與其全部塞進一張，建議依角色（網路／應用程式／資料／監控）拆分。節點約十個是拆分的好時機。不要塞得太滿，圖才更容易長期維護。