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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 如何解決存在的問(wèn)題呢？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6. 最終效果

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

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

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

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

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