SRE經過谷歌的實踐和推廣，已經被很多互聯網公司所采用。如果想要實踐SRE，成為SRE工程師，需要做好哪些方面的知識儲備？本文介紹了SRE相關的技術，提供了大量有益的資源，有志于這一方向的同學可以以此作為技術發展路線圖。原文：A Journey To The Site Reliability Engineering[1]
很多組織都已經開始采用站點可靠性工程（SRE，Site Reliability Engineering）實踐來代替傳統的運維。LinkedIn上最新的工作搜索顯示，全球范圍內有超過19萬個SRE工程師職位空缺。
如果你還不熟悉SRE，那么可以看看谷歌是如何描述的~
SRE是當你要求軟件工程師設計一個運營團隊時所發生的事情。
SRE由7個重要原則定義 --
- 運維是一個軟件問題（Operations is a software problem）
- 按服務水平目標管理（Managed by Service Level Objectives）
- 盡量減少工作量（Work to minimize the toil）
- 把今年的工作自動化（Automate this year’s job away）
- 通過減少失敗的代價來快速行動（Move fast by reducing the cost of failure）
- 與開發者分享所有權（Share ownership with the developers）
- 無論是什么職能或職位，都使用相同的工具（Use the same tooling, regardless of function or job title）
對于擁有運維支持、系統管理、基礎架構、DevOps工程師等背景的人來說，SRE工程是一個很好的職業發展方向。
在本文中，我將提供各種資源，幫助你開始SRE工程師之旅。
掌握SLO的藝術（Mastering the Art of Service Level Objectives(SLOs)）
為了旅程順利，我們有必要從理解服務水平指標(SLIs, Service Level Indicators)和服務水平目標(SLOs, Service Level Objectives)的概念開始。
SLI: 服務可靠性的可量化度量
SLO: 為SLI設置可靠性目標
有很多關于SLI和SLO的資源，但我建議通過SLO藝術工作坊[2]來深入理解這一概念。
如果你是某個嘗試采用SRE實踐的組織的一員，那么我建議在組織內為有抱負的SRE開展這個工作坊。
工作坊旨在向你介紹如何以數據驅動、客觀和以用戶為中心的方式通過SLO和錯誤預算（Error Budgets）來度量和管理服務的可靠性。
工作坊可以指導我們選擇正確的SLI，并通過案例幫助我們獲得定義SLI/SLO的實踐經驗。
在學習的過程中，請保持開放的思維和新鮮的視角，因為我看到很多人認為SLI/SLO類似于他們使用的APM工具所做的基礎設施監控，但事實并非如此！
云技術（Cloud Expertise）
根據Gartner的報告[3]，超過75%的企業都有云優先戰略。
因此，熟悉AWS、GCP和Azure等云服務是非常必要的。
許多組織都在積極使用云技術進行應用程序現代化轉型之旅，SRE被要求在這一轉變過程中發揮重要作用。
在互聯網上有很多像Udemy, PluralSight, Coursera, CloudGuru等網站來提升我們的知識儲備。
基礎設施即代碼（Infrastructure as Code(IaC)）
隨著組織在云中遷移工作負載，高效、動態的管理基礎設施的需求就更加突出了。因此，SRE應該擁有下面這樣的IaC工具：
- Terraform
- Ansible
- Chef
- 等等
即使所有云服務提供商都有自己的SDK/Shell來管理服務，使用IaC工具仍然有很多好處。
下面的內容引用自《Quickly Deploy Applications Using Terraform With Kubernetes on GCP[4]》：
Terraform能夠顯示當前狀態和期望狀態之間的差異，這意味著一旦我們編輯了Terraform配置文件，就能看到將要做的改變。
Terraform不僅負責初始部署，還負責維護。我們可以使用命令輕松的創建、更新和刪除跟蹤的資源。
清理Terraform構建的所有東西非常容易。如果使用腳本，我們還必須編寫一個清理腳本。但對于Terraform，可以簡單的通過“terraform destry”命令來實現。
Terraform能夠檢查配置文件中聲明的動作的順序。這意味著，如果我們想運行基于Kubernetes的服務或部署，即使我們錯誤的聲明了操作的順序，Terraform仍然將首先創建集群。
你可以查看以下鏈接來了解關于這個主題的更多信息。
容器及容器編排平臺（Containers & Container Orchraction Platforms）
由于SRE在應用程序部署中扮演著關鍵角色，所以了解容器和容器編排平臺非常重要。
許多組織使用Docker和Kubernetes平臺進行服務部署，可以在網上找到大量關于這個話題的資源。
這里有一些可以作為開始的鏈接：
持續集成及持續部署（Continuous Integration & Continous Deployment(CI/CD)）
SRE需要將盡可能多的工作自動化，為應用程序提供適當的CI/CD流水線是快速交付的重要部分。許多組織使用下面這樣的平臺：
- GitLab
- GitHub
- Azure DevOps
- Jenkins
- 等等
因此，擁有建立CI/CD流水線的專業知識是一項基本技能。這些平臺中有很多都支持免費服務，可以不用花一分錢就能自學。
這里有一些學習資源：
- https://about.gitlab.com/learn/
- https://lab.github.com/
- https://azure.microsoft.com/en-us/overview/devops-tutorial/
發布策略（Release Strategies）
作為SRE角色的一部分，我們需要不斷為用戶部署新特性。這么做的同時，還需要確保在部署新特性時沒有消耗錯誤預算（Error Budget），因此需要熟悉如下發布策略：
- 金絲雀發布[5]
- 藍綠發布[6]
- 等等
熟悉特性標記(feature-flag)[7]的開發策略將增加優勢。如果使用像Kubernetes這樣的容器編排平臺，可以使用Kubernetes的定義文件描述這些策略[8]。
在谷歌的SRE工作手冊中深入介紹了金絲雀發布的過程[9]。
事故響應和非指責的事后剖析（Incident Response & Blameless Postmortems）
隨叫隨到是SRE的另一個重要職責。因此，SRE需要對事故響應流程有非常好的理解。
PagerDuty事故響應課程[10]涵蓋了如下話題：
- 什么是事故？
- 事故級別
- 事故管理的各種角色
- 事故電話禮儀
- 等等
將事故響應過程記錄下來是很重要的，因為如果人們知道事故發生時如何應對，就能更好的管理突發事故。
PagerDuty還有另一個關于如何在SRE團隊中培養非指責文化的課程[11]，其中提供了一些非常詳細的模板，可以用來執行無指責的事后分析。
強烈推薦這兩門課程。
安全（Security）
因為SRE負責整個應用，對應用安全性有基本的了解總是好的。
強烈建議你熟悉下面提到的概念：
- OWASP Top 10[12]
- Application Threat Modelling[13]
對于自動化部署，SRE需要管理各種服務憑證，因此應該熟悉憑證管理工具，如HashiCorp Vault[14]或云原生加密管理解決方案，如Azure密鑰庫、谷歌加密管理器等。
文檔（Documentation）
SREs需要確保所有重要的文件都定期更新，易于遵循，因此應該專注于制作高質量的文檔，比如：
- 運維操作手冊（Operation Runbooks）
- 發布/回滾文檔（Release & Rollback documents）
- 等等
谷歌提供免費的技術寫作課程[15]，建議大家在日常生活中學習并運用其中的原則，當然如果你有時間的話也可以報名參加有導師指導的培訓課程。
另外，我也寫過一篇關于工程師技術寫作最佳實踐的文章《軟件工程師文檔寫作最佳實踐》[16]。
災難恢復測試/混沌工程（Disaster Recovery Testing / Chaos Engineering）
為了測試平臺的健壯性，SRE還負責執行災難恢復測試。谷歌將災難恢復測試作為其健壯服務的一部分，《Weathering the Unexpected》[17]是一篇關于谷歌DiRT項目的詳細文章。
最近Netflix的混沌工程理念變得非常流行，我在《Why Every Software Developer Needs to Learn Chaos Engineering》[18]里也寫過關于混沌工程的內容。
非抽象大規模設計（Non-Abstract Large Scale Designs(NALSD)）
當我們開始討論大型、復雜、分布式系統時，谷歌已經設計了一個流程[19]，可以幫助SRE發展評估、設計和衡量大型系統的能力。
NALSD過程包含了問題陳述、需求收集，以及幫助評估大規模系統對不同故障模式的容忍度的迭代系統設計。
谷歌還提供了一個工作坊，帶領我們了解分布式消息隊列(如pub/sub)的系統設計，并解釋如何對其實現NALSD原則。
我個人從中學到了很多。
社區
為了更多的向他人學習，并了解行業最新動態，建議加入以下在線社區：
- https://www.reddit.com/r/sre/
- LinkedIn — School of SRE — https://www.linkedin.com/groups/12493545/
結論
總的來說，SRE工程流程非常有趣，并且正在被許多組織所采用。
References:
[1] A Journey To The Site Reliability Engineering: https://deshpandetanmay.medium.com/a-journey-towards-site-reliability-engineering-7c893dae23ab
[2] The Art of SLOs: https://sre.google/resources/practices-and-processes/art-of-slos/
[3] The Latest Cloud Computing Technology and Security: https://www.gartner.com/en/information-technology/insights/cloud-strategy
[4] Quickly Deploy Applications Using Terraform With Kubernetes on GCP: https://medium.com/google-cloud/quickly-deploy-applications-using-terraform-with-kubernetes-on-gcp-6a4d7d142839
[5] Canary Release: https://martinfowler.com/bliki/CanaryRelease.html
[6] Blue Green Deployment: https://martinfowler.com/bliki/BlueGreenDeployment.html
[7] Feature Toggles: https://martinfowler.com/articles/feature-toggles.html
[8] Kubernetes Deployment: https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
[9] Canarying Releases: https://sre.google/workbook/canarying-releases/
[10] PagerDuty Incident Response: https://response.pagerduty.com/
[11] PagerDuty Postmortems: https://postmortems.pagerduty.com/culture/blameless/
[12] OWASP Top 10: https://owasp.org/www-project-top-ten/
[13] Application Threat Modelling: https://deshpandetanmay.medium.com/threat-model-what-is-that-b45eac2c4104
[14] Vault: https://www.vaultproject.io/
[15] Technical Writing Courses for Engineers: https://developers.google.com/tech-writing/
[16] Best Practices When Documenting Your Code for Software Engineers: https://betterprogramming.pub/best-practices-when-documenting-your-code-for-software-engineers-941f0897aa0
[17] Weathering the Unexpected: https://queue.acm.org/detail.cfm?id=2371516
[18] Why Every Software Developer Needs to Learn Chaos Engineering: https://betterprogramming.pub/why-every-software-developer-needs-to-learn-chaos-engineering-ef08992f4354
[19] Introducing Non-Abstract Large System Design: https://sre.google/workbook/non-abstract-design/
你好，我是俞凡，在Motorola做過研發，現在在Mavenir做技術工作，對通信、網絡、后端架構、云原生、DevOps、CICD、區塊鏈、AI等技術始終保持著濃厚的興趣，平時喜歡閱讀、思考，相信持續學習、終身成長，歡迎一起交流學習。
微信公眾號：DeepNoMind
