多元背景組成的 SRE 團隊#

SRE 團隊由多種技能組成，每位成員專長不同：監控、開發、基礎設施、變更審查、設計討論。以下用四個工作日案例呈現他們的日常。

假設這個 SRE 團隊同時負責工程與運維。

案例 1：早班排查 + 下午自動化開發#

• 工程師登入 ITSM，工具自動分派工單
• 進入監控儀表板查看系統健康
• 透過協作平台留意告警通知
• 兩張低優先級工單入隊，SLA 4 小時
• 注意到某服務出現 HTTP 500
• 從日誌工具拉相關紀錄
• 進變更管理工具，檢視該服務 24 小時內的變更
• 透過知識庫工具比對歷史告警
• 鎖定下游服務的某次變更，登入原始碼進行檢視
• 在本地除錯後確認下游變更導致 HTTP 500
• 與開發合作回退變更
• 同步用內部工具把流量切到其他健康區域，避免業務中斷
• 為新版本建立缺陷工單
• 半天後交班；後半段轉戰自動化工程任務
• 開發新工具後，與團隊在當日會議中分享經驗、補充知識庫
• 使用工具：VSCode + Python、ITSM、變更管理、Splunk、Kibana、GitHub、Jenkins CI/CD

案例 2：客戶申訴與混沌工程#

• 工程師早上監控系統並關注高優先級工單
• 客戶反映某功能無法使用
• 為該服務臨時開啟 debug log，蒐集 3 天紀錄
• 鎖定問題後，發現原本沒有對應告警，於是建立工單請 SRE 補上
• 通知開發優先修補、回覆客戶現況
• 接著回頭把缺漏的告警設定完成、更新該服務的 runbook
• 切換到工程任務，進入混沌工程
• 列出 chaos 測試案例，使用測試工具建置
• 與 QA 同步交流測試環境發現的混沌情境
• 執行測試後發現「資料庫單一節點下線時應用無法復原」
• 與開發討論服務的連線設定
• 修補方案：在服務中加入資料庫健康檢查
• 本案涵蓋：監控與告警、混沌工程、排錯、開發

案例 3：設計討論 + 實時故障處理#

• 工程師以非運維任務開始一天，先檢視儀表板
• 上午第一場：與架構師討論新功能設計，建議納入服務自動 failover
• 接著參加新服務上線前的知識轉移會議，建議加入重試、告警與日誌
• 同事通報 production 出現故障
• 與另一位 SRE 加入 war room 一起繞過故障
• 透過日誌與最近變更紀錄定位問題
• 與開發合作修補
• 本案涵蓋：系統設計、新服務審查、排錯、協作、程式碼

案例 4：缺陷修補 + 變更審查#

• 工程師檢查任務佇列；其中一項是回顧所有 production 影響可靠性的開放議題
• 列出缺陷，從非功能性缺陷修起（例如為最後一次重試補告警、改 log 等級、加資料庫健康檢查）
• 收到請求審查臨時變更
• 加入審查會議；變更未說明影響範圍，工程師退回，要求補上 rollback 計畫
• 回到缺陷修補
• 本案涵蓋：變更管理、開發、監控

四個案例呈現相同訊息：SRE 的工作可大可小，但 協作 + 解題 + 開發 永遠是核心。

角色與職責摘要#

• 監控與儀表板配置
• 辨識系統 bug 並修復（包含設計、架構、程式碼、基礎設施）
• 基礎設施配置與管理
• CI/CD 管線建構
• 混沌工程
• 變更審查
• 事件管理
• 協作
• 溝通
• 規劃

SRE 職涯起點#

只要你具備以下 2 ～ 3 項技能，就有條件踏入 SRE：

• 軟體開發
• 軟體設計
• 腳本撰寫
• 基礎設施配置
• 雲端知識
• 系統管理 / 資料庫管理
• production 支援經驗

SRE 是「不斷成長的角色」。今天你也許從某個技能切入，明天就會被推進到設計、架構或業務層；保持學習、持續協作，是 SRE 工作能長久的關鍵。