SRE網站可靠性工程師
SRE需要做什么？
一般:
- 故障模式，尤其是SPOF(單點故障)。消除SPOFs是你作為SRE最大的挑戰和樂趣。
- 基礎設施組件，從應用程序到硬件(服務器、交換機、路由器、互聯網連接、防火牆、isp、互聯網路由(BGP)、IPS系統等)。
應用程序級別:
- 應用程序負載測試、內存泄漏和斷點。
服務器級別:
- 高可用性和系統故障轉移。如何使系統優雅地失敗，而不會丟失事務並從最終用戶的角度保持有狀態。
- 備份系統。
- 硬盤的可靠性和故障轉移(包括RAID功能)。在數據中心級別，應該考慮災難恢復(確保故障轉移到不同的位置)。
安全與管理:
- 了解不同類型的網絡安全攻擊。
- sla——把最好的留到最后，sla(service level agreements服務水平協議)是SRE工作中最重要的方面之一。設置、監視和執行sla將占用大量工作。
SRE核心組件
SRE的以下5個理念可以通過事實數據和洞察力帶來更好的客戶體驗。可觀察性和實用的度量標准是現SRE促進服務彈性和基礎設施正常運行的最佳方法——滿足客戶的期望。
1)可用性
SRE工程師將負責制定和滿足服務水平的目標、協議和指標(SLOs、sla和SLIs)。基於底層應用程序和基礎設施的成熟度，以及整個團隊的結構和可靠性實踐的支持，SREs可以評估合理的指標，以量化客戶的正常運行時間和可用性。什么樣的可用性水平是合理的，可以假定您可以持續地維護，以及什么會讓客戶和潛在客戶滿意，從而帶來更多的業務?
2)性能
當然，如果站點可靠性工程師要對服務可用性負責，那么他們也要對性能負責。在某種意義上，性能是看待可用性的另一種方式。在工程團隊看來，經歷了某種程度的延遲或另一種類型的性能下降的客戶，很可能正在經歷停機。如果服務不是高性能和可用的，那么它幾乎是不可用的。SREs負責為這些生產系統帶來見解和行動，以確保開發人員和IT團隊快速修復問題，改善客戶體驗，並使應用程序和基礎設施隨着時間的推移更具彈性。
3)監控
為了確保性能和可用性，SREs需要知道在其應用程序和基礎設施中監視和警告什么。可觀察的服務大大提高了開發和發布團隊的效率，這自然會提高面向客戶的服務的正常運行時間和性能。SREs同時使用白盒和黑箱監控，以及儀表板和其他可視化工具來確保開發，組織中任何地方的IT和安全團隊都能更好地了解他們的應用程序和基礎設施的健康狀況。
4)事件反應
SREs的隨叫隨到管理和事件響應，通常在不同的組織之間是不同的。雖然站點可靠性工程師並不總是需要隨叫隨到，但他們至少應該對事件后的評審做出貢獻，並在高水平上了解事件響應過程。系統可靠性在很大程度上取決於DevOps和IT團隊在處理生產中的事故和中斷時的效率。站點可靠性工程師需要對他們的事件響應團隊的成功負責——這通常意味着他們需要成為隨叫隨到過程的一部分。
5)協作溝通
SREs需要確保開發人員和IT運營團隊擁有他們需要的資源，以了解他們的系統，知道什么地方出了問題，並快速響應問題。通過事件后的協作評審過程、有用的度量標准和指示板，以及對組織的CI/CD過程的全面改進，站點可靠性工程師在DevOps和IT效率方面有很大的優勢。
google招聘SRE的要求
最低學歷:
- 計算機科學學士學位，軟件/系統工程相關技術領域，或同等的實踐經驗。
- 至少使用以下語言之一進行編程:C、c++、Java、Python或Go。
- 熟悉算法和數據結構。
優先條件:
- 具有設計、分析和故障排除大型分布式系統的專業知識。
- 具有調試、優化代碼和自動化日常任務的能力。
- 系統解決問題的方法，加上有效的溝通技巧和驅動力。
- 了解Unix/Linux操作系統。
參考
Google’s SRE Book
Google’s Site Reliability Workbook PDF
Google Cloud Platform Podcast
Splunk’s Beginner’s Guide to Observability
SRE, Golden Signals and Happier Customers (webinar)
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (book)
The Complete Guide to Post-Incident Reviews
Reducing MTTD for High-Severity Incidents (guide)
The Unicorn Project (book)