有些日子沒有整理案例了，回顧了下上次案例分享的日子，已經有將近四個月了。。
~~~~~~~
從開始在51CTO上寫架構師服務這個系列後，因爲留了聯繫方式後，有不少志同道合的的朋友留言、加好友對一些特定的場景進行交流，其中個人收穫並糾正了不少錯誤的觀點。無論如何還是要謝謝有這麼個地方，讓我去記錄並分享個人的一些經驗和心得。
~~~
又脫更這麼久了，抱歉抱歉~~~（讀者：“信不信我把你按着地上摩擦~~！！”）
最近確實忙着很多連續性的工作，但都不是具體配啥了，讓各位失望了~~~：），如我前面幾篇文章提到的，確實當“技術方案”推進到一定的階段後，有很多時候並不會讓你接着像以前本地接console、遠程SSH去調試了。。（當然你讀者要是純支撐運維部門的一員的話，直接忽略我的觀點，：）），那多出來的時間都去幹嘛了呢？
很顯然是，“設計方案、規劃實施交付過程、學習業務、業務運行邏輯、開發調用過程~~”
這不，有一個好的機會遇到了一個全球運動品牌的Top5企業。這個項目由比較幸運的我來配合做了。擺在眼前的挑戰是“完全新的公有云環境、新的PAAS特性、新的Docker運行環境、新的交付邏輯以及全英文的溝通環境”。着實讓人興奮~~~，我在官網找個案例講講這個項目大概痛點在哪裏？如下圖所示；
圖（一）
如上圖所示：
在最右邊圖上有個不起眼的地方標註了：“OLAY專櫃及天貓旗艦店積分權益共享”。現在越來越多的傳統零售企業，選擇在國內一線TO C/B的電商平臺上註冊並運營自己的店鋪。因爲類似阿里巴巴（天貓）這樣的平臺，已經成爲了“國人”不可或缺的購物平臺選擇，業務上天貓能帶來非常多的流量，例如：六一八、雙十一、雙十二，這也是後面我會談到的“流量紅利”。
類似天貓平臺的還有很多，比如蘇寧、京東等。而且京東雲的也已經在零售行業開始發力。
PS：找個時間我會單獨寫一篇文章帶各位認識下京東的“零售能力”。
但如果我們的零售企業只關注擴大獲客渠道，也不是特別妥善的增收的辦法。現在的獲客成本逐年在增加，企業的獲客能力卻甚至在倒退，有質量的付費用戶羣體越來越容易被撬動，這對較傳統的企業的衝擊是非常強的。 舉個具體的例子，比如；我就是一個網購愛好者，我喜歡在網上買東西，但也熱愛去實體店體驗試穿併購買。以前沒有注意“線上和線下的體驗”，但後面因線下有庫存，線上沒有的原因關注到了，我在天貓官方旗艦店鋪是已經是V3會員了，但在線上的實體店裏，我個人的屬性仍然是普通用戶。體驗特別不好，‘至少我也是V3的會員啊’，怎麼一點都不重視我呢？，所以就是哪怕實體店看好了，都不會在實體店下單，會優先考慮在天貓上同款下單~~~
產生這些消費觀念的根本原因：
1.天貓有優惠券，買得多優惠的更多。
2.我也不差這麼幾天，什麼時候寄到什麼時候穿，時間不是痛點
3.確實和實體店的質量是一樣一樣的
圖（二）
那麼說到這裏，那麼問題&挑戰來了！對於已經構建了自己的官方APP、官網的企業這也就會直接導致以下幾個問題出來：
1.主站流量被“分割”
quj：客戶不在企業官方通道下單，直接在天貓、京東以及蘇寧下單。
2.應用去“中心化”嚴重，全渠道管理難上加難
Allen：企業自身維護的訂單系統、分銷系統、庫存系統、物流配送系統多而管理成本高，再通俗一點，用戶數據庫就有好幾個（比如自己官方一個、天貓一個）。這就是TO C/B其他電商渠道平臺帶來的平臺“數據扭轉割裂”的問題
3.管理成本“幾何級”上升
Allen：第二點的補充，有部分傳統行業是這樣應對的。比如用戶天貓上下單，確實使用了天貓平臺的訂單和庫存還有會員系統，運行和表現都不錯。但是我們的庫存訂單和物流中心的系統都是在線下，且獨立運行的（又或者說是獨立的團隊支撐），所以這個時候就需要把天貓的訂單重新在自己的系統裏面再次錄入一次。那麼怎麼解？這裏“那就再顧個客服”做這個事情吧。
架構師旁白：
“2C平臺到底自建還是用天貓？”
Allen：其實沒有絕對的答案，在這個技術驅動業務的時代，本應該“業務數據流匯聚後，集百家之長。而並非絕對要一定選擇一邊，拋棄另外一側”。
大致流程如下所示：（不嚴謹樣例）
圖（三）
所以，我個人認爲，新零售它帶來的除了技術的“革命”，還有更重要的側重點是“打破數據割裂的格局”，在雲端更好更快的處理，既而產生“數據價值”。解決“人、訂單、物流(車)、庫存、直營門店”的運行效率低下的問題。即“新零售”~~~
——包括微信端的終極“兩個半”生態~~小程序：
圖（四）
PS：不論是小程序上的來伊份也好，還是其他的華味亨等門店就更加典型，我也參與了來伊份2017下半年-2018上半年的信息化的建設，深有感觸，找個時間也寫篇心得給大家。
————————
這裏推薦一偏運營的書《從互聯網+從IT到DT》——阿里巴巴集團。
PS：講的不錯，有務虛也有務實。我雖然是2017年底開始看的，但是已經確認了擁有數據的公司，才能得以更好的生存的論點。
————————
好，不展開了，我們暫且先忽略提到的幾個問題，
畢竟我們討論的是Best Practice，在分析項目進展的過程中，大家要試着設身處地的思考。我分享的目的也是期望引發大家的思考，而不是告訴大家“以後”就這麼做~~~~，畢竟有些說法還是比較侷限個人且帶有一定的主觀意識。
這一次這個大企業所面臨的業務問題就是天貓旗艦店的會員如何與自己的線下的旗艦店會員系統打通，所以這個就是前面我鋪墊這麼久的的總結~~~~~
“讀者：“真的囉嗦啊，這人~~”：）”
天貓聚石塔官方是有成熟的解決方案——品牌會員中心，如下圖所示：
圖（五）
用戶的收益：
爲滿足品牌對會員管理的個性化需求，基於會員中心全渠道會員打通的能力爲品牌商實現會員註冊、會員綁定、積分累計、會員互動、權益兌換等業務流程，併爲品牌會員提供數據分析及精準營銷的能力。
名詞解釋：
入駐天貓，需要“入塔”，什麼意思？就是要入駐“聚石塔”，現在改名叫：阿里雲-零售雲。它與傳統的阿里共有云（金融雲、螞蟻金融雲）都在物理設施上有着完全物理隔離、數據隔離、網絡隔離等區別。完全是獨立的運營的，但也有一些聯繫！就是零售雲本質上底層使用的就是目前阿里的公有云的那一套技術環境，所以在操作上並無特別大的區別。
補充說明：
當你經營着天貓的旗艦店，天貓（零售雲）的數據是有非常嚴格的數據進出限制。基本可以理解爲：“天貓的用戶數據，阿里是絕對不允許你拿走的！”，這涉及相當多的數據安全和管控要求，大部分來自於國家的法律監管。
註釋：關於零售雲（阿里）平臺的介紹不放在這一篇裏面贅述，各位讀者如果有心想去了解下，可以移步https://cloud.tmall.com。平臺裏面確實擁有大量的“零售業務”的阿里特質的中間件服務。適當瞭解下也不耽誤多久時間~~~~
圖（六）
好了，不再囉嗦了，上主菜！第一次項目拜訪~~~~~~~【敲黑板，劃重點劃重點啦！！！】
第一次溝通是我們boss和公司cto直接駕車殺到客戶總部，據後來瞭解是全英文溝通環境，雖然有客戶的人兼着翻譯一些疑問，但現場仍然多少有些尷尬~~~，客戶由三波人（開發部門、業務部門、IAAS基礎架構部門），我們則是boss和cto。一個二十人的會議室坐的滿滿的。是個大場面~~~~~
Topic-1，項目背景、項目POC測試情況、天貓-JST平臺的情況（這裏指的是客戶對平臺的熟悉程度）
Topic-2，我們公司能給予的全棧支持彙報、公司目前的資質情況、技術人員的構成情況、雲服務的詳細清單和服務邊界、以及是否有服務的類似項目案例
Topic-3，交流話題三，項目啓動和交付時間。
Topic-4，交流話題四，整個項目背後實現的業務設計和調用邏輯（偏開發環節）
架構師事後思考旁白：
這一次拜訪不同的是以往都是隻有一個部門參與，這次客戶集中了三個部門參與。我們在這個拜訪過程中集中聊了業務的實現流程。可能跟CTO在場的關係，所以聊了比較多業務運行的。因爲個人行程問題會議沒參加，故我簡單的總結下。客戶對我們的感知除了基礎雲運維服務、業務的理解能力，還有我們的基於雲平臺的專業能力。
~鑑於我們對“零售雲”平臺並沒有特別的客戶案例背景，所以有相當多的技術問題需要了解和學習。所以這個時候我們找到了Partner去一起參與項目，但後面因爲Partner的時間安排不過來，後面就決定還是自己來了。但是非常感謝Partner的前期交流和支持！~
同時也意識到自己需要更多的測試來驗證自己“天馬行空”的架構設想，所以同步找了公司申請一部分的資金來進行平臺部分特×××的測試費用。
——————————————————————————————————————————————————————
做任何事情，不要忽略你或可能得到的公司的支持
——————來自於Allen
——————————————————————————————————————————————————————
協商完成後，用自己的支付寶註冊了賬號，嘗試開些機器學習docker開通和交付以及平臺相關特性。這裏我也貼一些熟悉平臺過程中的一些經歷“截圖”，平臺截圖如下：
圖（七）
適應過程中，我也邀請了我們的售後團隊參與其中，大家適應的效率非常高。最後確認了好幾次後給出“和公有云部署基本一樣”的結論。
這列幾個裏詳細區別——————————
1.沒有安全組的設置界面，因爲“零售雲”對於有着嚴格端口控制，平臺內部已經做了嚴格控制，如果你的業務是非默認端口，或者需要使用其他的端口，就需要申請了。如下所示
圖（八）
PS：聚石塔主機默認開通30001~30005端口提供使用，如果需要額外的端口需要提交端口開放申請。
2.默認給計算資源（ECS）提供2GB的DDOS×××防禦，與“公有云的5GB防禦”略有不同
3.可以部署自建的監控工具
4.有很多場景化的PAAS產品，這很“零售雲”，例如：御膳房、數據銀行、電子發票、阿里全渠道服務、會員運營平臺短信服務、頑兔多媒體等等
5.額外提供了一個類似傳統組網中DMZ區域的功能，但比DMZ區域強很多。即：御城河
6.最後就是本次項目中最核心的Docker服務—EWS
1）這裏我們把EWS的服務展開稍微帶一下，如下截圖所示：
圖（九）
圖（十）
2）這個容器(EWS)有一點不同，在提供統一容器管理和運維平臺的時候，他同時也提供了基於EWS的統一接入管理層，如下圖所示：
圖（十一）
3）從以上圖上可以看到，EWS在IAAS這一層上面做了一層控制層面的服務，ECS主機購買完成後，進行agent的安裝，容器即添加完成。所以我們在平臺上的設置時也證明這一點（如下圖操作說明所示）：
圖（十二）
4）我們再詳細看下EWS起某一個服務時候的配置界面：
圖（十三）
當我們使用了統一接入層，我們就無需額外購買【外網負載均衡】，相當於平臺提供了免費的負載均衡給你使用。當然也可以去接，只是有些業務不適合接外網的SLB，所以分析好業務需求很重要。默認一般使用EWS提供的LB
5）最後完成基礎的創建後，我們就可以看到控制檯看到這樣一個界面：
圖（十四）
6）點擊容器管理，進去就看到運行的容器了，就可以歡快的運行自己的業務了：（容器內部有對應的版本管理等一系列標準的功能模塊）
圖（十五）
回神過來，差不多一個禮拜，內部團隊徹底消化這個從零到一的過程，挑戰是有的，但很享受。
緊接接着回到項目中來，第二次溝通，我又因爲時間衝突沒有前往客戶現場進行溝通，（我這售前確實有點不稱職~~~）
Topic：
1.架構類似業務實現案例分享
2.項目預啓動
3.團隊人員角色互相認識
架構師旁白：
所以說，第二次會議是很重要的（幾乎可以與世界盃臨門一腳相提並論），因爲客戶關係、商務問題都經過了老闆親自帶隊搞定的，結果項目啓動時候，我這個架構師（項目經理）又不在。現在回想起來，着實有點讓我挺抱歉的。
~~~~好，現在開始了本章最最最最最最最核心的部分——“方案、報價”
【讀者：“我了個擦，這兄弟咋這麼嘮叨~~~~”】
一、方案怎麼寫？（Solution）
二、報價怎麼弄？（Cost-Effective）
三、實施文檔怎麼搞？（Sop）
四、項目流程怎麼管？（PM）
五、信息安全（Security）
六、災備預案
七、~~~
一大堆的問題，老闆丟給了我，現在想想當時自己的心態，着實有點“強”。是不是有這種“遇強則強”的能力呢？其實我也不知，emmm~~。總之那兩個禮拜幾乎天天到夜裏十二點，是非常正常的事情。也有幾次熬夜經歷!!
“待我一一詳細分解給大家”講講！
1）第一期技術方案框架：
核心需求：國內到國際延時優化、Docker（EWS）、Proxy反向代理
基礎架構業務流梳理：
Tmall————JST————Aliyun-Cloud（China）————Aliyun-Cloud（Global）————AWS（US）
1.1）第一期技術報價明細：
IASS資源：
Aliyun-Cloud(China)：24W
Aliyun-Cloud(Global)：12.4W
JST：21.1W
Total：57.5W
雲服務：147W
1.2）第一期方案報價Total：204.5W
1.3）第一期方案三年Total：601.5W
架構師旁白：
爲什麼服務費會有這麼多？達到1:3，請留意一點，外企用戶真的是非常認可服務提供商。而且所有的每一個環節的工作內容都需要被顆粒度到非常細節，並需要SLA保證、SOW的文件支持。所以外企做事情嚴謹（效率慢是有道理的）的工作態度，着實值得我個人學習。
在進行第一期技術方案&報價方案交流過程中，我和老闆也同時處理了關於《Vendor Service Questions》的問卷調查，因爲是第一次處理這樣的文件，所以多少是有點經驗不足和一點小興奮（全英文環境），被打回兩次後，終於通過了客戶的要求！！
我截部分脫敏問答給大家分享下。
圖（十六）
回到技術方案上，第一期如我和老闆所料，被打回了。技術細節要調整。原因是：基礎資源架構過於多餘和服務昂貴。希望將國內阿里雲、國外阿里雲刪減，並剔除部分服務內容。
圖（十七）
花了一天時間，技術框架和報價方案調整完畢，第二期技術方案框架：
核心技術匹配：Docker、Proxy反向代理
基礎架構業務流梳理：
Tmall————JST————AWS（US）
2）第二期技術報價明細：
IASS資源：
JST：21.1W
雲服務：41W
2.1）第二期方案報價總計：62.1W
2.2）第二期方案三年總計：174.3W
注意~！！！方案調整明細如下：
第二次與客戶負責人溝通交流，客戶部分工程師再次認爲有部分安全資源是多餘。
Why？因爲整體的業務的觸發來自於Tmall的平臺，JST本身業務不直接對外且點擊跳轉的流量全程已經是“加密”“合規”的流量，如果中間再加了安全層“檢測”，未知潛在的問題會有很多，客戶希望儘量避免增加額外開銷。
第二次刪減內容：Waf、態勢感知、服務器數量縮減
經過一天調整後，我們隨即再次約到客戶進行第三期交流資源配備方案：
第三期溝通後，業務流程如下：
Tmall————JST————AWS（US）
3）第二期技術報價明細：
IASS資源：
JST：5.6W
雲服務：25W
3.1）第二期方案報價總計：30.6W
3.2）第二期方案三年總計：91.8W
———————————————顯然“事不過三”是有道理的，果然到第三期方案的確認，我們達成了共識，並確認技術方案沒有其他問題，
整理下這個“一上一下”的落差的過程：
1、第一期方案，我們給出的是最大最理想的方案推薦
2、第二期方案，我們給出了一個合適體量且理想的方案推薦
3、第三期方案，我們給出了最小化上線的方案
註釋：
從600W到91.8W這個降幅確實大，但客戶說的總歸是沒錯的，所以客戶既然這麼要求，那作爲售前也好、銷售也好，滿足他，讓客戶感覺到爽舒服即可。
差不多的進行到這裏的時候，客戶公司的第四個部門（信息安全）找到我們（前面是基礎架構、法務、商務），要求審計我們的信息安全&合規性等情況，第二次審計工作的暴風雨來臨了~~
PS：還是一樣，我share部分脫敏後的內容。本文旨在分享經驗，而不是詳細的材料和文檔。請各位讀者留意，切勿私信找我索要相關文檔，因爲前面幾次的分享出現過很多次這樣索要的情況了，很顯然這些文檔我不能Share的。
1.Have company information security policies been published, approved, communicated and reviewed in the last 12 months?
2.Are passwords for systems containing scoped data hashed or encrypted in storage to protect from unauthorized disclosure?
3.Has the security incident response plan been tested in the last 12 months?
我大概“擼”了一遍後，總結下來問的問題比較通用，我能從文檔提交的內容中看出，客戶對所有類似我們這類MSP雲計算服務提供商都有一套這樣的流程去管控，故，我非常放鬆的去做了這個事情。總計調查130項，每項都需要詳細的文檔支持。不能簡單的回答“yes or no”
這個調查，我看了間接花了我大概12天的時間。最後比較波折的通過了。本來以爲結束了，開始部署實施了~~~
結果客戶的基礎架構架構部門再次找到我們，要我們給客戶提供的《XXX-項目零售雲平臺規劃》重新以客戶的文檔管理結構進行修正，
這是我們提供的文檔部分截圖如（已和諧）下：
圖（十八）
圖（十九）
這是客戶提供的文檔部分格式（已重度和諧）下：
圖（二十）
圖（二十一）
註釋：得到這個消息，我其實是拒絕的。。全新的文檔格式、方法論、排版。這一part，我直接跳過過程，總共開銷花了5天左右（當然是和其他工作同步進行的）
好了，還有實施進展中的一些技術攻堅，我放到下一次詳細分享，這裏對今天以上內容總結下架構師在這個項目的核心能力需求：
1.對業務的工作流的瞭解
2.雲平臺的實施部署經驗、特性和安全合規的理解
3.豐富的文檔（表格）製作功底
4.有足夠的耐心講業務實現細節闡述清楚，並形成文檔
與甲方用戶通過skype開會彙總：
1.技術架構細節：3次（≥60min）
2.堡壘機的使用和災備方案：2次（≥90min）
3.JST資源配置方案：8次（≥60min）
4.JST資源付款形式：2次（≥30min）
5.信息安全細節：4次（≥60min）
6.JST資源購買方式&付費開通：3次（≥120min）
PS:這些會議都是穿插在整個項目中的，全部由boss、我和我們服務團隊共同完成的。
最後補充幾個平臺監控的知識點：
1. EWS容器的擴容，只要計算資源（ECS）足夠，則可以通過任何ECS去添加到容器中運行，建議啓用EWS-LB服務，橫向平行添加即可，保證配置文件、版本一致即可。
2.監控對於用戶來講，可能更關心PV、UV等數字。對於運維來講可能更關心服務運行、ECS的機器運行情況，已經容量等問題。所以運維相對簡單（zabbix+wechat）對接即可。或者有自有的其他監控均可，保證響應時效即可。
業務的監控，JST平臺已經內置好了，如下圖所示：
一個熱愛生活的網工努力的故事
——————Allen在路上
QQ:549675970
Wechat：
Johnny_JunJun
QZONE:
http://user.qzone.qq.com/549675970
E-mail：
人生格言：越努力、越幸運