ToB 服務(wù)交付的方式分為公有云部署和私有化部署兩種。其中，對成本敏感的中小企業(yè)往往采用公有云部署的方式，從而盡量減少成本?？蛦蝺r(jià)較高的大型企業(yè)、政府、銀行和事業(yè)單位，考慮到數(shù)據(jù)隱私、安全、合規(guī)等要求，往往采用私有化部署的方式?；趯緺I收的巨大貢獻(xiàn)，私有化部署便成為了 ToB 企業(yè)的重中之重。

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

1. 存在的問題：部署耗時(shí)和成本

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

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

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

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

2. 存在的問題：質(zhì)量缺陷

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

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

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

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

兼容性：從客戶角度看，不同行業(yè)不同客戶，真可謂是千人千面。基礎(chǔ)設(shè)施的供應(yīng)商不同，組網(wǎng)協(xié)議不同，硬件的品牌型號規(guī)格不同，操作系統(tǒng)和內(nèi)核版本不同，登錄和認(rèn)證方式不同，等保要求不同，資源提供方式不同，還有各種極小眾的東西，比如非常生僻的數(shù)據(jù)庫，十幾年前的軟件，小眾的編程語言等等。專有云產(chǎn)品為了兼容這些差異，必然需要臨時(shí)開發(fā)一些定制化功能，這也成了質(zhì)量缺陷的重災(zāi)區(qū)。

3. 存在的問題：可運(yùn)維性

為什么在公有云環(huán)境下大家反饋良好的產(chǎn)品，在私有化部署中被如此吐槽，主要是因?yàn)樵诠性茍鼍跋?，問題被化整為零了。

舉例來說，各個(gè)產(chǎn)品做的都很不錯，每個(gè)產(chǎn)品平均僅存在一個(gè)部署的小問題，這對于一個(gè)研發(fā)了數(shù)十個(gè)模塊，擁有百十人規(guī)模的團(tuán)隊(duì)來說，已經(jīng)是不錯的成績了。但同樣的問題，放在私有化環(huán)境下，就不好玩了，五十個(gè)產(chǎn)品，每個(gè)產(chǎn)品部署的時(shí)候都有一個(gè)小問題，而交付團(tuán)隊(duì)人員少，對系統(tǒng)的掌握程度也不如研發(fā)團(tuán)隊(duì)，你讓他怎么辦？

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

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

通過降低部署環(huán)節(jié)的技術(shù)難度，實(shí)現(xiàn)一鍵部署的能力，將交付工作交給外包團(tuán)隊(duì)，從而具備大規(guī)模批量交付的能力。整個(gè)的過程大致如下：

第一步，對部署流程進(jìn)行原子化拆分；

第二步，對每一個(gè)原子化的部署步驟進(jìn)行標(biāo)準(zhǔn)化改造，例如以統(tǒng)一的全局錯誤碼進(jìn)行異常輸出，便于查找解決方案；

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

第四步，為每一個(gè)原子操作提供功能測試能力，確保僅在該操作正確無誤后，才會進(jìn)入下一個(gè)操作環(huán)節(jié)；

第五步，梳理各個(gè)原子操作間的串并行關(guān)系和依賴關(guān)系，從而生成部署時(shí)序圖，進(jìn)而基于部署時(shí)序圖打造出一鍵部署能力。

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

業(yè)內(nèi)眾多廠商也在提一體機(jī)的概念，一體機(jī)的解決方案確實(shí)更好，理想情況下，把一批機(jī)器放到客戶的機(jī)房，加電并設(shè)置網(wǎng)絡(luò)就可以使用了，而且公有云廠商的硬件成本更有優(yōu)勢，客戶也能看到"實(shí)物”，只是在當(dāng)下，主要是在企業(yè)客戶中使用。

5. 值得注意的關(guān)鍵點(diǎn)

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

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

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

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

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

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

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

6. 最終效果

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

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

7. 下一步發(fā)展計(jì)劃

在解決私有化部署過程中的問題后，接下來的重點(diǎn)工作是提升系統(tǒng)的自動化運(yùn)維水平，降低系統(tǒng)的運(yùn)維成本，逐步將運(yùn)維工作從廠商交接給客戶的運(yùn)維團(tuán)隊(duì)。主要在兩個(gè)方面發(fā)力：

• 操作平臺，將日常運(yùn)維工作中的各類場景（包括但不限于日常巡檢，故障處理，版本升級、預(yù)案執(zhí)行、問題定位、配置變更、補(bǔ)丁升級），進(jìn)行標(biāo)準(zhǔn)化的文檔改造并錄入到操作平臺，然后按照使用頻率和重要性逐步將各類場景進(jìn)行自動化和智能化的升級，減少運(yùn)維人員需要介入的頻次。
• 可視化，運(yùn)維人員的主要工作從執(zhí)行變?yōu)楸O(jiān)督，因此可視化會變?yōu)橹饕氖褂霉ぞ摺Ｍㄟ^各類大屏，將系統(tǒng)的運(yùn)行狀態(tài)、健康度、核心指標(biāo)、容量數(shù)據(jù)等關(guān)鍵信息進(jìn)行實(shí)時(shí)展示，便于運(yùn)維人員了解情況。