反模式如何傷害系統表現#

反模式是各種「短期省力、長期付出」的捷徑：草率的快修、糟糕的設計、不遵循流程。它們可能解燃眉之急，卻會在系統可靠性與擴充性上留下永久後遺症。

沒有任一反模式能孤立存在。它們會層層疊加、彼此放大，最終都落在 SRE 的工單與 production 上。

服務設計反模式對可靠性的傷害#

• 設計是系統可靠性的基準
• 不良設計會引入難以追蹤的 bug，或讓已有 bug 難以被監控察覺
• 即便監控建得再好，底層程式碼糟糕仍會帶來缺陷與當機

監控與可觀測性反模式的影響#

• 可觀測性是 SRE 的核心工具：失靈時 SRE 就「看不見」也無法及時介入
• 多層守門互補：例如在服務設計引入了反模式，但只要可觀測性夠強仍能補住；反過來也成立。當兩者都失守，故障就無法被即時偵測，影響使用者並阻擋擴充

發布與部署反模式的衝擊#

• 發布管理是控制「壞變更」進入系統的最後關卡
• 一個大型系統每天可能跑 1000 多支微服務，發布反模式會把品質直接打折
• 例：版本錯誤部署到 production，雖然設計沒問題，但流程沒守住，仍可能造成重大事故

變更管理反模式的衝擊#

• 變更管理與發布管理是雙生關係：變更管理紀錄、優先排序，發布管理執行
• 反模式存在時，變更失去掌控，SRE 無法判斷哪些是真正關鍵
• 這類問題通常不會直接造成 bug，但會讓 SRE 把時間花在錯的事情上

事件與缺陷管理反模式的衝擊#

• 直接影響 MTTR（Mean Time To Recovery）與 MTTD（Mean Time To Detect）
• 例：高優先級事件未被優先處理，最後演變成全應用當機，使用者完全無法存取

MTTR 與 MTTD 會直接寫進每月可靠性報表。事件管理沒做好，數字就會難看，而且難以解釋。

錯誤處理反模式的衝擊#

• 範例：開發把 ERROR 印在 INFO log。事故發生時，SRE 與 dev 都只看 ERROR/WARN，因此找不到關鍵訊息，最後拖延修復、造成多服務當機

溝通文化反模式的衝擊#

• 文化反模式高影響但常被忽視
• 包括最佳實踐、無責檢討、不孤立、跨團隊協作、透明度、主動解決問題
• 文化基調得從一開始建立，由領導者持續推動；技術無法替代文化

把每個反模式視為「對系統可靠性與擴充性的一張支票」，每張未兌現的支票都會在某天被退票。SRE 要做的不是逐張處理，而是改造寫支票的環境。