好久沒來了，這段沉浸的時間都在專注學習雲計算相關的解決方案和進行實戰，這一次更新那當然是有項目在個人的努力下，落地了！！！！
所以過來更新下，我在項目中的各個狀態。當然仍然是用第一視角的去解讀，這也是一次彙總和回顧，有很多主管的想法在裏面，不喜勿噴。
先在“上菜”前，開放的聊聊我個人理解中的雲計算是什麼樣子的？到底什麼樣的業務部署形式才屬於真正的雲計算部署？到底我們在雲計算這樣的趨勢下如何合理運用好雲計算的特點去提交合適的技術解決方案？
首先，我個人的總結了幾點：
1. 改變了傳統IT運營交付模式，減少了傳統IT對網絡高級工程師需求，降低對運維團隊的投入。
2. 動態彈性調整，按需使用，按量付費。完全靈活自主，若企業過於龐大，預算控制等相關IT治理流量冗長，對於業務團隊開發效率是致命打擊。無法很好的控制預算申請額度，還要考慮傳統的設備利舊等等問題，接踵而至的管理上的問題，都是傳統IT治理中無法避免的。在企業應用上線初期保證業務系統架構和IAAS架構高可用的情況下，可以用最低的資源配置讓業務快速上線進行demo的環境的ready，等待業務經過壓力評測後，在平滑的進行資源配置提升。在成本控制上也是boss非常樂意看到的。
3.DDOS***的包袱、IT基礎資源的硬件維護投入（每年維保服務）、機房的風火水電維護、中國多家運營商之間的異網傳輸問題，應用和網絡安全的的包袱。都可以扔掉，完全交給專業的運營商去解決。
綜上，所以雲計算帶來的“革命”一定是新鮮互聯網企業和軟件開發商（ISV）的必選。無論是從運營角度還是技術對接難度難度上，雲計算均是無懈可擊之勢，所以搞清楚客戶的準備上雲的系統應用非常重要，這個可以做爲一個突破點，去了解其他的應用。然後慢慢引導上雲。一定會雙贏
好了，上菜，上菜！！！！！！
項目背景：
簡述,客戶考慮上一套物聯管理系統，涉及消防系統、門禁等傳感信號管理，管理員可以通過手機app、客戶端管理終端等方式管理
1. 客戶屬於國資背景
2. 企業應用屬於物業管理系統性質
3. 無任何新舊數據過渡的“負重”，完全新的系統上線
項目經過：
大家能明白，做售前或者架構師，一定是銷售機會現行，那就一定是sales先接觸到最終客戶。那這個時候我一般會先找到對應的sales，先聊聊客戶的情況，通過什麼方式找到的？對方是CIO還是CTO，還是engineer。總結一句話，先弄清自己面對的對象是誰，再去考慮怎麼去設計方案和溝通。
進行了一些溝通後，確認了對方角色，公司名稱。隨後進行了一些百度瞭解。
這裏再嘮叨一句，我們有很多衝售後走向售前的工程師，特別容易犯的意識形態錯誤，會先去想這個技術怎麼落地，自己有沒能力做？不會去關注即將面對客戶是誰？總結一句話，如果你從幕後走向業務前端，一定務必先搞清楚你的客戶（博弈的對手）是誰。
我還是像之前的一樣，用個人的視角去闡述自己的處理經過，當然中間有很多觀點均是個人主觀出發，若感覺比較偏激或偏執願意與筆者交流討論，留言給我噢，若覺得沒有什麼必要，直接往下看正文略過即可。
第一次電話溝通-【需求溝通&設計階段】：
在去客戶現場前一天，我通過sales，我與客戶進行了基於阿里雲的產品第一次溝通，溝通了應用場景、軟件情況、高可用等思想。可以說是一聊就明白了，非常順利。
接着晚上加班整理了架構方案，架構圖如下：
方案一
方案二
方案三
這裏一共提供了給客戶了三種架構構建方案，關於ucloud暫時沒有給出，因爲發現ucloud的雲產品-負載均衡在某些地域沒有，這個侷限性比較大，就直接忽略了。
PS：因涉及三個產商對標的情況，涉及一些競爭，我這裏不透露，大家自己去琢磨吧，哈哈
注意，這裏是此篇文章分享的重點，我們在第一次面對溝通中，客戶提出了不少技術上的挑戰，當然你會想，就這麼點產品，哪會有什麼挑戰？
第二次面對面拜訪洽談-【方案確認&可信性對接】：
這裏先說說下前面設計的方案的思想：web無狀態，統一存儲、數據庫分離部署
挑戰：
1. 軟件商目前告知數據庫、文件存儲不可拆分部署
2. 軟件未在負載均衡環境下測試過，需要測試
3. 騰訊雲、阿里雲、ucloud的產品優劣勢對標
因客戶最終比較偏向於阿里雲，所以這裏給大家稍微提一下阿里雲的產品的知識設計出於的考慮。
前端：WAF（應用防火牆）+SLB（負載均衡）+ECS（無狀態雲服務器）
後端：RDS（雲數據庫）
文件存儲：NAS文件存儲
網絡：VPC（虛擬私有網絡）+NAT網關（解決ECS出局流量）
當我們在部署的SLB後，對於後端私有網絡VPC中的ECS，ECS是不具備主動出去訪問的能力。
注意看我如下的流量走向示意圖，SLB到ECS這段，因爲在阿里雲內部，我們會選擇在SLB上設置後端監聽ECS一定是內網IP處於對。這樣同時也可以保證安全。
故根據以上的判斷如下：
1. 在SLB中的ECS是無法主動對外訪問ISP資源，只能通過其他方式去實現。可以這樣理解。
2.，SLB只做了DNAT的功能，SNAT的功能他不負責，這個在傳統的F5設備上其實是可以做的，這一點要注意。
3. 所以要找到一個可以解決SNAT的產品，NAT網關就是一種，當然也可以利用ECS去自建iptables去解決，只需在VPC內把缺省流量扔到對應的主機上即可。
在得知客戶說數據庫拆分和文件存儲不可拆分時候，我倒是一點都不擔心，因爲在做過一些系統集成單子的售前都明白，在系統架構中，數據庫調用也都是依靠IP地址，文件存儲是依靠路徑。只是以往我們放在一臺設備上，就無需考慮這些事情。
關鍵點一：
這裏是幫助客戶說服軟件提供商，拆分的事情也可以做的，不是不能做。所以除了你要了解一些系統底層常規的結構之外，還要清楚一些拆分後給軟件開發（程序員）帶來的問題。
所以我們與對方的程序員工程師進行了一通電話溝通，並進行了詳細的“技術實現推演“，在大概30分鐘左右的溝通後，顯然對方已經敗下陣來。認可了我的方案提議。
關鍵點二：
大家注意，這裏我解決的不是這個技術實現問題，是解決了目前這個客戶和軟件商之間的問題。相當於你可以理解，我是甲方的工程師，我代替甲方去“challenge”軟件提供商。那換來的自然是客戶的信任和好感。所以大家在後面支持客戶上雲時候，沒條件也要去想辦法創造條件去弄清楚客戶的整個IT架構中的組織架構。這個對於後期開展工作非常重要！！！注意
比如：有多少個軟件供應商、有哪些運維人員、多少人是外包的等等。
關鍵點三：
解決了技術問題，解決了商務問題，那還有什麼可以說的呢。當然有的說，這個時候就要問客戶的項目預計上線時間、二期擴容計劃、整體項目預算大概在多少數量。——————這一點爲什麼要問，大家自己體會吧，有時候感覺自己太白話也不好。
然後，因爲我個人不抽菸，來客戶公司前，看見客戶在抽菸。所以就在提議結束的時候，讓銷售陪客戶出去抽抽菸，瞎聊聊。我留下來整理下信息。至此第一次拜訪結束。
第三次客戶來我們公司洽談-【方案計劃實施階段】
在第一次會議後，我們將相關資源配置報價方案給到了客戶後，客戶主動約到我們公司詳細談方案價格方面的事情。
在來了後，我們直接進入到商務合同的確認事宜，所以我給上次拜訪下了一個成功的結論。
這裏，大家應該很清楚，基本上這個項目已經八九不離十了，所以這裏只要保持好標準的推進節奏即可，無需擔心丟單的問題了。
不過在這裏同樣也出現了一些小問題，比如客戶對雲上的產品不熟悉，就會出現各種部署細節上的一些疑問。所以這裏需要扮演原廠的工程師提供一些支持，這個對於售前的能力考驗很大，因爲售前一般都會比較偏框架的設計，很難有心思去關注到實施細節上。
例如：
1. SLB上的會話保持怎麼做？它四層轉發和七層轉發是否可以共存。
2. ECS部署後，如何快速起一個http服務測試SLB的效果。
3. RDS上如何連接並導入demo-DB進行測試。
4. 對於測試和驗證是否有詳細的測試報告。
5. 。。。
例如：SLB如何配置，如下圖的操作截圖。
注意這裏！！！！如果一個架構師僅僅是做好技術解決方案一定是不行，要善於發現客戶的“痛”！！
其實，當客戶問到我這些問題的時候，我第一時間想到的不是如何回答！！！而是立刻想到了一問題，客戶可能遭遇到了來自公司高層的一些“challenge”，因爲客戶對公司IT整體負責，那自然會涉及到像“述標”的情況。我想到是客戶遭遇到這些，自己無法很快的頂過去。所以此時我已經做好持久解決和複習學習的心裏準備。
一、是複習自己對產品的認知
二、是幫助客戶在內部站住腳跟
三、是引導客戶在哪裏可以找到解決文檔方面的工作的案例文檔
好了，今天就暫時先分享到這裏，因爲一篇好的文章，往往幾千字是說不完的。所以我後面會繼續分享，分成【業務上線的項目管控與跟進】等部分去展開。期待各位讀者持續關注本博客。
目前正在進行對一些傳統IDC的方案向雲計算方面轉化，後面會持續分享項目工作心得。感謝各位的細細評味。
我的初心一直是這樣，我在嘗試着真誠地描述自己遇到的問題和解決經歷。若你也是一個在技術路上堅持的人兒，那就一起加油，一起努力。
———來自一個正在努力讀書的網工Allen
QQ:549675970
QZONE:http://user.qzone.qq.com/549675970
E-mail：
[email protected]
[email protected]
人生格言：越努力、越幸運