CAMS 為何而生#
CAMS 模型代表四個面向：
- 文化（Culture）
- 自動化（Automation）
- 量測（Measurement）
- 分享（Sharing）
在 DevOps 與 SRE 出現前，許多組織被穀倉化、互相推卸責任。CAMS 是從 Agile、DevOps、SRE 中提煉出來的整合框架，專治這個老問題。
文化（Culture）#
文化是日常實踐的同一套標準、流程與願景：
- 願景（Vision）：由領導層由上而下定義，所有專案承襲它。例如旅遊公司的願景是「成為全球領先的線上旅行社」
- OKR（Objectives and Key Results）：依願景訂出可量測的目標與里程碑。例：目標是改善應用效能，KR 就是效能指標
- 標準與流程：跨團隊共用的缺陷管理、事件管理、測試、部署流程；組織級訂規範，團隊內自由補小流程
- 工具與軟體：開發、SRE、DevOps 共用同一批工具（如 Jira），增加協作機會
創新與穩定常被視為對立。CAMS 文化的關鍵在於：開發追求創新、SRE 與 DevOps 用自動化與監控帶來穩定，目標一致、手段互補。
自動化（Automation）#
自動化在 CAMS 中扮演「跨團隊協作橋樑」：
- 透過自動化消除 toil、節省時間與成本
- 自動化要列為企業級目標，並反映在團隊 OKR 與 KPI 上
- 例如 DevOps 建的 CI/CD 管線同時被開發、測試、SRE 共用，自然形成共同語言
跨團隊重用自動化工具，比為每個團隊各自打造自動化更有效率，也是建立共同文化的具體實踐。
量測（Measurement）#
量測是 CAMS 的驅動引擎：
- 沒有量測就無法評估改進
- SRE 應在 SDLC 一開始就定義目標與里程碑
- 每個里程碑都做評估與回顧（retrospective），找出阻礙並調整
推薦的 SRE 量測項目#
某次新功能上線一個月後，可衡量：
- 應用程式失敗百分比
- 各類失敗的 MTTR
- 失敗之間的 MTBF
- 已自動化的手動任務比例
這些指標背後的問題（自動化是否真有效？告警是否真的縮短復原？自我修復是否真的提升穩定？）才是改進的真正槓桿。
分享（Sharing）#
CAMS 中最容易被忽略、卻最重要的面向。它是人性的、難以靠技術解決：
兩個分享要素#
開放（Openness）：團隊願意彼此補位、共享知識
- 定期知識轉移（knowledge transfer）會議
- 資深成員 mentorship 機制
- 回顧（retrospective）會議理解挑戰
- 規律的肯定與表揚
透明（Transparency）：領導與團隊對專案進度、成員工作狀態彼此公開
- 用中央工具追蹤專案績效
- 共享每位成員的每日任務追蹤
- 每日同步會分享卡關，讓他人協助
- 跨團隊定期會議交換挑戰
CAMS 的獨特之處在於 Sharing——技術可以買，文化要靠人。把分享文化建立起來，SRE 才能真正落地，而非只剩工具與流程的軀殼。
Agnostic Approach：跨平台不可知#
Agnostic（不可知）方法指軟體不被綁定特定框架、平台或技術。常見做法：
- 選擇與作業系統、伺服器無關的語言與框架
- 設計可搭配任意資料庫、任意雲端的架構
- 程式碼易於擴充並移到新基礎設施
- 日誌、監控指標可被任意工具消費
- CI/CD、前後端框架可分別替換
案例：從 AWS 遷往 GCP#
一個線上配送平台原本部署在 AWS。某天業務決定改用 GCP。Java/React 都是雲端不可知，加上開發者一開始就把組態與程式碼分離，搬遷只需替換底層配置，省下大量重寫工。
優點與代價#
優點：
- 長期省成本（未來搬遷不必重做）
- 工具選擇彈性高，可在不同工具間切換
- 易於水平/垂直擴充
- 自由度與控制力大
- 對長期成長的企業是穩健投資
代價：
- 前期建構成本高，可能需從零搭建
- 需要稀有的技能組合，人才費用偏高
- 可能放棄特定雲端的獨家功能
Agnostic 並非萬靈丹。對小型短期專案、或希望充分用某雲服務的應用，Agnostic 反而帶來不必要的成本。應依專案壽命、規模、未來預期演進審慎評估。
沒有量測就沒有改進#
最後再強調一次：「沒有量測就沒有改進」適用所有產業。SRE 的版本是定義量測指標，把改進建立在客觀資料上。
SRE 的核心量測項#
- MTTR：恢復時間
- MTBF：故障間隔
- 系統上線率（uptime）
- 系統延遲（latency）
- 資源使用率：CPU、記憶體與閾值設定
- 負載平衡、錯誤率、回應時間
每個指標背後都串接一系列追問：自動修復？人工恢復？是否有告警？根因為何？是否在測試環境出現？是否與某次變更相關？這些追問會直接指向改進的方向。
把指標的「是否達標」改成「為何達標／為何未達標」，量測才會真正驅動改進。