最近找了一個典型的雲服務客戶的案例對內進行分享，今天把核心內容脫敏後分享出來。希望能給目前在路上（做雲服務MSP）的同行，有一些借鑑意義或者幫助。
該用戶據全年跟進情況，目前該客戶距正式啓用我們公司雲服務（運維服務）的日子已經有半年有餘了，目前整體趨於穩定，故將目前用戶進行深度覆盤剖析，讓各位夥伴更好的從該客戶案例中提取一些有用的“武器”、“售前技巧”。
雲產商：阿里雲
企業背景—日企上來的終極三問~
- > 爲什麼選擇我們做雲服務商？
PS：此雲服務並非指的是阿里雲、騰訊雲、華爲雲、亞馬遜，而是雲運維管理服務（MSP）- > 用戶爲何會引進雲運維管理服務商？
- > 怎麼妥善處理應用問題引發的“扯皮”問題？
這些問題，其實也是目前所有做售前相關工作的99%會遇到的？
有很多不一樣的應對姿勢，這個因人而異。這也是我今天主要分享的內容，我是如何應該此類用戶，並且“拿下”用戶的“認可”和“信任”
分享目標，今天強調下，學習要有目標
以前一直沒有講分享目標，這一次囉嗦下（或我們會有後期學習目標的考覈）：
1、 從該案例中，sales能獲得“打單”部分經驗
2、 找到如何做服務輸出的思路和打法
3、 瞭解到我們公司是一家服務輸出型公司，而並非一家資源轉售型的代理商
4、 用戶營業模式的初步認知以及產品策略
因爲信息敏感問題，最終用戶以“用戶”簡稱、自己的公司以“公司”簡稱。如果您是我文章中提到公司的管理者，且認爲文章表達措辭不當，請及時聯繫我進行刪除或者修改
郵件聯繫方式：[email protected]
客戶來源：
線上主動電話諮詢過來的，後面由上海總部本地獨立進行跟進：
同行競爭分析：
- 寶寶樹
- 歪歪兔
客戶訴求來源背景：
客戶自身沒有相關雲計算的IT團隊，加上公司部門“牆”和獨立結算的問題，兩邊團隊的IT資源不共享，總結的說：一邊是IT基礎架構部門（獨立公司）、一邊是APP應用部門（獨立公司），但兩邊同屬一家母公司。
客戶想找到一個做“IT外包服務”的公司，幫助內部解決一些基礎性的技術問題，彌補內部團隊技能的缺失導致的低效的問題。
客戶企業營業模式判斷
屬於傳統零售行業，通過線上的官網、天貓等虛擬店鋪提供在線預訂早教材料和周邊玩具。結合線下實體店（多以×××店擴展，但蘇州有自己直營店）進行面對面的互動體驗，通俗的講就是“陪孩子們”完，大多在滬的家長都會在週末和孩子一起過去玩，也有的放在那邊“託管”。：），既而產生支付行爲。
用戶商業模式分析、產品構成體系、企業backgroud這裏統統省略，我們直接開始售前階段的拜訪主線講述。
第一次"售前"拜訪
Sales安排了當面拜訪，我記得當天行程安排還是很緊密的。一點都不能耽誤（一場接着一場，總共四場一天）。
我和sales到客戶現場後，我確認是我們的老客戶，但是另外的獨立的部門。
會議室清一色的“仙女”坐在對面，進去後很快的發現對接的部門是一個單獨應用部門，且目前負責的人員屬於偏管理職能，非相關IT專職人員兼顧管理雲上的資源和應用服務。
Sales提醒我，我也立刻意識到要換一種通俗化的溝通方式，快速的講解了我們的業務形式（包含公司企業價值觀，工程師文化，發展經歷）。
~~這裏有個小插曲，過去之前，sales已經進行過一次服務內容報價的整理了，所以是第二次片細節內容的彙報~
很快簡短彙報完後，客戶的部長緊接着就直接聊到了目前的問題，整理如下：
即刻需要解決的痛點：
1） 用戶在更新APP內容時候，經常出現秒下載等訪問不到的問題，既而導致用戶投訴，app體驗糟糕，平均每月預估有30起以上的使用投訴（而客戶的處理辦法也就是送些玩具和訂購優惠）
2） 軟件開發商遇到很多技術問題無法妥善的傳遞給我們，我們也無法正確的識別到一些技術風險，導致用戶無法正常控制項目中潛在的技術問題既而產生的風險，當出現應用問題後，軟件商經常的推諉，消極對待，責任擔當意識不夠。
3） 目前阿里云云上的安全（數據）問題無從得知，擔心出現嚴重的信息安全問題影響公司形象。
4） 用戶組織結構需要學習阿里雲相關知識，並對目前業務運行的情況有一個“透徹”的自主掌握
隨後我略顯着急的講了一個近期的客戶案例——P2P支付客戶的案例，詳細闡述了我們在其中如何輔助用戶積極解決問題、識別問題、代碼問題優化建議等。
客戶參考客戶案例：某P2P支付公司
詳細表述，我這裏不贅述。大家有空看看文章就明白我的策略了。
（文章分析傳送門：http://blog.51cto.com/allen686/1968113）
接着繼續正面的探討（部分摘要）：
我個人針對性的去分析了目前存在的問題幾個方面：
1） 第一個問題推斷是傳統運營商本地DNS劫持導致，建議使用HTTPDNS
2） 第二個問題是否是合同中並沒有明細的服務描述以及處罰措施，對第三方供應商管理上存在一些經驗性的缺失，既而導致消極對待等。
3） 阿里雲安全問題主要是組織結構缺失導致，故建議通過第三方專職人員完成
4） 客觀的描述了用戶內部缺失專業技能人員或沒有學習“土壤”，導致雲計算能力成長天花板不高
ISV和公司可以是平行關係也可以是相互依賴關係，但一定不是對立的角色設置。我們和客戶內部IT團隊（運維）的關係一定是賦能和被賦能的關係，而不是替代和被替代的關係
首次拜訪結束後，
首次拜訪結束後，我習慣性的記錄了會議紀要併發布出去“調研”文檔等等，沉寂了一個半禮拜後，事情出現了一些新的轉機。~我和sales都異常興奮~
【客戶讓我們去現場交流運維交接的細節問題】，我和銷售心照不宣，這件事情成了，後面就是穩穩的推進即可。
我們給出第一份調研表（顯示如下）：
最終，如我所料想的一樣，軟件商（ISV）選擇了無視，給了一份自己的文檔，接着我們進行很久的過濾和提煉。這才最終確認全都是配置詳細的中間件的配置文件，以及簡要的一些拓撲圖和業務邏輯圖。
關於腳本放置的位置、運行頻率等重要信息都沒提，關於特殊需要注意的地方沒提，所以這仍然具有很大的挑戰。事後是我們的工程師進行了一臺一臺的看配置確認了一些關鍵的內容，這才梳理出來的，確實花了不少精力~！！
這裏可能會有疑問，用戶找我們來做什麼？額外造成一些溝通成本和費用支出值得嗎？我後面循序漸進的描述後就會有所體會，我們這個角色（MSP）這個行業的生意是如何構建的！
積極的態度，能解決不少問題
在以上描述的過程中是客戶對我們認可的一個階段過程，軟件商（ISV）不知是因爲不夠開發，還是沒有精力積極的應答我們，反而倒是這種對比，也是帶來直接服務感知差距的來源
這裏省略一萬個字的流水賬
隨後的一個月中，
我從權限治理再到基礎的監控和數據安全管理，再到很多內部IT管理上的干預工作。逐漸培養出了客戶對這件事的高度認知以及充分認識到過往工作的一系列的缺失項。如某月計劃推進的詳細工作清單：
中間因爲北京有一些任務，需要出差去北京。有一次會議是在回來上海的動車上進行的，我記憶還挺深刻，那天北京大雪。北京當日因很多動車、高鐵、復興號全部取消導致大量的人員滯留，我拖着行李在北京南站用“熱點”搶到了一張票，在徐州後一路站到上海（也開會開到了上海）
架構師（售前）旁白：
整個雲運維接管的過程中，以信息安全爲中心一點一點開展。
期間我能準確的感受到，客戶（以女神爲主），都沒有計算機基礎，對於很多應該注意的地方都沒有辦法關注到。如果以一個老師的身份把這件事情講清楚，極爲重要
作爲架構師除了要有極好的耐心、細心，更要用通俗化的語言解釋一些技術專業術語，巧妙而有技巧的傳遞信息
這一點也一直是我在努力的地方（幫助客戶成功），所以相對進行的很順利
客戶業務部門的組織關係構成，這裏省略
這年頭寫一點項目分享顧首顧尾的，好難！！
技術輔助以及服務輸出的關鍵內容介紹：
––––––––––––Dns劫持之用戶APP更新秒下載，無法正常使用的root cause
使用場景：
1、由於通過HTTPDNS進行域名解析獲取IP信息後，您需要基於該IP信息進行網絡請求，即您需要具備定製網絡請求的能力。因此HTTPDNS比較適用於C/S架構的應用場景。2、瀏覽器環境下（B/S架構）由於客戶端的網絡實現對於開發者而言是黑盒過程，無法定製DNS與網絡請求的實現，因此不適合在該場景下使用HTTPDNS。
因爲首次見面就提出了該方案，客戶對我們的專業能力極爲認可
––––––––––––堡壘機之第三方運維管理
基於協議正向代理實現，對SSH、Windows遠程桌面、SFTP等常見運維協議的 數據流進行全程記錄，再通過協議數據流重組的方式進行錄像回放，達到運維審計的目的，包括遠程授權登錄windows主機，通過IE瀏覽器，進行聚石塔平臺相關部署操作，如下圖所示：
––––––––––––數據安全管理，數據備份策略管理
重新設計了自動快照策略，定時數據備份策略，通過第一項權限賬號的治理來干預數據管理的詳細方式和手段。
––––––––––––雲上信息化安全持續改造建議計劃書
通過安暢的自身最佳實踐輸出信息化安全實踐的流程制度以及it基礎架構的改造建議。基於公司內部運行三年的ISO20000/ISO27001的體系，定製化輸出：
––––––––––––面對面培訓工作的開展
這方面的輸出根據實際情況來判斷，目前進行了一次。如何支持？參考阿里雲線下培訓服務內容：
––––––––––––自研分佈式的監控月報/週報
––––––––––––詳細工作變更日誌
雲服務成本優化計劃書
這一個概念，我在上一篇文章中有詳細解讀過關於IDC和雲計算成本投入的問題，希望各位讀者有一些新發現。因爲未來IT不再是簡簡單單的做做技術這麼簡單，業務IT的概念會越來越strong。IT不再是一個簡單且獨立的環節。
**最後一項，是客戶感知更進一步的地方。因爲確實真正的在幫助用戶合理的使用雲上的資源，相比目前市面上大量的號稱“費用使用可視化分析”，雖然我們還沒徹底工具化，但是人工的好處就在於是準確並經得起反覆推敲的。
最終的結果總結：
1） 最終結果證明，我的第一判斷是對的（這一點上，客戶對我認可度非常高），因爲過來第一次交流就看出根本的問題，事前投訴季度（≥100起）事後投訴在各位以內，但仍然存在少量的情況，（我也知會了用戶，用HTTPDNS只是緩解並非根治）
2） 通過我們來扭轉部分技術問題，技術與技術的對話更容易產生共振和相互理解（ISV、用戶、我們）
3） 安全問題通過我們向用戶管理形式上進行賦能，具體的從訪問管理、數據備份、審計等方面入手，先對整個雲上IT資源的控制進行有目的的“留痕”控制，保證操作可回溯，杜絕操作不留痕跡。再到最後的系統運行中間件的加密與優化調整。
4） 通過F2F的方式進行定期的登門拜訪與交流，除解答疑惑之外，並約定定期現場進行一些基礎雲上的功能講解和分享上。
該用戶在阿里雲上的雲服務構成如下：
1、 VPC（專用網絡）
2、 ECS（雲服務器）
3、 SLB（雲負載均衡）
4、 Snapshot（快照）
5、 OSS（對象存儲）
6、 NAS（文件存儲）
7、 Clouddisk（雲盤）
8、 Vod（視頻點播）
9、 CDN（靜態資源加速）
10、 HTTPDNS
11、 Security group（安全組）
12、 RAM（權限控制）
13、堡壘機（安全審計）
QQ: 549675970
Wechat: Johnny_JunJun
E-mail: [email protected]一位正在轉型的網工（Allen） 人生格言：越努力、越幸運