DevOps 是什麼? Google 實做 DevOps 的 SRE 方法介紹

DevOps 是什麼? Google 實做 DevOps 的 SRE 方法介紹

DevOps 這個概念已行之有年,但在業界的實施程度落差很大,在台灣走在前面的公司,可能已經玩 DevOps 玩超深,有些還不知道什麼是 DevOps ,只知道這是Development和Opeartion部門間的戰爭合作。

定義: DevOps 是什麼?

根據維基百科「上一版」的定義是這樣子寫的: DevOps 是過程、方法和系統的統稱,促進 Development、Opeartion和QA部門間的溝通、協作與整合。

有沒有很籠統的感覺?XD

看一下圖好了

DevOps示意圖 來源:維基百科
DevOps示意圖 來源:維基百科

這圖到底是什麼意思呢?難道我們沒有 DevOps 就沒有溝通、沒有協作、沒有整合嗎?

這個我也會畫啊!我再畫一圈然後寫 HR,然後說導入 DevOps 可以更有效使用人力,再畫一圈 Finance ,然後說導入 DevOps 可以節省人力成本,乾脆再畫一圈,然後直接寫 Money 好了,代表導入 DevOps 可以發大財,你開心,我開心,大家都開心!感覺好像都沒錯耶!?

其實它這樣畫是有原因的,而且非常具體的原因。我們先來看一下這張圖:

影響開發速度的系統圖示 來源:ruddyblog
影響開發速度的系統圖示 來源:ruddyblog

為什麼要DevOps?

隨著公司持續成長,系統的規模、功能、複雜度、事件和更新次數變多,有很多額外的工作,必須要手動處理回應各項事件。

而公司通常在應用程式的發展,通常分開發和維運,有些會再有測試部門,而開發和維運部門由於不同的背景、技能、目標和激勵措施不同,容易產生衝突。

  • 開發:「我做了一個超炫的功能,什麼時候可以上線?」
  • 維運:「不要停機、不要更新、不要掛掉。」

如果今天突然程式發生重大錯誤事件,就會變這樣:

  • 開發:「都是你沒上新版,我在新版已經解決這個Bug」
  • 維運:「你還敢說,上個月那一版,一部署網站就全部掛掉,害我去開檢討會議罰站一整天」
  • 開發:「可是……在我電腦上是好的!」……(經典名句啊 XD)

這種情況不會只發生在 Google ,也不只發生在開發和維運兩個部門之間,在世界上各個角落都會發生,也就是所謂的「穀倉效應」。(還有人專門寫成一本書)

書:穀倉效應
書:穀倉效應

簡單說就是各部門之間變成孤島,發生衝突之後,部門之間互不信任,使用各種措施阻礙對方:

維運:根據以前發生過的錯誤,準備一連串的 Checklist。

開發:強調這不是改版,是微調,可以直接上。

部門間從合作變成互相角力,拖慢了整個系統開發流程。

同樣的事情發生在 Google ,而 Google 又怎麼解決這樣的問題呢?

2003年成立 SRE Team (Site Reliability Engineering) ,組成如下:

  • 50%~60%純軟體工程師。
  • 40%~50%接近軟體工程師,兼有 SRE 技能(系統和網路專家)。

SRE 軟體工程師必須要

  1. 維運產品
  2. 建一個系統來執行「維運」的人工操作

Google 規定, SRE 只能花50%的時間解 ticket、on call、人工操作。
超過 50% 的部分,指派給開發團隊負責。

所以開發團隊則是要:

  1. 開發產品
  2. 如果 SRE 太忙,要幫忙分擔工作

所以 SRE 除了做維運,也要寫「維運」的程式,而開發團隊除了寫「產品」的程式,也要做維運。==>>產生交叉培訓。

也帶來了其他好處:

  • 系統變大變複雜,卻沒有僱用更多人。
  • 軟體更新速度保持不變。
  • 軟體不用停機就可以直接進行修改。

同時來看看其他的例子,Line Engineering的部落格寫得很好:

IBM和微軟

「2家公司發現當他們還在以每季度在更新軟件時, Google 卻是每天都能更版甚至使用 A/B Testing 的方法在快速反應使用者的回饋。結果是 MS Office 轉型後且上了雲端似乎帶來更好的結果,但 IBM 卻退出了企業協作軟件的市場。」

以及Nokia的例子:

「2010 年當其董事會主席 Risto Siilasmaa 視察公司時發現,Symbian 作業系統建製一次需要 48 小時,對於當時的他猶如當頭棒喝,而內部雖然一直有淘汰 Symbian 的建議,卻一直沒被管理層所採納。」

