需要專職的 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: 內部的測試環境,包含功能、整合、效能、資安 … 各種測試階段參閱:淺談軟體測試的階段與策略
  • Go Production: 對外的環境都是 Producion Ready 的。像是:Staging、Canary、Sandbox、Production

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

  1. 產出物管理 (Artifact Management)
  2. 建置環境 (Provisioning)
  3. 配置管理 (Configuration Management)
  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 Management
  3. 配置檔說明

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

關於 In-House 測試階段、目的、策略,參閱:淺談軟體測試的階段與策略

部署策略 (Deployment Strategies)

部署策略是現代系統架構更新 業務功能 或者 架構異動 時候,異動線上版本的方法與流程。我在公司內部的讀書會也好、或者一些場合常會用這張圖說明什麼是部署策略:

圖片來源: https://thenewstack.io/deployment-strategies/

部署策略就是一種選擇,依照以下的考量,會有不同的方式:

  1. 影響範圍:業務功能、服務架構異動、基礎架構異動 (OS/Security Patch)
  2. 業務需求:少量測試、蒐集回饋

這些考量決定使用什麼樣的部署方法,這個 選擇 稱為 部署策略 ,換言之,部署的方式不會是萬年不變,而是會隨著需求,有所調整,那麼 一鍵部署 就不是那麼單純了。所以 Release 工作每一次必須:

  1. 選擇 (Plan) 怎樣的部署策略?
  2. 實作 (Execution) 這些部署方法
  3. 驗證 (Acceptance) 這些部署方法
  4. 執行 (Go Live) 這個部署方法

所以,這是工程問題。其中,實作、與驗證更是很容易被忽略的,所以千萬,不要隨便找個人,就以為搞得定。

一鍵部署的假象

延續部署策略,針對一鍵部署的誤解與迷思,提兩個觀點:

  1. 你是按下那個按鈕的人?
  2. 還是設計那個按鈕的人?

如果是 設計的人,是依據什麼樣的背景設計那個按鈕背後的動作?考慮些什麼?要有怎樣的技能?要知道些什麼?這是工程任務,說白了,不是阿貓阿狗做得來的。至少要具備一定的架構思維、程式開發、系統分析等能力。

如果你覺得 Release Engineer 只是按下按鈕的那個人,那你真的是太天真了,按個按鈕,當然不需要專人專職,但是設計那個按鈕就是工程的問題。汽車的離合器不過是一根轉來轉去的桿子。

一些想法,也分享在這場演講: 聊聊軟體交付的濫觴 談產出物管理 ,主要是以 Artifact Management 的角度談這件事情。



錄影:


企業階段

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

  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: 可以駕馭技術,但看不到全貌,狂踩油門,跟酒駕沒兩樣。快點找顧問或者架構師幫忙。
  4. 11: 能看到全貌、能駕馭技術。剩下的問題是:如何讓團隊成員都可以 - 1) 選擇適當的部署策略 2) 一鍵部署

整理如下圖:

結論

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

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


相關文章 (站內)

更新紀錄

  • 2019/09/10: 增加部署策略、四象限圖、一鍵部署的假象兩段

Comments