由於此項目是一個集成項目，相當於將之前的若干個網站的首頁面統一到一個頁面來登錄。客戶方各個技術負責人不同，所用到的開發技術也不一樣，當集成到一起之後，發現首頁加載過慢，同時登錄過慢的現像。之前單一網站登錄需要4～5秒即可。而在集成之後，卻需要30～50秒纔可以登錄。在網絡併發數量較大的時候，登錄更慢。針對此種現像，開始了本次的售前調研與諮詢。
1，瞭解架構
現在網站大部分是採用LAMP與LNMP兩種架構，前端，中臺，後臺的語言是否一致，線程，進程的配比，代碼偏移量這些內容都是需要在前期進行相關的調研的。在與研發溝通的過程中，以上的方面都要以問題的形式精確的描述，才能夠得到我們想要的答案，纔可以更好的調用我們後方的研發資源。
有的時候，客戶方的技術人員與我方技術人員的代碼語言不同，相應的邏輯就會有很大的差別。在與對方溝通的過程中，要做到相關的內容最好有截圖，文字記錄。方便到時與後方研發人員的交流及支持。
2，深入分析
一般在網站登錄緩慢，可以通過一些運維工具，或一些抓包工具，分析相關的網絡時長或HTTP建鏈時長。這些的排查方法，一般是先外界，後內部，先循環，後邏輯。總之，就是先易後難。當我們通過抓取全鏈路時間後分析，發現網絡層的時長只有3～4秒，大部分的時間消耗是在代碼處理，以及線程處理上。我們就把分析更細化至代碼偏移量（不同代碼段的運行時長）。
當我們開始進程分析之時，前端需要配合我們做相關操作，當出現登錄慢時，我們捕捉到相應的線程，在其後臺找相關中間件的消息。突然發現中間件顯示有線程鎖的標誌。後來抓取了相關截圖發至後端研發，在研發定位後，才明白，原來所集成後的統一登錄網站是屬於.net開發，線程鎖默認爲0.5秒。而這種情況相當於代碼在進Session時是要有這一項限制。
3，解決問題
在找到問題之後，剩下的就是解決的方面了。客戶方也派來了開發人員，在明確了本項目問題之後，將之前的代碼加載機制進行重新改寫。直接在前端TCP進程建立之時就開始加載。最終，在進程分析之時，實現了更快加載。實際上這種問題，在我們日常的上網中也很常見，現在的技術一般是用GO語言這種分佈式併發加載來解決，或者是本地推送的方式來解決，單一的遠端加載模式越來越少。
在解決好本問題之後，再通過前端操作進行全鏈路追蹤，發現全鏈路加載時長變短。讓客戶進行相關體驗。客戶反饋網頁反應速度比之前快了許多。至此，故障解決。
4，服務合作
在幫助客戶解決完這個問題之後，客戶方要求出一個PPT來詳細向領導講解此問題的解決過程。後來在與客戶研發接口之後，輸出相關解決方案PPT。在獲得客戶側研發的讚揚之後，發現客戶側只是生產單位，研發能力有限，而研發負責人也在解決問題的過程中逐步對我方建立了信任。
深度瞭解客戶的組織結構之後，在向客戶領導側彙報完相關解決方案後，順帶提服務合作的意向。最終在客戶側研發主管的支持下，獲得了領導口頭的承諾。後將這一信息反饋到銷售，繼續跟進此項合作。最終，此項目由最初的解決登錄慢的問題，最終落地成爲一單服務合同。
5，項目覆盤
回想這個項目，可以說是由一個點引發的一個整體的解決方案。有的時候，售前賣的不單單是一個產品，有的時候也是一種服務。客戶的需求有很多，先要抓住客戶當下最重點的問題，幫助解決。後邊再談相關回報。技術在這個項目中起到了很關鍵的作用，但也只有在溝通過程中，才能瞭解到客戶的架構，以及未來對一些新技術的考慮。
這個項目，沒有像之前的售前打法，先上來講一通我們自己的技術方案，而是從客戶側的實際問題出發，幫助客戶定位。與客戶側研發一起去解決問題。建立合作關係，最終我們能解決，一方面感謝客戶的信任，另外一方面，也是公司後臺研發同事的支持。因爲在一些代碼原理的實現方面，一家公司也是需要有相應積累的，尤其是要有相關的成功案例。
互聯網行業的項目，一般來說都相對複雜。而當用互聯網的一些方法技術去解決傳統IT問題（從ToC到ToB）的時候，又需要多傾聽客戶側的聲音，讓一線的人能調動更多的資源。而且，慢慢發現，自己在跟一個懂技術的客戶聊天時，會非常輕鬆。而從技術的角度去推導客戶側的應用實現及併發解決時，總也可以預測到合適的點，從而可以更提前的與銷售配合好，也爲銷售找到相關的拜訪理由。
售前就是一個不斷學習的過程，重點越來越感覺不是學相關的技術，而是從客戶的角度去思考技術的實現，業務的驅動。