SRE 路上的最佳實踐簡述#

在進入反模式分類前，先複習 SRE 的幾條核心最佳實踐：

• 整體性的變更分析（依賴強健的變更管理）
• 自動化重複性任務以消除冗餘
• 透過技術與流程擴充技能、培養強文化
• 從失敗中學習：知識庫工具、缺陷管理、事件管理、明確流程
• 定義清楚的 SLO

反模式很像「短期看似快速、長期創造障礙」的捷徑——這就是為什麼它們往往以善意的形式出現，卻造成系統性傷害。

遺留系統的反模式#

不少組織仍在使用 legacy 系統，理由包括：系統夠用、規模小、升級困難、預算有限、與新技術不相容等。常見的 legacy 反模式有：

• 軟體與作業系統緊密耦合，難以遷移
• 單體（monolith）架構不易擴充與維護
• 服務間採同步循序流程，更新一個服務需鎖整個應用
• 沿用過時的業務流程

使用 legacy 系統不必然是錯，關鍵在於識別並修正其中的反模式，仍可建構出穩定、夠用的系統。

服務設計階段的反模式#

服務設計是 SDLC 的骨幹。常見反模式：

• 單一服務多重依賴：一支服務被多支服務當作主來源，初期沒事，但隨系統長大會成為瓶頸；解法是預留可拆分的設計，必要時切成微服務
• 單一資料來源：所有服務共用一個資料庫，當資料源出問題時全應用都受影響；解法是定期審視設計、必要時拆分或解除依賴
• API 版本氾濫：所有 API 都建多個版本會讓部署與管理變得混亂
  • 適用情境：同一 API 在不同需求下需回傳不同資料、暫時相容性問題、應用已長期累積多版本
  • 不該濫用：理想情況下，底層服務變動 API 不應破壞，直接覆蓋即可

設計階段的反模式對可靠性影響最大。透過定期 review 與架構文件的回歸，能及早抓出問題。

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

可觀測性是 SRE 的支柱。常見反模式：

• 過量無結構日誌：日誌太多卻無分類，根因分析事倍功半。解法：開發在程式中加入事件碼、嚴重性與時間戳；用 Datadog 等工具進階分組
• 告警雜訊（noise）：重複的低優先級或無意義告警讓真正重要的訊息被掩蓋。解法：與開發合作，從程式或設定面消除錯誤告警；ELK/Kibana 可建立期望規則
• 多儀表板、多工具：跨多個工具排錯極耗時，也增加維運成本。應定期審視工具必要性、整合儀表板
• 指標選錯或取樣錯：例如用 30 分鐘取樣監控一個本來就要跑 1 小時的工作，就會誤報。解法：選用支援自動取樣與異常偵測的工具
• 告警未關聯（no correlation）：相同根因的多重告警散落各處，誤導排查。解法：以 RCA 累積資料訓練監控系統、AI 關聯告警；同時與開發合作預先列出可能連動的告警鏈
• 忽略上下游監控：只顧自家系統，忽略與外部系統的介面、資料流、網路。應把上下游也納入監控

可觀測性的反模式往往讓 SRE「看得見」的範圍縮小。日誌分類、告警關聯、上下游視角是修補的三大重點。

發布與部署的反模式#

發布管理與 SRE 緊密相連。常見反模式：

• 環境不一致：測試與正式環境跑不同版本，問題追蹤困難；採用 Terraform、Ansible、AWS CloudFormation、Puppet、Chef 等基礎設施即程式碼工具（Infrastructure as Code, IaC）保持一致
• 缺乏自動化：大型專案半自動半手動會拖延、易錯
• 無變更守門（gating）：手動觸發部署需 SME 把關，依賴人。Jenkins、GitHub Actions 可內建 gating
• 多工具不統整：不同子系統有自己的 CI/CD 工具，跨團隊協作變沉重
  • 微服務架構下難免有此情境，需強協作與一致標準

變更管理的反模式#

變更管理控管「能進系統的東西」，是發布的上游。常見反模式：

• 缺乏文件：尤其臨時變更未紀錄，事後無從追溯
• 未訂優先級：高優先級被忽略、低優先級擠占資源；應在工具裡內建分類規則
• 單日過多變更：升級、安全修補、bug 修復混在同一天，事故發生時難以歸因；應在規劃階段限制每日數量並保留 ad-hoc 視窗

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

事件與缺陷管理是 SRE 的雙支柱。常見反模式：

• 事件與缺陷未正確分級：高優先級沉在隊列、低優先級先被處理
• 缺乏值班分派流程：多人撞在同一事件、或事件無人接手；應由工具自動指派
• 多條接收通道：信箱、工單、簡訊各送一份，造成重工或漏單；最佳實踐是單一通道，必要時讓所有通道彼此同步
• 缺陷管理未自動化：當監控人手忙於高優先級時，低優先級缺陷常被遺忘，最終演變成事故
• 工具參考：PagerDuty、ITSM、Opsgenie

錯誤處理的反模式#

多屬開發端，但會直接傷害 SRE 排錯能力：

• 錯誤分類錯（如把 ERROR 印成 INFO 或 WARN）
• 完全不處理錯誤
• 日誌訊息含糊或誤導

範例：開發把錯誤印在 WARN 等級。SRE 過濾 ERROR 完全找不到，最後白費時間排錯。

溝通協作的反模式#

• 缺乏明確協作通道：多種工具混用、追蹤分散，重要事項可能被漏掉（例如憑證即將到期沒人確認，造成上線中斷）
• 未自動化協作成果：解法、設計決策沒被記錄，下次發生同樣問題又得重來

文化與團隊的反模式#

• 未用技術強化文化：只在紙上寫「無責文化」，但事故發生時沒有工具紀錄事實，最後仍是團隊互推責任
• 缺乏團隊運作模型：沒明確何時、為何、跟誰一起做事，工作分配與承擔不平均

培育健康文化的策略#

• 根因分析模型：所有事件以 RCA 收尾，而非草草關閉
• 回饋迴路模型：團隊間定期互相回饋，提升透明度
• 同一指標模型：跨團隊共用同一組指標，避免衝突，朝同一目標前進

文化反模式最難量化卻影響最深。工具與流程能輔助，但領導者的示範與堅持才是決定性因素。