他說：「如果面試 Senior 以上的職位，我更看重他過去是否有處理正式環境 Critical issue 的經驗；因為技術可以靠後天學習，但有能力處理正式環境 issue 的人並不多。」

停頓了一下，又補充一句：「技術能力只能用來衡量平時的工作效率，但遇到緊急狀況時，在壓力下是否有足夠的膽量與決策能力就很看人格特質了。」

接著向我分享一個系統升級遇到意外的案例。

為什麼正式環境發生意外時很難處理？

如果公司有一定的制度與規模，系統在升級前往往有完善的單元測試，並通過 QA 團隊在不同情境的模擬測試。

因為事前已經考慮得相當周全，所以當問題發生時，就代表大家根本沒想過這個情境。

加上系統升級會對外公告維護時間，如果沒在期限內解決問題就出包了。

這邊我簡單描述一下問題是怎麼發生的：

A 系統升級時，會需要跑一個一次性的腳本向 B 系統取得資料；但 B 系統的資料不完整，所以 B 系統還要向 C 系統取得部分細節資料。

在測試環境跑腳本時，一切順利，但上到正式環境後，跳出了「timeout（超時）」的錯誤訊息。

如何定位問題？

出現「timeout（超時）」的問題後，大家並沒有很緊張，覺得只要放寬 A 系統呼叫 API 的時間就好。

但時間放寬後，timeout 的問題依舊存在，所以接著把目光轉移到 B 系統與 C 系統上，並將程式與 Nginx 的 timeout 時間拉長。

原本想說這樣問題總能解決了吧？

但結果不如人意，timeout 的錯誤依舊頑強地顯示。

為了更精準定位問題，大家把 A 系統、B 系統、C 系統的 API 分開測試，最終發現根本的問題在 C 系統。

不要讓自己陷入只有一個解決方案的思維

儘管成功定位了問題，但不知道為什麼 C 系統怎麼放寬 timeout 的設定都沒有生效。

而此時系統維護的時間剩不到半小時，想透過優化演算法來加快效率已經來不及了。

經過討論後，大家決定不解決 timeout 的問題，而是想辦法不要讓 API timeout。

最終的方案也非常簡單，只是將 B 系統取得的資料多拆成多份，以 C 系統絕對不會 timeout 的資料量傳送就解決了問題。

這個案例有什麼值得學習與警惕的地方

從結論來看，加 3 行程式碼就解決了問題。

但要做出這個決策並不容易，因為 A、B、C 系統是由不同的團隊進行開發，如果沒有良好的溝通能力，可能連一開始的問題定位都做不到。

找到問題點後，如果沒有人同時對 A、B、C 系統有一定的掌握度，我想大部分的人會把目標放在解決 timeout 問題，而非調整程式邏輯。

以這個案例來說，解決問題的人不一定要程式能力很強，但要具備良好的溝通能力，並對多個系統有一定的掌握度，且擁有靈活的思維，不會只想用一種方法解決問題。

我想，擁有如上特質的人，是市場上真正的稀缺人才。

最後提醒一下大家，雖然解決問題很帥，但以這個案例來說，只要在測試時考量到正式環境與測試環境的資料量差異，並加上對應的限制與分頁設計，就有機會避免問題發生。

如果你對目前的職涯感到迷茫，想從不同視角檢視自己的選擇，相信《工程師下班有約》這本書能為你帶來靈感與啟發：