所謂的 Troubleshooting 就是，在現有的問題的表象之中 (錯誤訊息、系統環境)，以現有的知識，有時搭配一些 Research、學習等，推敲出問題可能的原因。必要時，做一些測試，驗證、排除掉不可能的其他因素。而 Troubleshooting 也是將問題的發生的成因合理化，因為一開始不知道問題，就會覺得問題的發生成因不合理，但就是因為有東西你不知道，或者是被你忽略，才導致此問題的發生。而 Troubleshooting 也是要找出我們不知道的東西。
為什麼談論這個問題？其實是因為最近我到客戶端安裝我們開發的 Web API 的框架，我大概說明一下這個框架的功用，它是一種，提供給不懂網頁 MVC、Web API 的開發者使用的框架，開發者只要知道 C# 基本語法、與 會撰寫 ClassLibrary、類別 Class、Method 即可，因為該框架會自動將你寫的 Method 開放為 Web API，並且提供動態更新，你可以 Runtime 上傳、更新你的 DLL。
開始之前，我們先來談談什麼是 Troubleshooting？
什麼是Troubleshooting？
所謂的 Troubleshooting 就是，在現有的問題的表象之中 (錯誤訊息、系統環境)，以現有的知識，有時搭配一些 Research、學習等，推敲出問題可能的原因。必要時，做一些測試，驗證、排除掉不可能的其他因素。這與筆者之前一篇 如何培養架構性思考 (談軟體架構師必經之路) - 投影片分享 中所提到的豐富的 Troubleshooting 經驗是相互輝映的。
而有時 Troubleshooting 也是將問題的發生的成因合理化，因為一開始不知道問題，就會覺得問題的發生成因不合理，但就是因為有東西你不知道，或者是被你忽略，才導致此問題的發生。而 Troubleshooting 也是要找出我們不知道的東西。因此，有時還要搭配一些學習、Reserach 、Google、或是翻書，甚至了解一些基本的原理、概念，都可協助便釐清問題。
最近在客戶端一個實際的例子
我來說說一個最近至某個客戶安裝 UAT 環境的一個例子，為什麼特別提個例子？因為這個問題一開始讓人摸不著頭緒，怎說呢？主要問題是 Web API Host 在運行時，載入任何 DLL 的 class Method 時，都需要 42 秒才能得到結果，但實際看 LOG 紀錄又發現，實際執行那個 Method 才 92毫秒，可是前端總是得在 42 秒後才可以得到結果，使用 Fiddler 監控效能時發現，確實 HttpRequest 等待了 42 秒，時間都花在 AP Server 端的 Web API，可是 Web API 端我們都會記錄 LOG，但在 LOG 裡卻都沒有記錄到任何錯誤，妙的是，在兩台 UAT 機器中，又只有第一台會出現此效能狀況。當下，問題實在相當詭異。
於是，我索性將 VM 原封不動複製下來，COPY 回公司，使用公司的 VMWare 掛上來測試，以便釐清問題，因為不使用對方網路環境也可以徹底排除對方 Domain Policy 問題。但... 問題似乎沒有這麼簡單，我將 VM原封不動帶回之後，原封不動以公司的 VMWare 啟動，相同的程式碼、相同的 IIS Web Sites，都沒有動，只是 On 起來而已，居然..... 正常！！整個 Web API 執行回來只需要 729毫秒，數據正常~ 天啊，實在越來越詭異，案情一度陷入膠著。由於客戶端環境不允許你裝 IntellTrace 、Microsoft Agent 等工具，本想 VM 複製回來安裝 DEBUG 工具，但.... COPY 回來就 OK 了！！！.... 這？！ 此時我心想，這是我執行顧問以來最艱鉅的挑戰嗎？
於是隔天，我也只能再回到客戶端，只是回去之前我已經預先在程式裡每一段 Method 都加入 Trace Log，以記錄執行時間，包含 Web API 的 Action 進入、結束等等。現在也只有原始的方式了可以使用了....
不過這個時候我有了驚人的發現，就因為這些寫 LOG 的動作讓我發現，就 NLog 寫入的動作會不明原因的等待 40 秒，只有在第一台 UAT 環境才會如此，我不知道是 VM 的 Storage 的問題還是？但客戶說每台 VM 都架在相同的 Storage 上，沒有理由啊？案情又再度先入膠著狀態，不過可以確定的是，確實是 NLog 寫入時發生等待的狀況，目前只能懷疑與客戶端 VMWare 設定有關又或者是快照檔的關係。不過也總算有查到問題的發生點，至於問題實際的原因也要等筆者下星期再去客戶端進行處裡後，在向各位報告了。
在這個問題的處裡過程有一些需要檢討的地方，首先，上述其實有些盲點。
盲點一：這個系統安裝過許多客戶端，但不代表不會在某個客戶端出現問題。
盲點二：VM 的 Storage 運作其實我們並不瞭解，這部分應請這方面的專業人士協助，不該在這裡花費時間。
盲點三：NLog 雖然有需多人在使用，但不代表在所有平台環境執行運作都會正常。
這當中，我犯了幾個錯誤：
1. 不該太相信自己短暫的記憶力
隨著年紀增長，常常剛剛才記下客戶的電話號碼，馬上就忘了，而這個錯誤是怎麼樣呢？就是五分鐘前才建立的 db account (dblog)，我輸入到 web.config 時，卻覺得我剛建立的應該是 loguser，使的 Ap Server 端一直出現登入失敗，而我卻覺得怎麼可能沒有這個 Account？我剛剛才建立而已！
這個錯誤是什麼？其實這個錯誤就是，有時 Troubleshooting 還是得遵循一些基本的 SOP，絕對不能偷懶，不能用腦袋來記憶過程 (比如我剛提供了 DB1 的帳號 logdb, DB2 提供了 loguser)，該使用筆記本時就該使用筆記本來記錄這些資訊，這些資訊都是 Troubleshooting 的過程。這麼一來尋找問題才會有一致的方式，才會有效率。
2. 不要在急躁的情況下進行 Troubleshooting，這樣容易誤判情況
有時在客戶端處理 Production 問題時，客戶一定會很急躁，但你千萬不能受影響，千萬不可以因此影響你的 Troubleshooting 、還有你的判斷，也就是說，不要在急躁的情況下進行 Troubleshooting，這樣容易誤判情況。
3. 不要在精神狀況不佳的時候進行 Troubleshooting
也就是說，不要在急躁的情況下進行 Troubleshooting，這樣容易誤判情況。
4. 不要自作聰明
聰明反被聰明誤。有時自以為沒有問題的地方，反而問題發生點偏偏就在那裏。在客戶端的環境，任何環節的有可能出現問題，即使是原本你認為穩固無虞，絕不會有問題的地方，也是有可能會有問題的。就算是測試過的程式也是一樣，因為雖說我們只相信測試過 (Unit Test) 的程式，但，測試過 (Unit Test) 的程式不代表到客戶端就不會有問題。
另外，當我們在 Troubleshooting 時，有一點非常重要，如果超過一至兩小時還無法解決問題，那麼可能表示方向有誤，這時可能該回到原點，拋棄手上現有查詢到的資訊，重頭且重新的看此問題。
結論：
一旦到新的環境，一切思考就該回到原點，任何環節都要確認，在公司確認過的不算，到客戶端還是得確實在確認一次，絕不可以偷懶。到最後害到還是自己。此次的經驗對我來說是極重要的經驗，以往，AP Server 的 Troubleshooting 我沒有一個問題無法解決的，自以為了解所有環節，但有時過度自信卻也形成一個盲點，這也是執行顧問以來，我覺得我需要改進，以及可以與大家分享的地方。
簽名：
學習是一趟奇妙的旅程
這當中，有辛苦、有心酸、也有成果。有時也會有瓶頸。要能夠繼續勇往直前就必須保有一顆最熱誠的心。
軟體開發之路（FB 社團）：https://www.facebook.com/groups/361804473860062/
Gelis 程式設計訓練營（粉絲團）：https://www.facebook.com/gelis.dev.learning/
如果文章對您有用，幫我點一下讚，或是點一下『我要推薦』，這會讓我更有動力的為各位讀者撰寫下一篇文章。
非常謝謝各位的支持與愛護，小弟在此位各位說聲謝謝!!! ^_^
