什麼是隱藏的反模式#

不同組織與專案對 SRE 的最佳實踐落地差異極大。除了書面上的反模式，還有一些看似誘人、實則危險的隱藏陷阱。它們在短期內提供快修，但日後挪除的代價遠高於一開始就避開。

文化（Culture）#

組織文化決定成敗。健康文化包含協作、賦權、成長型領導、團隊合作、持續學習與工作生活平衡。

文化是漸進的工程，不會一夕成型。一旦走偏，要扭轉非常困難。

案例：被遺忘的 RCA#

一個電商現代化專案做了所有功課：最新工具、優良設計、良好 SRE 實踐。但軟體出現大量小缺陷，SRE 為了避免客戶受影響，每次都靠繞過解掉，沒空和開發走 RCA。幾個月後 RCA 缺席演變成「互相指責」：SRE 把 bug 推到開發、開發被工單淹沒、雙方都感到挫折。最後修復速度下降、客戶流失、競品搶走市佔。

問題就出在「沒有 blameless 文化」這條 SRE 與 DevOps 重要的文化支柱。

解法#

• SRE 與開發共同調查、共同修復
• 透明度與協作能化解大部分指責
• 把 SRE 提早納入功能設計，給予 production 視角；同時讓 SRE 看見開發投入的努力
• 建立持續學習機制，避免「沒時間做 RCA」變成新常態

量測與正確指標選擇#

「無法量測就無法改進」。SRE 兩大常用指標是 MTTD 與 MTTR，但若選錯底層指標，量測就失準。

隱藏陷阱#

• 看似「正確的指標」，但分母或基準錯誤
• 例：MTTD 量測影響客戶的缺陷平均偵測時間，但若沒先做缺陷分級，連「真正影響客戶的事件」都辨識不出，數字就只是好看而已

沒有正確的優先級，就沒有有意義的 MTTD/MTTR。指標只是表面，背後的分類與資料才是核心。

不切實際的 SLO、SLI 與 SLA#

提醒：SLA、SLO、SLI 屬於高階性能衡量；MTTD 與 MTTR 屬於更細粒度的指標。

每家組織都想要 100% 可用，但系統一定會有問題。把 SLA 訂在 100% 是隱性反模式：

• 給開發團隊不合理壓力，逼他們搶救每個微小問題
• SRE 必須繞過所有問題，連客戶不會察覺的小事都得處理
• 團隊累壞、品質妥協、最終以 quick fix 收場
• 這些妥協反過來再傷害系統表現

訂 SLA 時要承認「不完美」是常態。99.9% 可用率背後的 0.1% 是現實，不是失敗。

工具重用的反模式#

重用是好做法，但組織常為了讓各團隊「自由」而忽略重用機會。

風險#

• 各產品團隊各建一套類似工具，缺乏標準化
• 增加技術債、額外成本、減少協作機會
• 每個團隊從外部看交付得不錯，整體組織卻陷入孤島

重用不是強迫統一，而是評估「不同產品的共通需求」並抽出可共用層。一旦重用變成文化，技術債才有機會被控制住。

隱藏障礙的共通特徵#

• 都帶有「短期甜頭」
• 都涉及人、文化或制度，而非單純的技術選擇
• 都需要由領導層主動察覺與導正

把這些隱藏障礙列為團隊定期回顧的固定議題：每季問一次「我們目前最甜的捷徑是什麼？」往往能挖出最危險的反模式。