一位架構師用服務打動客戶的故事之五

有接近小四個月沒更新客戶案例的分析了，脫更一直挺嚴重了，講真「本身也挺無奈的」，這一次帶來一個傳統IDC機房總體遷移上雲（AWS）的案例的剖析。

---

有不少讀者也是剛剛從後端「運維、售後」轉到前端「售前、銷售」的，因此我也很但願個人經歷能幫助到大家一些。

我是一直很相信「溝通」+「技術」是能夠很好結合在一塊兒的，在行業內，咱們稱之爲「技術顧問式銷售」、「銷售工程師」等。由於若是你有很牛的技術底蘊，卻沒有team的文化，良好的溝通能力，你沒辦法把本身、本身的公司很好的表達出來。或許除了研發是一個很好「歸宿」以外，其餘我實在想不到了。

---

別的感情啊啥的就不廢話了，直接上菜。：）

客戶背景：
用戶的IDC服務器資源在DC運行平均超過五年，面臨從新採購新服務器的「鉅額」一次性成本投入。

去年幾回重大的事件的列出：
1）某月存儲AC主控制器出現異常，業務暫沒受到影響，但存儲徹底「脫管」，後經產商千萬DC修復後完成。期間遇到兩次業務的「新增」被擱置。
2）因軟件商誤操做，執行了一段刪除主數據中一張XX表。後經確認數據沒有備份，而沒有執行備份策略的緣由是由於磁盤空間不足
3）oracle數據庫硬件服務器出現硬件故障，主節點離線。
4）金蝶財務軟件系統出現故障，中斷12小時以上

架構師旁白：
雖然過程較爲波折，但想一想仍是比較後怕的~~~~

補充下，咱們每一年都會有很是詳細的變動事件記錄（這應該是作雲計算服務公司的基本素質），相似以下這種（IDC）：

---

寫在前面

---

由於該客戶一直是咱們的用戶，咱們在續約前兩個月的回訪中，除了交流整年的變動事件外，咱們也準備了關於混合雲的架構的topic與客戶探討下雲計算的內容。

架構師旁白：
有時候老客戶反而很差伺候，爲何？由於留給時間來證實的內容，就是你以前承諾的內容。若是有遺漏或者故障事件發生，這個對於剛步入售前的工程師來說多少有些棘手。
這一次的彙報，對於續約來說是成功的，對於上雲來說是失敗的。客戶對於雲的理解和承認度並不高，認爲仍是物理機簡單。並拋出了好幾個問題：
1） 上雲，我oracle的license會不會須要單獨新購
2） 業務系統使用的是比較老的版本，上雲後會不會不兼容等問題
3） 雲上的每一年成本預估大概有多少
4） 雲上的數據備份、安全等是怎麼設計的。
5） 。。。。

---

對於我的來說這些話題基本每一個用戶都會提到，因此仍是相對篤定，可能有些成本數字，產商的對比仍是要拿出來整理成PPT來面向用戶彙報。

---

偶爾看過我博客的讀者都應該比較瞭解，我所在的公司是什麼公有云都服務和支持的。由於是家中立的雲服務商（MSP）。

這一次，由於客戶的背景是外企性質，在交談中用戶有意傾向於AWS（亞馬遜），因此咱們就以AWS的技術方案爲前提提交了技術方案（包含遷移、雲上架構、安全架構、持續運維服務構成）

AWS的服務是至關全的（雖然在國內產品寥寥無幾），對於熟悉了國內公有云的工程師來說，本身須要作的轉變仍是比較大的。~由於思考方式，要變一變，國內的公有云好在符合國人的思路和更加服務化的console界面，可是aws就另說了，徹底是工程師的公有云，並且有更新的概念「基礎架構即代碼」，這個留在之後分享。可謂是學習成本、技術門檻都比較高。

這一次的客戶案例中，咱們的總體PPT風格使用了AWS的風格，相似以下：

---

---

真是有種天生驕傲的感受，畢竟全球公有云領跑者，在國內的公有云的產品中多少有一些AWS的影子。
這裏必須支持下阿里雲和騰訊雲、華爲雲，一直在穩穩的追趕中。文章是在國慶期間寫的，因此這個普天同慶的日子裏。貼一張上海南京西路，軍人的無私付出：

