公有云時代的售前打單

Xx金融遷移金融雲案例分享（售前支持分享）

                                       

你們好，本次的案例分享，會給你們分享一下踩過的一些坑以及本身的一些心得，但願能給你們在後續的項目中帶來一些幫助，若是有不對的地方，歡迎你們拍磚頭，使勁拍~~~

Ps：裏面一些涉及客戶隱私的部分已經和諧掉了，請見諒~

   使命召喚  臨陣磨槍~

在2018年x月x日這一天，我收到了一封郵件，由Allen轉發，告知有一個項目須要支持， 打開以後發現是一個金融客戶須要從公有云遷移到金融雲上，爲何要遷移到金融雲呢？金融雲的好處就不詳細展開說明了，總之相較於公有云，不管是安全仍是服務都有顯著提高，可是這樣一來成本會增長，咱們知道今年對於某些行業是比較特殊的一年，隨着《網絡安全法》的下發，不少企業受到衝擊，金融行業固然也不例外，爲了響應政府金融政策以及自身更加的安全考慮，所以客戶決定搬遷金融雲，固然可能還有另外一層的考慮（僅爲我的判斷），高投入換來的是高回報，一旦搬遷到金融雲以後對用戶來講也是一個安全的保障，所以只要宣傳作的好，會所以吸引到大批的用戶，並獲得用戶對提供服務的應用提供商的信任，如今的市場魚龍混雜。今年國家對「互金」行業的規範政策一直持續着，因此對於那些「不紮實」的企業必定會進行一些措施。好比IAAS基礎設施連最基本的「high availability」都沒法保證的企業。還有「運維人員權限管理、公司制度不健全」等等。

好比以下截圖所示：

客戶有需求天然須要溝通，可是因爲客戶身處杭州，地域關係，所以實施以前的溝通都是以電話和微信溝通爲主。

在前期的溝通中，收到郵件以後，發現有一個附件，需求調研表（該附件爲銷售經理髮給客戶的），裏面記錄了客戶的需求以及客戶的體量，可是在後續溝通的時候發現裏面的調研內容不少都是直接在網上覆制的，這點做爲售前須要注意，由於以前有過這樣的案例，就是售前階段是南，實施階段是北，最後固然是雙方扯皮，徹底說不清，緣由是客戶本身對需求都不清楚，這種狀況下建議不要去刨根問底，這樣可能會獲得一份客戶本身不成熟的看法。

 

第一次電話溝通------簡單瞭解客戶需求

由於這個客戶的特殊性，我不可能拿着ppt去給客戶講解，因此第一次的溝通側重詢問客戶需求點，以前的《需求調研表》此時能夠做爲一個切入點，可是注意，通常在溝通一次以後，客戶會但願能有一個方案出來，這時候作出來的方案每每是不夠成熟的，由於客戶的需求不少尚未了解到（而當時的我並無意識到這一點，因此後續出現了不少問題）， 當時沒想太多，下意識拿一份以前的遷移模板進行修改，結合客戶目前的狀況整理一下，加上報價一塊兒發送過去。

 

方案解讀：

1.     高安全，架構採用DDOS-WAF-SLB的方式，這樣的作的好處，一個是針對異常流量或者×××有了很好的防禦，另外源站隱藏在後面減小了源站暴露公網的危險

運維人員經過堡壘機登錄，操做皆有記錄，且須要受權才能操做。

2.     高可用，應用層的服務由兩臺相同配置的服務器提供，一臺出現故障另一臺能夠隨時頂上，數據庫層採用的阿里雲成熟產品RDS，底層 是主備架構，多可用區，

3.     高擴展，當業務量增長的時候，能夠隨時對服務器進行橫向擴展而不會影響業務

 

固然沒有絕對完美的方案，後面我會對改進版的方案進行說明，並說明目前這個架構存在的缺點（所謂的缺點實際上是相對的，最大符合客戶業務需求的方案纔是最好的方案，並不必定那些高大上方案必定符合客戶的業務需求,切記）~~

 

