大家好，本次的案例分享，會給大家分享一下踩過的一些坑以及自己的一些心得，希望能給大家在後續的項目中帶來一些幫助，如果有不對的地方，歡迎大家拍磚頭，使勁拍~~~

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~~~

公有雲時代的售前打單