傳統的軟體開發，系統維運與品質保證三個單位各自獨立，因為部門之間的區隔，形成了 Wall of Confusion，為了讓整個開發活動在這幾個參與的單位之間，形成更有效率更有生產力的程序，轉化部門之間的對立為正向的互助合作，dev2ops.org 提出DevOps，希望能補足目前開發流程的不足。
上圖說明了系統開發與維運兩個單位之間的隔閡，因為單位不同，各單位傾向於維護自己單位的利益，系統維運為求系統穩定，通常會盡所有可能的方式，阻擋新版程式的更新，因為更新就有可能會帶來混亂，而不穩定的系統通常會歸咎於維運單位的問題，而如果到最後，又找出來問題的根源在於開發單位的錯誤、更新程序的說明文件不足、新版程式測試不完整，這種種可能的原因，最後上線了，都得要讓客服與維運人員承受客戶的壓力，惡性循環下，讓兩個單位之間的高牆更高、更難跨越。
業務單位的需求來自客戶，而開發單位需要更新程式，最常發生的原因是來自業務單位的需求，這也是業務跟開發之間的高牆，開發單位需要有個開發的程序，用來管理客戶需求跟開發的步驟。這個部份是目前討論最多的，也就是軟體工程的方法論，傳統的方式是 waterfall，後來進化到 Unified Processing，然後是 Agile Development Process。
DevOps將開發活動從客戶需求，實際的開發與測試，延伸到最後維運單位的系統更新與上線，DevOps 也可看成是開發、QA與維運三個單位的交集。
DevOps wiki 提供了一份很清楚的說明，DevOps 就是要解決系統發布與更新的問題，解決的方式就類似由 waterfall 轉變到 agile development 的過程，打破一個月、一季或更長時間的更新堆積，導入 DevOps 帶來的影響是
- 減少變更範圍：每天或每週更新一次，減少更新帶來的變化，更新的速度更頻繁，讓系統開發與維運的活動更熱絡，養成工作習慣的 routine，少量更新也讓所有人員更容易找出發生問題的地方
- 加強發布協調：以發布協調人員居中協調系統開發與維運之間的橋樑，採用各種協調互動的工具，讓所有人了解系統更新的程序與內容
- 自動化：自動化部署程序，確認可重複性的系統更新，減少出錯的可能
其實 DevOps 就等同於 Release Management，但是更強調快速與自動化的部署與驗證，還有開發跟維運兩個單位之間的互助合作。
身為開發人員，我們接受 agile development 的概念，貼近客戶與業務的需求，擁抱改變，還要以 DevOps 補足開發與維運之間的落差，認清系統的更新變化是常態的事實，既然不能拒絕改變，那麼就要擁抱改變，習慣它，然後持續尋求更好的方法與變化共處。
沒有留言:
張貼留言