需要專職的 Release Engineer?


本文整理 SRE 讀書會 Round 2 的討論與筆記。問題是:

團隊 Release 的角色是否應該專職? (不管是叫 DevOps Engineer, Release Engineer, or SRE)

那天 (2018/09/13) 討論的章節是 第七章 提交階段,我在回程公車上寫下這段 筆記,重新整理成文章,也補充一些想法。 這問題討論通常到最後會分成兩種:

  • 不該專職:團隊成員輪著做,不應該專職 (偏向 Agile 的概念)
  • 應該專職:技術 know how 很深,應該專人專職 (偏向傳統、大型組織)

我想想都對、也都不對,因為這兩個都沒有提到 前提條件與背景,這樣的討論不會有結論。我從以下幾個面向分析:

  • 企業階段
  • 架構與組織
  • 產品特性

Release 負責怎樣的工作?

Go Live

我把 Deploy 的過程稱為 Go Live,Live 包含 Release 前、後的所有環境,包含 Functional / Non-Functional / Production 等環境。Go Live 的範圍與分類如下:

  • In-House: 內部的測試環境,包含功能、整合、效能、資安 … 各種測試階段參閱:Stages in Software Testing
  • Go Production: 對外的環境都是 Producion Ready 的。像是:Staging、Canary、Sandbox、Production

這邊特別強調的是,測試環境也是一種 Go Live,也就是包含交付的概念,而交付的第一要務,要面對以下四個:

  1. 產出物管理 (Artifact Management)
  2. 建置環境 (Provisioning)
  3. 配置管理 (Config)
  4. 部署策略 (Deployment)

這四個階段的任務,必須在測試階段就必須確立這些東西,Go Production 隨時間前進,業務增長,才能穩定的長大、長壯、長強。

更多參閱:DevOps 8 字環的誤區:左環問題Go Live 的說明。

Go Production

把開發好的產出物 (Artifact),這東西已經經過內部 (In-House) 測試、驗證過,準備放到 (Deploy) 正式環境 (Production),這個過程稱為:ReleaseGo Production

Production 只是 Release 的其中一個對象,有些產品需要有 Sandbox,例如給客戶測試用的 API Sandbox,有時候需要 Canary Deployment,同樣都是 Release 的。Release 對象可能有:

  1. Sandbox
  2. Staging
  3. Canary
  4. Production

這四種,最常見的就是 Staging 和 Production。而 Go Production 是 Release Engineer 的工作範圍。

In-House

In-House 的建置必須由 QA/SDET 等角色自行完成,但是開發 Team 必須提供以下:

  1. 完整架構圖
  2. Artifact
  3. 配置檔說明

部署策略則在測試過程中,由 Dev / QA / Ops 三方協作討論出最佳策略。

關於 In-House 測試階段、目的、策略,參閱:Stages in Software Testing


企業階段

不同的企業階段,針對職務、或角色有不同定義與需求,整理前提與背景的組合如下:

  1. SOP 未確立之前:工具、流程、架構還在混沌狀態,也就是 deployment pipeline 還在探索、確認中
    • 一定是專人專職,因為狀況很複雜,流程一直在變,必須用技術來駕馭、控制整個過程。
    • 這個人對整理狀況有一定掌握度,有一定的技術能力
    • 通常是新創事業,要即戰力,每個人都是各個領域的專家、高手
    • 萬事起頭難,需要有經驗的人開始
  2. SOP 很清楚:工具、流程、架構都清楚了,deployment pipeline 已經很清楚。
    • 誰來點都可以,反正要做的就是那些 A,B,C,….
    • 只要能夠透過標準化的流程,透過一段時間訓練就可以上手的。
    • 這表示已經經過時間考驗的結果,經過 (1 焠鍊後的結果。

所以表示 2) 要先有 1) 的結果與歷練,才有辦法在不影響任務的前提下 輪著做

再說一次:不影響任務的前提!如果會影響任務,那這件事情會造成的現象稱為:壓力

所以,回到標題自問:你們的團隊、組織,現在在什麼階段?誰來劃分這些階段?怎麼畫分?


架構與組織

用架構與組織當作兩個維度,結果都是清楚與不清楚。

  • 架構:指的是系統架構的清晰度,包含邊界、依賴性、耦合度等面向。
  • 組織:組織的拆分,人員的專業、團隊的職責,簡單說就是 R&R (Role and Responsiblity)

這兩個面向,用清楚與不清楚分,所以有四種排列組合:

  1. 架構不清楚、組織不清楚:找技術高手和顧問來幫忙。
  2. 架構不清楚、組織清楚:找技術高手來幫忙。
  3. 架構清楚、組織不清楚:找顧問來協助
  4. 架構清楚、組織清楚:直接往下一個階段走,讓團隊自行發揮

組織結構與架構無法清楚的時候,造成的問題是:內部空轉以及溝通成本。


產品特性

除了 SOP,另外要提的是產品特性的 範圍

  1. 小範圍:互聯網的軟體,Startup 的核心團隊,或者 Microservice 的 2pizza team,這種一定是大家都要能相互 cover
  2. 大範圍:大型產品(作業系統、火箭、汽車),組織很龐大的 team,例如 M$ 的 Windows Team or NASA 火箭發射… 這種的團隊一定是專職專人

現在的 CI/CD 工具鍊複雜度以及觀念,甚至是架構,跟十年前比起來其實差不多。但是擴散的面積、應用技術已經跟以前不一樣,以前可能只有部分人有辦法看到全貌,現在是大家都可以看到全貌。

但是問題就在於:

看到全貌 != 可以駕馭全貌

這是兩回事。

  • 駕馭:需要一定的技術能力、專業與經驗
  • 了解全貌:需要組織能力、視野、判斷力、決策力,甚至是策略與戰略

問題的維度

我觀察到問題的維度有以下:

  • (A) 看到全貌:能否看見全貌,分成系統架構、組織架構
  • (B) 駕馭技術:技術成熟度,包含 CI/CD 工具駕馭、容器化等

這兩個變因的四種排列組合:

  1. 00: 看不到全貌,也無法駕馭技術。放低身段,快點找專家顧問來幫忙。
  2. 10: 能看到全貌,卻無法駕馭技術,那就像在玩遙控車:要趕快找高手進來,我們要玩真的。
  3. 01: 看不到全貌,可以駕馭技術,跟酒駕沒兩樣,狂踩煞車,卻不知為何而戰。快點找 DevOps 顧問或架構師幫忙。
  4. 11: 能看到全貌、能駕馭技術。剩下的問題是:如何讓團隊成員都可以做這件事情。

結論

回到開頭的是否需要專職的 DevOps Engineer, Release Engineer or SRE?你現在有答案了?

下一個問題是:需要聘僱專職的 SRE?或者成立 SRE 團隊?


相關文章 (站內)


Comments