2014/2/5

DevOps (Development + Operations)

傳統的軟體開發,系統維運與品質保證三個單位各自獨立,因為部門之間的區隔,形成了 Wall of Confusion,為了讓整個開發活動在這幾個參與的單位之間,形成更有效率更有生產力的程序,轉化部門之間的對立為正向的互助合作,dev2ops.org 提出DevOps,希望能補足目前開發流程的不足。



上圖說明了系統開發與維運兩個單位之間的隔閡,因為單位不同,各單位傾向於維護自己單位的利益,系統維運為求系統穩定,通常會盡所有可能的方式,阻擋新版程式的更新,因為更新就有可能會帶來混亂,而不穩定的系統通常會歸咎於維運單位的問題,而如果到最後,又找出來問題的根源在於開發單位的錯誤、更新程序的說明文件不足、新版程式測試不完整,這種種可能的原因,最後上線了,都得要讓客服與維運人員承受客戶的壓力,惡性循環下,讓兩個單位之間的高牆更高、更難跨越。



業務單位的需求來自客戶,而開發單位需要更新程式,最常發生的原因是來自業務單位的需求,這也是業務跟開發之間的高牆,開發單位需要有個開發的程序,用來管理客戶需求跟開發的步驟。這個部份是目前討論最多的,也就是軟體工程的方法論,傳統的方式是 waterfall,後來進化到 Unified Processing,然後是 Agile Development Process。

DevOps將開發活動從客戶需求,實際的開發與測試,延伸到最後維運單位的系統更新與上線,DevOps 也可看成是開發、QA與維運三個單位的交集。



DevOps wiki 提供了一份很清楚的說明,DevOps 就是要解決系統發布與更新的問題,解決的方式就類似由 waterfall 轉變到 agile development 的過程,打破一個月、一季或更長時間的更新堆積,導入 DevOps 帶來的影響是

  1. 減少變更範圍:每天或每週更新一次,減少更新帶來的變化,更新的速度更頻繁,讓系統開發與維運的活動更熱絡,養成工作習慣的 routine,少量更新也讓所有人員更容易找出發生問題的地方
  2. 加強發布協調:以發布協調人員居中協調系統開發與維運之間的橋樑,採用各種協調互動的工具,讓所有人了解系統更新的程序與內容
  3. 自動化:自動化部署程序,確認可重複性的系統更新,減少出錯的可能

其實 DevOps 就等同於 Release Management,但是更強調快速與自動化的部署與驗證,還有開發跟維運兩個單位之間的互助合作。

身為開發人員,我們接受 agile development 的概念,貼近客戶與業務的需求,擁抱改變,還要以 DevOps 補足開發與維運之間的落差,認清系統的更新變化是常態的事實,既然不能拒絕改變,那麼就要擁抱改變,習慣它,然後持續尋求更好的方法與變化共處。

沒有留言:

張貼留言