Skip to main content

專職？

那天讀書會討論到 Release 的角色 (不管是叫 DevOps Engineer or Release Engineer) 是否應該專職？

討論到最後一定分成兩種：

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

我想想都對、也都不對，因為這兩個都沒有提到前提條件，整理有以下：

  1. SOP (Pipeline) 未確立之前：一定是專人專職，因為狀況很複雜，流程一直在變，必須用 #技術 來駕馭、控制整個過程。
  2. SOP 很清楚的：誰來點都可以，反正要做的就是那些 A,B,C,.... 只要能夠透過標準化的流程，透過一段時間訓練就可以上手的。這表示已經經過時間考驗的結果，經過 (1 焠鍊後的結果。

所以表示 2) 要先有 1) 的結果與歷練，才有辦法在不影響任務的前提下， #輪著做，再說一次：不影響任務的前提！如果會影響任務，那這件事情會造成的現象稱為：#壓力

除了 SOP，另外要提的是 #範圍：

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

現在的 CI/CD 工具鍊複雜度以及觀念，甚至是架構，跟十年前比起來其實差不多。但是擴散的面積已經跟以前不一樣，以前可能只有部分人有辦法看到全貌，現在是大家都可以看到全貌。
但是問題就在於 #看到全貌 != #可以駕馭全貌 ... 這是兩回事。#駕馭需要 #技術能力、專業 與 經驗；了解全貌需要 #視野、判斷力、決策力，甚至是戰略。

現在的問題通常有以下：

  1. 無法看到全貌
  2. 無法駕馭技術
  3. 前述兩者的排列組合，有三個狀況會造成負面狀況

要 #成事，兩者缺一不可。能看到全貌，卻無法駕馭，那就像在玩遙控車；可以駕馭，看不到全貌，就跟酒駕沒兩樣，狂踩煞車，卻不知為何而戰。

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

原始資料​