好文分享 — The Scary Thing About Automating Deploys

Slack 在自家的 Slack Engineering 部落格上公布了 1 篇他們怎麼做自動化部屬的文章,這是 1 篇很有參考價值的文章,讀完之後會讓我們知道:

  1. 一旦規模規模大到一個程度,即使是日常小事,也成為一個令人頭痛的問題
  2. 了解一些統計學概念/公式的重要性

大致講一下 “The Scary Thing About Automating Deploys” 這篇文章的內容:

以 Slack 的團隊規模來說,他們每天 merge 的 PR(Pull Request) 數量已經超過 150, 而被部署到 Production 的 PR 也差不多是每天 merge 的數量。

這個數量級成為 1 個頭痛的問題,為什麼?

實務上,部署的變更越多,風險越大,譬如 1 次部署 1 個變更,如果壞了就只要 revert 1 個變更就好,團隊也很容易可以發現問題所在,就是剛剛部署的變更,甚至可以迅速針對該問題進行修正;如果 1 次部署超過 100 個變更,團隊就很難迅速找到問題,因為很少有人可以全盤的了解這 100 個變更到底在做什麼,所以很可能 100 個變更都會被 revert ⋯⋯。

所以 Slack 採取「小步」部署的策略,約略半數的部署都只有 3 個 PRs 不到,藉此控制 production 環境變更的數量以及風險,另外部署的步調與 PR 數量由 1 個內部工具 ReleaseBot 決定,做到 24/7 全天候執行。

這項內部工具還是需要從各個開發團隊輪流抽人組成 1 個團隊來做最後執行,他們稱為 Deploy Commanders (中文應該叫部署指揮官XD),這些人要監控上線過程的情況、上線後的手動測試等工作,為了做到這件事他們還需要做不少訓練與文件,教育每個 Deploy Commander 什麼情況是正常、什麼情況不正常等等,這個方案雖然可以運作,但是頗浪費人力資源,而且就算有訓練、文件,一旦出事多數人也不熟那些他很少參與、甚至沒有參與開發的系統,出事當下是很難馬上進入狀況的⋯⋯。

所以最後 Slack 開發團隊決定做自動化部屬,因爲只要監控做得夠正確,程式絕對可以比人類更有警覺、反應更快,如此讓開發者更專注在他們能發揮價值的地方。

自動化部屬的關鍵,就是統計學的 Z-Score, 也就是 1 個數值離平均值多遠的情況, Z-Score 正負 1 就代表離平均值 1 個標準差的距離,數值越小越接近平均值,代表數值常見,數值越大越遠離平均值,代表數值罕見。(這同時代表 Slack 開發團隊假設錯誤的數量屬於常態分佈)

他們用上線後的錯誤數量計算 Z-Score, 大於 3 就代表「出事了阿北」,如果落在正常範圍,就可以繼續執行下次的部署,不過後來就不侷限於 3 這個數字,而是針對不同的監控指標設定不同的 Z-Score, 甚至是導入歷史數據計算過去同一個時間區段(例如過去 3 天的 09 ~ 17 點)的 Z-Score 一同考量,減少固定的 Z-Score 有誤判的情況。

總之,這是 1 篇相當不錯的文章,推薦給大家!

The Scary Thing About Automating Deploys

對抗久坐職業傷害

研究指出每天增加 2 小時坐著的時間,會增加大腸癌、心臟疾病、肺癌的風險,也造成肩頸、腰背疼痛等常見問題。

然而對抗這些問題,卻只需要工作時定期休息跟伸展身體即可!

你想輕鬆改變現狀嗎?試試看我們的 PomodoRoll 番茄鐘吧! PomodoRoll 番茄鐘會根據你所設定的專注時間,定期建議你 1 項辦公族適用的伸展運動,幫助你打敗久坐所帶來的傷害!

追蹤新知

看完這篇文章了嗎?還意猶未盡的話,追蹤粉絲專頁吧!

我們每天至少分享 1 篇文章/新聞或者實用的軟體/工具,讓你輕鬆增廣見聞提升專業能力!如果你喜歡我們的文章,或是想了解更多特定主題的教學,歡迎到我們的粉絲專頁按讚、留言讓我們知道。你的鼓勵,是我們的原力!

贊助我們的創作

看完這篇文章了嗎? 休息一下,喝杯咖啡吧!

如果你覺得 MyApollo 有讓你獲得實用的資訊,希望能看到更多的技術分享,邀請你贊助我們一杯咖啡,讓我們有更多的動力與精力繼續提供高品質的文章,感謝你的支持!