咱們是如何將 ToB 服務的交付能力優化 75%？

ToB 服務交付的方式分爲公有云部署和私有化部署兩種。其中，對成本敏感的中小企業每每採用公有云部署的方式，從而儘可能減小成本。客單價較高的大型企業、政府、銀行和事業單位，考慮到數據隱私、安全、合規等要求，每每採用私有化部署的方式。基於對公司營收的巨大貢獻，私有化部署便成爲了 ToB 企業的重中之重。

在衆多私有化部署的場景中，較爲複雜的是公有云廠商的專有云產品，之因此複雜，是由於這些廠商直接將公有云的核心功能打包進行私有化部署，和垂直類解決方案每每提供單一功能相比，其難度可想而知。京東雲的 JDStack正是採用了此模式。

存在的問題：部署耗時和成本

私有化部署的耗時，通常須要兩週左右的時間，給人感受耗時太長了。但從耗時角度去看的話，一個大單從開始到最終結項，歷時半年到一年是很正常的，這樣看，兩週的部署耗時佔比不到 10%，並不是項目交付耗時的主要矛盾點。

但若是兩週部署耗時的背後，是從研發團隊抽調了幾十名高級工程師加班加點，夜以繼日換來的，可能你們都沒法淡定了。假設一次大型央企的異地私有化交付項目，部署耗時 20 天，期間現場累計參與人數超過 60 人，現場峯值人數超過 30 人，30% 的人員是高級工程師，相關人員頻繁往返於兩地間，粗略估算一下成本，至少 50 萬，這樣的模式，只能是在起步階段交點學費吸收點教訓。

在部署耗時的優化上，還須要考慮客戶所在行業的特殊性，尤爲是關係國計民生的領域，互聯網的快速迭代，越變越美並不必定適用。咱們能夠建議在入場前將咱們須要的資源準備完畢，但也只能是建議。對於在現場部署過程當中，諸如各類審批流程和要求，甲方工做人員天天的工做時長，基於安全因素對數據傳輸和拷貝的限制等等，都會影響最終的部署耗時。

所以，相比於部署耗時的優化，對部署成本的控制更現實一些。若是部署工做是由外包來進行的，且過程當中不須要公有云廠商的技術支持，那麼只要部署耗時控制在客戶可接受的範圍便可，廠商也會所以具有大規模批量實施的能力。

存在的問題：質量缺陷

什麼叫作質量缺陷呢？簡單來講，在你完成一套專有云產品的私有化部署以後，最嚴重的狀況，可能這套系統徹底沒法使用，大部分時候，都會有一小部分功能沒法使用。

質量缺陷的影響是什麼？最糟糕的情形莫過於你成功的將你的客戶轉化成你的測試團隊，從你部署的系統中，源源不斷的反饋各類問題，進而逐漸失去了客戶對你的信任。

既然是在公有云驗證過的產品，爲何私有化部署還會出現這麼多的功能不可用（或者稱之爲質量缺陷）？我以爲有以下兩點：

複雜度：從廠商角度看，公有云產品由數百個模塊構成，對外提供幾十種功能，涉及到從網絡，硬件，操做系統，程序，配置，上下游依賴關係，數據等方方面面，這樣一個在公有云廠商中每每是多個部門上千人耗費數年打造的產品，如今讓剛成立的交付團隊來搞定一個由上千人參與的複雜系統，其難度可想而知，僅僅是可以熟練使用公有云產品提供的這幾十種功能，就須要花費很長時間，更況且還要面對數百個模塊，數百種配置文件，數百個模塊間的複雜依賴，不一樣的開發語言，幾乎涵蓋了業界全部主流的開源軟件等，以及爲了一個小功能牽一髮而動全身的痛苦。

