有陣子沒更新blog了，，真的有陣子了，自上次更新《一位架構師用服務打動客戶的故事》已接近有五個月了。每次都是這一句，對不起各位，我又脫更了！！！哈哈
在開始正題前稍微給各位關注博客的夥伴說明下這段日子去幹嘛了？
～～其實早在2017年8月我就開始了自身網絡專家"修練"的日子。
修練什麼呢？
答：CCIE
爲什麼要去做這個事兒？
答：其實就想給自己過去曾經給cisco做助教的經歷一個交代
實戰派爲何需要這張paper？
答：第二個問題的補充哈，想認真的梳理下自己的知識結構
～～決定給自己列個百天計劃，享受一下這個百天計劃的壓迫感！！！
～～起的越來早，睡的越來越晚
～～衝勁十足，從來不抱怨
～～現在想想也覺得那近6個月的日子真開心，除了知識得到了系統性的查漏補缺，更得到了心智上的"收穫"。
好了，老鐵們，不扎心了，，來講講今天這個客戶的故事，上菜上菜！
在開始前講一個背景，我們跟騰訊有深度的戰略合作關係。
諸位也清楚，市面上的公有云論IAAS的組成其實都一樣。除了在一些特定行業特性上掛了自己的標籤之外，其次就是自身能力轉化成PAAS的產品能力！
總之，各有千秋，對於遊走在各個產商中的我，也只不過是多了一個廠家的特色學習，IAAS組網、系統應用中間件構架的難度並非是難事。
本文沒有解讀太多技術細節，着重在“售前和銷售在項目中的配合協作”上，所以不喜勿噴，(*^__^*) 嘻嘻……
時間回到2017年x月x日：
我們接收到騰訊雲一個很牛X部門的通知，告知在上海漕河涇園區中有一個潛在客戶（一家即將上市的公司）需要雲計算資源和服務，授權我們前往拜訪。
在接受到通知後，我們的渠道BD單獨找到我，表達了希望我前去支持下這個項目。
隨後呢，正趕上我們的雲服務Team在上海出差，於是我邀請了雲服務團隊的Sunny（Leader）和其中一位資深的linux專家、以及上海Pre—sales Team的一位同事共同前去，一共4個人。
PS：第一次拜訪因爲銷售時間關係，沒有辦法參加，所以和客戶約時間等事宜我個人全部代勞了。
第一次拜訪材料的準備———第一波重點探討，注意注意
因爲沒有前期的需求溝通，所以這個時候相對會比較"懵"，不知如何展開？我沒想太多，直接拿了一份某同事整理的《通用型上雲解決方案》的PPT準備起話術來。然後花了大概30分鐘左右瞭解了下這個客戶的情況（公司基礎信息，包含但不僅限主營業務範圍，人員結構，公司註冊信息～～），結合這些信息判斷了下客戶可能會有哪些應用上雲的訴求，並整理成材料。
材料部分截圖：
拜訪不只是相互認識，如果能在最短時間拿到客戶需求又或者在很短時間能勾起客戶"滔滔不絕"興趣話題這個相當重要。
身爲一個售前，假想下你初次拜訪的場景～～
1.相互遞個名片
2.公司介紹膠片走一遍
3.聽客戶把需求講完後，客戶告知發一些典型案例我們看看
4.差不多寒暄幾句結束了
那根據我個人走了小十個單子的經歷，這種情況基本你作爲售前就是失敗的。仔細聽需求是沒錯的，但如果不想着辦法讓客戶多講點其他的東西，那售前當的就多少有點問題！！
例如;
1.基於什麼考慮要做這個上雲事情?
2.爲什麼會選擇騰訊雲，沒選擇阿里雲、百度雲、ucloud、金山雲？
3.物理機房在哪裏？大概規模有多少？之前有出現過災難故障嗎？
4.目前有多少業務系統？等等
爲什麼我個人主張這麼去思考呢？我個人一直認爲第一次的拜訪一點不亞於破冰的概念，很多時候真的需要我們好好想想－技巧這兩個字！我把腦子大概閃出幾個關鍵點彙總如下：
1、讓客戶真正講需求，這一點共知沒問題
2、讓客戶講講公司的情況，我們除了因爲有云計算需求過來拜訪之外，我們也更希望深刻的認識和了解客戶！！
PS：先朋友，再生意，自古以來的道理，當然預先已經鋪墊好的項目就例外說了。別挺萌的一上來就談項目怎麼落地！這要是放在北京，不說別的，先是一頓大酒，喝好咱再談生意！
3、帶着專業的問題和預先準備好的（通用）方案過去客戶那邊，現場當面交流技術實現細節，以及方案的適用場景！別光顧着聽，然後聽完承諾回來給個方案，這種我就認爲售前角色做的太低級。
PS：作爲客戶角度着想，這種情境如同：年輕的售前＝信息傳遞者、年長的售前＝老油條一個，沒點真才實學。不敢直面現場交流，如果客戶有很好的關係做信任基礎，那就無礙。當然這是個人觀念，不喜勿噴。
4、 切勿以最高逼格直接上去梭哈！
PS：脫離實際，一味追求高大上的方案，客戶再有錢也不傻！當然項目利潤運作除外
5、老生常談了"我們來是過來解決問題的，不是來炫技的！"、"我們是來學習交朋友的，不是來吹牛皮的！"
PS：姿勢和站位要對，論換位思考的重要性，明白先感情再生意的讀者能體會到我想說什麼。
6、聊聊至少一年後的計劃
PS：表明我們此次前來的目標是着眼於未來，眼前的問題並非難事兒。當然這不是讓你"太務虛"，尺度自己把握好就行。
約到客戶時間後，就到了拜訪階段了。
我們提前十分鐘到達樓下，再次碰了下今天拜訪的主要目的和角色分配。隨後我們到達客戶會議室，相互遞了各自的名片後，進入正題。
按照我前面提到的幾個關鍵點開始了今天的拜訪。加上我們有騰訊的光環，客戶滔滔不絕講了非常多，方方面面幾乎都涉及到了。加上前面預先準備的一版方案，客戶更是表達了對我們做事的信心，也提到要做混合架構、安全、冗餘備份的想法，剛好方案中也提到了實現細節。在很融洽的不到一小時的會議中，客戶表示很期待我們下一次過來拜訪（協議合同、優惠尺度、服務合同的商定）
本次混合雲方案中PPT截圖；（同事預先準備好的通用方案）
本文第二波重點場景解讀：
舉幾個親身經歷的例子！
1、一次我代表甲方去跟新進的軟件供應商談運維話題的場景，對方什麼準備也沒有。絮絮叨叨沒邏輯的講了許久粗的"東西"，總之表達一個觀念："運維沒問題，我們有能力維護好"
Allen解讀：甲方無非其實就關注你能不能把他關心的方方面面講清楚。風險可控的最重要的參考就是"過程"，過程即意味着細節。倘若都是泛泛而談且沒有邏輯和極強的細節闡述，那就會勢必會造成冷場和尷尬，甚至客戶的不信任。（當然，關係型項目引進和利益運作除外）
2、我去給一家在物聯網領域研發技術能力很強的公司交流，雲計算的便捷和挑戰等內容時，對方甚至問到協議和數據報文的結構、數據流在各個中間件的走向與處理。再我在具體一點（Nginx灰度發佈的實現原理、以及對業務可能造成的有損範圍等）
Allen解讀：遇到技術能力很強的溝通對象，你的技術功底相當重要。在這一次溝通中，我並沒有回答上這樣的問題，告知我下去後與我們的linux技術專家學習和交流下，不知道就是不知道的觀念還是要積極去表達，不要裝懂！！！大忌
3、還有一次一個非常典型的視頻內容的客戶，由於原先供應商的強勢加上客戶自身並不懂技術的原因，運維中產生的話題給內部造成了巨大的困擾。（每次APP的更新通過CDN推送到全球后，手機終端觸發更新後都是秒下，導致更新失敗），我作爲技術顧問過去後得知這些問題多少是有些驚訝的，難道現在的ISV都介麼"強勢"嘛？，不過從IT人員組織結構來看，客戶側確實存在"缺失"。
Allen解讀：如我之前幾篇文章聊到的，開發對功能負責，運維對穩定負責。客戶對這一點沒有感知也能理解，避免術業有專攻。但作爲售前如何把這個觀點（故事）講清楚，就是售前的本事了。所以售前不僅需要有技術，還要有講故事的能力。最終用戶的root cause是本地網絡環境的DNS被劫持和CDN預熱問題導致。
第二天中午，我便準備好了資源採購清單報價，補充調整了相關基礎架構、安全方案。部分拓撲圖如下：
和BD的溝通後，我梳理了一份郵件（包含報價、方案等SLA協議）發送給了客戶側，郵件內容如下；（已和諧）
PS：做雲計算服務的公司，文化水平尤其是語句通順和意思表達上很多時候都是通過郵件來傳遞過去的，所以中國語言文化博大精深，我個人也是深有感觸的。
文章中有個上雲總體流程，也算是我們Team的思想結晶，所以還是額外提一句。團隊戰隊比個人作戰始終會強很多“三個臭皮匠賽過諸葛亮”，所以如果讀者你是一位正在擇業或大學畢業的學生的話，優先考慮選薪資待遇不如考慮選個好的Team文化的。。。當然，沒有什麼追求就想當個蘿蔔的，那就無視我這個觀念。並不是這樣不好，每個人追求不一樣。只是筆者是個90後，自然血氣方剛、更活力點，得罪得罪，不喜勿噴~~~~~
接下來，相當順利的進入到了項目的第二階段-深度調研，【怎麼落地的問題？】，基本上進入到這個階段就離正式簽單不遠了，而且八九能拿下項目。
PS：流水賬經過不作贅述。
劃重點啦，劃重點啦，以下本文的重點：
正如我前面的文章介紹的“售前策略”，這一次我是站在客戶位置去和對應的開發商去談上雲細節。
期間一共對接公司內部五個部門（財務、後勤、人事、業務、技術），外部則有三家應用供應商，可見這個溝通量很大，也對售前做事兒是很大的考驗。不過好在我是輕車熟路，雖然一路波折，但還在結果是令人皆大歡喜的。
PS：讀過我前面幾篇文章的讀者應該會知道，其實個人是非常喜歡分析和總結經歷和問題的。當你一個人承接了這個項目，項目裏面有這麼多溝通對象以及三方的站位問題所帶來的挑戰。似乎都是一些值得回味和反思的“細節”
我總自我反省，技術+溝通是可以很好結合在一起，使售前工作進展順利，讓個人價值得到提升。
我一直在嘗試學習MBI的方法論和做事路子，很多時候大廠的“套路”着實值得拍手叫好。
他們經常從組織架構聊到業務架構，再到應用架構和網絡架構～～～～～～～
PS：自上而下一層層幫助客戶理清思路
再如，傳統企業在互聯網時代使用了一些互聯網技術，在雲端更好的處理這部分業務（用戶數據），既而產生數據價值，達到提升公司整體運營、業務運行效率，解決數據之間的割裂。提高數據之間的扭轉問題，這就是“新XX（零售）”，然後假以情境進行佐證。
其實不得不說，大廠的思路很強之外，更強的在於他能告訴你“公司應該用什麼姿勢去承載這些需要互聯網技術的業務”。通俗的去講：給你做售前技術方案諮詢時，免費幫你把公司運營的諮詢也做了。非常值得我們學習，進一步轉化成自身的能力。
回到項目中來，差不多兩個禮拜後~~~~~~
我和銷售去了客戶現場，給客戶彙報了我們近期的工作“日誌”和項目實施計劃表（就是之前我分享材料），並進行了商務上的洽談。對話也就不到一個小時，確實很順利。剩下的就是等客戶美滋滋的打款了！
（~~~這中間省略一些人物細節分析，天天分析人物關係，人容易分裂~~(*^__^*) 嘻嘻……）
因爲項目的交付工作是由雲服務Team帶頭完成，我作爲PM+架構師中間偏問責和協調，所以這裏就不詳細贅述交付過程，只是列出一些交付期間產生的問題以及如何解決的？
1. 騰訊雲CDB（for sql），軟件商實施過程中無法執行license註冊，導致軟件部署工期延後
root cause分析：
架構是讓DB和web服務分離，通過CLB起到負載冗餘作用，但CDB屬於一個單獨的instance，獨立於windows OS運行之外，註冊失敗是因爲CDB無法主動與軟件商的license center通信導致的。
How to solve the problem?：
取消CDB部署形式，DB使用CVM單獨部署（與傳統部署一致）
2. 雲上***無法與動態IP對接
root cause分析：
騰訊雲的***-GW在指定對端peer時，只能寫IP地址（無法寫域名等方式），恰好客戶辦公室均是動態IP。
How to solve the problem?：
通過雲市場採購深信服雲防火牆，部署在雲VPC網絡內（相當於硬件防火牆***對接形式）。通過調整VPC路由完成部署工作
今天先分享到這裏，項目還有重要的第二部分的訴求，也是我徹底搞定對方boss的一個關鍵需求，且需求是摸出來的，並非放在檯面上讓你去“解”的，這裏買個關子留着下回分享。
2018年會有很多心願完成，我也在考慮是否要成爲一位開發者，因爲未來或將成爲開發者的天下。
———————來自一位在努力路上的網工
QQ:549675970
Wechat：
Johnny_JunJun
QZONE:
http://user.qzone.qq.com/549675970
E-mail：
人生格言：越努力、越幸運