軟體工程師該如何值班 (on-call)?

先前在《軟體工程師該如何做好監控 (monitoring)？》文中，我們談到了在監控時收到警報，負責值班 (on-call) 的團隊成員要先確認問題，如果確認問題真的存在，接著就會著手處理。很多剛入行的工程師，可能對值班沒有太多概念，或者比較資深的工程師，會想要去優化自己團隊的值班流程。因此在這一篇，我們將來討論如何做好值班這件事。

誰來負責值班?

在早些年，軟體開發與維運一般是被拆開的，當開發團隊開發完成後，就由維運團隊接手維運。在那個年代，開發者多半不需用參與到值班的工作。然而，在近幾年，這個現象有所改變。

會有這個轉變的主要原因，是因為過去把開發與維運拆開的方式，兩邊分裂難以擴展。除此之外，開發者不用負責值班，會讓開發者在寫程式時缺乏「要讓線上完好無意外」的意識，這狀況在由開發者參與維運後，有了明顯改善，所以業界就紛紛往這方向發展。

在英文有一句叫 You build it, you own it 的話，意思是指，自己開發的東西，就要負責到底，不是開發完就沒自己的事。當自己要負責維運自己寫的程式碼，在寫程式碼時，自然會更小心，不然出包了不再是別人扛，而是自己要吞自己搞出的問題。

在開發者也參與維運後，業界逐漸出現幾個軟圖ㄧ工程師 (SWE) 與網站可靠性工程師 (SRE) 的不同合作模式。先前 Increment 針對各大公司的調查 (連結)，有以下的協作模式：

Google 的 SRE 僅負責運行、維護和值班最重要且穩定的服務 (如廣告、Gmail 和搜尋)，而開發團隊則承擔其他非穩定、非關鍵服務的運維工作
Airbnb 有與開發團隊密切合作的 SRE，但 SRE 只專注於提高整個系統的可靠性。具體來說，開發者負責值班，SRE 協助開發團隊導入維運的最佳實踐
Datadog 的 SRE 和開發者共同值班，每次值班都會有兩個角色一起參與
Amazon 則是極致的 You build it, you own it (據說是基於 ownership 這個領導力原則)，所以是開發者一路從開發負責到維運

開發者的輪班

在談完開發者與 SRE 在值班的不同角色，接著來談開發者在實際值班時，是如何輪班的。

在值班的輪班通常是以週為單位，每個人每次負責主要輪班一週，然後當副值班人一週，團隊有多少人就是多久輪一次，例如團隊有 12 個工程師，那會是每 12 週輪一次主值班。

擔任主值班人時，當有某個異常出現，呼叫機 (pager) 第一個會打給你；如果主值班人沒有響應，則會再打給副值班人。這種主副模式，可以確保不會找不到人 (當然可能兩個人都沒有響應，一般預設會是再打去總監級別的角色，但相信多數人不會想要自己該負責的東西，漏接然後被大老闆接到，這種後果通常不會太好)。

好的輪班設計，應該要避免過度頻繁輪班，否則團隊成員會燃燒殆盡。因此，會推薦在面試時，跟用人主管聊多久輪一次班，以及該團隊目前的值班狀況，這會讓你對未來實際加入團隊後會發生什麼事，能有更具體的理解

值班時被呼叫了該怎麼辦?

在對值班有整體性理解後，相信多數人有的下個問題是「如果真的在值班時被呼叫了，該怎麼辦?」。

許多公司都會有值班的相關指南與訓練，舉例來說，GitLab 就有公開自己的 On-call Handbook (連結) 以及值班時的檢查清單 (連結)。如果你目前待的團隊，還沒有建立起相關的指南與訓練，本文的最下方還有附上其他業界公開的指南可以參考。

往下我們會進一步來談，在處理事故時推薦基本一定要有的原則與流程。

響應

當你在值班時收到通知，第一件做的事情是響應，一般值班相關的工具都會有一個 Ack (是 Acknowledge 的簡寫)，點下去後讓相關人員知道你收到通知。為了確保 SLA 能被維持住，假如主值班人沒有在一定時間內響應，就會往下去呼叫副值班人，然後再到團隊主管，然後部門主管以此類推。當然，相信多數人不會想要驚動大主管，所以收到通知時，會馬上按 Ack。

判斷與同步

在響應後，需要進一步判斷是否該異常警報真的是事故，判斷完如果真的是事故後，要接著要跟組織的其他人同步狀況。

一般出事故時，會有兩個群組，一個是有所有人的群組，會由負責值班的人去更新事故處理狀況 (下面會有模板可以讓大家參考)，讓組織的所有人都能被同步；另一個群組則是負責問題解決的人新開的群組，讓跟相關問題的討論能集中，如果有想了解細節的人再加入。

除了在公司內的同步，有時也會需要對外同步，讓客戶知道發生了什麼事，以及目前處理狀況如何。舉例來說，先前 OpenAI 的 API 掛掉後，除了有狀態頁面，也會在推特等平台，即時更新，讓使用 OpenAI API 的人知道何時問題得以被排除。

止損優先 (mitigation first)

在值班時，一個大原則是跟時間賽跑，如同在《軟體工程師該如何做好監控 (monitoring)？》一文有提到，公司多半會有 SLA 的設定，如果超出承諾的時間，會要賠錢給客戶；如果是直接面對使用者的，那可能每晚一秒鐘修復問題，都在造成商業上的損失。

而要能夠快速解決問題，需要先止損。業界有個詞叫 mitigation first, invesigation later (先止損，後排查根因)，意思是先確保問題沒有持續影響線上環境，事後再來詳細調查問題的根本原因。舉例來說，假如事故是因為某個剛上線的改動 (不論是新的程式碼，或是配置的更動)，那第一時間要做的事，就是立馬回滾 (rollback)。

止確保問題得到緩解，線上的使用者不再被影響後，再來談討根本原因，然後再去設計能解決根因的解決方案。這個順序很重要，過去業界有太多悲劇，就是工程師試圖想直接解決問題，導致一來過慢，二來可能在有時間壓力下，反而越弄越糟。

閱讀更多

如果你對於做好值班這件事感興趣，歡迎加入 E+ 成長計畫來閱讀更深入的內容。在 E+ 的完整版當中，我們會進一步談值班用的工具、第一時間要同步狀態可以用什麼模板、業界有哪些值得參考的值班規範、B2B 產品的值班可以如何優化等主題。

本文為 E+ 成長計畫的深度內容，截取前三分之一開放免費閱讀。歡迎加入 E+ 成長計畫閱讀完整版本 (點此了解 E+ 的詳細介紹)