CI/CD爆炸現場與部署突襲記
假設你遇到一位叫Sarah的工程師，她在新創公司和大企業都混過不少年頭，經驗差不多有快十年吧。她時常參加面試，也碰過各種棘手情境，偶爾還會跟大家分享一些準備面試的訣竅。她自己說過：「其實很多面試並不是只看你懂幾條指令，更重要的是你怎麼處理現場那些突發狀況。」所以這次，就讓Sarah帶著我們繞一圈，把將近五十道場景型DevOps問題拆開聊聊，順便穿插點她自己的觀察。
最開始那幾題大多圍繞在CI/CD上。像是有一次，他們團隊的CI pipeline突然掛掉，螢幕上就出現了「找不到依賴套件」這樣的錯誤訊息。Sarah說，她通常會先檢查最近是不是有人加了新的套件卻沒補進需求清單裡，有時候也會懷疑是不是build server網路又斷線了。有遇過某個版本號卡住下載，那可能要考慮調整一下設定檔，把那包拉進自己公司內部的套件倉庫，比較保險。
還記得有回新版本剛上線沒多久，用戶反應好像出現比較嚴重的問題。這類情況下，Sarah一般先評估影響範圍，再啟動他們事前規劃好的回滾流程——理想狀況下是全自動啦，大部分就是從舊版artifact repository把上一版重新布署一次。事情搞定後，她會用監控系統確認服務恢復正常、再通知相關人員，然後才慢慢去追原因。
另外有談到怎麼讓網站升級不中斷？Sarah偏好藍綠部署（blue-green deploy），簡單說就是維持兩組幾乎完全一樣的環境，一組負責現在服務用戶，另一組則拿來更新測試。如果新版驗證OK，就把流量切到新環境；萬一哪裡怪怪的，也能很快切回舊系統，不至於影響太多人。
講到pipeline優化，有團隊build流程大概得跑超過半小時才結束。Sarah通常會建議先找出耗時最多的步驟。有些情況下可以分批跑測試、做增量編譯或善用快取機制，加速依賴載入速度。如果硬體資源允許，就換台更強力的build server，再不然就把流程拆細，只針對實際變動的代碼執行必要測試。不見得每次都能縮短太多，但總比什麼都不做來得好些。
最開始那幾題大多圍繞在CI/CD上。像是有一次，他們團隊的CI pipeline突然掛掉，螢幕上就出現了「找不到依賴套件」這樣的錯誤訊息。Sarah說，她通常會先檢查最近是不是有人加了新的套件卻沒補進需求清單裡，有時候也會懷疑是不是build server網路又斷線了。有遇過某個版本號卡住下載，那可能要考慮調整一下設定檔，把那包拉進自己公司內部的套件倉庫，比較保險。
還記得有回新版本剛上線沒多久，用戶反應好像出現比較嚴重的問題。這類情況下，Sarah一般先評估影響範圍，再啟動他們事前規劃好的回滾流程——理想狀況下是全自動啦，大部分就是從舊版artifact repository把上一版重新布署一次。事情搞定後，她會用監控系統確認服務恢復正常、再通知相關人員，然後才慢慢去追原因。
另外有談到怎麼讓網站升級不中斷？Sarah偏好藍綠部署（blue-green deploy），簡單說就是維持兩組幾乎完全一樣的環境，一組負責現在服務用戶，另一組則拿來更新測試。如果新版驗證OK，就把流量切到新環境；萬一哪裡怪怪的，也能很快切回舊系統，不至於影響太多人。
講到pipeline優化，有團隊build流程大概得跑超過半小時才結束。Sarah通常會建議先找出耗時最多的步驟。有些情況下可以分批跑測試、做增量編譯或善用快取機制，加速依賴載入速度。如果硬體資源允許，就換台更強力的build server，再不然就把流程拆細，只針對實際變動的代碼執行必要測試。不見得每次都能縮短太多，但總比什麼都不做來得好些。
環境長歪怎麼辦？IaC與祕密管理亂流
有時候，為了讓開發、測試到正式上線這幾個環境保持差不多的狀態，Sarah會用像Terraform或CloudFormation那種基於程式碼的工具，先把這些環境需求寫成類似模板的東西。她好像也蠻常搭配Ansible處理設定檔，不僅如此，如果是應用程式本身，她又會搬出Docker這類容器技術，把軟體跟它需要的小東西一起包起來。這樣一來，每個地方跑起來，大致上都沒什麼太明顯落差。
至於公司打算往新的地區擴展，要從頭建設一套基礎架構，Sarah通常就直接調整原本現有的IaC模板，把地區參數換掉，有時還得修補一下某些只在特定地區才會遇到的小細節。她也不急著馬上全數部署，而是多半會先丟到一個跟正式機很像但沒那麼緊張的測試環境裡面，看看到底有沒有哪裡怪怪的再說。因為每個雲端平台和地區都有自己的小脾氣，所以不能完全照搬。
萬一突然發現生產伺服器配置跟IaC描述的不太一樣，她第一步大概就是把不同點記錄下來，再弄清楚原因——可能前陣子有臨時救火改過東西。然後，她通常不傻傻照原本IaC直接覆蓋，而是審慎比對後，必要時反過來把那些「合理」的臨時變更納入程式碼管理流程。一邊做，她也考慮加強自動化檢查，比如AWS Config或Terraform自己的狀態巡查功能，以便以後不要又出現類似狀況。而且，一般來講，公司內部流程還要再調整一下，盡量避免有人繞過自動化管道偷偷手改。
談到秘密資訊（API金鑰、密碼之類），Sarah倒是不會直接寫進任何儲存庫。她習慣另外找安全專門做秘密管理的服務，例如HashiCorp Vault或者AWS Secrets Manager，然後程式碼只指向那些密鑰的位置識別符號。有關布署階段，他們CI/CD系統拿到的是經過限制權限控管能夠讀取所需密鑰而已。不只是存放，小組還會定期輪替金鑰，也偶爾審查誰看得到哪些敏感資料。
測試基礎架構程式碼方面，她其實挺注重分層次檢查：最早先行的是語法驗證跟一些靜態分析工具抓低級錯誤；接著用「預演」模式推估到底會產生哪些變化，再丟進與正機高度相似但比較安全無害的暫存環境裡跑一次；最後還要靠自動化腳本針對功能性、安全性甚至合規等角度全面測試。在確保沒什麼大問題之後才考慮推進正式線上機房。
如果高層問起怎麼避免被單一家雲端廠商綁死——想要玩跨雲策略？Sarah一般會評估用IaC去抽象共通資源，但同時又留意每家平臺各自獨有的小細節——比如某些資源命名方式或網路結構總得微調。所以通常不是百分百複製貼上，多半是主幹一致、細部微調。另外，也許她還得花點力氣維護兩邊都能通用的一組腳本，不見得事事順利，但至少可以稍微降低轉移成本吧。
Comparison Table:
| 項目 | 內容 |
|---|---|
| 開發流程管理 | 主幹開發方式，短命功能分支，PR審查與測試要求。 |
| 檔案衝突處理 | 雙人編程、圖形化比對工具、建議溝通以減少衝突。 |
| 技術文檔維護 | 將文件視為代碼一部分，自動化生成與更新機制。 |
| 自動化DNS管理 | 使用Terraform與CI/CD流程綁定DNS設定，逐步全自動化。 |
| 資料庫備份策略 | 每天全備，異地存放，加密，並定期進行恢復測試。 |
容器塞車、K8s賽道與服務迷宮
如果說到雲端平台這一塊，Sarah大概會選那種比較不偏向單一廠商的工具，好像Terraform就滿常見。她通常會弄個抽象層，把不同雲服務的細節藏起來，讓開發者不用太煩惱那些麻煩的差異。她提到應用架構最好別過度依賴什麼專有服務，多半還是傾向容器化和Kubernetes這類好轉移、好擴展的東西。然後，她也習慣做持續測試，不管在哪個雲上跑，都希望表現不要落差太大。
至於容器在生產環境偶爾會因為記憶體不足而掛掉，她的處理方式就稍微多元一些。有時候先看監控數據，抓出記憶體使用狀況，再調整設定（像是多留點緩衝空間），不過光改參數可能還不夠，有時候還得回頭優化程式本身。如果是用Kubernetes，大致上她會讓請求資源與實際需求相近，又別讓上限設太鬆免得有人搶爆。碰到壓力一升高，她也有想過用橫向擴展去分散負載。
講到Docker映像檔動輒幾GB，有些團隊部署真的慢到快要等天黑。Sarah倒是建議從基礎鏡像下手，能用Alpine這種精簡版就別挑重裝備。有時候分階段建構，把編譯工具跟執行環境拆開，也能瘦身不少。臨時檔案和快取資料該清該刪都不要手軟，多合併一下指令也許能減少層數。此外，她偶爾會提到DockerSlim或類似的分析工具協助查缺補漏。不定期檢討整體映像優化流程也是她的一貫作風。
至於K8s裡面如果要特定Pod跑在某幾台機器上，其實做法沒有唯一標準答案，看情境隨機應變吧。最陽春的大概就是Node Selector，加個標籤就解決。如果規則複雜一點，就靠Affinity來搞定；要避免某些Pod亂跑進特定節點，也許Taints和Tolerations比較適合。例如有GPU那種特規主機，就貼標籤給它，然後只讓需要運算力的工作安排上去。
安全性方面，Sarah講究分層防護。她經常掃描映像找漏洞，用Trivy、Clair之類的不少見。而且很強調少即是多——越小型基礎映像越難留下破口。運行權限能降多低降多低，甚至要求非root執行。有些情境下連檔案系統都設成唯讀比較放心。另外網路政策限制彼此溝通範圍、底層鏡像固定更新、運作期間監控可疑活動，這些都是基本盤。不管怎麼做，「最小權限」原則始終沒忘記。
服務發現這件事，每個環境招式各異。在Kubernetes圈子裡內建DNS配Service物件已經夠穩了，要跨平台可能還得找Consul或etcd之類專門解決方案。不外乎健康檢查淘汰掉狀態不好的實例，再加點流量平衡與彈性配置，就是希望哪怕搬家換地，也可以保持溝通順暢、系統自我修正能力高一些啦。
說到底，每家公司遇上的警示疲勞問題大同小異——通知訊息湧現，不少又是假警報或誤觸發，團隊精神自然容易被消磨……
監控警報狂響，慢速追兇大作戰
有時候，像Sarah這樣的人在面對一堆警示訊息時，會先思考怎麼分層處理比較好。她大致會先翻一下現有的警報紀錄，想看看那些被誤觸發或者老是重複響起的情況是不是佔了七成以上。然後，警報門檻也許得調整一下，不只是看技術指標，而是多考慮實際影響到多少人或服務。訊息通知方式可能分幾個等級，有些急迫才用即時通訊軟體，有些則用郵件慢慢看。常見問題如果能自動修復，大概就不需要每次都打擾工程師。有些相關聯的異常，也會試著合併成一條提醒，不必讓大家收一堆碎片化通知。
至於那種應用系統跑很慢、使用者覺得卡頓的狀況，她通常不是直接問同事，而是會從監控平台下手，像APM工具那類的東西，看哪個功能或服務速度掉下來最明顯。有時還要交叉對照主機資源，是不是CPU或記憶體用了將近八九成，又或者磁碟I/O太高。遇到查詢慢時，她可能去翻請求追蹤紀錄，也就是說找找是不是資料庫查詢拖住腳步，又或是哪個外部API反應奇慢無比。如果前陣子剛推過什麼新版本更新，那改動內容也不能不查一遍。
至於日誌管理啊，如果每天產出的日誌量多到數十TB，她大致傾向讓每個服務都寫結構化日誌（很多人愛用JSON格式），這樣之後匯總起來比較省事。集中的話，大概就是ELK之類的平台，也有人選Grafana Loki。不過量太大真的存不了多久，所以高頻低價值的東西通常只取樣保存，而且日誌等級分細一點，把重要和一般資訊區隔開來。儲存期限就依據法規跟實際需求調整，沒必要全留著。有空還會做幾張儀表板，用來盯一些關鍵模式出現，比如說錯誤激增、異常行為等等。
半夜兩點突然收到全系統當機的警報？她多半第一時間先確認自己已經回覆了通知，再開監控頁面和狀態頁瞄一下，到底停的是部分服務還是整包掛光。流程上，一般都是先確認事件本身，再翻閱近期變更紀錄——畢竟很多故障都是部署新程式碼引起。如果能快速找到解法，例如回滾，就優先處理緊急恢復。有需要協助時再按排班制度叫其他人支援；期間無論怎麼折騰，都會隨手把處理步驟記下來，好方便之後檢討。
談到微服務要收集哪些專屬指標，她認為基本的大概就是流量（請求數量）、錯誤類型與比率、延遲時間，以及資源使用情況。而針對不同業務，其實還可以額外加上一些反映主要功能價值的衡量項目，但具體內容往往要和產品設計討論過才決定得了……
至於那種應用系統跑很慢、使用者覺得卡頓的狀況，她通常不是直接問同事，而是會從監控平台下手，像APM工具那類的東西，看哪個功能或服務速度掉下來最明顯。有時還要交叉對照主機資源，是不是CPU或記憶體用了將近八九成，又或者磁碟I/O太高。遇到查詢慢時，她可能去翻請求追蹤紀錄，也就是說找找是不是資料庫查詢拖住腳步，又或是哪個外部API反應奇慢無比。如果前陣子剛推過什麼新版本更新，那改動內容也不能不查一遍。
至於日誌管理啊，如果每天產出的日誌量多到數十TB，她大致傾向讓每個服務都寫結構化日誌（很多人愛用JSON格式），這樣之後匯總起來比較省事。集中的話，大概就是ELK之類的平台，也有人選Grafana Loki。不過量太大真的存不了多久，所以高頻低價值的東西通常只取樣保存，而且日誌等級分細一點，把重要和一般資訊區隔開來。儲存期限就依據法規跟實際需求調整，沒必要全留著。有空還會做幾張儀表板，用來盯一些關鍵模式出現，比如說錯誤激增、異常行為等等。
半夜兩點突然收到全系統當機的警報？她多半第一時間先確認自己已經回覆了通知，再開監控頁面和狀態頁瞄一下，到底停的是部分服務還是整包掛光。流程上，一般都是先確認事件本身，再翻閱近期變更紀錄——畢竟很多故障都是部署新程式碼引起。如果能快速找到解法，例如回滾，就優先處理緊急恢復。有需要協助時再按排班制度叫其他人支援；期間無論怎麼折騰，都會隨手把處理步驟記下來，好方便之後檢討。
談到微服務要收集哪些專屬指標，她認為基本的大概就是流量（請求數量）、錯誤類型與比率、延遲時間，以及資源使用情況。而針對不同業務，其實還可以額外加上一些反映主要功能價值的衡量項目，但具體內容往往要和產品設計討論過才決定得了……
雲端遷移、成本殺手及Serverless風險邊界
如果碰上那種老舊系統要搬到雲端，像是有些公司會這樣想吧，通常都得先把整個應用架構、相依的那些東西還有資料梳理一遍。有時候搞清楚到底牽扯到哪些服務、哪邊卡得比較死，其實也沒那麼快。然後選擇遷移方式，大致分成幾種啦，像直接搬上去（有些人說「原封不動」）、小修小補再轉移、稍微改造或大幅度重做。真要執行，好像不少人會建議分階段慢慢來，先從不那麼重要的部分測水溫，比較保險。當然測試環境一定要準備好，資料搬運也挺花工夫的。等一切穩定，再安排正式切換，不少團隊都希望能讓停機時間縮到很短。
費用問題常常在某個季度突然冒出來，比如說帳單忽然多出將近一半，公司就緊張了。這時候，有人會想到給各組加標籤，看是誰用最多；也有人利用雲端那些管理工具找出開銷怪異之處。一些常見節省作法像是調整資源規模，把太閒置的伺服器縮減掉，用彈性伸縮自動配合需求變化。有非關鍵工作負載，有人會考慮低價臨時型主機；至於冷門資料，也能丟到便宜儲存層級。另外，如果有長期預測得準的工作量，其實包月或訂閱型方案打折還蠻多人用。
講到無伺服器架構嘛，好像很適合流量起伏大或者事件觸發型任務。有人覺得這樣能少操心一些基礎設施。不過偶爾還是會遇到延遲啟動問題，有時候追蹤錯誤就麻煩點，而且綁在特定平台多少讓人猶豫。不確定高峰流量下費用怎麼算也是一件事。另外每次執行時間和記憶體其實有限制，有些複雜任務反而不好處理。
若要設計那種高可用又跨地區的系統，大約需要多個區域一起備援。有聽說過主動—主動或主被動模式，看需求選擇吧。一些重點元件像全域負載平衡，要配健檢機制；資料同步策略也不能馬虎，一致性該怎麼取捨各家說法不同。服務最好彼此獨立運作，比較不容易連環倒塌。而且萬一哪邊掛了，自動切換才靠譜。有的人甚至故意做失效演練，就是所謂混沌工程，希望平常就習慣突發狀況。
有關企業自己要求公有雲跟本地機房之間弄條安全通道嘛，解法其實很多。例如站點對站點VPN可以加密但品質波動可能比較明顯；至於專線（例如AWS Direct Connect、Azure ExpressRoute）聽說價格偏高但速度穩定，而且走的是私網路。如果公司很多據點，有軟體定義廣域網路方案也是一派選項。不過最終考慮還是回歸頻寬、安全、延遲和預算這幾個條件。
最後，假如二十位左右工程師同時弄同個專案，那Git流程怎麼設計？
費用問題常常在某個季度突然冒出來，比如說帳單忽然多出將近一半，公司就緊張了。這時候，有人會想到給各組加標籤，看是誰用最多；也有人利用雲端那些管理工具找出開銷怪異之處。一些常見節省作法像是調整資源規模，把太閒置的伺服器縮減掉，用彈性伸縮自動配合需求變化。有非關鍵工作負載，有人會考慮低價臨時型主機；至於冷門資料，也能丟到便宜儲存層級。另外，如果有長期預測得準的工作量，其實包月或訂閱型方案打折還蠻多人用。
講到無伺服器架構嘛，好像很適合流量起伏大或者事件觸發型任務。有人覺得這樣能少操心一些基礎設施。不過偶爾還是會遇到延遲啟動問題，有時候追蹤錯誤就麻煩點，而且綁在特定平台多少讓人猶豫。不確定高峰流量下費用怎麼算也是一件事。另外每次執行時間和記憶體其實有限制，有些複雜任務反而不好處理。
若要設計那種高可用又跨地區的系統，大約需要多個區域一起備援。有聽說過主動—主動或主被動模式，看需求選擇吧。一些重點元件像全域負載平衡，要配健檢機制；資料同步策略也不能馬虎，一致性該怎麼取捨各家說法不同。服務最好彼此獨立運作，比較不容易連環倒塌。而且萬一哪邊掛了，自動切換才靠譜。有的人甚至故意做失效演練，就是所謂混沌工程，希望平常就習慣突發狀況。
有關企業自己要求公有雲跟本地機房之間弄條安全通道嘛，解法其實很多。例如站點對站點VPN可以加密但品質波動可能比較明顯；至於專線（例如AWS Direct Connect、Azure ExpressRoute）聽說價格偏高但速度穩定，而且走的是私網路。如果公司很多據點，有軟體定義廣域網路方案也是一派選項。不過最終考慮還是回歸頻寬、安全、延遲和預算這幾個條件。
最後，假如二十位左右工程師同時弄同個專案，那Git流程怎麼設計？
Git衝突日常—分支切換與文件永遠不全的故事
Sarah當時是這麼說的——她會用那種主幹開發的方式，大家通常從主分支拉出短命的功能分支。每次有人要加新東西或修bug，大概都會從主幹再生一條支線，然後小步快跑地提交。等到差不多了，就丟個PR上去。那邊流程還算嚴格，每次合併請求都要有自動化測試過關、兩位左右同事審查才行。這些過程裡，有時候人多事情雜，她也會建議排隊合併，用點像合併序列之類的工具，避免大家同時動手把主分支搞亂。為了讓主幹穩定，他們還會設限制規則。這樣做，好像在協作和穩定中找個平衡。
遇到檔案衝突？她說大約會先把兩位工程師找來聊一聊，聽清楚彼此到底想改什麼。有些衝突一目瞭然，她就建議用比較圖形化的比對工具，一塊一塊看清楚誰改了哪裡。有時候事情複雜起來，她甚至讓他們直接一起寫（可能就是所謂雙人編程），慢慢解決每段衝突。如果問題太頻繁，她會提醒大家溝通要再緊密點，盡量分批、聚焦地提交代碼，也許引入一些像功能開關那種辦法來降低風險。
審查PR她挺有自己的一套，據說主要是看正確性、安全漏洞、效能疑慮、是不是有依照團隊慣例，以及測試和文件補得夠不夠全面……大致抓住這些面向吧。給回饋時不直接否定，而是先肯定，再問問題、解釋背後原因，有需要還舉例子，而且也會區分哪些非改不可、哪些只是建議。她強調這種互評其實重點不在挑錯，更像知識交流與漸進改善。
至於選單一倉庫還是拆成好多個倉庫，那場討論她參與過。記得她觀察到幾個重點：如果團隊很大或結構複雜，常常會考慮要不要集中管理；假如服務間彼此綁得很緊，共用函式庫很多，那用單一倉庫可能省事，也方便一次性更動多項內容。但若各服務獨立又有不同維護團隊，各自發布周期不同，多倉庫管理反而明確、有彈性一些。此外，權限控管和編譯速度也是考量之一——拆開小倉庫，有時單元測試能快不少，不必全打包重新來。
講到技術文檔怎麼跟著系統變動走…Sarah覺得文件最好就當作代碼處理，把它放在專案裡頭，每當有人提PR修改代碼時，就順便要求文件也更新。有空還可以設定自動化機制，例如透過註解或API描述生成部分說明書。如果怕連結失效或內容陳舊，可以安排工具做簡單檢查。另外，她有提過，用模板統一格式其實對整理蠻有幫助，只要不是太死板，大致能減少日後維護負擔。
最後那題DNS啊，他們以前好像真的是靠人力手動調整記錄——每部署新服務就得跑去網頁上敲資料，但時間久了總有人嫌麻煩。有考慮寫腳本自動串API，其實市面上一些平台都提供可程式介面，不一定非自己造輪子。只要部署流程加一步呼叫腳本，大部分情況下，新服務上線DNS就能自動更新了。不過現場狀況總是不盡相同，有時環境特殊還是免不了人工介入，只是比例比以前低不少罷了……
遇到檔案衝突？她說大約會先把兩位工程師找來聊一聊，聽清楚彼此到底想改什麼。有些衝突一目瞭然，她就建議用比較圖形化的比對工具，一塊一塊看清楚誰改了哪裡。有時候事情複雜起來，她甚至讓他們直接一起寫（可能就是所謂雙人編程），慢慢解決每段衝突。如果問題太頻繁，她會提醒大家溝通要再緊密點，盡量分批、聚焦地提交代碼，也許引入一些像功能開關那種辦法來降低風險。
審查PR她挺有自己的一套，據說主要是看正確性、安全漏洞、效能疑慮、是不是有依照團隊慣例，以及測試和文件補得夠不夠全面……大致抓住這些面向吧。給回饋時不直接否定，而是先肯定，再問問題、解釋背後原因，有需要還舉例子，而且也會區分哪些非改不可、哪些只是建議。她強調這種互評其實重點不在挑錯，更像知識交流與漸進改善。
至於選單一倉庫還是拆成好多個倉庫，那場討論她參與過。記得她觀察到幾個重點：如果團隊很大或結構複雜，常常會考慮要不要集中管理；假如服務間彼此綁得很緊，共用函式庫很多，那用單一倉庫可能省事，也方便一次性更動多項內容。但若各服務獨立又有不同維護團隊，各自發布周期不同，多倉庫管理反而明確、有彈性一些。此外，權限控管和編譯速度也是考量之一——拆開小倉庫，有時單元測試能快不少，不必全打包重新來。
講到技術文檔怎麼跟著系統變動走…Sarah覺得文件最好就當作代碼處理，把它放在專案裡頭，每當有人提PR修改代碼時，就順便要求文件也更新。有空還可以設定自動化機制，例如透過註解或API描述生成部分說明書。如果怕連結失效或內容陳舊，可以安排工具做簡單檢查。另外，她有提過，用模板統一格式其實對整理蠻有幫助，只要不是太死板，大致能減少日後維護負擔。
最後那題DNS啊，他們以前好像真的是靠人力手動調整記錄——每部署新服務就得跑去網頁上敲資料，但時間久了總有人嫌麻煩。有考慮寫腳本自動串API，其實市面上一些平台都提供可程式介面，不一定非自己造輪子。只要部署流程加一步呼叫腳本，大部分情況下，新服務上線DNS就能自動更新了。不過現場狀況總是不盡相同，有時環境特殊還是免不了人工介入，只是比例比以前低不少罷了……
自動化腳本誤刪檔案？批次處理與備份冏事簿
如果讓莎拉來規劃自動化流程，通常她會找個像Terraform這類基礎架構即程式的平台，把DNS設定直接和服務部署綁在一起。據說每次有新東西上線時，CI/CD流程便會自動觸發腳本去調整DNS，好像不用人手動弄。然後還會加幾道驗證步驟，確保那些記錄真的指到對的位置。初期她習慣留一個人工審查的環節，等到團隊對這整套機制有點信心之後，再慢慢全自動化。
至於要怎麼處理龐大伺服器群的設定變更，她似乎偏向用Ansible、Chef或Puppet那種配置管理工具，所有設定都寫成程式碼丟進版本控制，有什麼改動先在測試環境搞一輪，再由同儕檢查、跑自動化測試，最後才分批推到正式系統。有些場景她還會考慮pull或push模式，看安全需求再決定。另外，如果是在雲端，也許會走「不可變基礎架構」那條路——直接換掉舊主機，不去修補原有的設定。
談到關鍵資料庫備份，其實莎拉挺注重完整性的。她計畫每天離峰時段做一次全備，其餘時間約二三十分鐘抓一次交易紀錄（有人說是為了能隨時回復）。每次備份後都會做完整性驗證。而且這些備份不只放一個地方，好像還得有異地存放、加密之類的要求。監控也很重要，一旦發現失敗就跳通知。至於恢復測試，她覺得要定期自動演練，不然資料真出事時可能措手不及。
說起大量數據夜間批次處理，她想到的是Airflow或AWS Step Functions來當總管，把工作拆成好幾份同時跑。如果哪裡壞掉，可以設個檢查點方便重新接續。一連串過程裡也不能少了日誌紀錄與監控，要知道現在跑到哪、效能如何。前後資料都得校驗沒問題才算結束。遇到短暫狀況不穩，就自動重試。有通知功能也是常見做法——無論成功或失敗，都能讓人及時知道。
如果只是寫個腳本清掉舊日誌，她提供的大致是：指定目錄和檔案型態，例如/var/log/application底下那些附有log副檔名的東西，只要超過大約一個月沒改過，就納入清單。執行前先記下總共找到多少檔案，有刪除就把相關資訊寫進另一個專門記錄操作歷史的log。如果沒什麼可刪，也順便記下來。不過命令細節，每家公司可能還是自己調整比較好。
遇到資安漏洞爆發，大概沒誰敢輕忽吧？莎拉一般先評估這洞到底影響多大，如果感覺風險高得嚇人，她傾向馬上用防火牆擋一下網路流量，也許暫停某部分服務撐著等修補。同時間開始準備緊急更新，把問題函式庫升級至較新版本，再經過測試流程走特急通道佈署上線。不放心的話還得再掃一次安全弱點，比對是否真的堵住漏洞。有些團隊甚至藉此回頭盤點其他可能被忽略的相似風險，但執行細節往往跟公司文化與經驗值有關。
安全漏洞瞬間爆發，合規魔王現形記
情境三十七，其實就是公司得去符合那個SOC 2的規範嘛。關於安全、可用性、流程正確性、機密性還有隱私那些，通常有人會建議先從權限下手——像是讓每個人只能碰到該負責的部分。然後，基礎設施可能就用那種寫成程式碼、有版本控制的方式，這樣改過什麼都留痕跡。基本上，不管哪裡調整，都會自動記錄在審計日誌裡面。如果再細一點，也許可以把合規檢查放進CI/CD流程自動跑；漏洞掃描、資料加密這些防禦措施也不太能少。有時候還要測備份、災難復原是不是真的有效。至於文檔紀錄，大部分團隊都會保留一套給稽核看的，那種感覺好像很繁瑣，但應該蠻必要的。
下一題是講祕鑰輪換那類敏感資訊要怎麼自動換新。有些人或許會選Vault或AWS Secrets Manager那類平台，然後設定每種秘密的更換頻率，看實際需求彈性安排。有些輪替步驟大致是：先產生新的，再讓系統同時接受新舊一段時間，測試新版沒問題之後，就把舊的撤掉。過程中通常都要有日誌記錄，以防之後查詢需要。如果特別關鍵，好像也有人加裝監控來確定換鑰匙沒出差錯。
講到Kubernetes叢集內微服務間通訊加強安全，有人會說得防守型一點。例如會先用網路政策限制哪些Pod能互連，多數只開必要路徑。如果想再進一步，有時候團隊用service mesh（像Istio）搞雙向TLS，把流量全加密，也能驗證彼此身份。不少工程師同時搞嚴格RBAC和Pod安全策略，避免帳號權限亂飛或者容器升權。偶爾還要加一些流量偵測工具看看有沒有怪異行為。有的人隔陣子就重審一次這堆設定，看合不合規。
審計紀錄這塊一直都很敏感。一些做法，是所有基礎設施變更必須經過IaC跟版本管理系統，一路有完整歷史記載。運作中的系統則盡可能打開詳細認證、授權、組態變更等相關日誌。而且大家常把所有日誌丟去某種集中管理的平台，加上無法任意竄改的設計，外部存取通常也有限制。依照法規要求，有時候還得把保存期限拉長並且設定警示，如果發現誰偷偷刪改或日誌漏掉片段馬上反應。不少團隊還定期抽查整個審計流程到底完整不完整。
資料庫效能如果慢了起來，大致上的思考順序差不多都是先打開查詢分析功能，挑出那些最拖台錢的語句。有些人可能抓來執行計劃看看到底是哪裡效率不好，例如某幾張表老是在掃全表或者缺索引什麼的。短期內，也許補點索引或優化幾條SQL就有改善，有時則靠快取頂一下。如果狀況一直沒解決，有人會考慮分片或者弄讀取副本分散流量，更長遠就是重新評估現在這款DB到底適不適合公司越來越複雜的需求吧。
電商網站遇上突如其來將近十倍客流，例如閃購活動期間怎麼辦？其實各家做法滿多元，有人偏愛彈性方案…
下一題是講祕鑰輪換那類敏感資訊要怎麼自動換新。有些人或許會選Vault或AWS Secrets Manager那類平台，然後設定每種秘密的更換頻率，看實際需求彈性安排。有些輪替步驟大致是：先產生新的，再讓系統同時接受新舊一段時間，測試新版沒問題之後，就把舊的撤掉。過程中通常都要有日誌記錄，以防之後查詢需要。如果特別關鍵，好像也有人加裝監控來確定換鑰匙沒出差錯。
講到Kubernetes叢集內微服務間通訊加強安全，有人會說得防守型一點。例如會先用網路政策限制哪些Pod能互連，多數只開必要路徑。如果想再進一步，有時候團隊用service mesh（像Istio）搞雙向TLS，把流量全加密，也能驗證彼此身份。不少工程師同時搞嚴格RBAC和Pod安全策略，避免帳號權限亂飛或者容器升權。偶爾還要加一些流量偵測工具看看有沒有怪異行為。有的人隔陣子就重審一次這堆設定，看合不合規。
審計紀錄這塊一直都很敏感。一些做法，是所有基礎設施變更必須經過IaC跟版本管理系統，一路有完整歷史記載。運作中的系統則盡可能打開詳細認證、授權、組態變更等相關日誌。而且大家常把所有日誌丟去某種集中管理的平台，加上無法任意竄改的設計，外部存取通常也有限制。依照法規要求，有時候還得把保存期限拉長並且設定警示，如果發現誰偷偷刪改或日誌漏掉片段馬上反應。不少團隊還定期抽查整個審計流程到底完整不完整。
資料庫效能如果慢了起來，大致上的思考順序差不多都是先打開查詢分析功能，挑出那些最拖台錢的語句。有些人可能抓來執行計劃看看到底是哪裡效率不好，例如某幾張表老是在掃全表或者缺索引什麼的。短期內，也許補點索引或優化幾條SQL就有改善，有時則靠快取頂一下。如果狀況一直沒解決，有人會考慮分片或者弄讀取副本分散流量，更長遠就是重新評估現在這款DB到底適不適合公司越來越複雜的需求吧。
電商網站遇上突如其來將近十倍客流，例如閃購活動期間怎麼辦？其實各家做法滿多元，有人偏愛彈性方案…
資料庫卡住、閒時資源白搭，快取策略拼圖碎片
如果要設計一個內容量龐大的網頁應用程式，通常會考慮多層級的快取。Sarah大致是這麼說的：她會先在邊緣節點，也就是CDN那裡，讓靜態資源還有給陌生訪客的整頁內容都能被快取下來。進到應用層，有些人會挑Redis或Memcached來存放資料庫查詢結果、API回應和像是使用者登入狀態這類資訊。至於快取什麼時候失效，就沒那麼死板了——可能設定一個大概多久就自動過期，有新內容上架時觸發更新，或者給每份資料打一組版本號，只要資料改變就換key。針對個人化的內容，她說也許可以試試微型快取或分片快取，好讓命中率高一點但又不至於讓個人化消失。
雲端資源閒置這件事，在Sarah看來，其實也有不少方法可以省錢，不過都得小心不要犧牲掉表現。有些團隊會根據平常流量波動，把機器數量在夜間慢慢調低；開發測試用的環境，也許到了非工作時間自動暫停，真的有人需要再自己打開就好。像批次運算這種工作，大概都會安排在人少系統閒下來時跑完。如果服務本身容錯力還行，選擇價格比較親民但容易被中斷的雲端主機也是有人在做。不過這些做法基本上還是得搭配監控才比較放心，不然哪天突然出問題就糟糕了。
負載測試部分，她提到一般會選JMeter、Locust或Gatling之類工具，然後根據線上實際紀錄去寫一些模擬劇本，讓測試更貼近真實情況。很多公司其實都不太敢直接拿正式環境冒險，所以通常是在一套幾乎跟正服差不多的預備環境跑壓力測試。有的人可能會從輕到重逐步加壓，看系統哪裡先撐不住，也有人專挑爆衝型瞬間流量觀察怎樣才不容易掛掉。測完以後得到那些數字與瓶頸，再回頭調整預算和自動擴展策略。
碰到像主機房全面斷電這種災難時，有些經驗豐富的人可能第一反應不是直接修復，而是趕緊啟動事故處理流程——叫齊團隊、確保聯絡管道通順。接著先弄清楚影響範圍跟大約多久才能修好，如果覺得等太久超出大家可接受範圍，那就切換到另一個地區備援站點吧。有些操作現在已經可以自動化，包括把流量透過DNS或者負載平衡器導向新的地方、啟用同步好的資料庫，再確認一下服務是不是都有正常運作。在整個過程中持續跟相關單位報告進度，順便留意資料有沒有同步好，其實也是很重要的一環。不見得每次災難規模都一樣，但大致流程大概就是這樣走一遍。
雲端資源閒置這件事，在Sarah看來，其實也有不少方法可以省錢，不過都得小心不要犧牲掉表現。有些團隊會根據平常流量波動，把機器數量在夜間慢慢調低；開發測試用的環境，也許到了非工作時間自動暫停，真的有人需要再自己打開就好。像批次運算這種工作，大概都會安排在人少系統閒下來時跑完。如果服務本身容錯力還行，選擇價格比較親民但容易被中斷的雲端主機也是有人在做。不過這些做法基本上還是得搭配監控才比較放心，不然哪天突然出問題就糟糕了。
負載測試部分，她提到一般會選JMeter、Locust或Gatling之類工具，然後根據線上實際紀錄去寫一些模擬劇本，讓測試更貼近真實情況。很多公司其實都不太敢直接拿正式環境冒險，所以通常是在一套幾乎跟正服差不多的預備環境跑壓力測試。有的人可能會從輕到重逐步加壓，看系統哪裡先撐不住，也有人專挑爆衝型瞬間流量觀察怎樣才不容易掛掉。測完以後得到那些數字與瓶頸，再回頭調整預算和自動擴展策略。
碰到像主機房全面斷電這種災難時，有些經驗豐富的人可能第一反應不是直接修復，而是趕緊啟動事故處理流程——叫齊團隊、確保聯絡管道通順。接著先弄清楚影響範圍跟大約多久才能修好，如果覺得等太久超出大家可接受範圍，那就切換到另一個地區備援站點吧。有些操作現在已經可以自動化，包括把流量透過DNS或者負載平衡器導向新的地方、啟用同步好的資料庫，再確認一下服務是不是都有正常運作。在整個過程中持續跟相關單位報告進度，順便留意資料有沒有同步好，其實也是很重要的一環。不見得每次災難規模都一樣，但大致流程大概就是這樣走一遍。
災難應變混亂戲碼，on-call夜驚魂與SLA實驗室
.**情境四十七：無責備的事後檢討**
假如遇到比較大的系統中斷，Sarah大概會在事情剛解決後沒多久就把相關的人都找來開會——這時大家記憶還算新鮮。她說明一開始要先營造心理安全感，重點放在流程和系統本身，不去針對某個人批評。然後，大夥兒會依據監控數據還有現場人的回憶，把整個事件經過梳理出一個時間線。有些細節可能得多問幾次「為什麼」，才比較接近原因深層。最後文件裡通常包含：事件摘要、過程、導致問題的各種背景、哪些地方運作良好、哪些不太行，以及明確的改善步驟（都有人負責跟截止時間）。這份報告常常被分享到全公司，好讓大家多少能從裡頭學點經驗。
.**情境四十八：SLA管理**
怎麼訂定服務等級協議？Sarah大致上是先挑出最重要的用戶流程，再去設計能量化衡量成效的指標，比如可用性、延遲或錯誤發生機率等等。根據業務需求和技術限制，她會抓一組合適目標值給每項指標，這些目標再加上一點彈性空間之後，就變成正式協議內容。平時必須有完善監控，如果某些數字快碰到底線，自動通知才不至於漏看。有時候半年一次，也許一年幾次，都會檢查實際狀況跟目標差多少，有需要就調整指標或者協議內容。
.**情境四十九：輪班待命設計**
如果要顧及即時應變，又想工程師別太操勞，Sarah建議採分層輪班制——也就是說有人當主要負責，有人輔助備援，每次排班大約持續一週左右，而且得盡量平均分配。她強調每個人都該有明確升級處理路徑與常見狀況手冊。如果跨國團隊，可以嘗試讓不同時區輪流，以減少夜間打擾；而且臨時加班要給補貼或休假，同一位工程師兩次當班最好隔開兩週以上。另外，那些不需要人工處理的小警示自動篩掉，就不用影響大家休息了。她認為最關鍵還是慢慢減少輪班負擔，例如修正根本原因或提升自癒能力，讓未來問題越來越少。
.**情境五十：混沌工程導入方式**
談到如何推行混沌工程，她覺得不能冒進，一開始最好很小心地一步步來。首先，必須先把監控做完整，而且服務目標得明確。不妨從非正式環境下手，用最簡單那種像模擬伺服器失效、網路延遲的小實驗練習看看。如果信心逐漸建立，再挑低流量時段，在主線環境做一些高度可控測試，但一定要設定安全閥門，只要出現異常馬上終止實驗。每次測試前都寫好假設跟紀錄，下來一起檢討哪裡可以加強。久而久之，公司內部其實就累積了一套常態驗證穩定性的工具箱。
## 結語
走完這將近五十道DevOps面試題，Sarah最後提醒一句：「其實真正厲害的DevOps工程師，不是死背指令，而是懂原則、有彈性解決難題的人。在面試裡，多展現你的思考邏輯和權衡短期修復與長遠優化的方法。」準備這類情境式問題，其實也是訓練自己面對真實工作挑戰的一種方法。有些經歷也許沒那麼全面，但每道題都是你展示專業知識、解題能力，以及理解最佳實踐的機會。如果真要說什麼祝福，大概就是——一路順利吧！
假如遇到比較大的系統中斷，Sarah大概會在事情剛解決後沒多久就把相關的人都找來開會——這時大家記憶還算新鮮。她說明一開始要先營造心理安全感，重點放在流程和系統本身，不去針對某個人批評。然後，大夥兒會依據監控數據還有現場人的回憶，把整個事件經過梳理出一個時間線。有些細節可能得多問幾次「為什麼」，才比較接近原因深層。最後文件裡通常包含：事件摘要、過程、導致問題的各種背景、哪些地方運作良好、哪些不太行，以及明確的改善步驟（都有人負責跟截止時間）。這份報告常常被分享到全公司，好讓大家多少能從裡頭學點經驗。
.**情境四十八：SLA管理**
怎麼訂定服務等級協議？Sarah大致上是先挑出最重要的用戶流程，再去設計能量化衡量成效的指標，比如可用性、延遲或錯誤發生機率等等。根據業務需求和技術限制，她會抓一組合適目標值給每項指標，這些目標再加上一點彈性空間之後，就變成正式協議內容。平時必須有完善監控，如果某些數字快碰到底線，自動通知才不至於漏看。有時候半年一次，也許一年幾次，都會檢查實際狀況跟目標差多少，有需要就調整指標或者協議內容。
.**情境四十九：輪班待命設計**
如果要顧及即時應變，又想工程師別太操勞，Sarah建議採分層輪班制——也就是說有人當主要負責，有人輔助備援，每次排班大約持續一週左右，而且得盡量平均分配。她強調每個人都該有明確升級處理路徑與常見狀況手冊。如果跨國團隊，可以嘗試讓不同時區輪流，以減少夜間打擾；而且臨時加班要給補貼或休假，同一位工程師兩次當班最好隔開兩週以上。另外，那些不需要人工處理的小警示自動篩掉，就不用影響大家休息了。她認為最關鍵還是慢慢減少輪班負擔，例如修正根本原因或提升自癒能力，讓未來問題越來越少。
.**情境五十：混沌工程導入方式**
談到如何推行混沌工程，她覺得不能冒進，一開始最好很小心地一步步來。首先，必須先把監控做完整，而且服務目標得明確。不妨從非正式環境下手，用最簡單那種像模擬伺服器失效、網路延遲的小實驗練習看看。如果信心逐漸建立，再挑低流量時段，在主線環境做一些高度可控測試，但一定要設定安全閥門，只要出現異常馬上終止實驗。每次測試前都寫好假設跟紀錄，下來一起檢討哪裡可以加強。久而久之，公司內部其實就累積了一套常態驗證穩定性的工具箱。
## 結語
走完這將近五十道DevOps面試題，Sarah最後提醒一句：「其實真正厲害的DevOps工程師，不是死背指令，而是懂原則、有彈性解決難題的人。在面試裡，多展現你的思考邏輯和權衡短期修復與長遠優化的方法。」準備這類情境式問題，其實也是訓練自己面對真實工作挑戰的一種方法。有些經歷也許沒那麼全面，但每道題都是你展示專業知識、解題能力，以及理解最佳實踐的機會。如果真要說什麼祝福，大概就是——一路順利吧！
