DevOps 做好自動化,遠離肝硬化

DevOps的定義

在還沒有DevOps這個字出現之前,這樣的概念早就成形,當時人們使用這些名詞:Agile Operations and Infrastructure、Agile System Administration、Dev and Ops Cooperation。

在2009年的Velocity研討會上, Flickr的兩位工程師John Allspaw和Paul Hammond發表了一個演說《10+ Deploys Per Day: Dev and Ops Cooperation at Flickr》,分享Flickr內部開發人員和維運人員合作的實例,讓他們可以在一天內做完十次的部署。這也是DevOps第一次向世人展示出它的威力。

維基百科引用了2009年Rajiv的解釋和一張經典圖例來定義DevOps:
『DevOps(英文Development和Operations的組合)是一組過程、方法與系統的統稱,用於促進開發(應用程式/軟體工程)、技術運營和質量保障(QA)部門之間的溝通、協作與整合。』


這個定義翻成白話來解釋,就是「不同的團隊一起合作」。相信這個神邏輯大家早就知道了,但DevOps不只是這樣而已。它真正的重點在於,必須讓溝通、協作、整合的「文化」根植在組織內部,並落實到每個人的日常工作上。

從系統開發到維運上線都是DevOps可施力之處,通常可以包括以下範疇:
  • 程式部署
  • 效能監控
  • 日誌管理
  • 版本控管
  • 備份管理
  • 各種環境的建置
  • 各種測試
  • 問題追蹤

沒有自動化,遲早肝硬化

儘管有這麼多的工作要執行,老闆並不會因此加派人手,所以落實DevOps,必須盡一切可能做到:自動化,自動化,自動化,因為很重要所以要說三次。如果沒有自動化,遲早會得肝硬化。

DevOps的目標是「借由工作自動化,來提升團隊工作效能,減少錯誤,進而縮短產品交付周期」。必須盡量把重複性高的工作自動化,因為重複性的工作交給人工去做,不但沒有效率,而且容易出錯,以下舉兩個例子來說明自動化的優點。
  • 程式的部署常常需要重複執行,而且環境配置可能很複雜,如果交由人工執行,若某人前晚打電動太晚睡,部署時突然晃神,少執行一個步驟,程式部署可能就失敗了,如果交由程式自動執行,比人工有效率且可靠得多。
  • 使用者回報正式環境發生嚴重錯誤,團隊收到問題之後,通常要花大半天的時間追查問題,再花更多的時間修正問題。如果可以在系統發生錯誤當下,自動把錯誤日誌以簡訊方式發送給工程師,工程師收到錯誤日誌後,可以很快知道問題的根本原因,進而修正問題,然後新版程式再依循持續交付和自動化測試的程序,很快就可以部署到正式環境。

自動化的迷思

然而自動化不是萬靈丹,並非沒有缺點或限制,以下是工作自動化的過程中,需要考量的部份:

自動化的工作通常沒有彈性

一般的自動化程式是以腳本方式人工編寫完成,然後由機器按步驟依序執行,通常只會有最基本的例外處理。自動化程式的設計通常不會有多大的彈性,如果臨時因為某個特殊需求,需要增加額外步驟,只能修改程式。然而,根據成本效益原則,自動化程式用於處理80%足夠多的工作,不必為了20%的例外狀況去做特殊設計,如果要做到100%有彈性的自動化程式,不如去研發自動化產品。

不是所有工作都要自動化

也是因為成本效益原則,不是全部的工作都要自動化,某些稀少或久久執行一次的工作,人工執行就好,不需要全部的工作都做到自動化。例如某些只有1%發生機率的測試案例,人工測試可能還比較有效率。

不能太依賴自動化程序

如果太過於依賴自動化,萬一自動化程序出問題,工作就會停擺,因為工作已經習慣交給自動化程序去做了,大家都不去學習如何用人工完成工作,所以沒有人有足夠的知識和經驗來完成這份工作。這就像你坐在Google電動車裡,在高速公路上Google電動車的自動駕駛功能壞了,會開車的人可以切換成手動駕駛模式繼續行駛,而你不會開車,只好在高速公路上等待救援。

工作不會因為自動化而被機器取代

不要害怕自動化後工作被取代,機器不會取代工作者的工作,反而可以減輕工作者的負荷,讓他們有機會可以從更高的層次去管理工作。例如QA測試人員不會因為測試自動化後就被裁員,他們可以把平日繁瑣的測試工作交由機器去執行,而有更充裕的時間撰寫測試案例,及思考與學習如何運用有效的測試策略來測試系統。



相關文章

如何將電腦畫面經由 Chromecast 投放到電視螢幕上

Chrome 的檔案續傳功能

Mac與Android裝置傳輸檔案的方法

使用 Vysor 在電腦上控制 Android 裝置