需要專職的 Release Engineer？
本文整理 SRE 讀書會 Round 2 的討論與筆記。問題是：
團隊 Release 的角色是否應該專職？ (不管是叫 DevOps Engineer, Release Engineer, or SRE)
那天 (2018/09/13) 討論的章節是 第七章 提交階段，我在回程公車上寫下這段 筆記，重新整理成文章，也補充一些想法。 這問題討論通常到最後會分成兩種：
不該專職：團隊成員輪著做，不應該專職 (偏向 Agile 的概念)應該專職：技術 know how 很深，應該專人專職 (偏向傳統、大型組織)
我想想都對、也都不對，因為這兩個都沒有提到 前提條件與背景，這樣的討論不會有結論。我從以下幾個面向分析：
- 企業階段
- 架構與組織
- 產品特性
Updated 2023/07/19: 本文收錄在個人著作 《SRE 實踐與開發平台指南》 - 2023/08 上市
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，也就是包含交付的概念，而交付的第一要務，要面對以下四個：
產出物管理 (Artifact Management)建置環境 (Provisioning)配置管理 (Configuration Management)部署策略 (Deployment)
這四個階段的任務，必須在測試階段就必須確立這些東西，Go Production 隨時間前進，業務增長，才能穩定的長大、長壯、長強。
更多參閱：DevOps 8 字環的誤區：左環問題、 Go Live 的說明。
Go Production
把開發好的產出物 (Artifact)，這東西已經經過內部 (In-House) 測試、驗證過，準備放到 (Deploy) 正式環境 (Production)，這個過程稱為：Release 或 Go Production。
Production 只是 Release 的其中一個對象，有些產品需要有 Sandbox，例如給客戶測試用的 API Sandbox，有時候需要 Canary Deployment，同樣都是 Release 的。Release 對象可能有：
- Sandbox
- Staging
- Canary
- Production
這四種，最常見的就是 Staging 和 Production。而 Go Production 是 Release Engineer 的工作範圍。
In-House
In-House 的建置必須由 QA/SDET 等角色自行完成，但是開發 Team 必須提供以下：
- 完整架構圖
- Artifact Management
- 配置檔說明
部署策略則在測試過程中，由 Dev / QA / Ops 三方協作討論出最佳策略。
關於 In-House 測試階段、目的、策略，參閱：淺談軟體測試的階段與策略
部署策略 (Deployment Strategies)
部署策略是現代系統架構更新 業務功能 或者 架構異動 時候，異動線上版本的方法與流程。我在公司內部的讀書會也好、或者一些場合常會用這張圖說明什麼是部署策略：
部署策略就是一種選擇，依照以下的考量，會有不同的方式：
- 影響範圍：業務功能、服務架構異動、基礎架構異動 (OS/Security Patch)
- 業務需求：少量測試、蒐集回饋
這些考量決定使用什麼樣的部署方法，這個 選擇 稱為 部署策略 ，換言之，部署的方式不會是萬年不變，而是會隨著需求，有所調整，那麼 一鍵部署 就不是那麼單純了。所以 Release 工作每一次必須：
- 選擇 (Plan) 怎樣的部署策略？
- 實作 (Execution) 這些部署方法
- 驗證 (Acceptance) 這些部署方法
- 執行 (Go Live) 這個部署方法
所以，這是工程問題。其中，實作、與驗證更是很容易被忽略的，所以千萬，不要隨便找個人，就以為搞得定。
- 類似的概念，請參考測試策略：淺談軟體測試的階段與策略
- Plan, Execution, Acceptance, Go Live 的想法，參閱 Software Development Lifecycle
一鍵部署的假象
延續部署策略，針對一鍵部署的誤解與迷思，提兩個觀點：
- 你是按下那個按鈕的人？
- 還是設計那個按鈕的人？
如果是 設計的人，是依據什麼樣的背景設計那個按鈕背後的動作？考慮些什麼？要有怎樣的技能？要知道些什麼？這是工程任務，說白了，不是阿貓阿狗做得來的。至少要具備一定的架構思維、程式開發、系統分析等能力。
如果你覺得 Release Engineer 只是按下按鈕的那個人，那你真的是太天真了，按個按鈕，當然不需要專人專職，但是設計那個按鈕就是工程的問題。汽車的離合器不過是一根轉來轉去的桿子。
一些想法，也分享在這場演講： 聊聊軟體交付的濫觴 談產出物管理 ，主要是以 Artifact Management 的角度談這件事情。
錄影：
企業階段
不同的企業階段，針對職務、或角色有不同定義與需求，整理前提與背景的組合如下：
SOP 未確立之前：工具、流程、架構還在混沌狀態，也就是 deployment pipeline 還在探索、確認中- 一定是專人專職，因為狀況很複雜，流程一直在變，必須用技術來駕馭、控制整個過程。
- 這個人對整理狀況有一定掌握度，有一定的技術能力
- 通常是新創事業，要即戰力，每個人都是各個領域的專家、高手
- 萬事起頭難，需要有經驗的人開始
SOP 很清楚：工具、流程、架構都清楚了，deployment pipeline 已經很清楚。- 誰來點都可以，反正要做的就是那些 A,B,C,….
- 只要能夠透過標準化的流程，透過一段時間訓練就可以上手的。
- 這表示已經經過時間考驗的結果，經過 (1 焠鍊後的結果。
所以表示 2) 要先有 1) 的結果與歷練，才有辦法在不影響任務的前提下 輪著做。
再說一次：不影響任務的前提！如果會影響任務，那這件事情會造成的現象稱為：
壓力
所以，回到標題自問：你們的團隊、組織，現在在什麼階段？誰來劃分這些階段？怎麼畫分？
架構與組織
用架構與組織當作兩個維度，結果都是清楚與不清楚。
架構：指的是系統架構的清晰度，包含邊界、依賴性、耦合度等面向。組織：組織的拆分，人員的專業、團隊的職責，簡單說就是 R&R (Role and Responsiblity)
這兩個面向，用清楚與不清楚分，所以有四種排列組合：
- 架構不清楚、組織不清楚：找技術高手和顧問來幫忙。
- 架構不清楚、組織清楚：找技術高手來幫忙。
- 架構清楚、組織不清楚：找顧問來協助
- 架構清楚、組織清楚：直接往下一個階段走，讓團隊自行發揮
組織結構與架構無法清楚的時候，造成的問題是：內部空轉以及溝通成本。
產品特性
除了 SOP，另外要提的是產品特性的 範圍：
小範圍：互聯網的軟體，Startup 的核心團隊，或者 Microservice 的 2pizza team，這種一定是大家都要能相互 cover大範圍：大型產品（作業系統、火箭、汽車），組織很龐大的 team，例如 M$ 的 Windows Team or NASA 火箭發射… 這種的團隊一定是專職專人
現在的 CI/CD 工具鍊複雜度以及觀念，甚至是架構，跟十年前比起來其實差不多。但是擴散的面積、應用技術已經跟以前不一樣，以前可能只有部分人有辦法看到全貌，現在是大家都可以看到全貌。
但是問題就在於：
看到全貌!=可以駕馭全貌
這是兩回事。
駕馭：需要一定的技術能力、專業與經驗了解全貌：需要組織能力、視野、判斷力、決策力，甚至是策略與戰略
問題的維度
我觀察到問題的維度有以下：
- (A)
看到全貌：能否看見全貌，分成系統架構、組織架構 - (B)
駕馭技術：技術成熟度，包含 CI/CD 工具駕馭、容器化等
這兩個變因的四種排列組合：
00: 看不到全貌，也無法駕馭技術。找顧問諮詢，才知道聘雇哪一種技術專家。10: 能看到全貌，卻無法駕馭技術，就像在玩遙控車：確認技術棧，聘雇技術專家，我們要玩真的。01: 可以駕馭技術，但看不到全貌，狂踩油門，跟酒駕沒兩樣。快點找顧問或者架構師幫忙。11: 能看到全貌、能駕馭技術。剩下的問題是：如何讓團隊成員都可以 - 1) 選擇適當的部署策略 2) 一鍵部署
整理如下圖：
結論
回到開頭的是否需要專職的 DevOps Engineer, Release Engineer or SRE？你現在有答案了？
下一個問題是：需要聘僱專職的 SRE？或者成立 SRE 團隊？
相關文章 (站內)
- 導入 CI/CD 的第一步
- 怎樣的 CI/CD 才夠 Quality?
- Resource Provisioning and DevOps
- What is Automation?
- Go Live
- Artifact Management
- Role And Responsibility
- 淺談軟體測試的階段與策略
- 怎樣的 CI/CD 才夠 Quality?
- DevOps 8 字環的誤區：左環問題
- 聊聊軟體交付的濫觴 談產出物管理
- Software Development Lifecycle
- 個人著作《SRE 實踐與開發平台指南》 (2023/08 上市)
更新紀錄
- 2019/09/10: 增加部署策略、四象限圖、一鍵部署的假象兩段
Comments
About
著作
演講
AWS Certifications
