文章段落
這篇文章旨在探討何謂維運管理以及如何進行維運管理，並透過 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 就是當你去問一個軟體工程師如何設計一套維運方法的表現。）
一般來說資訊單位在規劃維運團隊的時候，傳統上常見的公司或企業 (特別是地端)，會將開發及維運分成兩組單位，開發人員多半是由軟體工程師組成的 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 normal | Reduce organisational silos | Implement gradual change | Leverage tooling and automation | Measure 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%可用性。
所以很常見到的情況是這樣的：
- 開發團隊開發出一個新功能
- 然後發布新功能到 prodcution 環境
- 結果因為改動就出事了
- 然後維運團隊就改了一些規定 要更嚴格 更謹慎
- 最後導致更長的 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 包含品質:
- 新功能 修正 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%，則需要：
- 增加 SRE 工程師人數
- 降低產品開發週期
50% 原則的好處：
-預防 team member 太累
-促使團隊成員去自動化 效率化 降低重複的勞務工作 以軟體工程師的角度
-更少的手動操作 更穩定的 prodcuion 系統
同時也可以讓 SRE 有更深的知識去寫出更穩定的 code，透過檢閱和建議的方式讓開發團隊去寫出 production -ready 的 code。
那麼我們如何達到可靠性呢？
- 自動化 – 透過自動化來提高效率，並考慮導入 CI/CD 等流程建置自動化流程
- 經常檢討 – 其用意為提高可用性進而去分析及檢討 Root Cause 。
- 事前演練 – 事故發生時透過類似消防演練、防災演練的概念，達到預防勝於治療的功效。
總結
SRE 的觀點中，同時也應用了所謂的不責罵原則，不去責罵任何一個個體，而是應該由記錄所有的事故、文件化，並從錯誤中學習。
記得：接受失敗是常態。
不要去罵任何一個團隊成員，人都會犯錯，應該以 Team 或整體的角度去看待每一次錯誤跟失敗，失敗沒什麼，如何修正他、預防他才是關鍵。
所有的檢討都是內部的，宗旨都是在不幸的事件發上到你身上的時候，都將會是一個經驗的累積和應用。
