維運管理與 SRE 的關係
維運管理與 SRE 的關係

維運管理與 SRE 的關係

這篇文章旨在探討何謂維運管理以及如何進行維運管理,並透過 SRE 的觀點去強化維運管理的方式。

Operations Management

談到維運管理,首先我們需要從 WWH – What Why How 的角度知道來探討。

維運的 WWH - What Why How  

1. What – 了解什麼是維運管理?

從 Business 的角度來看維運管理的話,通常指的會是企業的經營或公司的策略,但從IT管理的角度,我們要談的是針對 IT Service 或 IT System 系統方面的管理。

2. Why – 為什麼談維運管理呢?

想像一下我們有一個很厲害的線上服務或是 IT 產品,結果因為某些原因導致系統不能用或是不能正常使用,結論是這仍然是一個沒用處或是沒法提供服務的產品。所以一個死掉的服務或是掛掉的系統是無用的,沒辦法做任何事情。這也是為什麼維運管理相對來說是重要的。

3. How – 那我們怎麼去做維運管理呢?

難道是買了一套十萬 or 百萬的數台 Servers ,然後就放在那邊不理他?並假裝相信這套設備永遠不會壞掉嗎?其實各種系統都是一樣的,單單只是希望它不會壞掉放著不管,並不是一個好的策略。SRE 可能是一個解決的答案。

既然提到了 SRE ,到底什麼是 SRE 呢?

SRE 其實是 Google 早在十年前就提出並且應用的一個實現。SRE 全稱 Site Reliability Engineering,根據 Google 當時提出 SRE 概念的 Benjamin Treynor Sloss (Vice President, Engineering, Google),他提到:“SRE is what happens when you ask a software engineer to design an operations function. “ (中譯:SRE 就是當你去問一個軟體工程師如何設計一套維運方法的表現。)

Site Reliability Engineering – How Google Runs Production Systems, Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Richard Murphy

一般來說資訊單位在規劃維運團隊的時候,傳統上常見的公司或企業 (特別是地端),會將開發及維運分成兩組單位,開發人員多半是由軟體工程師組成的 RD Team,而維運人員多半是由所謂的系統工程師 (System Admin) 組成的,這便是我們講的由系統管理員的方式去做為維運 Team。這些由系統工程師所組成的維運 Team 在維運的時候可能基於手冊式的方式,較多為手動的去執行一些相關的任務,例如說開關機、備份、清理資料…等。

而根據 Site Reliability Engineering 這本書所提,Google 的做法,則是使用的是 SRE (網站可靠性工程)的方式,透過由軟體工程師組合成的 SRE team 做維運上的設計和操作。

那麼,系統管理員 (System Admin) 跟 SRE 網站可靠性工程師 Site Reliability Engineer) 相同嗎?其實有一點點不同。

系統管理員 (System Admin) 跟
SRE 網站可靠性工程師 Site Reliability Engineer) 相同嗎? 

開發、系統管理的這種結構,慢慢的已經演變出所謂 DevOps 的概念,也就是說將開發跟運維綁在一起的概念,如果說 DevOps 是一個原則,那麼 SRE 則是基於這個概念的實現,以程式的語言來表現就會類似像: class SRE impements DevOps。 

當然 DevOps 這個議題已經被提出很久,他有一些基本大方向的原則:

Accept failure as normalReduce organisational silosImplement gradual changeLeverage tooling and automationMeasure everything

例如像是:  

接受失敗是常態:SRE 就是透過 SLO 或是檢討的方式來實現這個概念  人及文化方面  心理上的安全感   跟不責罵的文化  也是很重要的一環

降低組織隔閡:SRE 的實踐就是把 ownership 在維運跟 product team 共同來分擔,人及文化上  包含了整體的視野, 協作, 以及溝通跟知識的分享等等

漸進式更動:SRE 的實踐就是降低錯誤的 cost,或是說提出所謂canaries (alpha, beta 版本這種模式) 進而導入 CI 持續整合/ CD 持續部署  人及文化上則是透過設計思考啊,Prototyping 雛形/原形化。

利用工具及自動化:SRE 則是降低所謂的Toil 勞務 (一直重複做的事情)方面的自動化   人和文化上則是要去思考改變所帶來的阻力。

測量所有東西:SRE 則是衡量出 Toil 勞務和可靠性 利用一些 SLA 的指標或數值來達成,人和文化上則是設定正確的目標,透明化,然後是基於數據所做的決定

這所有的目標主要就是想要表達:

要建立出一個良好文化去幫助 DevOps 以及 SRE 的實踐。

當然這會有難度,尤其是在大型的組織可能會有很多的因素,政治, 商業考量….等等  所以這會需要整個公司的人來一起完成才有可能。

Dev vs. Ops problem

我們知道,常見地端機房的淺規則就是:千萬不要去機房碰穩定在跑的機器,連重開機都是大忌。

不碰就沒事!

但這其實就會造成開發團隊及維運團隊的方向或是動機不一致。

開發團隊:想要新功能,增加核心價值,修正 bug,改進產品

維運團隊:希望穩定就好,最好都不要改動及變化,希望這樣可以達到100%可用性。

