SRE與其他框架與其未來

1. SRE與其他框架的整合
2. SRE的演化

SRE與其他框架的整合

我們在本系列的文章提到過，SRE是DevOps的延伸。而DevOps則是IT部門的其中一部分，IT部門還有其他的事情要做。企業應該檢視正他們的整個價值流並優化它們的方法。以下四種框架(包含SRE)可以相互的整合再一起，並且負責各自善長的領域，它們分別是。

• 敏捷將業務與產/服務交付整合成一體
• DevOps提倡持續交付和持續部署機制來驅動速度和流程
• SRE 使業務廣泛關注穩定性和可靠性
• ITSM 在整個價值流中建構組織學習

SRE不是獨立的

SRE團隊可以使用敏捷方法來運作，像是運用Scrum與Kanban這一類的框架。待辦作業清單使SRE工作變得可見，並且可以優先考量能自動化的作業。而相關的SRE儀式確保作業的"協調、可見性和優先順序"。這可以讓我們專注於生產的定義是甚麼。SRE將透過「工作軟體」交付其價值，而這也是敏捷12原則其中之一。

而SRE 和 DevOps/精實是互補的方法，因為它們協助組織:

• 組織的穀倉效應將被進一步的打破
• 交付流水線機更進一步的優化
• DevOps指標與措施更進一步完善
• 自動化更加廣泛和具一致性

SRE 可以透過自動化和工程技術幫助進行 ITSM的相關合規作業。與 SRE 一樣，ITSM 流程可以透過自動化來運行，特別是在過渡和營運流程期間，作為持續測試和交付的一部分。在SRE中，失敗是一個學習機會，持續學習是嵌入在ITSM中的。ITSM 為變更、配置、發布、事故和問題管理等流程（SRE 涉及的領域）提供了指導和架構。

SRE 是交付「系統的系統」的一部分

SRE的演化

組織可以將SRE的精神、原則、實踐套用在以下的角色中

NRE(Network Reliability Engineer)

網路工程師在SRE的原則下需要注重網路的"Availability 與 Reliability"。此角色需要:

• 應用工程方法來"量測和自動化"網路的可靠性
• 編寫 SDN 並將 SDLC 原則應用於 build/test/deploy等 網路變更
• 使用混沌工程測試網路的可靠性
• 監控網路 SLI 並根據建立自動化或手動的回應

DBRE(Database Reliability Engineer)

雲端產生的IaC也影響了DBA這一角色的作業。DBRE需要:

• 運用軟體與工具來自動化以前的手動作業
• 用混沌工程測試來確認DB的failover與restore作業
• 將DB搬移到託管服務 — 如AWS RDS
• 提供組織更多關於資料治理挑戰的創新解決方案

CRE(Customer Reliability Engineer)

最佳的 SLO 閾值可以讓大多數使用者滿意，同時最大限度地降低工程技術成本。CRE需要:

• 將工程思維應用於客戶支援
• 在供應商和客戶之間建立共同責任
• 使用 SRE 實踐來改進客戶應用程式
• 利用自動化（例如自動化事故管理、聊天機器人）來減少過勞

HRE(Heritage Reliability Engineer)

組織的傳統應用程式還是有機會透過SRE的思維與方法得到效益。所以HRE應該:

• 建立聚焦於傳統流程的 SLO，例如 批次時間
• 重新建構現代架構的平台，從Mainframe到X86架構，甚至轉移到雲端
• 透過在工程技術上投入時間來消除過勞
• 投資遙測技術來提高可觀測性
• 執行故障測試以確保關鍵服務可用