---

第二次上門拜訪記錄

---

一週後，咱們帶好技術方案、方案資源配置價格，前往客戶現場作了第二次彙報。
技術等相關方案核心問題：
1）oracle上雲的license問題
2）oralce 上雲的高可用保證（原IDC是oracle-rac部署形式）
3）Microsoft sql server 的license問題
4）MS sql的高可用保證（原IDC是單機部署）
5）遷移所帶來的停機時間設計
6）雲運維服務和IDC運維服務的區別宣講
7）上雲先後的收益對比（主要體如今成本支出上）

今天的分享內容挑其中幾個關鍵的問題作詳細彙報（談不上分享了，技術問題一直是市面上那幾種成熟，主要是售前的溝通策略和PPT的內容重心）

---

若是但願能學到一些技術，經過博客內容的話，那可能要等等了，國內由於社區太多，彼此的博客都習慣於各類抄（爬蟲），技術博客目前都存在本身的私人電腦中，我會一點一點的同步出來。剛在CTO發的文章，大概一個小時後在其餘地方就有徹底同樣的文章，因此這一次我把筆者的交流方式留在文章中間，至少讀到這裏的夥伴是真正在看文章的夥伴。

---

QQ:549675970

Wechat：

Johnny_JunJun

E-mail：

allen_junjun@hotmail.com

人生格言：越努力、越幸運

---

解決方案中的成本部分（核心）

雲計算帶來最大的轉變就是把一次性的投入變成了按需投入，加上客戶目前公司總體運營背景，確實在進行「開源節流」、「縮減對應人員職位重疊的編制」、「後端支撐團隊進入輕運營」。
當看到這一點，確實跟我以前想的重點不謀而合，故客戶在第一次拜訪中並無直接否認雲計算的方案，而是持觀望態度，因此這第二次的彙報尤其重要。

成本方案測算的過程當中：
我與sales計算了一次性投入和純公有云每一年的投入數字，如我所料想，IDC 超出 雲計算不少。加上沿用過去的雲服務體系（甚至漲價都不存在問題），我這裏列出非實際數字，方便你們有個概念：

---

PS：分別爲純IDC方案、AWS方案、混合雲架構方案。

---

成本部分的總結：
1）AWS總體上雲成本性價比會高於純物理和混合雲。
2）License是否須要額外新購的評估中：確認了oracle、mssql的許可證只要保證版本號一致，我更換運行環境不會產生額外新購的成本（預估在12W左右）
3）Windows操做系統的licnese是否新購：
客戶原來的系統都是運行在2003的系統行的，很是老舊。咱們也在這次上雲方案中提出了升級2008/2012的方案。我料想「客戶就會問，系統要正版的，是否要單獨購買正版受權」，這一點我也會給客戶解釋，公有云的OS（windows正版受權），都是包含在單個實例購買的費用裏面，並不會須要額外再次購買。開通即正版
另外，咱們將部分前端web應用從windows環境改形成了linux的環境。

最終拜訪的效果：成本測算客戶90%以上已承認，有一些同產商的對比須要補充。

---

客戶提問一 ：

這裏會有讀者問了，

客戶雖然傾向AWS但畢竟在國內仍然是阿里雲、騰訊雲佔大頭。並且他們的成本相對於AWS來講，具備絕對的碾壓優點。技術實力目前看來也不會落後很大一個差異。並且國內的AWS不少安全產品、PAAS產品都沒有，阿里雲、騰訊雲也具有拿下客戶的能力！爲何不考慮它們呢？

---

筆者回復~是的，這一點也沒錯，可是我想說的是，這屬於純內部採購項目，不會有招標一說，加上客戶基礎在這裏，咱們可謂幾乎沒有對手，並且對於咱們雲服務產商來講「資源對咱們來說自己就接近沒有利潤」，因此用任何一家我都支持，也不會有引導性的技術方案和溝通策略，客戶說什麼就是什麼，總體 基調「客戶說了算」

讀者又說，你仍是沒有正面回答個人問題？

