儘管站點可靠性工程已經存在了一段時間，但也只是最近纔在業界獲得一些名聲。但人們對於站點可靠性工程師（SRE）的作用仍然存在很多疑問。我們所知道的大部分內容來自谷歌的《站點可靠性工程》一書。我們將在這篇文章中多次提到這本書。
人們將SRE與運營、系統管理員等進行比較，但這種比較不足以說明他們在現代軟件環境中所發揮的作用。他們承擔的責任多於運營。他們通常具有系統管理背景，同時也具備軟件開發技能。SRE結合了所有這些技能，確保複雜的分佈式系統能夠順利運行。
那麼他們是怎麼做到這一切呢？
自動化一切
自動化是SRE角色與傳統運營團隊之間的一個區別。在過去，運營人員會通過執行腳本、按下按鈕和其他手動操作來讓軟件系統保持運行。然而，在SRE世界中，人們非常重視自動化。這種驅動力來自SRE角色的工程方面。
當軟件開發人員處於日復一日重複相同功能的境地時，他們將被迫實現自動化。這就是軟件開發人員最擅長的事情。自動化並不僅限於對軟件構建和一些驗收測試進行自動化，還包括CI/CD和基礎設施的創建和修補，以及監控、警報和自動響應某些事件。在谷歌的《站點可靠性工程》一書中，這也被稱爲消除辛勞：
辛勞是一種與運行生產服務相關的工作，它往往是手動的、重複的、可自動化的、戰術性的，缺乏持久的價值，並隨着服務的增長呈線性增長。
那麼爲什麼我們要如此關注如何減少辛勞呢？減少工作量不僅使流程可重複和自動化，而且還爲SRE提供了更多的時間用於構建工具和研究基礎設施變更以便進一步提高站點可靠性。總之，工作量越少，用於確保軟件生態系統可靠運行的時間和資源就越多，你就能越快地實現業務價值。
監控分佈式系統
隨着分佈式系統的普及，對監控的需求也在增長。僅僅啓動和運行應用程序是不夠的。我們還需要確保基礎設施運行正常，並確保所有其他內部依賴項都可訪問且運行正常。此外，應用程序的業務功能應該提供適當的監控功能，以驗證它們是否運行正常。
提供待命支持
與傳統的運營角色類似，SRE也有輪班待命的職責。除了監控基礎設施和他們自己的服務之外，開發團隊還可以向他們諮詢和請他們一起進行故障排除。
輪班待命看起來是怎樣的？通常，SRE根據計劃表進行輪班待命，計劃表可以讓其他SRE專注於工程方面，而且不會導致輪班待命工程師感到倦怠。輪換待命可以從幾天到一週不等，或者更長時間。
在發生高優先級的事件時，SRE需要調查和診斷問題。他們還可能會要求其他工程師或軟件開發人員一起來解決問題。根據系統的SLA，他們可能需要一起工作才能在幾分鐘內解決問題。對於低優先級問題，SRE通常會在工作時間內處理它們。對於那些不喜歡在凌晨3點鐘起牀的工程師來說，這是一個好消息。
管理事件
管理事件時SRE角色的另一個重要部分。你可能會說這與輪班待命沒有什麼兩樣。找到問題然後解決它，這能有多難？
好吧，在管理事件時，SRE需要運用額外的專業技能來確保一切順利。例如，在發生中斷時，可能有很多方法來診斷和解決問題。因此，爲了妥善管理事件，必須有人監督和促進所有相關人員的行爲。這就需要定義明確的角色。
雖然並非所有公司都包含谷歌推薦的角色，但我們至少應該考慮它們。這些角色包括：
- 一名事件指揮官，對所發生的一切都保持高度關注；
- 處理或修改基礎設施或系統的工程師；
- 將正確的信息傳遞給客戶和管理層的溝通者角色；
- 負責規劃會議、交接和後勤需求的規劃者角色；
- 如果SRE沒有明確定義的角色，那麼當他們在嘗試不同的解決方案時，如果沒有前期協調和溝通，就容易發生混亂。
事後調查
我們已經經歷並解決了一個事件，現在準備好進行事後調查。通常，SRE會促進或參與這些事後調查。
在進行事後調查時，所有相關方都被匯聚在一起，目標是分析事故期間都發生了什麼，並找出根本原因。參與者還將決定將來如何防止或修復同樣的事件。下面列出了事後調查將產出的內容：
- 提高可靠性的故事或監控；
- 附加文檔，以協助未來事件的處理；
- 進一步調查或測試，以證實與事件有關的任何假設。
跟蹤中斷
SRE的另一個職責是跟蹤中斷。這最終有助於識別長期趨勢和創建合理的SLO和SLA。
跟蹤中斷的用途包括監控低優先級事件。這些事件可能不會給消費者帶來真正的問題，但是觀察長期趨勢和時間可以幫助隔離和解決那些似乎找不到原因的煩人bug。
與開發團隊合作
除了在輪班待命期間爲開發團隊提供支持，SRE還提供諮詢和故障排除服務。這樣可以幫助其他SRE團隊和軟件開發團隊，這些團隊苦於處理運營或可靠性問題。
在這種情況下，SRE將評估當前問題，並確定哪些可以通過自動化或工程工作進行改進。SRE還可爲可靠性問題提出解決方案。最重要的是，SRE將推動團隊流程的變革。這些變化將確保站點可靠性工程團隊能夠增強團隊交付價值的能力。
創建服務水平指標和目標
當你聽到有人說服務已經達到或正在努力達到99.99％的正常運行時間時，他們指的是服務水平目標（SLO）。服務水平指標（SLI）用於衡量這些目標。換句話說，SLI是關於如何衡量SLO的協議。SRE通過提供歷史服務性能數據來協助這些工作。它們還有助於爲未來提供切合實際的目標，並可能爲客戶提供適當的SLA建議。
然後，SRE會確保你的應用程序滿足（但不超過）規定的SLO。現在你可能會認爲沒有超過SLO會很奇怪。然而，製造超出實際需要的東西是對資源的浪費。SRE平衡了客戶需求和所提供服務的目標。
職責可能會有所不同
在這篇文章中，我們討論了站點可靠性工程師參與的各種活動。雖然這些活動是由SRE完成的，但並不是一成不變的。公司會根據需要改變SRE的角色和職責。一般而言，處於SRE過程不同階段的公司可能有不同的需求。
例如，新公司可能需要SRE的支持才能控制一般性中斷。大部分能量都趨向於可靠性的基本水平。但是，在這一過程中走得更遠的其他公司可能已經消除了公司範圍的中斷。他們可能會花更多時間來改進或驗證與業務相關的服務指標。例如，在網站的普遍可用性達到穩定和可靠的狀態之後，你的披薩店應用程序可能需要對披薩推薦機制進行新的監控。
結論
正如你所讀到的，SRE將時間花在技術和流程方面的職責上。他們不僅僅是運營或系統管理團隊。他們利用自己的工程技能自動化和減少管理任務所需的人工干預。此外，他們還與其他工程團隊合作，提供適當的監控、事件響應和管理。
隨着時間的推移，這些職能提高了分佈式系統的可靠性並降低維護成本。最後，他們通過組織傳播站點可靠性工程文化，讓所有團隊都能學會在做出決策時以可靠性作爲出發點。