背景
昨天因客戶私有部署問題，需要到客戶公司去排查問題。
他們是一家外企，各種權限需要提前申請(最大的坑)。他們之前部署的一般為單域名，很少部署互聯網類型多個域名的情形(第二個坑)。這次私有部署總計使用了十幾個站點，我們之前提供過發布文件與配置信息，這次是過來檢查部署，保證主功能正常使用。
出行問題
客戶公司需要身份證登記，臨行前我忘了帶身份證又折回重拿。到地鐵站和同事匯合時，同事又早下了兩站(地鐵站名相似)，耽擱了一些時間，本來預計9點半到，實際到時十點了。
網絡問題
由於工作電腦已經換成了台式機，所以上周申請了一台筆記本過來，結果就遇到問題，連不上客戶的wifi，無線網絡可以搜到其他的wifi，但搜不到要我連的那個。然后客戶和同事分別開了熱點，竟然也連不上！沒得辦法，只能用同事的mac電腦遠程公司服務器來開發了，這相當於浪費了一個人。
過了一二十分鍾，我配好服務器的環境后，用自己手機開了熱點，我的筆記本確能連上，真是奇葩了。由於已配好服務器環境，就沒有繼續用這個電腦了(事后想來，真是失策,在客戶現場，時間是充足寶貴的，能連自己熱點，應該立即使用，從而解放同事的電腦！謹記)
一遍一遍的日志
域名轉發端口號問題
先解決第一個問題。客戶部署的mj站點在sso站點跳轉是帶上了內部的端口號，而這個端口號在經過負載均衡轉發后，對外網不可訪問，應客戶要求跳轉時取的url統一去掉端口號。順利解決
驗證失敗死循環跳轉問題
我們的sso與客戶方公司自己的sso配通后，sso已實現登錄，但sso跳轉到主站點mj時，驗證失敗重跳回sso，出現死循環跳轉問題(由於內部訪問其他站點超時，非常慢，這點當時沒注意)。
經過漫長的幾版加日志，由於客戶方無法使用U盤，只能使用他們專用的文件郵件服務器來傳送，速度也不快很耽誤時間。
在這種反復折騰中，很快就吃過午飯一兩點了，終於日志記錄定位到一個訪問sso站點驗證cookies的地址超時，看到了明確的超時記錄，又無意間到我們的站點在調用restA站點取config時也出現超時問題(這里取不到值上周五電話會議已知道，當時sso登錄后默認跳轉地址取不到，當時一直沒在意，想的是優先解決跳轉問題，取不到值后從web.config獲取值，錯過了一次提前發現問題的機會)
既然兩個站點都出現超時，那便優先解決restA的超時問題吧，同事就開始上場了。
站點超時問題
一頓操作猛如虎，也折騰了一個會，取到了必要的請求參數放到fiddler里請求，然后返回了值。
這就很奇怪了！
我們又讓客戶重新走了一下流程，終於確認外部能直接請求，服務器內部訪問超時！同事就詢問服務器相互之間是不是有限制，防火牆等。終於找到了正確的方向！
沿着這個道路，我們發現客戶部署我們的十幾站點全是不同的ip，同一個物理機，每個站點虛擬不同的ip，配置的這么繁鎖……
既然走在了正確的道路上，剩下的就通順了。我們需要提供各個Api之間調用關系，讓客戶去申請防火牆權限。dev,was,production三套環境，每個環境那么多站點，相互之間要信任，我聽着都累。他們審批最少一周后了。
這個時候已經四點半了！總算可以返程回公司處理下額外的一些事了。
事后總結
這次雖然我通過不斷的打log定位到超時問題，同事針對特定超時鏈接，外網能訪問，服務器超時，定位到問題。但其實我打log對這次實施來講是十分低效耗時的，其實本可以直接通過取配置的接口定位問題，而不用通過sso的跳轉來分析問題，如果采取定位配置接口查問題，估計上午就可以搞定了。
用最簡單的辦法，先解決掉普遍的問題。再針對重點區域重點分析。
延伸擴展
以上雖然表面是服務器之間超時，同樣還是我們和客戶都沒有權限遠程登錄服務器操作的問題，客戶也僅僅只有固定的一些目錄權限。
當然還有關於日志，配置檢測的不足，許多都需要臨時打日志，這是非常低效的。如果每一個請求都能記錄結果，這些請求參數能保存下來，對於分析問題都是很快的。這也是APM的重要性所在。雖然正式環境有了聽雲和搭了ELK日志，但聽雲也沒有記錄的那么詳細，ELK使用率還不夠，而且私有部署也不會考慮這些的。
當然還有老代碼遺留的技術債，如這次打日志發現了很多問題，按Key取配置，竟然的單個取的，雖然只首次運行一回，但首次加載時間必然很慢。還有很坑的try catch后不處理，完全發現不了任何信息。
雖然這次用低效的方式處理了問題，但也多知道了一些坑，為后期優化提供了幫助，長遠看還是有用的。
最后還有一個問題，如果很多請求都超時，是不是可以意味站點無響應？我們在外部已經通過部分頁面確認站點可訪問，這個時候是否可以直接得出內部服務器有限制？如果早意味到這個問題，也許在看到超時的那一刻就知道了答案。
這是我個人第一次遇到這次復雜的權限部署，域名轉發后域名可正常訪問，內部卻因防火牆限制。做個總結，聊表慰藉。