如何開始導入DevOps
說到DevOps，我想最常見的切入要點便是組織文化、自動化、Silo與各種工具，但這篇文章並不打算從這角度直接地討論DevOps。在任何的新流程與技術導入之前，應該先討論的是—需求。這是一切改變與改善的基礎，不應該為了任何Buzz word而衝動地進行任何決策改變。因此，整篇文章打算從“精實思考”，開始討論整個DevOps導入的起點。
從精實思考的角度切入，首要之務便是討論“價值”，到底整個生產過程所要轉換出的價值是甚麼，這個價值基本上與客戶所期待的價值有關。以目前科技服務市場來說，業務的樣貌與需求變化快速，為了能夠因應這樣的現況，並且協助業務單位快速地捕捉這樣的變動，工程必須找出一個更具效率，並且快速驗證需求的方法。因此，我們可以定義目前所需要的傳遞的價值是
基於業務的需求，快速地實作並且改善服務的功能，以便能夠正確且有效地滿足終端使用者的需求。
有了以上的設定後，所需要思考的便是整個價值傳遞所需步驟與資源為何？先看看在客觀情況下，整個價值製造所需要的步驟與資源。下圖以服務開發流程為例。
從程式碼的建構到部署，所歷經的流程不外乎就是，開發—打包—測試—版控—發佈。從這流程中，可以辨識出整個流程必要的工作項目，接著便是工具的選用與組裝。工具的選用與組裝，最重要的就是省去重複人工的行為與流程的阻塞的問題。傳統的服務設計以大顆粒且複雜的系統結構作為其基礎，增加了服務上線前的測試複雜程度與準備時間，因此往往採用重重的簽核機制，確保服務的品質。然而，此舉卻導致無法應對快速變動的業務需求，因此，工程設計上，必須考量低耦合與容錯設計，讓各自的服務能夠被獨立且快速的驗測，提高服務的穩定與品質，而在此前提之下，傳統的變更流程也必然得面對簡化與自動化，品質的提高並非靠已習慣的簽核流程，而是靠流程的自動框架，確保每個檢查項能夠被正確且無誤的執行。換言之，簡化不需要的檢查項，並且加強且落實每個確認機制。如此一來，整個釋出流程才能快又有效，從月級轉移至分鐘級。
至於工具的選用上，這部分就必須考量到組織內目前的工具樣貌與成員的技術能力狀況，建議上，採取單一且有效的工具即可，流程與工具的建立並非一朝一夕，沒必要非在一開始便是全副武裝，重點是因組織樣貌與市場需求，積極地改善整個流程，並且讓工程能夠基於需求開發。
最後，仍然免不了要來討論一下文化問題，DevOps推動必須要基於需求，主要的原因在於這樣的改善才能有效地得到組織內決策者的支持，在流程改善過程中，必然會使得原先工作崗位上的人，面對工作項目的變動，而此現象也必然產生一些衝突與挑戰，建議上，可以先在新專案上採用，使用併軌的方式進行，然後再擴展至舊有流程的移轉與改善。這樣會讓整個推動上較為順遂。
訂閱：
文章
(
Atom
)
沒有留言 :
張貼留言