程序員版《On Call 24 小時》

身為開發者的你，一定有過不止一次的 On Call 24 小時爆肝經歷，隨時待命，隨叫隨到……

作者 |Henrik Warne

譯者 | 彎月

責編 | 仲培藝

出品 | CSDN（ID：CSDNnews）

我現在正在做的系統需要我每七周中有一周要做到「隨時待命」。在過去十年的大部分時間裡，我都需要為我開發的系統輪流當值。我認為隨叫隨到是工作的職責所在，同時我們也可以從中學到很多東西。但很顯然，這種工作模式所帶來的壓力也是不容小覷，也未免會有諸多不便，所以我們理應得到與付出相應的報酬。

為什麼開發人員應該「隨叫隨到」

許多系統需要全天候在線，所以必須有人隨時準備好提供支持，而該系統的開發人員則無疑是提供相關支持的不二人選。

共同進退

作為開發人員，你應該對你的代碼負責，這意味著不僅需要編寫代碼，還要測試代碼，確保它能夠完成預期的工作，即使在產品環境中也不會出問題。當你清楚出了問題的代價將是大半夜爬起來工作，那麼寫代碼和做測試的時候就會更加小心謹慎。Nassim Nicholas Taleb 在其著作《反脆弱》（Antifragile）中曾提到羅馬工程師會在他們建造的橋樑下住一段時間，以確保他們的工作做得更好。

全盤考慮

在對系統進行故障排查的時候，你可以充分理解其工作原理。如果你不提供支持，那麼最終很可能導致你非常了解某些部分，但是卻不清楚系統的整體情況，比如所有的部分如何連接在一起以及如何交互。此外，提供支持也可以讓你直接了解客戶使用系統的方法。

推動改進

在修復系統問題的時候，你可以清楚地看到日誌記錄或故障排除工作是否不盡如人意。作為系統的開發人員，你可以在遇到這些問題的時候立即解決。你可以通過添加更多相關信息來改善日誌記錄，也可以刪除造成日誌阻塞的語句。你可以編寫腳本和其他有助於故障排除和恢復系統的工具。你還可以刪除錯誤的警告——日積月累，最終這樣的小改進可以建立更好更有彈性的系統。

警報

電話與警報

在 TriOptima，我們有一個緊急號碼，如果系統出現問題，可以撥打該號碼，呼叫後會轉給開發人員。隨著時間的推移，我們還增加了很多監控，例如異常拋出、隊列長度以及內存、CPU和磁碟利用率。這些監控會生成警報，然後即時反饋給開發者。那段時間裡，我們幾乎從未在半夜被電話吵醒，因為在大多數客戶發現問題之前，我們就從監控中獲得了警報。

心跳作業（Heartbeat jobs）

我們在兩個主要的交互系統上按周期運行心跳作業（每一分鐘和每五分鐘）。如果未按預期執行，就會引發警報。事實證明這非常有用，因為這些作業常常會捕捉到一系列的問題。例如，最近給我們發送數據的伺服器線程耗盡，其中一個反饋表現就是我們的心跳作業沒有運行，因此我們得到了警報。有時，我們還可以通過心跳作業捕捉到連接問題。在《Release It!》這本書中，作者 Michael T. Nygard 稱這些為合成事務（synthetic transaction）。

輕鬆回滾

在工作中，功能開發好後，我們需要部署新功能並修復 bug。這意味著全天都有許多小型部署。如果半夜因為出現問題而被叫醒，那麼通常的解決方案就是回滾到最近的一次部署。感謝 Kubernetes，我們可以輕鬆快捷地完成回滾。然而，有些改動比如資料庫遷移等可能很難回滾，但既然我們已經清楚認識到這一點，而且我們需要承擔其中的責任，我們自然會想辦法在編寫代碼時注意令其更方便回滾。我們還會在早間進行高風險部署，這樣就可以有一整天的時間來監控系統了。

改善警報

我們不斷地調整警報，使其更準確，同時也清除了誤報。一個例子是隊列長度的警報。剛開始我們設置的警報是，如果過去10分鐘內的平均長度超過閾值，那麼就會發出警報。但是，在修復了這類問題後，隊列長度警報會一直響，直到平均值低於閾值。如果不立即清除警報，那麼可能會掩蓋新出現的問題。所以我們將其更改為在達到閾值時立即報警，並在隊列長度降至零時立即將其清除。這樣一來這個特定的警報就更加準確和敏感了。前不久，我剛剛調整了另一個警報：一些同步的問題可以等到正常辦公時間再進行，這樣就不會在大半夜吵醒別人了。

報酬與時間計劃

加班費

隨叫隨到的人理應獲得額外的報酬——如果說必須準備好在一周內的任何時間隨時到位並解決問題，這對個人的生活影響很大，所以額外的報酬會是個必要條件。我認為最好的情況是，你可以拿到固定的 「On Call」 加班費，而且無論是否有意外發生，每次你半夜出勤都可以獲得報酬。同時也可以進行相應的調休。

時間計劃

在我值班的時候，通常是一周被叫一次。我認為這個時間間隔度很好。最好提前制定時間計劃（提前幾個月）。這樣你就可以更好地規劃生活中的其他活動。能夠與團隊中的其他開發人員換班也非常好，我們很難說理想的換崗時間是多長。很多時候，值夜班就無法過正常的生活，如果時間間隔太長，那麼可能會得不到足夠的練習，技藝生疏。每隔 7-8 個星期對我來說是相對合理的間隔選擇。

危機升級

一旦危機真正出現，我們隨時都應為危機進一步升級做好準備。如果整個系統都停止了工作，而且你在解決問題方面沒有取得任何進展，那麼就需要更多的幫助。通常情況下，下一步你應該通知經理，他們會找其他人來幫忙。同時我也告訴我的同事，我不介意被吵醒，即使我不值夜班，如果需要我幫忙的話也可以給我打電話。在過去十年中，我只接到過幾次電話，但如果事先知道在必要情況下還可以求助隊友，那麼隨時待命帶來的心理壓力也會小很多。

入職培訓

團隊中的新成員需要時間來了解系統，並在加入輪崗之前練習故障排除。入職培訓過後，我們將與新成員兩兩結對，共同承擔為期一周的隨時待命工作，然後再讓他們單獨操作。

總結

儘管隨時待命可能會帶來很大壓力，但是我認為這種工作也有很多好處。隨叫隨到意味著對你開發的東西負責，在此過程中，你可以了解系統的工作原理（或故障的原因），還可以利用其間的反饋來改進系統。但是，團隊成員之間需要分擔隨叫隨到的重任，而且你理應獲得相應的報酬。

原文：https://henrikwarne.com/2018/12/03/developer-on-call/

作者：Henrik Warne，瑞典斯德哥爾摩人，TriOptima的軟體開發。

本文為 CSDN 翻譯，如需轉載，請註明來源出處

熱 文推 薦

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！