好文分享 — The Scary Thing About Automating Deploys
Slack 在自家的 Slack Engineering 部落格上公布了 1 篇他們怎麼做自動化部屬的文章，這是 1 篇很有參考價值的文章，讀完之後會讓我們知道：
- 一旦規模規模大到一個程度，即使是日常小事，也成為一個令人頭痛的問題
- 了解一些統計學概念/公式的重要性
大致講一下 “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 篇相當不錯的文章，推薦給大家！