所以很常見到的情況是這樣的:

  1. 開發團隊開發出一個新功能  
  2. 然後發布新功能到 prodcution 環境
  3. 結果因為改動就出事了
  4. 然後維運團隊就改了一些規定   要更嚴格 更謹慎
  5. 最後導致更長的 QA 跟更長的測試

總 Cost ,相對來說是無形的增加的。

當你的 Business 是成線性成長的時候 (當然我知道很多公司也有可能是指數下降..XD),以往系統管理員所進行手動勞務的部分可能是根據手冊或是list模式去做事。當你的服務增加,你需要做的事情也會將對增加,以比例來講,相對的突然/出包的事件也會增加,結果就是系統管理員的人數要增加,維運的成本也隨著服務增加。

指數成長 vs 預算是有限的情況下,又要最大化系統或服務核心價值的時候,該怎麼辦呢?

True Reliability

這邊就會談到真正的可靠性,什麼是可靠性,可靠性就是可用性嗎?Business 的核心價值是基於100%可用性而已嗎?

 可靠性包含很多因素: 

 -可用性
 -系統維護的時間跟週期
 -最新的安全性應用
 -期望提供什麼樣的服務給客戶

當我們把可靠性是設定為 100% 其實是一個錯誤的目標,最簡單的原因:因為不實際。

第一、無法分辨不同,例如你家 ISP 網路只有99%的 SLO ,結果你提供99.99%的 SLO,但使用者早就無法上網了  根本無法發現到你的99.99%有什麼好處。

第二、多一個9你可能要考量到更多 HA 的節點,成本相對來說多一個9是非常昂貴的。

第三、系統的剛性:為了維持並保持好100%,你需要更長的 Lifecycle(例如更長的 QA 時間,更長的更縝密的系統或功能的規劃)去發展新功能或修復新 bug,導致沒辦法敏捷的調整及擴展。

一個理想的 SLO,應該是要在創新跟穩定中間取得平衡,這個平衡有很大的觀點來自於客戶的體驗。

Error budget 

SRE 提出的概念是 Error Budget,所謂的 Error Budget ,其實就是你的SLO   扣掉之後剩下的就是你可以出錯的空間。

100% – “SLO” = error budget

例如 SLO 是 99.9% ,100%-99.9% = 0.1% 就是所謂的 error budget 了。

這個 Budget 空間非常的有用,因為在你的 SLO 不變的前提下,這就是允許你做調整及修正的空間,這個容錯空間會是shared,在 SRE team 跟開發團隊之間的一個共享的容錯空間。這就是 SRE 觀點內,蠻重要的一個關鍵,去影響你的創新跟穩定之間的平衡點在此。

Error budget 包含品質:

  1. 新功能 修正 bug

2. 如果達到這個容錯空間 SRE ,可以選擇降低 Lifecycle 的速度 抑或 SRE 也可以決定停止整個 lifecycle 。

3. 如果有太多勞務要維護或是太多的服務停擺, SRE 可以回報 BUG

4. 開發團隊需要寫出更高質量的 code 跟測試去改善維運性跟服務品質。

所以,Error budget 主要的功用便是在於減少產品開發週期之間各階段的摩擦。

-Business 要開發很快速的解決某個需求
-開發想要很快速的開發出新功能
-維運想要保持穩定性

透過 Error budget ,我們可以將其應用在創新與穩定之間的平衡之上。

SRE missions 

SRE 的任務包含了:

  • Availability (可用性)
  • Latency (延遲)
  • Performance (效能)
  • Efficiency (效率)
  • Change management (變更管理)
  • Monitoring (監控)
  • Incident response (事故應變)
  • Capacity planning (容量規劃)
SRE 工作中有一項很重要的原則稱為:50% 原則

50% 原則:意思是只能有 50% 的時間再處理 ticket、on-call、手動要做的事情上,剩下的應該去研究如何自動化 以及高效率的完成。

如果超過50%,則需要:

  1. 增加 SRE 工程師人數
  2. 降低產品開發週期
50% 原則的好處:

-預防 team member 太累
-促使團隊成員去自動化 效率化   降低重複的勞務工作   以軟體工程師的角度
-更少的手動操作 更穩定的 prodcuion 系統

同時也可以讓 SRE 有更深的知識去寫出更穩定的 code,透過檢閱和建議的方式讓開發團隊去寫出 production -ready 的 code。

那麼我們如何達到可靠性呢?
  1. 自動化 – 透過自動化來提高效率,並考慮導入 CI/CD 等流程建置自動化流程
  2. 經常檢討 – 其用意為提高可用性進而去分析及檢討 Root Cause 。
  3. 事前演練 – 事故發生時透過類似消防演練、防災演練的概念,達到預防勝於治療的功效。

總結

SRE 的觀點中,同時也應用了所謂的不責罵原則,不去責罵任何一個個體,而是應該由記錄所有的事故、文件化,並從錯誤中學習。

記得:接受失敗是常態。

不要去罵任何一個團隊成員,人都會犯錯,應該以 Team 或整體的角度去看待每一次錯誤跟失敗,失敗沒什麼,如何修正他、預防他才是關鍵。

所有的檢討都是內部的,宗旨都是在不幸的事件發上到你身上的時候,都將會是一個經驗的累積和應用。


Solution Architect

Cloud Ace 解決方案架構師,負責協助各大企業上雲