【系統運維】Google 對運維的解決之道：什麼是SRE－網站可靠性工程(Site Reliability Engineering)?
SRE 全名是 Site Reliability Engineering 網站可靠性工程，是 Google 提倡的系統管理實踐之道、指導思想，這個名詞同時也是 軟體工程師
(Software Engineer) 的角色，可以類比於傳統的維運工程師或系統工程師，但是 SRE 是用
計算機科學 和 軟體工程 手段，實踐 大型系統維運、分散式系統 的設計與開發。
SRE產生的背景
SRE是由Google的工程副總裁Ben Treynor Sloss提出的術語（和相關的工作角色）。正如我們在上一節中所看到的，DevOps是運維和產品開發之間在整個生命週期互相協作的一系列廣泛原則。SRE是一個工作角色，也是我們發現的一組實踐（稍後介紹），以及一些激勵這些實踐的信念。如果您將DevOps看作一種哲學和工作方法，則可以認為SRE實現了DevOps描述的一些哲學，並且比“DevOps工程師”更接近於這個工作或角色的具體定義。因此，在某種程度上，SRE類實現了DevOps介面。
與DevOps運動不同，DevOps運動起源於多家公司的領導者和從業者之間的合作，而SRE在整個行業廣泛普及之前，則是由Google的SRE繼承周圍公司的大部分文化。 考慮到這一軌跡，整個SRE學科目前並沒有像DevOps那樣在文化上突然增長。 （當然，這並不能說明文化變革對在任意組織中進行SRE是否是必要的）
SRE團隊的職責
雖然每個 SRE 團隊都有自己的工作流程、優先級定義以及日常工作規範，但是所有的 SRE 團隊都有一套共同的核心方法論。一般來說，SRE 團隊要承擔以下幾類職責：可用性改進，延遲優化，性能優化，效率優化，變更管理，監控，緊急事務處理以及容量規劃與管理
SRE 團隊要承擔以下幾類職責：可用性改進，延遲優化，性能優化，效率優化，變更管理，監控，緊急事務處理以及容量規劃與管理。
線上項目是錯綜複雜的，如果你只是部署某人的代碼，你如何對其服務的響應延遲負責？還好，你有一些標準化的手段，比如使用容量規劃、監控並配合變更管理來幫助你。
通常，運維的工作是對系統變慢或不可用的情況負責，從長期來說，需要與開發團隊溝通，將潛在的問題修復；從短期來看，有時候運維增加更多的伺服器也許反而降低了性能？或者想讓程序運行更快反而會降低了可靠性。
Google SRE 的 8 大核心原則
1、確保長期關注研發工作
Google 將 SRE 團隊的運維工作限制在 50% 以下。SRE 團隊應該將剩餘時間花在研發項目上。SRE 處理運維工作的時候的一項準則是：在 8 ~ 12 小時的 on-call 輪值期間最多應該只處理 2 個緊急事件。
2. 在保障服務 SLO (Service Level
Objective) 的前提下最大化疊代速度
產品研發部門和 SRE 之間可以通過消除組織架構衝突來構建良好的合作關係。在企業中，最主要的矛盾就是疊代創新的速度與產品穩定程度之間的矛盾。正如上文所說，其表現形式可能是間接的。在 SRE 模型中，我們選擇正面面對這種矛盾，使用的工具是錯誤預算。
3. 監控
監控系統是 SRE 團隊監控服務質量和可用性的一個主要手段。所以監控系統的設計和策略值得著重討論。最普遍和傳統的報警策略是針對某個特定的情況或者監控值，一旦出現情況或者監控值超過閾值就觸發 E-mail 報警。但是這樣的報警並不是非常有效：一個需要人工閱讀郵件和分析報警來決定目前是否需要採取某種行動的系統從本質上是錯誤的。
3.1 警報
意味著收到警報的用戶需要立即執行某種操作，目標是解決某種已經發生的問題，或者是避免即將要發生的問題。
3.2工單
意味著接受工單的用戶應該執行某種操作，但是並非立即執行。系統並不能自動解決目前的情況，但是如果一個用戶在幾天內執行這項操作，系統不會受到任何影響。
3.3日誌
平時沒有人需要關注日誌信息,但是日誌信息依然被收集起來以備調試和事後分析時使用。正確的做法是平時沒有人主動閱讀日誌,除非處理其他請求的時候被要求這麼做。
4. 緊急事件處理
可靠性是 MTTF（平均失敗時間）和 MTTR（平均恢復時間）的結合結果。評價一個團隊將系統恢復到正常情況的最有效指標，就是
MTTR
任何需要人工操作的事情，都只會延長恢復時間通過事先預案並且將最佳方法記錄在「運維手冊」上通常會使 MTTR 降低 3 倍以
5.變更管理
SRE 經驗告訴我們，大概 70% 的生產事故由某種部署的變更而觸發。變更管理的最佳實踐可使用自動化來完成以下幾個項目：
l
採用漸進式發布機制。
l
迅速而準確地檢測到問題的發生。
l
當出現問題時，安全迅速地回退改動。
這三點可以有效地降低變更給 SRE 和最終用戶帶來的時間成本和服務質量的下降。通過將人工因素排除在流程之外，這些操作將不再受到經常發生在人身上的「狼來了」思想以及對大量重複性勞動的關注疲勞所影響。於是，變更執行的速度和安全性同時得到了提高。
6、需求預測和容量規劃
需求預測和容量規劃簡單來說就是保障一個業務有足夠的容量和冗餘度去服務預測中的未來需求。這裡並沒有任何特別的概念，但是我們發現行業內有許多團隊根本沒有這個意識和計劃去滿足這個要求。一個業務的容量規劃，不僅僅要包括自然增長(隨著用戶使用量上升,資源使用率也上升)，也需要包括一些非自然增長的因素（新功能的發布、商業推廣，以及其他商業因素在內）。
7、配置
資源的部署與配置是變更管理與容量規劃的結合物。在我們的經驗里，資源的部署和配置必須能夠非常迅速地完成，而且僅僅是在必要的時候才執行，因為資源通常是非常昂貴的。而且這個部署和配置的過程必須要確保能夠正確地執行完畢，否則資源就仍然處於不可用狀態。增加現有容量經常需要啟動新的實例甚至是集群，這通常需要大幅度修改現有的集群配置 ( 配置文件、負載均衡、網絡等 )，同時還要執行一系列測試，確保新上線的容量可以正確地服務用戶。因此新資源的部署與配置是一個相對比較危險的操作，必須要小心謹慎地執行。
8. 效率和性能
高效地利用各種資源是任何營利性服務都要關心的。因為 SRE 最終負責容量的部署和配置，因此 SRE 必須也承擔起任何有關利用率的討論及改進。因為一個服務的利用率指標通常依賴於這個服務的工作方式以及對容量的配置與部署上。如果能夠通過密切關注一
個服務的容量配置策略，進而改進其資源利用率，可以非常有效地降低系統的總成本。
一個業務總體資源的使用情況是由以下幾個因素驅動的：用戶需求（流量）、可用容量和軟體的資源使用效率。SRE 可以通過模型預測用戶需求，合理部署和配置可用容量，同時可以改進軟體提升資源使用效率。通過這三個因素能夠大幅度推動一個服務的效率提升（但是並非全部）。
軟體系統一般來說在負載上升的時候，會導致延遲升高。延遲升高其實和容量損失是一樣的。當負載到達臨界線的時候，一個逐漸變慢的系統最終會停止一切服務。換句話說，系統此時的延遲已經是無窮大了。SRE 的目標是根據一個預設的延遲目標
SRE(
Site Reliability Engineer)工程師十大特點
1.The SRE model
has a more specific focus on application reliability and performance at scale.
SRE工程師主要著力點在於應用程式在擴展上的可靠性與性能表現，該性能是一種高User Experience的指標，通常會反應在business上顧客的滿意程度。
2. The SRE has
no exclusive alignment with either Dev or Ops, and must be prepared to support
either group – and stand up to them when necessary.
SRE雖然多數時間會與Dev一起co-work，但其實並沒有一定，他必須在有需要時跟Dev或Ops的人一起協同工作，同時也是Dev與Ops之間的銜接橋樑。
3. The SRE’s principal focus is on the reliability and performance of
applications – combined with a wider perspective on the
needs and priorities of the business and its customers.
SRE需要對他的應用程式的客戶需求以及應用business有廣泛的理解，並能識別其中的優先順序，藉此引導出實作應用程式的可靠度與性能的最佳方案。
4. Be
comfortable with coding.
SRE像Dev一樣熱愛寫程式並總是喜歡探求應用程式的operation之組成元件與基礎架構，如：網路與DB…等，如此才能針對應用程式的reliability 及 performance進行改善精進。
5. As a bridge
between Development and Operations, SREs are empowered(使能夠) to
fix application issues in production.
SRE必須能夠迅速處理production
issue，並且是要能溝通Dev和Ops一起解決問題。
6. Error Budget
- Creates an error budget of 0.01%, within which outages(斷電;中斷供應) and downtime are considered acceptable.
SRE應該要知道百分之百的應用程式availability
及 reliability 是不可能的，必須有0.01的Error budget容忍彈性。
7.Today, modern
applications must be able to scale quickly and have the right capacity. The SRE
will keep one eye on the future, to plan for how the application can maintain
performance and reliability without linear increase in manual effort.
SRE清楚應用程式的擴充將愈來愈快，所以必須隨時了解如何迅速擴充應用程式並且給予適當的資源容量同時一切擴充動作必須都是減少人工介入的。
8. The SRE must
have a strong drive to be a detective and understand why things are working or
not working as they should. go beyond understanding everything about the
application to being curious about the potential of next-gen architectures.
總是了解應用程式運作的所有事不管是成功的或失敗的，並且總是能跳出應用程式框架去追求下一代新應用程式架構的樣子。
9. They will
instead proactively diagnose the problem using their holistic(整體的)
knowledge-set and then get busy with coding a permanent fix, rewriting a
process or working with third parties to ensure that lessons are learnt and the
problem never recurs again.
主動診斷並解決問題透過編程或第三方工具以及流程修正，以確保問題不會再發生。
10. All issues
are recorded in written form, stored digitally, for future reference.
了解並紀錄追蹤每一個問題，從錯誤中學習。
11. Embrace
automation.
SRE 熱愛automation工作，把繁鎖的作業最簡化，提高工作效率。
12. The SRE
must also be able to have business centric conversations with application
owners and Line-Of-Business managers, using terminology they understand.
SRE 必須了解Business的語言並且能轉換成技術語言來作為與business manager和DevOps溝通的中繼。
13. SREs seek
to understand why and how customers interact with the business, always looking
for ways to remove friction(阻力;衝突), using
innovative applications and technology.
了解並知道使用者如何運用business，然後從中找出應用程式不合理之處，運用技術與創新的功能解決客戶需求。
14. Be prepared
to move on.
永遠不滿足現狀，在一切都運作順暢之後，知道下一步改往哪裡前進，不斷自我追求卓越。
相關文章：
沒有留言:
張貼留言