軟體工程師的修煉與成長 (3) — Oncall的挑戰
--
新手村
上集提到，新手工程師剛加入一家公司，第一個難題就是了解現有的系統和程式碼，並找到對的地方改程式。英文有個很生動的詞，叫做”navigate”，跟用GPS「導航」是同一個字，但在這裡指的是在錯綜複雜的程式碼中跟著程式流動的方向，順著邏輯找到正確的進入點或函式。
剛進D社不久，我就發現可以學的東西實在太多了。除了自己團隊負責的產品外，公司內部還有一大堆自製的系統，從資料庫、開發環境、自動測試、部署系統、監看和警報系統、機器管理系統、各式各樣的除錯工具，全部都是自建的。
這些自建系統好處是完全量身打造，非常符合我們公司的需求，有團隊專門負責更新和維護這些系統。但缺點也很明顯，文件很少，出問題機會高（因為每天都被改來改去），也沒辦法靠外部的資源（像google或stack overflow）學會怎麼用，而且還要養很多團隊來維護。
我就這樣一邊學各式各樣的內部工具和系統，一邊在我們產品的程式庫中navigate，慢慢學著不依賴別人也能獨立作業。雖然我在幾個星期後就能夠開始有所貢獻，但我對於不是自己負責的部分還是非常陌生。我也因為很專注在做自己的東西，所以也沒太多機會去研究其他部分是怎麼運作的。幾個月後，報應來了。
我開始要oncall了。
Oncall的挑戰
oncall是現代軟體公司的標配。很多網路服務看起來很穩定，24小時都不間斷，其實背後都有無數個工程師得24小時oncall。有的公司系統比較不穩，工程師甚至常會被半夜叫醒處理危機。表面的穩定很多時候只是因為被影響到的人還不多就被及時修好，或是在危機還沒有從內部擴散到外部時就被處理掉了。
oncall最可怕的是時間壓力。通常面對business的軟體系統都會有嚴格的SLA (Service Level Agreement)，會有個合約定義好系統至少要有多久的uptime。如果沒有達到SLA，公司需要付出一定的賠償金。大部分的SaaS產品，基本要求都是3個9 (99.9%)，而如果是提供更底層系統的服務（像是AWS），SLA會更嚴格到3.5個9 (99.95%)或是4個9 (99.99%)。
一個系統如果要有99.9% availability，一個禮拜大約只有10分鐘的故障時間預算。這意思就是說，如果你的系統平均每個禮拜會故障一次，那oncall就不能花超過10分鐘回應和處理。如果系統稍微穩一點，平均每兩個禮拜才故障一次，那一次的處理時間就可以有20分鐘。
oncall通常是一個團隊裡的工程師輪流擔當的，像我們是一個人一個禮拜primary oncall，整個團隊有N個人就會N個禮拜輪到一次。另外還會有一個禮拜的secondary oncall，當primary oncal沒有在被呼叫的一定時間內回應，secondary就得要替補上場救援。（但我們的primary通常都很負責，所以secondary幾乎都沒有上場的必要。）
這種安排之下，如果團隊夠大（至少7~8個人），那負擔不會很重。當時我們團隊大概就在接近10人的大小，所以其實兩個月才會輪到一次。但即使頻率不高，因為oncall要處理的範圍是整個團隊負責的產品和系統，每次oncall對新人來說還是很可怕的。
因為對整個系統都很陌生，如果系統某個地方出了問題，很難能在時間壓力下找出根源然後解決它。我第一年oncall時都很緊張，如果是上班時間還可以找得到其他人問，但在晚上甚至半夜就麻煩了。有時碰到完全不熟的問題，就只能硬著頭皮呼叫比較資深的人，即使是半夜也得把人叫醒來幫忙。
幾年後我到了別的團隊才知道，其實當初我們團隊的oncall制度還很不成熟。很多警報沒有明確的playbook，oncall不知道該做什麼處理。或是警報沒有明確區分重要程度，很多沒必要馬上處理的事情也會在半夜叫醒工程師。
這很大一部分是因為產品很新，開發速度遠比穩定來得重要，所以團隊沒有投資太多時間在運營上。有一定經驗的工程師都知道，系統會壞掉大部分時候都是團隊裡的工程師自己搞壞的。（新寫的程式中有bug，或是操作系統的人為錯誤）。每次只要放長假，其實都是系統最穩定的時候，因為這時沒人在提交新的程式碼，壞掉的風險就小了很多。早期Facebook有個說法是 “Move fast and break things” ，就是在說他們寧願犧牲一點系統穩定度，也要加快開發速度來迭代產品。
當初我沒有這種維護production系統的經驗，只覺得自己對於現有系統了解太少，出事時很難看清全貌找出病因。後來團隊慢慢擴張，有一些資深的人進來，馬上就看出我們的開發部署流程和oncall制度有很多可以改進的地方。例如，在自動部署時，可以先部署到一台canary機器上，等待個半小時，同時有系統自動監看這台機器上產生的錯誤。如果發現有太多異常的錯誤，就自動roll back不要讓有問題的程式部署到全部的伺服器上去。這類的改進並不難做，甚至不用全自動，都可以產生很大的價值。
我也因此發現，我會覺得oncall很困難其實根源不完全在於我自己的知識和經驗不足，而是團隊的開發流程和制度還沒有把這件事變得夠簡單。也就是說，如果有人能改進這些流程，可以讓每個人開發和oncall時更有效率也更有信心，擴張團隊也就更容易，系統也變得更穩定更少出問題，這樣對於整個團隊的貢獻其實遠大於提升個人的知識和技術。這也讓我開始思考自己是該專注在做產品，還是來改善產品背後的開發流程和基礎建設(infrastructure)以產生更大的貢獻。
(待續)
