最近聊到的一些 DevOps 大坑...真的學到很多
最近在一些國外的技術論壇和 LinkedIn 上，看到一個蠻有趣的話題：「你犯過最大的 DevOps 錯誤是什麼？」 結果釣出一堆資深工程師、架構師的血淚告白。我邊看邊做筆記，發現有些模式一直重複出現，看完真的會改變你對工作的看法。這些東西學校老師不教，但真的超重要。
重點一句話
我發現，那些最慘痛的錯誤，往往不是程式碼寫錯一行或某個指令下錯，而是更根本的職涯選擇、團隊迷思，還有對工具的心態問題。技術問題通常有解，但這些「軟問題」才是最磨人的。
那些血淋淋的案例，每個都像一面鏡子
我把看到的幾個經典案例整理了一下，真的，每個都值得想一下。
案例一：「我以為當主管就不用寫 Code 了」
有個在大公司當到管理職的 DevOps 主管分享，他最大的職涯錯誤，就是晉升後有整整 12 年沒再親手寫程式。他以為管人、管流程、畫架構圖才是主管的價值。結果...現在想回頭追上新的技術，像是 IaC [Infrastructure as Code]、容器化這些，覺得自己跟不上，非常痛苦。
他的建議很實在：就算當到主管，每週至少還是要擠出 3、4 個小時寫點東西。不一定要是核心產品，寫點自動化腳本、玩玩新工具都好。我自己是覺得，在 DevOps 這個領域，技術的觸感太重要了，一放掉，很快就生疏。你沒辦法真正理解團隊成員在蓋什麼，以及他們為什麼會卡關。
案例二：微服務，從時髦變災難
「微服務很好玩，直到它變成一場基礎設施的戰爭罪行。」這句話真的太經典。一個醫療科技公司的 DevOps lead 說，他最大的錯誤就是因為「聽起來很現代」，就把一個運作得好好的單體應用（Monolith）硬是拆成微服務。
這個問題引起超多共鳴。很多人是為了讓履歷好看，所謂的「履歷驅動開發」(Resume-Driven Development)，而不是真的為了解決商業問題。我看到有人分享，他們為了一個只有幾千個用戶的應用，搞了 70 多個微服務，結果維運成本高到爆炸，團隊每天都在救火，現在又痛苦地想辦法把服務合併回去。所以說，無聊的技術有時候才是最好的技術。
案例三：我到底是工程師，還是 AI 的詠唱師？
這點現在吵很兇。有個 18 年經驗的資深工程師承認，他現在幾乎不從零開始寫 code 了。AI 程式碼助理幾分鐘能產出上千行程式碼，以前可能要花他好幾天。但他也開始懷疑：「我是不是漸漸忘了怎麼像個工程師一樣思考？」
這不是個案，很多人說現在他們有三到五成的程式碼是 AI 產的。這效率很高，但副作用就是，遇到問題的第一反應不再是深入理解系統，而是想辦法把問題描述給 ChatGPT。有人反駁說，頂尖的工程師是把 AI 當作槓桿，省下的時間拿去思考更高層次的架構和問題。嗯...我自己覺得，這就像開車，你可以用導航，但你最好還是要知道東南西北，不然導航壞了你就完了。
那到底怎麼做比較好？
看了這麼多失敗案例，總要來點實際的。特別是微服務這個點，很多人都想知道那個「度」在哪裡。我整理了一個簡單的比較表，但記得，這不是絕對的聖經，只是個思考框架。
| 考量點 | 單體式架構 (Monolith) | 微服務架構 (Microservices) |
|---|---|---|
| 團隊規模 | 小團隊（例如 2-10人），溝通快，大家都在同一個 code base 上工作很方便。 | 大團隊或多個獨立小隊。可以切分權責，A 隊專心搞定用戶服務，B 隊專心搞定支付服務。 |
| 業務複雜度 | 初期、還在驗證市場的產品。功能單純，全部包在一起開發最快，先求有再求好。 | 業務超複雜，不同模組有完全不同的效能/安全需求。例如電商的核心交易跟後台報表，就可以分開。 |
| 部署頻率 | 可以接受全部服務一起更新。改一個小按鈕，整個網站都要重新部署一次。 | 需要極高彈性，不同功能要能獨立、快速上線。A/B 測試新功能超方便，反正只影響一個小服務。 |
| 維運成本 | 相對低。就一個應用程式要監控、要管，單純多了。 | 媽呀，超複雜。每個服務都要獨立部署、監控，掛了一個你還得像偵探一樣找是誰的鍋。網路延遲、服務發現...一堆新問題。 |
| 技術選項 | 比較受限。一旦選了 Java，整個專案大概就是 Java 到底了。 | 超自由！用戶服務用 Go 寫追求高效能，數據分析服務用 Python 寫方便接機器學習函式庫。 |
| 一句話建議 | 除非你痛到不行，不然就先用這個。簡單就是美。 | 確定你的問題大到值得用這麼複雜的解法再來碰。不要為了用而用。 |
幾個常見的迷思與修正
除了架構選擇，還有一些日常工作中的坑，感覺更像心態問題。
自動化的陷阱：不是什麼都能自動化
這點超反直覺。有個架構師花了兩週去自動化一個流程，但那個流程一季才跑一次，手動跑也才 30 分鐘。結果六個月後那個自動化腳本壞了，他又花了一整天去修。算下來，他手動跑好幾年的時間，都沒他搞自動化花的時間多。
這就是「自動化悖論」。很多老鳥的建議是，除非一件事「頻繁、耗時、容易出錯、或跟安全合規高度相關」，不然手動做就好。有個「三次法則」蠻實用的：一件事情你手動做了三次以上，覺得很煩，再來考慮自動化。那時候你對流程也夠熟了。
文件誰來寫？當然是你自己啊
「我最大的錯，就是以為文件是別人該寫的工作。」一個顧問這樣說。他蓋了很多漂亮的系統，但等他一走，沒人知道怎麼維護，因為沒有文件。過來人的血淚建議是：「寫文件的時候，要想像半年後那個完全失憶的你，會回來看這份文件。」
說真的，好的團隊會把文件當成系統的一部分，甚至搞「文件即程式碼」(Documentation-as-Code)，讓文件跟程式碼一起被 review、一起被版本控制。這才是長久之計。
求職的現實：400 次投遞 vs 聰明的方法
有個工程師分享他找工作的經歷，海投了 400 份履歷，結果只有 8 個面試，一個 offer 都沒有。後來他改變策略才成功。他的突破點是，不再只盯著那些光鮮亮麗的夢幻科技公司，而是去找跟他過去經驗相關的「產業」。例如他有醫療業背景，他發現醫療公司看重他「懂醫療領域」的價值，遠大於純科技公司看重他「懂某個技術」的價值。
這點在台灣其實也一樣，但有個更有趣的現象。根據像是 iThome 或是一些開發者社群的討論，在台灣，除了技術能力，很多公司，特別是本土企業，非常看重「文化適應性」和「團隊合作的感覺」。這點跟矽谷那種「英雄式」工程師文化有點不同。所以，你在 CakeResume 或 Yourator 上客製化履歷時，除了列出你會的 AWS、K8s，多寫一些你如何解決「人」的問題、如何跟 PM 或設計師溝通，有時候反而更吃香。不要只讓你的履歷通過機器人篩選，要讓那個最後看履歷的「人」有共鳴。
冒牌者症候群？別怕，大家都會
DevOps 這個領域太廣了，從網路、作業系統、資料庫、CI/CD、安全性到雲端服務，沒人能全部精通。所以覺得自己什麼都不懂，是很正常的。
有個資深工程師的建議我覺得超棒：「真正的自信，不是來自於你什麼都懂，而是來自於你知道自己的極限，並且有好的除錯技巧。」你不需要知道所有答案，你只需要知道去哪裡找答案，以及什麼時候該舉手求救。
另一個 team lead 提到一個具體作法：每次卡關很久才解決問題後，一定要把過程跟學到的東西記錄下來。這些筆記會變成你最強大的個人知識庫。六個月後回頭看，你會驚訝自己走了多遠。
所以說到底，技術再強，最後還是要回到人、回到流程、回到溝通上。那些最厲害的 DevOps 專家，不是不會犯錯，而是他們從錯誤中學習、總結，然後讓整個系統和團隊都變得更有韌性。
那你呢？踩過最讓你印象深刻的坑是什麼？底下留言分享一下吧，搞不好你的經驗可以救到別人。
