軟體工程師的修煉與成長 (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分鐘。