~好吧，我將客戶原話大體意思複述一遍，讓各位更爲了解下客戶自身所考慮的地方。
~國內的公有云廠商會默認在服務器中內置安全服務的agent的組件，而AWS沒有
~阿里雲是國內第一個作去IOE（IBM、Oracle、EMC）的產商、騰訊雲相對理智一些，至少雲產品中有單獨的雲上oracle一體機解決方案（相似黑石），客戶有Oracle的環境，相反AWS（中國）雲平臺原生支持RDS for oracle，console操做截圖以下：

---

~國內的比較大的雲都出現過人爲誤操做致使業務宕機、數據丟失的事情。外企性質客戶對此很關注，加上國內的公關都相對比較「拈輕怕重」，不多願意主動認可錯誤並徹底透明的覆盤整個過程，加上公有云的SLA時間保證沒有AWS好，參考以下：

PS：具體的產商名字我先隱去，可是這個都是對外能夠查詢到的，你們能夠放心去查詢便可

---

~若真出現平臺的故障，用戶得到的賠償在國內基本都是「代金券」、「服務器運行時長」，而國外Azure、Aws是直接賠償現金，這也許是國外公有云廠商的吸引CIO、CFO、CEO的地方，「契約精神」

---

筆者旁白：
咱們確實還離別人還有一段距離，但這沒必要擔憂，我一直相信阿里雲、騰訊雲、華爲雲、京東雲、滴滴雲、美團雲、網易雲、金山雲、×××、Ucloud、紫光雲這麼多雲，勢必能奮起直追。咱們這些作技術的工程師，雖然有能力看到全球頂尖的企業以及他的技術，但若是祖國哪天須要我，我必定會奮不顧身的爲本身祖國的技術創新拼搏。

---

我是中國人，我愛個人祖國~：）

---

有點小激動，每次心念祖國的時候

---

技術部分

技術上雲方案評估（與雲運維團隊一塊兒Brianstorm）

1）由於AWS中國雲上產品較少並從新check了整年oracle的監控數據（壓力極小），故咱們在oracle部署上確認使用oracle-DG方式，總體部署難度下降很多，架構圖參考以下：

PS：AWS oracle DG 官方參考文檔：https://docs.aws.amazon.com/zh_cn/quickstart/latest/oracle-database/data-guard.html

---

2）Mssql的原先是單機，在雲上部署always-on便可，算是技術架構上的升級
架構圖參考以下：

PS：AWS mssql always-on官方參考文檔：https://docs.aws.amazon.com/zh_cn/quickstart/latest/sql/welcome.html

---

3）這次方案設計徹底遵循AWS最佳實踐（多Az、IAM、數據加密等），文檔很是多，學習起來確實很值得。工程師充電必備~~~
https://amazonaws-china.com/cn/architecture/well-architected/
IAAS部分架構圖以下所示：

PS：業務架構圖就不分享了，須要和諧的內容太多。~偷個懶…

---

上雲收益（文檔精華內容，請細讀）

這部分接上以上兩部分展開，相對會比較務虛，但確實頗有說服力，我是從這幾個話題展開的。
1）將自身系統上雲，在公司層面，使用雲計算來爲自身公司內部提供支撐是一件很是值得興奮的事情，這個尤爲在傳統企業正在尋求轉型過程當中的效果最爲明顯。
2）不用再爲設備物理損壞而擔憂業務故障，服務可用時間指標可用優化的更好更高
3）資源可用更合理的被「掌控」，經過資源使用狀況合理對主機進行季度或半年爲週期單位的降配或升配
4）數據備份不用再擔憂硬件資源不夠，避免致使預先制定好的備份策略沒法獲得執行。
5）對於雲服務團隊，則能夠將重心更好的放在業務架構優化、DB性能優化上，無需再花精力對硬件的故障預判和風險預估。
6）。。。。。等，
PS：圍繞比較事務性的傳統架構中的問題就行逐一探討~~~

---

架構師旁白：
由於項目中用戶對成本很是關注，因此這裏探討一個關於一次性採購和上雲的成本的在五年/十年的分析對比，不管是站在上雲的角度，仍是駐守傳統物理組網的角度，本質上雙方並無直接的衝突，只是在國內由於競爭激烈，引起出了更多平行的產商對比，還有物理和雲計算的對比，如你們所料所看，網絡上處處瀰漫着略帶有主觀意志的見解。

---