兼容性：從客戶角度看，不一樣行業不一樣客戶，真可謂是千人千面。基礎設施的供應商不一樣，組網協議不一樣，硬件的品牌型號規格不一樣，操做系統和內核版本不一樣，登陸和認證方式不一樣，等保要求不一樣，資源提供方式不一樣，還有各類極小衆的東西，好比很是生僻的數據庫，十幾年前的軟件，小衆的編程語言等等。專有云產品爲了兼容這些差別，必然須要臨時開發一些定製化功能，這也成了質量缺陷的重災區。

存在的問題：可運維性

爲何在公有云環境下你們反饋良好的產品，在私有化部署中被如此吐槽，主要是由於在公有云場景下，問題被化整爲零了。

舉例來講，各個產品作的都很不錯，每一個產品平均僅存在一個部署的小問題，這對於一個研發了數十個模塊，擁有百十人規模的團隊來講，已是不錯的成績了。但一樣的問題，放在私有化環境下，就很差玩了，五十個產品，每一個產品部署的時候都有一個小問題，而交付團隊人員少，對系統的掌握程度也不如研發團隊，你讓他怎麼辦？

某雲提供的運維手冊，多達 2100 頁，80MB 的體積，我都不知道本身上次看這種大部頭書是何時了。固然，文檔也是交付的必要內容之一，從這個角度來講，某雲在國內作的仍是很好的。

如何解決存在的問題呢？

經過下降部署環節的技術難度，實現一鍵部署的能力，將交付工做交給外包團隊，從而具有大規模批量交付的能力。整個的過程大體以下：

• 第一步，對部署流程進行原子化拆分；
• 第二步，對每個原子化的部署步驟進行標準化改造，例如以統一的全局錯誤碼進行異常輸出，便於查找解決方案；
• 第三步，對每個部署步驟均進行屢次的部署可靠性驗證和回滾驗證，確保每個原子的部署操做具有較高的成功率，同時回滾後不會有任何影響二次部署的殘留物；
• 第四步，爲每個原子操做提供功能測試能力，確保僅在該操做正確無誤後，纔會進入下一個操做環節；
• 第五步，梳理各個原子操做間的串並行關係和依賴關係，從而生成部署時序圖，進而基於部署時序圖打造出一鍵部署能力。

這裏須要注意的是，一鍵部署並不等於全自動化部署，在至關長的時間，可能也沒法作到 100% 的全自動化部署，不少環節尤爲是前置依賴仍是須要客戶配合的。

業內衆多廠商也在提一體機的概念，一體機的解決方案確實更好，理想狀況下，把一批機器放到客戶的機房，加電並設置網絡就可使用了，並且公有云廠商的硬件成本更有優點，客戶也能看到 " 實物」，只是在當下，主要是在企業客戶中使用。

值得注意的關鍵點

部署流程圖，是整個解決方案中最重要的環節，沒有之一。相似於工程施工圖，將總體工程從無到有的全部過程、環節、工藝標準、施工要求、依賴和注意事項，進行完整的說明。部署流程圖決不能止步於模塊部署的內容，而是要涵蓋從網絡的實施、硬件的上架、操做系統的安裝到部署服務的全部環節，這樣才能保證一鍵部署的成功率。找一個徹底空白的環境，不斷的從零重建，相信你們均可以梳理出完善的部署流程圖。在這裏再次提醒你們，要覆蓋全部環節，尤爲是那些你從未接觸的部分，以我爲例，在交換機參數配置上就吃過好幾回虧。

功能驗證，以客戶的定製化需求爲例說明，研發開發完畢自測經過，測試也經過了，運維驗證經過後打包發版，交付發現功能上有缺陷，這時候，研發可能就憤怒了，有問題，怎麼不早說！所以，功能驗證是須要整合產品、研發、測試、運維、安全、法務、合規、交付和客戶各類角色對功能驗收的要求，便於及早發現問題，減小返工的成本。具體來講，在每一個原子操做執行完畢後，對涉及到的功能、接口、頁面進行充分的驗證，在每一個階段完成後，也要對該階段的組合功能進行驗證。同時，對於相關模塊的實例數量，實例規格，依賴，健康狀態，配置正確性，錯誤日誌以及性能指標等進行檢查，以及相關的配置是否真正生效。多管齊下，確保可以準確判斷每一個原子操做執行的正確性以及在異常狀況下儘量給出異常緣由。

