資訊文件化真的很重要。
雖然許多人覺得撰寫文件很花時間，平常也用不到。但當意外發生，需要查找相關資訊時，完整的文件就能發揮關鍵作用，讓我們快速定位問題。
案例分享：消失的 Gateway
最近遇到一個案例，某一天早上一進公司，公司同事就回報，外部人員無法連線回公司的系統。
盤點後發生，外網進入系統的 Gateway IP 突然失效的狀況，導致整個外部網路完全無法訪問。
要命的是，當下完全不知道對應 IP 的防火牆或主機的所在位置在那？是那一台？
在實際的場域環境中，網路架構橫跨多個樓層，串連了無數的交換器、Router 與防火牆。
錯綜複雜的線路，讓問題的盤查與定位變得極為困難。
尋找答案的困境
在這種情況下，最直接的方式是詢問當初參與架構設計的人員，或是查找網路架構的規劃文件。
巧合的是當初參與的人員已經離職，而且手邊也只有殘缺的規劃架構文件。
但如果這兩者都不存在呢？我們就只能投入額外的人力與時間，大海撈針般地逐一盤查，不僅延長了問題的排除時間，也對營運造成更大的衝擊。
如何開始文件化？三個起步行動
抱怨歸抱怨，但究竟該如何開始補救呢？其實建立系統文件不需要在一開始就寫出完美的手冊，可以從這三個小步驟開始：
- 先畫出核心拓樸圖：文字難懂，但一張標示著關鍵 Server IP、Gateway 與防護牆連線關係的架構圖，能在第一時間救你一命。
- 尋找統一的存放地：無論是 Notion、Confluence 還是簡單的 HackMD，重點是讓「所有團隊成員」都知道去哪裡找，而不是散落在各自的 D 槽或 LINE 記事本中。
- 將更新納入發布流程 (SOP)：文件最怕過期。把「更新文件」當作每一張 Ticket 完結或是上線部署前必經的 Checking list，讓文件與系統同步。
簡單總結
這次的經驗再次凸顯了資訊文件化的重要性。
它不只是一項「有空再做」的工作，而是團隊知識傳承與系統穩定性的基石。
事先投資時間建立清晰的文件，遠比事後花費數倍心力補救來得更有價值。
而且隨著 AI 的快速發展，資訊文件化的門檻值會越來越低，也越發的重要。
舉例來說，你現在完全可以把架構設定或邏輯說明丟給 ChatGPT，請它提煉出文件內容，或是直接生成 Mermaid 語法的網路拓樸圖。技術在進步，我們管理知識的作法也該跟上。
💡 互動時間 你們公司的網路架構文件還在嗎？還是也曾遇過找一台 Switch 找了半天的查修噩夢？歡迎在下方留言分享你的維運血淚史！
💬 留下你的想法
有問題、不同看法，或是你踩過類似的坑？歡迎留言討論，我會盡量回覆。