Site Reliability Engineering 概念與實作

前言

在現在事事講求商機的時代，商業功能的需求越來越多也越來越急，落後的功能可能就導致企業失去了市場，以致於服務團隊不斷的衝刺功能而有時將穩定的做法降級。又或著，大家都在追求功能實踐，覺得串得起來就是成就而往往忽略了穩定與運維的後續。直到服務出問題導致形象的損害才悔不當初。因此筆者強烈的建議穩定的設計要在開發與維運時要不斷檢視，不是在要推出服務的最後一關才做。

SRE

Site Reliability Engineering （簡稱：SRE），這個概念最早由 Google 工程團隊 Ben Treynor Sloss 提出。當全世界在大喊什麼都要 DevOps 與 Agile 時，Google 的工程團隊提出了 Site Reliability Engineering 概念，並公開了許多 SRE 人員的工作內容。Google 希望透過這樣的角色維持服務的穩定。

筆者在讀過這本書後，認為身為一個 SRE 要一直有擁抱並管控風險、不斷簡化複雜度、安全設計這三個觀念。當中最強調的是要透過擁抱並管控風險而不斷的進化服務，不能一直用舊的設計來應付新的市場。

在日常工作中，筆者認為 SRE 需要將下述三個做法不斷的實踐在服務中。

• Automation: 對於 online 的服務，沒有自動化部署的服務就如同賭博一般，手動的調整帶著極高的風險。
• Visibility: 在服務上線前 Telemetry 要預先準備好了，相關的 Monitoring 與 Log 都應該在 Production 環境的前一個環境驗證。如果你的監控是在上線後才設定，那代表著上線的那一刻成敗是無法衡量的。
• Reduction: 在工作中常常會有新的工具或新的服務出現，也許在快速迭代的世界中你有一些權衡，但要不斷的回顧與檢討更好的做法來減化複雜度。

當漸漸完成上述的做法服務會漸漸的達到高 SLA 等級，再不斷的循環上述的做法就可以將服務的範圍漸漸擴大。

實作

在提出上述的觀念與初步做法後，筆者根據 DevOps 實踐 loop 提供了下述的步驟。其中的小圖示是該階段讀者們可以考慮的工具。

眾所皆知 DevOps Loop 開始於 Plan 並經過 Build, Continuous Integration, Deployment, Operation, Continuous Feedback 後到 Plan 再繼續的走。筆者認為在這個 Loop 中的各階段 SRE 也有主要的事要做。

Plan

在這個階段 SRE 也像是開發團隊般試著尋找更好的解決方案，例如在 Kubernetes 1.15 版本後就提供了 kubctl rollout 的功能，有需要檢查或進一步要重啟 Pod 狀態都可以實現，而不需要透動手動一個一個砍 Pod 或更暴力的方式來達成。

Build

一個好的 Practice 對於穩定會是快速的進步，如手動變自動就是把人為錯誤因素減少。再如一個好的工具導入也可能為服務帶來極大好的變化。

Continuous Integration

在這個階段，SRE 一定要確保服務的設計有足夠的 reliability，並一定要確保佈署是透過 CI/CD 工具，而不是手動操作。

Deployment

發佈時的合作，除非服務有高度的獨立性，要不然服務的變化可能會影响著許多相關者，所以服務的改變是一個重要的議題，任何一次的 change 都需要有好的計劃。在佈署前也要準備好 recovery plan，如此才能應對風險，再者，負載平衡設計也需要在佈署前確認完成，這不單單指網路的負載平衡器，而是任何負載平衡的設計，如讀寫分流等。千萬不能忘的還有監控，沒有監控就像是在黑夜中關著大燈開車，任何的危機都無法提早反應。

Operation

在維運的階段確保 SLA 是最重要的任務，而當危機發生時 SRE 需要第一時間處理問題，需要在最短的時間內把服務帶回。

進一步，SRE 可以考慮進行 Chaos Engineering ，驗證服務的設計可以應付各種狀況。

題外話，筆者近期實作了提高 SLO 專案，筆者會另外寫一個 “Incident Prevent Practice" 文章分享。

Continuous Feedback

在每個服務運作的過程中多多少少都會遇到問題，而任何的問題都應該被記錄與追蹤並進一步思考進步的可能性，再往 Plan 的階段前進。

最後筆者要提醒讀者們，在實作 SRE 時，一定會遇到各種各樣的問題，建議各位一定要了解問題影響的程度，也許一個忽視的小問題在未來變成大問題。

如果讀者們對於 SRE 有更好想法也請讓筆者知道，就如上圖所示，業界的做法一定會越來越好，每一個人都應該抱持不斷回顧的心態，服務才會穩定。