為何 DevOps 會給開發人員帶來壓力和倦怠？

企業正在享受 DevOps 實施帶來的好處，但這也是有代價的。開發人員需要承擔額外的責任，可能會導致他們感到疲憊不堪。因此我們可以採取一些方法來確保 DevOps 工程師的滿意度。
 

DevOps 的支持者通常將這一概念說成是提高效率和生產力的好方法。透過加強開發人員和 IT 運維工程師之間的協作，DevOps 能讓每個人都朝著共同的目標更有效地工作。在很多情況下可能都是如此。然而，有人認為  DevOps 也有一個重大缺點：負責保持 DevOps 流程執行的工程師的壓力水平增加。
 

以下是 DevOps 可能使開發人員的工作更具挑戰性的原因，以及組織可以採取哪些措施來確保他們從 DevOps 中受益而不會讓工程師抓狂。
 

DevOps 如何為企業帶來效益

首先，讓我們來了解一下 DevOps 的含義及其對企業的幫助。
 

DevOps 的理念是開發和 ITOps 團隊應該緊密合作，即開發人員和 ITOps 之間的密切合作確保兩個團隊能夠相互支援。
 

DevOps 的出現是為了解決許多組織在過去幾十年中面臨的一個挑戰，即開發人員在編寫程式碼時往往很少或根本得不到 ITOps 團隊的反饋。這導致了溝通孤島、效率低下，在某些情況下，開發人員和 ITOps 工程師之間關係緊張。透過幫助每個人持續合作，DevOps 可以讓企業避免這些陷阱。
 

因此，從企業的角度來看，DevOps 是一件好事，因為它有助於確保工程師儘可能地提高工作效率。它能最大限度地減少時間和精力的浪費，通常還能提高企業推出新軟體的速度，這反過來又能為企業帶來市場競爭優勢。
 

DevOps 對工程師意味著什麼

對於開發人員本身來說，DevOps 並不總是那麼美好。DevOps 迫使工程師做兩件事，這會增加他們的工作壓力：

• 承擔更廣泛的責任：DevOps 要求工程師們同時負責兩類流程，而不是隻負責軟體開發或 IT 運營。

• 適應節奏更快的釋出週期：DevOps 與 CI/CD 等實踐齊頭並進，DevOps 團隊通常需要每週至少釋出一次新的應用程式更新，有時甚至需要每天釋出一次。這與 "瀑布式 "軟體開發戰略的時代大相徑庭，在 "瀑布式 "軟體開發戰略下，新版本即使一年釋出一到兩次，也是如此。
   

這兩個因素都會使工程師的工作變得更加緊張。在採用 DevOps 的企業中，工程師被要求做得更多、更快。
 

當然，DevOps 為軟體交付流程帶來的高效率有可能使工程師在滿足這些更嚴格要求的同時，總體壓力水平低於沒有 DevOps 時的水平。如果沒有 DevOps，團隊通常會浪費更多時間來修復程式碼，並在出錯時相互指責，這本身就是一種壓力。透過減輕這些挑戰，一個實施良好的 DevOps 戰略可以讓工程師們在整體上更輕鬆一些。
 

但並不是所有 DevOps 戰略都能得到很好的實施，DevOps 本身就存在一種風險，那就是過多的 DevOps 實踐只會導致工程師壓力更大，更容易倦怠。他們可能會設法更快地釋出新版本，但會犧牲工程師的工作滿意度作為代價，這種成就是以高昂的代價換來的。
 

讓 DevOps 工程師更輕鬆

為了避免這些問題， 選擇採用 DevOps 的企業應確保設定合理的期望值。例如，每週釋出一次新版本可能會給工程師帶來過大的壓力，至少在一開始是這樣。設定更適度的目標有助於降低 DevOps 工程師倦怠的風險。
 

限制 DevOps 工程師的職責也會有所幫助。雖然 DevOps 通常鼓勵 DevOps 團隊中的每個人共同承擔軟體交付流程中每個環節的責任，但讓某些工程師牽頭負責某些流程（如開發、測試和部署）通常更為現實。集體責任感仍然普遍存在，但為不同型別的任務指定牽頭人可以讓團隊成員優先處理某些任務，而不是試圖掌控軟體交付生命週期的每個階段，從而減輕每位工程師的整體壓力。
 

在某些情況下，企業首先應該 限制採用 DevOps 的範圍。並不是每個應用程式都需要持續開發；有些應用程式（如傳統軟體）的變化頻率並不高，不值得被嵌入 CI/CD 流水線。企業在實施 DevOps 時要有戰略眼光，這樣才能降低將過多 DevOps 實踐強加給沒有能力或時間處理所有實踐的工程師的風險。
 

總 結

在 DevOps 領域中，需要謹慎執行，因為過度的任務和壓力可能會減弱其優勢。雖然毫無疑問，DevOps 為企業帶來了顯著的優勢，使開發人員能夠實現更高的效率和生產力，但同時也可能給他們的團隊帶來負擔。為了防止 burnout 的風險，請避免過度採用 DevOps 實踐。
 

參考連結：
https://www.itprotoday.com/devops/downside-devops-stress-and-burnout-engineers