與客戶的溝通的時候須要有條理性，不是想到哪說到哪，溝通以前建議先本身整理一下將要與客戶溝通的內容，另外在有效時間內拿到本身想要的內容而且引發客戶的興趣，這個很考驗售前的功底~

 

 

      試想一下（售前常常乾的事情，「人格分裂大法」~），假如你是客戶，這邊有個架構師和你對接，問了一些問題，而這些問題感受都是在念課本同樣，你會怎麼想~  而在此次溝通完以後不久，發現這個架構師又找你問了一些問題，而這些問題又是毫無邏輯性，感受徹底就是調查戶口同樣，他來問你來答，這個時候你做爲客戶又會怎麼想~  我想說到這裏，

你們應該明白了，交流是相互的，而不是你一我的的獨角戲

 

這裏貼上一段以前看到的話，這個不管是售前仍是銷售均可以看一看，很值得深思，固然想要去真正的實現也很難。

 

「項目分爲項目需求和我的需求，我的需求是項目需求的動機，由於人會感到不足，缺失，痛苦，項目需求是我的實現的機會，由於項目的成功會讓我的需求獲得知足」

 

 而現實每每是，一個小小的事情，都有可能會影響到整個大局的變更，因此捕捉客戶需求，並非嘴上說說那麼簡單的~

 

Technical point：

a)   阿里金融雲目前sqlserver沒有隻讀實例，華東1

b)   阿里金融雲負載均衡目前僅支持性能共享型，華東1

 

繼續~

 

  POC測試階段---------------溫柔的陷阱

 

在通過初步的電話溝通以後，我發送了一個初步的報價和方案，此時的進度還算正常，等待客戶反饋，其中在裏面我建議先進行測試，即先測試再正式，客戶那邊也表示認同，此時第一個雷埋好了（佈置的好能夠給客戶一個驚喜，佈置的很差會把本身炸的體無完膚），不少人在上雲的時候每每喜歡說一句話，先測試一下吧，而這個測試，到底測試的是什麼，以及對後續的生產環境會產生了什麼影響，這個必定要想清楚，

 

這裏我簡單總結一下本次測試的目的以及一些測試思路（供參考）

1.     基礎架構測試，主要驗證架構是否適應客戶目前的業務，也能夠理解爲架構優化，

2.     高可用測試，主要目的是爲了驗證架構的容錯性，以及對業務的影響程度

3.     壓測，主要目的是驗證目前的架構是否能夠達到客戶預期的併發指望

 

部分測試文檔截圖以下

測試的目的主要是爲了驗證這個架構對客戶業務的適應性，以及架構的穩定性，而架構對業務的適應性測試任務主要放於客戶側，由於客戶對本身的業務最爲熟悉，而正是因爲這個決定，使得後續接收到的測試結果反饋信息都來自於客戶側，這個時候實際上是一種危險信號，由於此時的咱們對客戶內部的結構以及對接人的狀況並非太熟悉，更沒有想到接收到的反饋信息並非那麼的準確，此時的咱們都沉浸在遐想的世界裏，由於客戶側反饋測試正常，一切ok，在後面的實施發現其實並不ok~

   

稍微「走個神」~

形成這個問題的緣由多是多方面，可是若是考慮周全那麼風險將會大大的減小，就比如三國赤壁之戰，也許曹操註定失敗，然而當時若是郭嘉還在，至少不會敗得那麼慘,因此前期的考慮周全，是能夠對後期進行規避一些沒必要要的風險~

 

 

 

 

因此說在售前項目把控的時候，必定要注意，全局的把控，流程的規範，必定要作好，不只僅是對客戶有個交代，對本身也是提升工做效率。

 

方案優化~

測試過程當中，咱們瞭解到客戶須要和第三方接口對接（銀行），須要提供ip地址給第三方，添加白名單，考慮到後續的業務的擴展，所以咱們對目前的架構作了調整。

調整部分以下：

PS：接口調用，由於是從ECS主動發起調用，故須要在銀行側的接口那邊把NAT-GW的IP加入到白名單中。

 

方案優化解讀：

1. 更安全，初版的架構應用層是雖然是高可用架構，可是兩臺服務器仍然是放在同一

可用區，

優化方向 將服務器放於不一樣可用區（可用區能夠理解爲擁有不一樣物理位置的機房），至關於實現了傳統概念中的「同城雙活」的設計，固然如今的部分公有云徹底能夠經過SLB掛上不一樣區域的ECS，實現「異地+同城多活」的設計，前提要設計好用戶端本地優先接入的架構，

   2. 更便捷，初版的架構出口流量是從服務器自身出去的，這也就意味着對於第三方白名單來講是要添加更多的白名單的，前期業務量少的時候還能接受，一旦業務擴展那麼添加ip將會是一件很是麻煩的事情，

