DevOps：更容易做正確的事

July 22 22:50~00:00; July 25 09:50~11:15

 

▲圖片節錄自Google搜尋結果

 

今天介紹一篇刊登在5/6月IEEE Software 的文章：「DevOps: Making It Easy to Do the Right Thing」。文章主角是澳洲最大旅遊電商平台Wotif集團，旗下擁有Wotif.com和多個品牌（該集團在2014年底被Expedia收購）。在2013到2014年間，Wotif大幅整修他們的軟體釋出流程，將平均釋出時間從數週降低到數小時。文章介紹他們採用DevOps與持續交付（continuous delivery；CD）縮短釋出時間的經驗。

***

背景介紹

2012年時Wotif公司的工程部門有約170名員工，其中包含：

• 一個集中的營運團隊包含11位系統與資料庫管理員。
• 約60位開發人員。
• 30位測試人員。
• 15位業務分析師（business analyst）分佈在三個不同城市的12個開發團隊中。

以上人員約有20%（23人）不參與本篇文章所介紹的DevOps活動，也就是說實際牽涉人員約93人。

雖然工程部門的管理相當扁平，只有三個階層，但是他們的釋出流程卻非常的官僚。在產品釋出的前幾週就要先預定時間，但為了「夾帶」高優先權的功能，釋出的內容往往拖到最後一刻才決定。釋出流程並須經過層層關卡的檢查，例如所有釋出功能都要經過48小時的效能測試。

因為釋出流程很麻煩，團隊便想要塞進更多跨功能的異動到每次的釋出中以便減少釋出的次數，但卻因此造成每次釋出的內容變得很大一包，更增加釋出前的準備工作。如此一來團隊就很難滿足企業對於快速上市的需要，而且也沒時間去處理技術債。

為了解決這個問題，工程部門決定把延用了八年的Java EE架構改成微服務（microservices）。雖然在架構上他們覺得微服務有其優勢，但為了微服務卻引入更多的釋出工作因為他們必須要手動佈署與測試每一個微服務。結果原本的問題沒解決之前，還產生更多的問題。

因為導入微服務，不同部門所撰寫的微服務行為並沒有統一的規定，例如啟動服務的腳本、設定檔、管理端點、日誌檔的位置等等。這些問題又讓釋出的流程更加複雜，也造成維運團隊的困擾。

***

定義對的事

為了解決上述問題，Wotif成立一個CD團隊（持續交付團隊），包含兩個開發人員、一個系統管理師與一個流程改善業務分析師。該團隊採取一些策略來縮短釋出時間：

• 找出釋出流程的瓶頸，也就是只有11人的營運團隊。
• 藉由標準化應用程式包裝與佈署的機制來改善開發與釋出流程的一制性與可預測性
• 採用漸進式改變來擴充、精簡與自動化現有的基礎建設與工具。例如，繼續使用他們現有的資料中心，而不是把平台改成公有雲。

經過與開發團隊以及營運團隊的溝通，CD團隊整理了一份輕量級應用程式佈署標準，含蓋約30個規範，包含日誌檔位置與格式、初始化腳本位置與呼叫方法、配置檔位置、應用程式打包規範等。

***

簡化

CD團隊採取以下方法簡化開發與維運團隊實作上述標準的時間：

• 提供自動驗證測試套件（採用Fabric Python SSH函式庫開發），透過基本的Linux指令檢查每一個應用程式佈署之後，系統與程式是否正確。該驗證套件在開發人員每次提交程式碼時會在驗收測試環境中自動執行。
• 提供helloworld-service參考實作，該服務會被佈署到包含production的所有環境，用以展示與測試點到點（end-to-end）的佈署自動化過程。當Frbric Python版本升級時，它也做為自動驗收測試案例，確定此次版本升級沒有造成問題。helloworld-service也做範本，開發人員可以直接從它開始撰寫新的服務。
• 開發DevOps toolchain達成佈署與測試自動化。該DevOps toolchain包含Git、TeamCity、Yum、Hiera、Puppet，用Fabric Python將這些工具串起來，用以替代原本手動釋出的工作。為了測試服務的正確性，開發團隊需要針對每一個服務提供smoke test腳本。自動化佈署與測試完成之後，節省了85%的佈署時間，將原本需要幾個小時的時間縮短成幾分鐘。
• 要求服務必須獨立釋出。做到上述三點只解決各別服務佈署的問題，但是一個系統是由多個服務所構成，很有可能因為其中某一個服務升級，導致與其他服務發生不相容的問題。為了避免這個問題，所有的服務被要求必須要提供向下相容性，以便可以獨立釋出又不會影響到原本正常工作的其他相依服務。
• 訂定新的釋出流程，包含以下五項規則：
  • 讓異動獨立（keep changes independent）
  • 釋出過程不可以有人工測試
  • 不可以預約釋出時間
  • 應用程式必須符合最新的佈署標準
  • 維運人員可以將服務退回到之前的版本

在落實新的產品釋出流程之後，平均產品釋出時間從2週縮短到1天。

***

聽到DevOps許多人第一個印象就是找一堆工具來自動化測試與釋出流程，由這篇文章可以知道，工具與自動化只是其中一環。在自動化之前，必須找出流程上的瓶頸，接下來才能擬定改善計畫。如果流程沒有改變（改善），只是希望透過自動化工具加速錯誤流程的時間，就算是戴上DevOps這頂流行的帽子也不會讓你的團隊與產品看起來好棒棒。

怎麼找出瓶頸？最後置入性行銷，打個廣告：歡迎參加8月18日舉辦的「瓶頸遊戲：運用五步驟聚焦法持續改善流程」工作坊。

***

友藏內心獨白：要先do the right thing再do the thing right。