因此，這裏我也抒發下我的所謂的「客觀」見解，僅供各位參考，不理解也沒關係，畢竟我如今屬於雲計算的站位，多少會有些「端不平」的狀況在，因此看看足矣。

---

傳統架構通用考慮因素：
數據中心、機櫃租用、固定帶寬租用、硬件維保服務、一次性硬件投入（含firewall、loading-balancer、switch、server、bastionserver）、駐場運維工程、網絡/系統/DBA工程師

雲計算通用考慮因素：
計算資源（含安全產品）所有按需購買，網絡/系統/DBA工程師

---

成本配置場景一：三級信息等級保護（僅供參考）

---

---

---

咱們來以五年爲一個週期看看趨勢圖來直觀的看下：

---

有人要講了，我用3W的waf照樣能解決評測的問題。你爲什麼寫12多W的產品~~~~
1）這裏面，我尚未計算最重的部分——人工（即：各類工程師資源）
2）傳統的機櫃、帶寬等成本「大頭」，我也在此場景中也選擇忽略了。

結論：至少五年內，雲計算在等保三的場景中，成本有具備很是大的成本優點。

~有想了解等保三的內容的，尤爲是總體過程細節，我會擇日找時間寫一篇分享出來~~

---

**敲黑板，劃重點~~~

場景二：大型集團應用（門戶、電商、支付、交互式購物）等應用上雲成本測算【保留部分等保3產品】**

---

---

咱們來以趨勢圖來直觀的看下（建議放大看）：

---

---

~我忽略很是多存在歧義的焦點（好比；時間成本、故障處理的成本），因此僅僅在一個靜態的狀況下，動態去調整了可預見的人員、資源的配置成本。因此這份數據僅供參考，不具有任何實際數據價值。

---

註釋：
靜態，即指：不考慮業務的增加，徹底以第一年的總體項目的配置去評估次年
動態，即指：會考慮業務的增長與縮減，動態去調整人力成本、資源配置成本

---

結論：
在靜態數據預測對比狀況下，在接近第四年有一次數據交叉和第七年時第二次交叉。
在動態數據預測對比狀況下，第接近七年的時候會有一次交叉。

---

若徹底忽略業務運營數據、忽略意外硬件故障時間、忽略DDOS***，徹底把思考的寬度放在成本投入上去看，長期來看（10年爲一個週期）。理論狀況前提下，IDC的投入會比雲計算的投入來的划算一些。

但咱們將十年每一年的投入總計進行「橫向」彙總以下
數據源：

---

結論：
雲計算不管是靜態仍是動態去測算投入成本，雲計算最終的投入都始終會比IDC的投入要低一個數量級。

---

好，回到項目中來，第二次彙報結束。客戶追加了幾個問題，以下：

1）爲何選擇AWS？和其餘公有云的對比矩陣圖
2）上雲先後的物理硬件license的變更（相似軟件清單的對比）
3）全部應用遷移的實施的POC方案的「檯面交流」
4）遷移實施計劃補充
5）報價方案須要再優化下格式、分類以及部分機器的配置增長減。

---

---

架構師旁白：
對於這一次交流，我是很滿意的。由於基本已經平穩度過了「售前」階段的工做了，因此這一次提到的內容，都是一些小補充。後面就靠銷售最後的商務能力了。

---

咱們兩人離開客戶公司，銷售便告知穩了。不用擔憂，節後來簽單~~~
過節期間，我將補充好的方案與內容發給了用戶，所有經過了客戶的要求，上班第一天銷售就告訴我，籤合同了。至此總體這個項目的一些比較關鍵的通過我分享完畢了。

---

技術方案&報價方案版本記錄：

技術方案版本從1.1到1.8
報價方案版本從1.1到2.1
基本九月下半月就琢磨這個項目了，好事多磨~，這裏提一句，對初在售前崗位上的架構師也好、工程師也好。「耐力是基本功、多健身練練跑步：）」，文章中我也留着了我的的聯繫方式，志同道合的朋友歡迎來交流心得，互相學習互相補充。

---

好了，國慶沒回家，在家除了理方案外，寫個分享祝你們節日快樂，晚了幾天發佈，遲到的分享，抱歉抱歉~~

——————一個正在努力轉型的工程師

歡迎交流，技術圈子原本就不大：）