這告訴了我們,速度真的是非常重要的因素,即使別人很晚才進入巿場,只要他開發速度比你快得多,你總有一天會被他超車。

什麼時候要導入 DevOps ?

那什麼時候要導入 DevOps 呢?只要有以下症狀,都可以考慮看看(引用自KK-Stream 你在找的是SRE還是DevOps):

  • 開發部門無法在開發早期偵測軟體缺陷
  • 無法確定問題出現在哪一個部門
  • 人為錯誤經常發生
  • 只要部署出去, Dev 就認為工作完成
  • 問題發生,相互指責

如何導入 DevOps ?SRE導入方法

那要如何導入 DevOps 呢?五大原則如下:

  • 接受失效(Failure),視失效為開發週期中的一個元素
  • 減少組織之間的穀倉效應
  • 持續改善
  • 善用工具和自動化
  • 任何事都是可以被量測的

DevOps 畢竟是大原則,而 Google 在這部分使用 SRE 做為具體的實做方式,分述如下:

1.失效是一種常態  – 錯誤預算 Error Budget

預算指的不是錢,而是時間(雖然時間可以折算成錢)。這裡要先提一下 SLI (Service Level Indicators)、 SLO (Service Level Objects)和 SLA (Service Level Agreements)的簡單定義:

SLI :和系統效能有關的指標,例如 Latency或Throughput等等。

SLO :表示我們希望 SLI 有多少,但這個不會公佈出來,是公司內部自訂的。

SLA :是對客戶保證,每年或每月的停機時間不能超過多少時間,如果是公開的應用程式,是會宣告出來的,如果是開發給某客戶使用,就是和客戶談出來的,會寫在合約上。如果停機超過 SLA 所訂的時間可能是要賠錢的!

Google 在 SRE Book 有直接換算在不同的 SLA 和單位時間底下,最長的中斷時間各為多少:

SLA換算表 來源: SRE Book Availability Table
SLA換算表 來源: SRE Book Availability Table

但這不是給你拿來跟客戶說:「你知道嗎?我們家的系統最多可以斷三天喔!」這樣你可能會被踢出去。

你可能會問,為什麼不做到 100%呢?

為什麼不做到 100%呢?
為什麼SLA不做到 100%呢?

就像我們去考試一樣,從90分進步到99分比較容易,還是從99分進步到100分比較容易?

Google 的解釋是這樣的,為了達到 SLA 100%,中間有太多不可抗力因素,例如從你的應用程式傳訊息要先到電信商的基地台,中間可能已經是99.9%的 SLA ,再從基地台傳到你的手機可能又是99.9的 SLA ,這裡都還沒算到你開發的應用程式可用性, SLA 就已經是98.9%了,那你要怎麼做到100%?

先買下電信商,再買下那支手機的製造商,然後請超厲害的工程師把APP寫到100分?然後呢?你做到 SLA 100%了,客戶感受到你0.1%的進步嗎?客戶願意為了你0.1%的進步而多付100萬嗎?

我們回過頭來講錯誤預算,直白一點的意思是「在沒有超過約定好的中斷時間之下,我們有多少時間可以拿來做一些創新的嘗試」。所以錯誤預算可以:

  • 培養不究責的文化 Blamelessness => 以利事後調查
  • 允許犯錯 => 鼓勵創新
  • 用來承擔 Launch 的風險 => 做到快速 Launch 

這看起來有沒有像我們學生時代,老師對我們的教誨,不要怕犯錯,Try and Error?

現在呢?多做多錯,少做少錯,不做不錯。歡迎來到大人的世界。大人講的都是對的嗎?官越大,越正確,你不知道嗎?(怨念好深……)

是的,現在是團隊合作的社會,為了不造成別人麻煩,或怕被懲罰,或是怕犯錯變成別人攻擊的對象,我們總是避免犯錯。為了避免犯錯,我們就不再創新了。槍打出頭鳥啊~ DevOps 第一條原則就把我們的臉打得好腫。

貴公司是究責還是不究責呢?
貴公司是究責還是不究責呢?

2.減少穀倉效應 – Infrastructure as a code

就是盡可能讓環境,用統一規管的格式或設定檔(例如 yaml 檔)來部署,而不是人為去設定網路和伺服器等:

  • 讓 開發/測試/生產 環境長得幾乎一模一樣,提早發現錯誤
  • 可以被版本控制工具所管理 (如 git),這代表任何的改變都有跡可尋
  • 減少人工所產生的錯誤
  • 達成自動化
減少穀倉效應 - Infrastructure as a code
減少穀倉效應 – Infrastructure as a code

