傳統大型企業對轉型DevOps是高門檻

DevOps這個名詞，這幾年在台灣被討論次數有越來越高的趨勢，也發現想要導入或是開始進行DevOps的企業，也從過去的網路公司的產業、電商產業或是軟體資訊業，慢慢吹向到傳統企業與製造業的資訊部門。

我在一些非資訊相關產業的場子上，聽到很多企業主管說想要開始導入或是了解DevOps，再加上去年也剛好有幸講了多場的DevOps相關的場子，與培訓一些傳統企業了解DevOps。看來這股熱潮真的是吹向到一般企業。

不過，也令人擔心對於這種東西的渴望，不知道是否會跟早年大家一窩蜂想要導入Scrum，但是，到最後都不了了之。不過，有一點不同地方，早年在Scrum推行時期，倒還沒有聽說很多傳統企業或是製造業想要導入Scrum到自己的資訊部門，這次卻是不同。

聽到每個企業想要導入DevOps的想法，是認為DevOps是一個很潮的玩意，都想跟DevOps沾上邊，再加上一堆軟體大廠不斷推廣自己的DevOps工具，並推波助瀾說可以提升企業開發效能，讓這股熱潮更加火熱。如果仔細推敲後，發現大部分企業認為導入DevOps最大的好處就是可以加快開發效能與佈署效能(怎跟早期要導入Scrum理由似曾相似)，另外，就是可以自動化。

實際上，DevOps並沒有保證能讓專案開發速度變快，有時候，開發速度反而是會變慢的，但是，卻能讓用戶感覺會變好，至少當用戶提出修改需求或是產生Bug，可以快速修正並且立即進行佈署，縮短用戶等待時間。此外，要做自動化這件事情，其實跟DevOps並無太直接關係，沒有了DevOps這個框架還是能做到自動化的持續整合與佈署，但不知道何時這兩者基本上變成等號了。甚至，認為只要導入某家的DevOps工具或是平台，就可以轉型成DevOps了。

自動化整合與佈署並不代表DEVOPS!!

我想對於DevOps解釋大家都應該知道，DevOps是文化、流程及工具三者於一身的結合。而絕大部分的企業，也往往只看到工具，並且急於導入工具，對於前兩項的導入與改變，基本上都是視而不見。很多時候，變成要文化與流程去配合工具而改變，反而這有點本末倒置。最常見就是不同部門用的DevOps工具都不同，甚至，更多不同的規範互相牽制彼此，而系統開發流程必須橫跨這些部門時候，就發現在流程上其實是充滿了斷點，就像每個都是精英，但合作起來就跟散沙差不多，效益沒有提升反而得到更多錯誤與官僚

在2019 DevOps Report可以發現傳統企業或是製造業要轉型DevOps並不是那樣簡單的，整體的比例還是相對很低。尤其，企業越大轉型也越困難

傳統企業或是製造業要轉型或是導入DevOps是真的不容易，且花的時間也會比較久(通常花的時間越久，被阻止的機率也越高了)，再者，如果，轉型不是由Top Down方式下來，最終，結果大概也只有某某部門有執行DevOps，且還不算完整呢。整體狀況依舊不會改變。

個人認為在轉型上這些因素將會是影響DevOps推行，而這些因素分別為:

• 部門專業分工壁壘
• 角色分工分權
• 害怕改變

部門專業分工壁壘

在大型企業部門分工是非常細，說其好聽是所謂的專業分工，降低負擔，其實，也是讓每個人在組織中，至少有工作的做。這種情況下，每個部門都會因為所謂的專業考量下，開始建築了自己的圍牆，只要任何外人踏入該部門領域業務，就是必須遵守該部門所定義的專業政策或是專業做法。這時候，就會發現每個部門開始有了自己所謂的DevOps定義，也開始有了自己的DevOps工具。試想一個情境:

當一個系統從需求、開發到最後佈署，以及想要可以做到每天持續佈署，甚至達到Zero Down time，

這個情境下的流程，最少，會經過三種部門，分別是Infra, Develop和DBA，通常這種情況下，三個部門都會有自己所謂專業考量跟自動化工具。每個部門看來都可以在自己專業領域做到自動化或是所謂的DevOps(姑且先把自動化跟DevOps連起來)，甚至，有自己部門的政策或是規範。

實際上，從情境的流程上與DevOps觀點看來會是有很大問題。從持續整合與佈署角度去看，一套系統要能持續化佈署，怎可能是分批分時做完，系統是環環相扣的，不可能佈署了Application而不立即佈署DB的Application，又或是上了Application後，又要等Infra的Script佈署。雖然，可能在每個局部都有自動化協助，但是，每一個流程都必須等待，這是一件非常奇怪事情。每個部門如果有自己所謂的政策或規範，就會變成當流程走到某部門時候，必須轉換符合該部門政策才可以走下去，不僅又增加等待時間也會增加發生錯誤機率，這樣做法會是好的嗎?往往也只是為了規範而規範。

