最近跟一位擔任技術主管的朋友聊天，我問他：「面試過程中，你最看重求職者哪些經驗與特質？」
他說：「如果面試 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 問題，而非調整程式邏輯。
以這個案例來說，解決問題的人不一定要程式能力很強，但要具備良好的溝通能力，並對多個系統有一定的掌握度，且擁有靈活的思維，不會只想用一種方法解決問題。
我想，擁有如上特質的人，是市場上真正的稀缺人才。
最後提醒一下大家，雖然解決問題很帥，但以這個案例來說，只要在測試時考量到正式環境與測試環境的資料量差異，並加上對應的限制與分頁設計，就有機會避免問題發生。
如果這篇文章對你有幫助，可以對文章拍手讓我知道 👏🏻，也歡迎點擊「Follow」來追蹤我～
▶︎ 如果這篇文章有幫助到你
1. 可以點擊下方「Follow」來追蹤我～
2. 可以對文章拍手讓我知道 👏🏻
你們的追蹤與鼓勵是我繼續寫作的動力 🙏🏼
▶︎ 如果你對工程師的職涯感到迷茫
1. 也許我在iT邦幫忙發表的系列文可以給你不一樣的觀點 💡
2. 也歡迎您到書局選購支持，透過豐富的案例來重新檢視自己的職涯