這樣如果一套程式在開發環境run不起來,在測試或生產環境一樣run不起來,要發現錯誤容易的多,大家一起來看 yaml 檔就好了。而且誰做錯全部的人都知道,不用推責任給別人,也不用故意放大檢視他人,大家心裡知道就好,犯錯的人也會默默檢討,毋需指責。

3.持續改善 – 使用 CI/CD

什麼意思?誰不會持續改善,每個人都會不是嗎?聽起來好像廢話。

這裡講的持續可以用「漸進」來解釋,以前系統要改進,可能是收集完使用者回饋的100項缺點,一口氣全部改完再給使用者,就跟瀑布模式的系統開發流程一樣,常常要交付給使用者時才發現跟原始的需求不一樣。

所以這裡強調的是,只要修正一個點,就交付給用戶測試看看,測試OK再改下一個。這裡用到的具體做法就是 CI/CD,注意CD有兩種

  • 持續整合 Continuous Integration
    持續驗證開發結果 ,小部分小部分地儘早確認,期望產出符合需求,或依據產出進行快速修正。
    • 建置 (build)
    • 測試 (test) 
    • 程式碼分析 (source code analysis)
  • 持續交付 Continuous Delivery 
    • 發行到測試環境,確保軟體持續保持在隨時可以釋出的狀況。
  • 持續部署 Continuous Deployment
    • 自動部署到生產環境。
CD?持續交付還是持續部署?
CD?持續交付還是持續部署?

要做到以上哪一種,就要看公司內部的流程和分工的情況而定。

4.自動化 – 減少手工 (Toil,又稱工人智慧)

什麼是手工呢?手工的特徵如下:

  • 手動執行 script、開關機、上新版程式
  • 對每個新客戶進行的重複性工作
  • 沒有永久的價值(長期的改善)

因為這些工作是不斷重複的,因為重複就會感到單調,因為單調做起來就覺得很沒勁,甚至厭煩,久了甚至會忽視,不專心地做這些事情,這樣出錯的機率反而就會提高。

我曾經在以前的某個公司,也做過某件明明對公司就非常重要,卻沒有人重視也沒有人關心的「手工」,剛好有一次工作太忙,又覺得自己做很多次自以為熟悉,就忽略了一兩個檢查步驟,然後好死不死就剛好系統有問題沒檢查到,造成最後一條龍的流程全部受到影響,並且要全部重來,最後在檢討會議上給別人盯,這就是究責的文化啊~

別讓昨天在你傷口狂忘的撒鹽,一碰就痛,一想就悲。(明明就我自己撒的)

所以自動化說有多重要就有多重要,並且搭配漸進式部署 (Progressive Rollout)

  • 一次發布一點點變動,並且針對少量使用者發布,每次的變動都可以密切地監控效能是否有什麼影響。
  • 快速準確地發現問題。
  • 出現問題時安全地回滾更改。 
  • 只要錯誤減少,產品交付就會加快。

而自動化的工具很多,非常多,還有公司直接弄成元素周期表

自動化 - DevOps 工具元素週期表
自動化 – DevOps 工具元素週期表 https://devops.phodal.com/home

之後我們會再分享在 GCP 實做的相關工具。

5.任何事都是可以被量測的

這一點是跟 CI/CD 最大的差異之處,它強調的重點如下:

  • 監控是追蹤系統健康和可用性最好的方法
  • 如果必須要有人閱讀電子郵件, 並判斷是否需要採取行動的系統,從根本上是有缺陷的。
  • 只有一定要採取行動的時候,系統才發出通知。
DevOps透過監控達成資訊透明
透過監控達成資訊透明 資料來源:https://www2.slideshare.net/warfan/devops-68063058

跟之前「減少穀倉效應」的概念類似,就是要讓所有事情都透明化,所以才需要「監控」這個關鍵步驟,這樣發生任何事,都能快速找到原因,而不是浪費時間在那邊跟別人吵架。

其實,以上提到的實施方法,就是 Google 提出的 SRE (Site Reliability Engineering) 概念:

各位有空真的可以去讀一下 Google 的 SRE Book,非常適合在睡前看持續成長的你。

最後 Google 還說,方法歸方法,「人與文化」還是推動 DevOps 最關鍵的因素,我們非常需要高階主管的支持, DevOps 才動得起來。 Google 為了推動 DevOps 文化,曾經在公司內辦了大大小小的說明會,就是為了打造一個具有「心理安全」(Psychological Safety) 的環境,更何況是我們,有更多需要「人與文化」改善的地方啊!

Aaron Lee

超過6年的Google Cloud經驗,服務過上百家G Suite與GCP客戶,擔任多次研討會主講人與教育訓練講師,提供架構諮詢與技術支援,幫助各大企業上雲。

發佈留言