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測試人員不會因為測試自動化後就被裁員，他們可以把平日繁瑣的測試工作交由機器去執行，而有更充裕的時間撰寫測試案例，及思考與學習如何運用有效的測試策略來測試系統。