這其中在於大家只會專注於部門專業領域，甚至所謂的KPI，而忽略整體系統架構與系統開發的生命週期。而在DevOps中，更因該注重我們交付業務的整體流程，而非各自部門流程。當然，會有這樣情況下，也是避免導致某部門某些人的工作被消失。

因此，我認為DevOps是要注重是商業需求到交付需求整體的流程，中間過程都因該被整合到一個團隊或是一個部門內，才有辦法做到DevOps核心，不然，最少，也要跨部門間也要建立一個共通的Pipeline，且是標準化、一致性和可被自動化的，而不是層層規範，建築了層層的圍牆

角色分工分權

角色分工本來是一件好事，不過，有時這樣做法，久了就會走鐘。在越來越講究團隊合作的氛圍下，太過於角色分工與分權下，就會在一個團隊就會開始區分哪些是誰該做，哪些又是誰不該做。看似這樣做法是好的，如果當某一方的事物變多時後，且人員數量不變的情況下，就會發生某一方事情永遠就不完，某一方就會被閒置，這樣對團隊整體效益其實並不好。也就是所謂資源無法充分被使用

因此，在DevOps在很多論點就會強調開發與營運整合成一個團隊，且不分角色別:

DevOps 對團隊代表了什麼意義？DevOps 能讓先前各自獨立的角色 (開發、IT 作業、品質工程和安全性) 互相協調並共同作業，以生產更好、更可靠的產品
~Microsoft

在 DevOps 模型之下，開發與營運團隊不再「孤軍奮戰。」 有時，這兩個團隊會合併成為一個團隊，讓工程師負責整個應用程式生命週期中的工作，包含從開發和測試、部署以及營運，並發展出許多不限於單一功能的技能。
~AWS

在一般企業最常見狀況下就是開發人員與QA人員，QA人員負責測試，卻不會寫測試程式，必須由開發人員寫，但是開發人員又有需求要開發又要寫測試程式。當需求增加，開發人員人數是固定情況下，整體效能就會被卡在開發人員身上。

另外，開發人員也不能只認為談需求並非跟自己無關，只要對於商業需求有任何助益的事情，就是跟團隊任何成員都有關係。開發人員也不能只是單純開發，也必須能協助維運和測試，當然，這樣情況下，開發速度可能因此就會變慢，但是回覆或是修正問題速度，可能因此而增加。換句話說，團隊內都屬於工程人員，也就沒有所謂開發與QA角色了

所以，在DevOps對於團隊來說，因該只有事情的分別，而不該區分角色的分別。任何事項都因該在團隊中都可以是互相支援和幫忙的;不管是從Infra、DB或是Application，都因該在一個團隊內都是可以互相Cover。當然，要這種情況下，企業招募策略可能也會因此有所不同。

害怕改變

我想這是企業中最大問題之一，有時候，也不知道是成員害怕改變，還是，不想改變。畢竟，要轉型DevOps中，要被改變的事務非常多，要被顛覆的想法也很多，這都不是一朝一夕可以完成。

如前面提到，如果要讓QA人員改變，可以協助開發，開發人員必須協助營運，甚至所謂的On Call，這將會是多大改變啊，過程中，當然也必須承擔一定的風險。因此，改變大小與風險等級將會低度相關的，這也因此是企業轉型會考量的一點。

另外，對於成員來說，就必須花額外時間改變，往往企業內很多成員是不想這樣做的。畢竟，原本的工作與資歷讓自己在企業內活得好好的，為什麼還需要增加自己負擔?且可能還帶來一點風險。尤其，資歷越深的人，可能也往往越不容易想要去改變。

其實，人的心態也是DevOps是否能成功的重要因子，如果對於新的事物都抱持打太極或是馬上持反對的人，也很難進行改變的。

最後…

是否還有其他絆腳石會讓企業在推行DevOps不順利嗎?，我想除了上面三個影響外，也因該還有很多因素會導致不順利。例如: ERP或是MES適合走DevOps嗎?

當然，也有聽說把DevOps導入作為一項專案處理，這當然就更不可能成功了。DevOps的導入是否真的能讓開發流程速度加速或是變好，我想沒有一個人有保握，縱使有非常多案例是成功，也不代表使用到自己的企業是會成功，再加上大部份企業都想要急功近利，一旦短期看不到效果可能就會終止這項計畫或是不在持續往前，也當然會造成前功盡棄。

越大型企業是需要更多時間與人力進行這項工作。很多時候，Top Down是有其必要性，但是，在組織文化中只靠Top Down強勢推，也不一定容易成功，最好，也必須能Bottom Up，這樣才有辦法讓DevOps推行更為順利

而這種情況下，也必須大家能對DevOps認知是相同的，更重要的是要能觀看全局的DevOps，並非只局限於自己所謂專業或是領域的DevOps。

滴估

另外，當這氛圍真的沒有從上到下產生一致性，真的會變成艱難起步，一夕之間瓦解。這部分後續有機會再來談