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

在眾多私有化部署的場景中，較為復雜的是公有云廠商的專有云產品，之所以復雜，是因為這些廠商直接將公有云的核心功能打包進行私有化部署，和垂直類解決方案往往提供單一功能相比，其難度可想而知。國內采用該種模式的有京東云的 JDStack，金山云的 KingStack，騰訊云的 TCE 和阿里云的 Apsara Stack。

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

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

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

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

因此，相比于部署耗時的優化，對部署成本的控制更現實一些。如果部署工作是由外包來進行的，且過程中不需要公有云廠商的技術支持，那么只要部署耗時控制在客戶可接受的范圍即可，廠商也會因此具備大規模批量實施的能力。

2. 存在的問題：質量缺陷

什么叫做質量缺陷呢？簡單來說，在你完成一套專有云產品的私有化部署之后，最嚴重的情況，可能這套系統完全無法使用，大部分時候，都會有一小部分功能無法使用。

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

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

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

兼容性：從客戶角度看，不同行業不同客戶，真可謂是千人千面?；A設施的供應商不同，組網協議不同，硬件的品牌型號規格不同，操作系統和內核版本不同，登錄和認證方式不同，等保要求不同，資源提供方式不同，還有各種極小眾的東西，比如非常生僻的數據庫，十幾年前的軟件，小眾的編程語言等等。專有云產品為了兼容這些差異，必然需要臨時開發一些定制化功能，這也成了質量缺陷的重災區。

3. 存在的問題：可運維性

為什么在公有云環境下大家反饋良好的產品，在私有化部署中被如此吐槽，主要是因為在公有云場景下，問題被化整為零了。

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

某云提供的運維手冊，多達 2100 頁，80MB 的體積，我都不知道自己上次看這種大部頭書是什么時候了。當然，文檔也是交付的必要內容之一，從這個角度來說，某云在國內做的還是很好的。

4. 如何解決存在的問題呢？

通過降低部署環節的技術難度，實現一鍵部署的能力，將交付工作交給外包團隊，從而具備大規模批量交付的能力。整個的過程大致如下：

第一步，對部署流程進行原子化拆分；

第二步，對每一個原子化的部署步驟進行標準化改造，例如以統一的全局錯誤碼進行異常輸出，便于查找解決方案；

第三步，對每一個部署步驟均進行多次的部署可靠性驗證和回滾驗證，確保每一個原子的部署操作具備較高的成功率，同時回滾后不會有任何影響二次部署的殘留物；

第四步，為每一個原子操作提供功能測試能力，確保僅在該操作正確無誤后，才會進入下一個操作環節；

第五步，梳理各個原子操作間的串并行關系和依賴關系，從而生成部署時序圖，進而基于部署時序圖打造出一鍵部署能力。

這里需要注意的是，一鍵部署并不等于全自動化部署，在相當長的時間，可能也無法做到 100% 的全自動化部署，很多環節尤其是前置依賴還是需要客戶配合的。

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

5. 值得注意的關鍵點

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

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

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

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

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

全局標準化，以服務啟停方式為例，全部收斂為 Systemd 方式拉起服務，用戶僅需要知道進程名就可以實現任意服務的啟停操作，日志切分則全部由程序自行實現，不通過外部的 crontab 來進行，這樣既降低了復雜度，也大幅提升了可運維性。

插件化，對于專有云產品的定制化功能，盡量由系統通過插件的形式來支持，避免直接修改相關代碼導致后期的不可維護。以登錄功能為例，目前所有的主流公有云，都支持多種登錄方式，這樣，在專有云模式下，多增加一種登錄方式，其對系統整體的影響就非常小了。

6. 最終效果

通過一鍵交付整體解決方案的落地，私有化部署的成功率大幅提升，我們目前已經可以確保交付后所有核心功能均可正常使用。同時，私有化部署的耗時，在我們可控的階段，控制在 3 天內。

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

7. 下一步發展計劃

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

• 操作平臺，將日常運維工作中的各類場景（包括但不限于日常巡檢，故障處理，版本升級、預案執行、問題定位、配置變更、補丁升級），進行標準化的文檔改造并錄入到操作平臺，然后按照使用頻率和重要性逐步將各類場景進行自動化和智能化的升級，減少運維人員需要介入的頻次。
• 可視化，運維人員的主要工作從執行變為監督，因此可視化會變為主要的使用工具。通過各類大屏，將系統的運行狀態、健康度、核心指標、容量數據等關鍵信息進行實時展示，便于運維人員了解情況。