[{"data":1,"prerenderedAt":310},["ShallowReactive",2],{"article-\u002Farticles\u002Fdevops-calms-framework":3},{"id":4,"title":5,"body":6,"date":296,"description":286,"excerpt":297,"extension":298,"meta":299,"navigation":300,"path":301,"seo":302,"stem":303,"tags":304,"__hash__":309},"articles\u002Farticles\u002Fdevops-calms-framework.md","DevOps CALMS 實踐框架：不是先買工具，而是先看哪個字母在拖後腿",{"type":7,"value":8,"toc":285},"minimark",[9,14,18,21,24,28,35,45,48,52,58,61,81,84,88,91,111,114,118,121,124,188,191,195,198,218,221,225,228,282],[10,11,13],"h2",{"id":12},"calms-是拿來自我檢查的框架不是驗收清單","CALMS 是拿來自我檢查的框架，不是驗收清單",[15,16,17],"p",{},"CALMS 這個字，是 Culture（文化）、Automation（自動化）、Lean（精實）、Measurement（量測）、Sharing（分享）五個字的縮寫，最早由 Jez Humble 在《The DevOps Handbook》系列的討論中提出，用來描述一個組織要走向 DevOps 需要同時成立的五個條件。",[15,19,20],{},"它常被誤用成一份「導入清單」——CI\u002FCD 裝好、Grafana 儀表板做好、就打勾說「我們 DevOps 了」。但這五個字母彼此互為前提：沒有文化上「出事不究責」的安全感，自動化只會把犯錯的速度變快；沒有量測，精實改善無從驗證；沒有分享，前面四項全部卡在少數人身上，離開就斷層。",[15,22,23],{},"真正有用的用法，是拿它當一份自我診斷表：團隊現在踩了哪個字母的坑，資源就該優先投在那裡，而不是每個字母都均勻地花錢買工具。",[10,25,27],{"id":26},"culture先問出事之後第一個問題是誰還是為什麼","Culture：先問「出事之後，第一個問題是誰還是為什麼」",[15,29,30,31],{},"文化是五個字裡最抽象、卻決定其他四個能不能落地的一項。實務上最快分辨團隊文化健不健康的問題是：",[32,33,34],"strong",{},"發生 Incident 之後，會議室裡第一句話是「這是誰改的」還是「發生了什麼、我們怎麼避免下次再發生」。",[36,37,38,42],"ul",{},[39,40,41],"li",{},"前者是究責文化（Blame Culture），工程師學到的教訓是「少改東西、少扛風險」，長期結果是沒人敢碰核心系統，變更集中在少數「敢做」的人身上",[39,43,44],{},"後者是無究責事後檢討（Blameless Postmortem）文化，把焦點放在系統性原因——為什麼這個錯誤沒有被測試攔下來、為什麼監控沒有更早示警、為什麼一個人的失誤可以直接影響到生產環境",[15,46,47],{},"該問的問題：團隊寫的 Postmortem 裡，行動項目（Action Item）是「加強某某人審查」還是「補上某個自動化檢查、修正某個流程缺口」？前者是文化沒到位的訊號。",[10,49,51],{"id":50},"automation自動化的順序通常應該是部署-測試-環境","Automation：自動化的順序，通常應該是「部署 → 測試 → 環境」",[15,53,54,55],{},"自動化常被簡化成「把 CI\u002FCD 建起來」，但 CI\u002FCD 只是自動化裡最顯眼的一塊。更完整的問法是：",[32,56,57],{},"團隊裡有哪些步驟，還在依賴某個人手動執行、手動記得要做、只有他知道怎麼做？",[15,59,60],{},"這些步驟不分好壞，都是自動化的候選名單，常見的排序原則是先做「頻率高、風險低、規則明確」的事：",[36,62,63,69,75],{},[39,64,65,68],{},[32,66,67],{},"部署流程","：手動 SSH 上機、手動跑腳本，是最常見也最該優先自動化的部分——風險最高、又最常做",[39,70,71,74],{},[32,72,73],{},"測試","：自動化測試套件（Unit \u002F Integration \u002F E2E）要能在 CI 裡穩定跑完，而不是「本地測過就上」",[39,76,77,80],{},[32,78,79],{},"環境建置","：用 IaC（Terraform、CloudFormation）取代手動在主控台點設定，讓環境本身也能重現、能被版本控制",[15,82,83],{},"常見誤區：自動化的目標不是「消滅人的判斷」，而是消滅重複、機械化、容易手滑的步驟，把人的判斷力留給真正需要判斷的事情（例如：這次變更要不要上、風險評估）。",[10,85,87],{"id":86},"lean把還在做的浪費找出來而不是先加流程","Lean：把「還在做的浪費」找出來，而不是先加流程",[15,89,90],{},"Lean（精實）源自製造業的精實生產，核心精神是持續辨識並移除「浪費」（Waste）。在軟體交付的情境下，常見的浪費包括：",[36,92,93,99,105],{},[39,94,95,98],{},[32,96,97],{},"批次過大","：累積一個月的變更才一次上線，出問題時不知道是哪個改動造成的，回滾成本也高",[39,100,101,104],{},[32,102,103],{},"等待","：一個 PR 卡審核卡三天、一個環境申請要走簽核流程一週",[39,106,107,110],{},[32,108,109],{},"交接損耗","：需求從 PM 傳到工程師、再傳到維運，每次交接都遺失一部分上下文，導致重工",[15,112,113],{},"該問的問題：從一行程式碼被寫出來，到它真正在生產環境跑起來、產生價值，中間有多少步驟是在等待，而不是在做事？精實的第一步永遠是先把整條交付流程畫出來（Value Stream Mapping），再決定要優化哪一段，而不是先加一堆新流程、新工具。",[10,115,117],{"id":116},"measurement先能回答這次改動有沒有變好才能談持續改善","Measurement：先能回答「這次改動有沒有變好」，才能談持續改善",[15,119,120],{},"沒有量測，前面三項都無法驗證是不是真的有效——文化變好了嗎？自動化真的省下時間了嗎？精實改善真的縮短前置時間了嗎？",[15,122,123],{},"DevOps 圈子最常用來量測交付績效的是 DORA（DevOps Research and Assessment）四大指標：",[125,126,127,140],"table",{},[128,129,130],"thead",{},[131,132,133,137],"tr",{},[134,135,136],"th",{},"指標",[134,138,139],{},"衡量什麼",[141,142,143,155,166,177],"tbody",{},[131,144,145,152],{},[146,147,148,151],"td",{},[32,149,150],{},"部署頻率","（Deployment Frequency）",[146,153,154],{},"多久上一次線",[131,156,157,163],{},[146,158,159,162],{},[32,160,161],{},"變更前置時間","（Lead Time for Changes）",[146,164,165],{},"從 commit 到上線要多久",[131,167,168,174],{},[146,169,170,173],{},[32,171,172],{},"變更失敗率","（Change Failure Rate）",[146,175,176],{},"上線之後導致問題的比例",[131,178,179,185],{},[146,180,181,184],{},[32,182,183],{},"服務恢復時間","（Time to Restore Service）",[146,186,187],{},"出問題後多久能恢復",[15,189,190],{},"這四個指標刻意同時看穩定性與速度——只看部署頻率會鼓勵「衝快但常常壞」，只看變更失敗率又會鼓勵「怕出事乾脆少上線」，四個一起看才不會顧此失彼。實務上不需要一次到位地精算，先能穩定拿到這四個數字的粗略趨勢，就已經比完全沒量測進步很多。",[10,192,194],{"id":193},"sharing知識卡在一個人身上就是團隊最大的單點故障","Sharing：知識卡在一個人身上，就是團隊最大的單點故障",[15,196,197],{},"分享指的是把知識、工具、經驗跨團隊、跨角色地流通，而不是留在少數人腦中或某個沒人維護的 Wiki 裡。常見的實踐方式：",[36,199,200,206,212],{},[39,201,202,205],{},[32,203,204],{},"內部技術分享","：把踩過的坑、解決問題的過程整理成文件或分享會，而不是解決完就結束",[39,207,208,211],{},[32,209,210],{},"共用工具與範本","：Runbook、部署腳本、監控儀表板範本統一維護，而不是每個團隊各自重造輪子",[39,213,214,217],{},[32,215,216],{},"輪值與結對","：讓值班（On-Call）、部署這類「只有某人會」的工作，透過輪值或結對逐漸擴散給更多人",[15,219,220],{},"該問的問題：如果團隊裡「懂最多」的那個人請假一週，會不會有東西因此卡住？如果答案是會，代表分享這一項還沒做到位，而這通常也是知識最集中、風險最高的地方。",[10,222,224],{"id":223},"用-calms-做自我檢查而不是導入清單","用 CALMS 做自我檢查，而不是導入清單",[15,226,227],{},"實務上判斷團隊卡在哪個字母，可以用下面這張表快速定位：",[125,229,230,240],{},[128,231,232],{},[131,233,234,237],{},[134,235,236],{},"症狀",[134,238,239],{},"通常對應的維度",[141,241,242,250,258,266,274],{},[131,243,244,247],{},[146,245,246],{},"出事就開始找戰犯，沒人敢碰核心系統",[146,248,249],{},"Culture",[131,251,252,255],{},[146,253,254],{},"部署還要靠一個人手動跑腳本",[146,256,257],{},"Automation",[131,259,260,263],{},[146,261,262],{},"PR 卡審核好幾天、環境申請要走簽核",[146,264,265],{},"Lean",[131,267,268,271],{},[146,269,270],{},"說不出這次改動到底有沒有變好",[146,272,273],{},"Measurement",[131,275,276,279],{},[146,277,278],{},"某人離職／請假，某個流程就沒人會",[146,280,281],{},"Sharing",[15,283,284],{},"CALMS 的價值不在於背下這五個字，而在於每次要導入新工具或新流程之前，先問一句：這解決的是文化、自動化、精實、量測還是分享的問題？如果答案不清楚，很可能只是在給一個沒被真正診斷出來的問題，貼上一塊新的 OK 繃。",{"title":286,"searchDepth":287,"depth":287,"links":288},"",2,[289,290,291,292,293,294,295],{"id":12,"depth":287,"text":13},{"id":26,"depth":287,"text":27},{"id":50,"depth":287,"text":51},{"id":86,"depth":287,"text":87},{"id":116,"depth":287,"text":117},{"id":193,"depth":287,"text":194},{"id":223,"depth":287,"text":224},"2026-09-21",null,"md",{},true,"\u002Farticles\u002Fdevops-calms-framework",{"title":5,"description":286},"articles\u002Fdevops-calms-framework",[305,306,307,308],"DevOps","CALMS","團隊文化","工程實踐","m0dIxAvcZ9TG7HoLq1hXbmXZgGWlpu8TgAjRg5C9Ugo",1792959149882]