一致性維護，經過 Puppet 等配置管理工具來確保服務器配置的一致性，如 NTP、DNS、YUM、信任關係、日誌統一收集、工具列表和版本以及系統參數，避免手工維護缺失和遺漏致使的質量缺陷問題。例如在部署階段，NTP 時鐘不一樣步致使的趨勢圖沒法展現實時數據，進而耗費了很是大的人力來進行問題定位。

檢查清單，主要是對標準規範、統一配置、最佳實踐，易錯問題且會致使嚴重後果的問題再次確認，避免後期的大規模返工或者故障。例如，配置變動後須要重啓服務器才能真正生效的策略，不只要檢查其配置是否生效，還須要在相關步驟執行完畢後，確保檢查服務器的運行時間；經過 Systemd 拉起的服務，要檢查其設置了開機自動啓動；系統安裝後，要確保全部磁盤均爲 XFS 格式且所有寫入系統配置中；全部用戶定製化內容，所有須要再次檢查是否生效，如不一樣用戶要求的超賣比。

虛擬化和啓動自檢，將模塊實現虛擬化部署，從而可以和硬件、組網協議、IP 地址等用戶資源解耦，實現鏡像在多套環境下的固化，從而大幅提高模塊部署的成功率。短期內沒法實現虛擬化部署的模塊，則必須實現啓動自檢功能，在物理機或者虛擬機環境下啓動前，須要檢查環境是否知足本身的要求，例如 JAVA 是否可用，版本是否符合要求，Swap 是否關閉等。

全局標準化，以服務啓停方式爲例，所有收斂爲 Systemd 方式拉起服務，用戶僅須要知道進程名就能夠實現任意服務的啓停操做，日誌切分則所有由程序自行實現，不經過外部的 crontab 來進行，這樣既下降了複雜度，也大幅提高了可運維性。

插件化，對於專有云產品的定製化功能，儘可能由系統經過插件的形式來支持，避免直接修改相關代碼致使後期的不可維護。以登陸功能爲例，目前全部的主流公有云，都支持多種登陸方式，這樣，在專有云模式下，多增長一種登陸方式，其對系統總體的影響就很是小了。

最終效果

經過一鍵交付總體解決方案的落地，私有化部署的成功率大幅提高，咱們目前已經能夠確保交付後全部核心功能都可正常使用。同時，私有化部署的耗時，在咱們可控的階段，控制在 3 天內。

另外，咱們的兄弟團隊，提供 SaaS 化服務的私有化交付，複雜度略低一些，在採用咱們的方案，半年間每個月交付能力提高了 3.6 倍，從每個月 3 套提高到每個月 14 套。

咱們是如何將 ToB 服務的交付能力優化 75%？

下一步發展計劃

在解決私有化部署過程當中的問題後，接下來的重點工做是提高系統的自動化運維水平，下降系統的運維成本，逐步將運維工做從廠商交接給客戶的運維團隊。主要在兩個方面發力：

操做平臺，將平常運維工做中的各種場景（包括但不限於平常巡檢，故障處理，版本升級、預案執行、問題定位、配置變動、補丁升級），進行標準化的文檔改造並錄入到操做平臺，而後按照使用頻率和重要性逐步將各種場景進行自動化和智能化的升級，減小運維人員須要介入的頻次。

可視化，運維人員的主要工做從執行變爲監督，所以可視化會變爲主要的使用工具。經過各種大屏，將系統的運行狀態、健康度、核心指標、容量數據等關鍵信息進行實時展現，便於運維人員瞭解狀況。

若是您想了解更多關於JDStack 專有云，歡迎點擊「連接」閱讀。

歡迎點擊「京東雲」瞭解更多精彩內容