為何要關注 SRE 自身的反模式#
開發階段的反模式若未被攔住，會直接傷害 production 的可靠性與可用性。SRE 是最後一道防線——但 SRE 流程本身也有專屬的反模式，若不主動辨識會反而變成系統的瓶頸。
反模式像陷阱：有時是團隊明知故犯，有時則是某個流程被打破後的連鎖效應。它們既傷可用性，也加重專案成本。
Misconfigured Alerts（誤設告警）#
告警是可觀測性的核心，但設錯告警會讓正確警示被淹沒，或讓真正的失敗無聲無息。
常見成因#
- 手動設定告警時把新服務的告警掛到名字相近的舊服務上，且沒有自動驗證
- 服務退役時告警未一併移除，產生雜訊
- 客製告警掛到錯的通知頻道（信箱、Slack channel）
- 將「無需動作的提示性告警」與「真正需動作的告警」混在一起，導致告警疲勞（alert fatigue）
告警疲勞是長期的隱形殺手。SRE 看膩告警後會本能忽略，真正的事故可能就此錯過。
Incorrect Ticketing（錯誤工單）#
告警與工單緊密相連。把不該變工單的事件變成工單，是另一個常見反模式。
常見情境#
- 為低優先級或可自動化解決的問題開立工單，分散 SRE 注意力
- 把例行修補與升級這類可自動驗證的工作做成手動工單，讓 SRE 重複勞動
不是所有事件都該成為工單。SRE 應該定期檢視工單分類規則，剔除浪費注意力的雜訊。
No Automated Remediation（缺少自動修復）#
自動化是 SRE 的心臟。已知問題若仍靠手動修復，會放大人為錯誤、加速 SRE 燃燒。
常見徵兆#
- 高 CPU、高記憶體告警仍由人工擴充
- 服務間歇性失敗仍需人工逐一驗證
任何「重複出現、有固定處理流程」的告警都應該被自動化。手動處理不只慢，還容易出錯。
No Change Management Process（缺乏變更管理）#
變更是不可避免的，但缺乏完整的變更管理會讓任何改動都成為高風險動作。
案例#
- 開發提出「為資料庫新增一張表」的變更，誤填為「建立新使用者並建表」。沒有驗證流程，執行者直接 force create，覆寫既有使用者密碼，多項服務因認證失敗而當機
- 兩個變更同時要在兩個區域升級 OS。沒有驗證流程，最終雙區同時故障，全應用中斷
變更管理應該被視為獨立的、自動化的流程，並要求對應審核者把關。沒有它，每次變更都是賭注。
Unrealistic Expectations / Chasing Nines（追逐五個 9 的迷思）#
有些團隊把可用性目標訂在 100% 或 99.99999%（五個 9）。雖然這是常見的可用率衡量單位，但沒有任何系統能 100% 持續上線。
受維護、升級、自然災害等外部因素影響，100% 是不可能的目標。對外承諾這個目標會讓終端使用者與團隊都背上不切實際的期待。
要維持五個 9 以上，必須有完全自動化、零失敗紀錄、超高技術團隊——實務上幾乎無法持續。
Pinpointing / No Blameless Post-mortem（指責文化、缺少無責事後檢討）#
事故發生時，若團隊把時間花在追究「是誰造成的」，會嚴重拖慢復原與根因分析。
SRE 強調「無責事後檢討（blameless post-mortem）」：把焦點放在原因與預防，而非究責。指責文化會讓人隱藏錯誤、阻礙真實學習。
反模式的整體影響#
以上五大反模式共同作用時：
- 影響 SRE 的日常工作節奏
- 直接拖累系統可靠性
- 讓持續改進變得困難
不是所有專案都能套用全部 SRE 最佳實踐，但所有反模式都該避免。把 SRE 從反模式中解放，他們才能專注於創新與可靠性。