優化方向 使用NAT，統一出口，彙總網內出去的帶寬。相似咱們傳統架構意義上的「防火牆」的SNAT的功能。爲的就是解決主動出去的帶寬被統一。

 

會師杭州  風雲再起~

 

在原有計劃中，正式的切換要在5月份以後，而在4.19號客戶側表示但願提早遷移，

【這種狀況，在金融背景的客戶案例中是不多見的，由於金融公司通常對於時間都會超前不少去規劃，每一天的安排都是通過很是多的前期準備定義下來的。可是爲何會接收到這樣的要求呢？~~~1%的特殊而緊急的狀況】

這就意味着計劃表須要更改，不過因爲前面測試基本上代表網站能夠在現有架構上正常運行，並且架構也基本知足客戶的業務需求，所以提早切換對咱們來講時間也是夠用的，這個時候須要售前進行評估，根據現有客戶狀況以及多方面綜合因素進行考慮，是否能夠提早遷移，由於對於客戶來講可能只是一句話，而這一句話所涉及的方面確是甚廣~

貼上部分實施計劃表截圖

計劃表解讀：計劃表是對總體項目進度的一個管理和把握，所以須要考慮全面，另外對每一步所進行的步驟須要作到合理可行，以及後續風險的可控均可以體如今實施計劃表中，所以很是考驗售前對項目的控場能力的功底和售前對售後技術協調溝通的能力，因此這是個團隊的活，並不是一我的強就能夠了。任什麼時候候都須要團隊，這一點在這個項目中體現的特別深入。 

 

遷移前準備與確認

因爲咱們是提早趕到客戶那邊去的，所以在遷移以前大概2個小時左右，我建議將客戶與咱們這邊的工程再次彙集進行最終細節確認以及分工，主要涉及到的是遷移過程當中每一步的實施人員以及目前的準備程度，這個是很是有必要的，

在遷移工做準備完畢以後，就能夠等待正式遷移了~

這裏稍微嘮叨幾句，若是讀者參與過「物理機房的遷移、中小企業的網絡割接、運營商的網絡割接、銀行業務的調整等」，那就知道這一步必定要過。由於每一分鐘都很是重要。

 

 

遷移過程~

  

1） 中止解析（客戶側）

PS：這一步驟按理來講不該該中止解析，而是解析到新環境中，這樣會出現一個維護界面提示，直接中止會出現訪問空白的狀況，這樣給用戶的體驗很差。後面的項目你們要留意，這一點你是站在客戶的角度去考慮的「自身用戶的體驗」，因此後面這些習慣能幫助加快客戶的「好感」

 

2） 數據同步，DTS（客戶爲主，咱們爲輔）

這個在分工中，客戶考慮到數據的安全性，所以不讓咱們進行操做，可是咱們建議咱們從旁協助，若是客戶操做過程當中有問題，咱們能夠進行協助，在接下來的遷移中，咱們也發現了，客戶對這個工具使用不熟悉。

Ps：遷移的時候遇到第一個問題，DTS提示權限不夠，這個須要注意賦予的權限是否賦予上了，此次出錯的緣由是由於多了一個空格致使權限沒有賦上去，一直報錯。

3） 安所有署（咱們）

這個步驟須要將域名和證書部署到安全產品上，證書咱們放置的位置是WAF上，

      劃重點~~~：域名解綁以後，此次遷移發現生效時間居然達到一個小時，即在新環境佈置域名，一直提示被佔用，這個在以後的遷移中必定要當心，一個小時時間太長，而目前對於生效時間還未想到有效的解決辦法，只能提工單，催一下阿里那邊。

若是網站中斷時間小，仍然是先將域名解析到負載均衡上去，先讓網站運行起來，不過此時的訪問多是http，而不是https

       

4） 解析切換，環境驗證（客戶&&乙方（咱們公司））

 

 

至此爲止，這個項目算是告一段落了，可是打單之路遠遠沒有結束，這個只是打單路上的一道風景，不過慶幸的是前進路上並不孤單，你們一塊兒fighting~~~