前兩天說完了溝通小狀況，今天想跟大家分享一下怎麼去查找問題，還是要來回憶一下問題，這次我們要處理的問題是「Ａ產品在維護後，大約會有五分鐘載入圖片的速度很慢，如果說只有Ａ產品維護後，會有這樣的情況也就算了，但是Ｂ產品維護後，Ａ產品會遇到一樣的問題，而且持續了幾週。」

當組織成長到一定程度時，查問題很容易會議變成是開發團隊會先檢查自己的程式是否有狀況，這次的情形是只有維護後會出現，所以應該不會是程式面有問題，因為如果是程式面有問題，那應該會是一直都有問題，而不會只是在維護後，再有這樣的定論後，就會把問題往後拋給 IT 部門，因為問題可能是在設備或是線路上。

如果這時候，設備與線路的部門同仁，檢查後發現也沒有異常資訊，就會回覆「沒有發現異常」，然後就會發現這個問題落在一個三不管地帶，因為大家都做完例行檢查後，發現都沒有其他狀況，都認為不是自己權責內的問題，那到底問題是出在哪兒？

這次我們怎麼做呢？我們已經先把相關的架構畫出來，從用戶端開始到伺服器，中間會經過哪些設備，又有哪些線路，接著，一步步拆解，去假設系統可能的瓶頸在哪？因為這次的狀況是維護後才會發生，所以我們初步的推斷很有可能是維護結束後，瞬間有多人要使用 A產品時，造成封包壅塞。

也有可能是當維護中斷連線一陣子後，用戶端要跟伺服器重新建立連線時，速度較慢，當理出可能的方向之後，接下來就是要做實驗了，我們與小林討論後，如果要檢查是否為封包壅塞，那需要在幾個端點開錄封包，但錄的話其實因為中間線路有點複雜，也不能確定問題會出在哪？

於是我們決定先從第二個部分先簡單做的時間，我們先在離目標伺服器很近的地方建設一台測試用的機器，讓他從內部網路就直接開啟Ａ產品的功能頁，如果說從內網就都會有慢的情況，那從外部當然就一定會更慢，實驗我們還在進行中，如果內網直連測試發現皆正常的話，那我們可能就會安排改錄封包來分析其他的可能性。

雖然還不知道結果，但從目前的配合方式，其實我可以滿有信心可以找到造成問題的根本原因，因為這次在跟小林或是設備單位溝通時，大家都是願意從自己的角度假設瓶頸點，而不是當例行檢查完就以不是自己部門問題的答案做結論，我認為這也是實踐 DevOps 精神很重要的一環。