#工作心得 Oncall 101

大家好！這裡是小恐龍的窩🦖～又到了無事一身輕的星期天！今天的西雅圖天氣不太好，陰雨不斷 >< 不過幸好我昨天已經出門玩過啦！所以，配上好喝的咖啡，今天來專心達成自己前幾天立的 flag 吧！Let’s go~

· · ────── ꒰ঌ·✦·໒꒱ ────── · · 上週是我工程師人生中第一次 oncall。首先，我先來解釋一下什麼是 oncall 吧～基本上，公司裡每個 Team 除了要努力開發新的服務，也會有一些已經在運作的服務。雖然『開發新的服務』對於拓展 Team 的方向很重要，『維護既有功能、滿足手邊客戶』也非常重要。然而，已發展成熟的服務通常不會需要很多維護，這樣要如何決定人力分配呢？這時，oncall 就會派上用場了。每個組的每個人都會輪流當一週的 oncall。在那週，oncall 有點像是在輪一個 24Hr x 7 Days 的班，要負責處理所有一線的任務，像是解決客戶的疑問等等。Oncall 更要在運作的服務出現問題時，快速注意到問題，並視情況的嚴重性，將任務分配給隊友們。一般來說，為了避免 oncall 漏注意到很嚴重、影響公司盈利的問題，工程師會設定一些程式，以確保在重大問題剛發生時，他們就可以立刻被通知 (aka『被 paged』)。當然，通常『被 paged』的時候，就代表問題已經大到需要立刻放下手邊所有事，馬上開始處理問題。舉一個好懂的例子來解釋 oncall，一個組就好像是一個小型的甜點工作坊。一方面師傅們要努力研發出好吃的甜點，但另一方面也要有人處理訂單、客服這種事情。這時候，就可以透過大家輪流當 oncall，去處理後者。在這個情境裡，『被 paged』就像是工作坊出現很嚴重的食安問題，需要有人立刻去釐清問題、了解情況。了解 oncall 是做什麼後，接下來就要來聊聊我如坐過山車般的第一次 oncall。自從加入這個組後，我就一直聽同事說我們組的 oncall 壓力很小、只有小事情要處理，而且幾乎從來不會被 paged。我也就天真的相信了。天曉得我錯的離譜。上星期一 (aka oncall 的第一天)，我還悠悠、哉哉處理著那些固定要做的事情，以為唯一要做的事就是在群組裡回覆客戶的問題。這種悠閒、慵懶的情緒，在星期二下午我的主管問我『某個服務掛掉了，你有在處理嗎？』後，徹底消失了。原來，我們組有一個群組會固定收到通知，告訴我們有哪些服務可能有問題。但是，因為那個群組真的有太多通知了，我就默默把那個群組靜音了。。。這就導致在我主管跟我系統掛掉之前，我完全沒發現它掛掉了 🫣 。接連幾天，我都在緊急跟同事學習如何找出問題並試著讓服務復活 xDD 當這個問題好不容易解決後，我原本以為我剩下的 oncall 就會順順的過去，結果在星期六的時候，突然有多個服務掛了！！重點是，作為一個菜鳥工程師，我根本不知道處理這些問題的 SOP 是什麼。假日的時候又沒有人可以問，導致我整個人快嚇死了 QAQ 我就只好自己做一些緊急處理，並在群組裡跟大家說明遇到的問題跟我做的處理。好不容易熬到星期一的 oncall 交接會議，我戰戰兢兢地跟大家說明這週遇到的各種問題跟處理方法，原本以為主管他們會覺得我哪裡沒做好等等，但意料之外的是，大家都很 nice！很包容我第一次做 oncall 可能沒做好的地方。真的是太感謝他們了！不知不覺已經寫很多啦～第一次 oncall 的經驗就分享到這裡。這次收穫最大的地方就是，我發現有時候真的就是要 reach out for help。在這次 oncall 之前，我遇到問題通常會想要自己解決，不想麻煩別人。但這次的經驗讓我了解到，很多事情本來就需要更有經驗的人來處來，甚至很多時候真正的問題根本跟我想的不一樣。『給自己設定一個時間限制，若在時間限制內沒有辦法解決問題，就 reach out for help』是一個對自己、別人都好的做法。最後的最後，雖然這次 oncall 意外連連，但其實我已經很滿足了啦！一個在 Amazon 工作的朋友告訴我，他們 oncall『被 paged』的次數如果小於 20 次，就已經很少了 XD~~ 那我們就下次再見啦！