為何 SDLC 已含可靠性，仍需要獨立 SRE#

在 SDLC 中每個階段都已強調可靠性：

  • 設計團隊把擴充性與韌性納入架構
  • 開發團隊遵循最佳實踐
  • 測試團隊用端到端測試案例提升覆蓋

那為什麼還需要 SRE？因為 SRE 站在最後階段，能看到「整體」的可靠性：

  • 360 度視角觀察產品從交付前到上線後
  • 整合來自多服務、多依賴系統、實際使用者負載的訊號
  • 觀察到單一團隊看不到的整體現象（外部整合、第三方依賴、混沌情境）

設計、開發、測試各自負責「自家可靠性」；SRE 負責「合併後的可靠性」。

案例：阻擋潛在的可靠性問題#

開發團隊完成新功能、QA 通過測試。SRE 用工具進行擴充性驗證時發現某情境失敗，於是把程式碼退回設計與測試。這就是 SRE 在守住「最後一道可靠性閘門」的具體展現。

SRE 必備技能組合#

軟體編碼#

  • 不限語言，需具備寫工具與修補非功能性 bug 的能力
  • 熱門語言：Python、Go、Java

自動化／腳本撰寫#

  • 把重複手動工作自動化
  • 熱門語言：Python、Linux/Unix Shell、PowerShell（Windows）
  • 「Coding 蓋大樓、Scripting 鋪小路」是常見比喻

ITIL 知識#

  • 了解 IT 基礎建設庫（Information Technology Infrastructure Library, ITIL）流程
  • 兩大重點：
    • Release & change management：合作審查並落實變更
    • Incident management：管理工單、優先排序、嚴重度與處理流程

CI/CD 管線設計#

  • 雖多由 DevOps 主導，SRE 也常需建構或重用管線
  • 工具：Jenkins、Ansible、Terraform

雲端運算#

  • 熟悉至少一個雲端平台（AWS、Azure、GCP）
  • 了解雲端原生應用的部署與監控
  • 能在雲上建立管線、儀表板

資料庫管理#

  • 同時涉及關聯與非關聯式資料庫
  • 常見：Couchbase、MongoDB、Apache Cassandra、Oracle NoSQL（NoSQL）；Oracle、Postgres、DB2、MySQL（RDBMS）

分散式基礎設施#

  • 高可用必備分散式架構
  • 與雲端、作業系統知識重疊

系統管理#

  • 安裝、配置、安全、監控
  • 對 OS、網路、版本管理有基本掌握

工具熟悉度#

  • 監控：Grafana、Prometheus、AppDynamics、DataDog、Dynatrace、Splunk、Nagios、New Relic
  • 日誌：Splunk、FluentD、Logstash、SumoLogic、SolarWinds
  • 版控：GitHub、GitLab、Bitbucket、Azure DevOps、SourceForge

軟性能力#

  • 溝通：跨團隊協作、把技術翻譯成商業語言
  • 解決問題：每天都會碰上的核心能力

不必擁有清單上每一項技能。50% 涵蓋率就足以入門 SRE，剩下的可在團隊中互補與成長。

SRE 的常見入門背景#

  • 軟體開發者、軟體測試者
  • DevOps、系統管理員
  • 基礎設施工程師、production 支援工程師、架構師

入門條件#

對開發、雲端、作業系統有基本理解，就能踏入 SRE 領域。後續可以依專案需求補強更深的技能。

Backward SRE 的一天 角色與責任 Forward