DevOps CALMS 實踐框架：不是先買工具，而是先看哪個字母在拖後腿

CALMS 是拿來自我檢查的框架，不是驗收清單

CALMS 這個字，是 Culture（文化）、Automation（自動化）、Lean（精實）、Measurement（量測）、Sharing（分享）五個字的縮寫，最早由 Jez Humble 在《The DevOps Handbook》系列的討論中提出，用來描述一個組織要走向 DevOps 需要同時成立的五個條件。

它常被誤用成一份「導入清單」——CI/CD 裝好、Grafana 儀表板做好、就打勾說「我們 DevOps 了」。但這五個字母彼此互為前提：沒有文化上「出事不究責」的安全感，自動化只會把犯錯的速度變快；沒有量測，精實改善無從驗證；沒有分享，前面四項全部卡在少數人身上，離開就斷層。

真正有用的用法，是拿它當一份自我診斷表：團隊現在踩了哪個字母的坑，資源就該優先投在那裡，而不是每個字母都均勻地花錢買工具。

Culture：先問「出事之後，第一個問題是誰還是為什麼」

文化是五個字裡最抽象、卻決定其他四個能不能落地的一項。實務上最快分辨團隊文化健不健康的問題是：發生 Incident 之後，會議室裡第一句話是「這是誰改的」還是「發生了什麼、我們怎麼避免下次再發生」。

• 前者是究責文化（Blame Culture），工程師學到的教訓是「少改東西、少扛風險」，長期結果是沒人敢碰核心系統，變更集中在少數「敢做」的人身上
• 後者是無究責事後檢討（Blameless Postmortem）文化，把焦點放在系統性原因——為什麼這個錯誤沒有被測試攔下來、為什麼監控沒有更早示警、為什麼一個人的失誤可以直接影響到生產環境

該問的問題：團隊寫的 Postmortem 裡，行動項目（Action Item）是「加強某某人審查」還是「補上某個自動化檢查、修正某個流程缺口」？前者是文化沒到位的訊號。

Automation：自動化的順序，通常應該是「部署 → 測試 → 環境」

自動化常被簡化成「把 CI/CD 建起來」，但 CI/CD 只是自動化裡最顯眼的一塊。更完整的問法是：團隊裡有哪些步驟，還在依賴某個人手動執行、手動記得要做、只有他知道怎麼做？

這些步驟不分好壞，都是自動化的候選名單，常見的排序原則是先做「頻率高、風險低、規則明確」的事：

• 部署流程：手動 SSH 上機、手動跑腳本，是最常見也最該優先自動化的部分——風險最高、又最常做
• 測試：自動化測試套件（Unit / Integration / E2E）要能在 CI 裡穩定跑完，而不是「本地測過就上」
• 環境建置：用 IaC（Terraform、CloudFormation）取代手動在主控台點設定，讓環境本身也能重現、能被版本控制

常見誤區：自動化的目標不是「消滅人的判斷」，而是消滅重複、機械化、容易手滑的步驟，把人的判斷力留給真正需要判斷的事情（例如：這次變更要不要上、風險評估）。

Lean：把「還在做的浪費」找出來，而不是先加流程

Lean（精實）源自製造業的精實生產，核心精神是持續辨識並移除「浪費」（Waste）。在軟體交付的情境下，常見的浪費包括：

• 批次過大：累積一個月的變更才一次上線，出問題時不知道是哪個改動造成的，回滾成本也高
• 等待：一個 PR 卡審核卡三天、一個環境申請要走簽核流程一週
• 交接損耗：需求從 PM 傳到工程師、再傳到維運，每次交接都遺失一部分上下文，導致重工

該問的問題：從一行程式碼被寫出來，到它真正在生產環境跑起來、產生價值，中間有多少步驟是在等待，而不是在做事？精實的第一步永遠是先把整條交付流程畫出來（Value Stream Mapping），再決定要優化哪一段，而不是先加一堆新流程、新工具。

Measurement：先能回答「這次改動有沒有變好」，才能談持續改善

沒有量測，前面三項都無法驗證是不是真的有效——文化變好了嗎？自動化真的省下時間了嗎？精實改善真的縮短前置時間了嗎？

DevOps 圈子最常用來量測交付績效的是 DORA（DevOps Research and Assessment）四大指標：

這四個指標刻意同時看穩定性與速度——只看部署頻率會鼓勵「衝快但常常壞」，只看變更失敗率又會鼓勵「怕出事乾脆少上線」，四個一起看才不會顧此失彼。實務上不需要一次到位地精算，先能穩定拿到這四個數字的粗略趨勢，就已經比完全沒量測進步很多。

Sharing：知識卡在一個人身上，就是團隊最大的單點故障

分享指的是把知識、工具、經驗跨團隊、跨角色地流通，而不是留在少數人腦中或某個沒人維護的 Wiki 裡。常見的實踐方式：

• 內部技術分享：把踩過的坑、解決問題的過程整理成文件或分享會，而不是解決完就結束
• 共用工具與範本：Runbook、部署腳本、監控儀表板範本統一維護，而不是每個團隊各自重造輪子
• 輪值與結對：讓值班（On-Call）、部署這類「只有某人會」的工作，透過輪值或結對逐漸擴散給更多人

該問的問題：如果團隊裡「懂最多」的那個人請假一週，會不會有東西因此卡住？如果答案是會，代表分享這一項還沒做到位，而這通常也是知識最集中、風險最高的地方。

用 CALMS 做自我檢查，而不是導入清單

實務上判斷團隊卡在哪個字母，可以用下面這張表快速定位：

CALMS 的價值不在於背下這五個字，而在於每次要導入新工具或新流程之前，先問一句：這解決的是文化、自動化、精實、量測還是分享的問題？如果答案不清楚，很可能只是在給一個沒被真正診斷出來的問題，貼上一塊新的 OK 繃。