Categories
程式開發

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


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

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

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

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

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

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

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

我們是如何將 ToB 服務的交付能力優化 75%? 1

存在的問題:質量缺陷

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

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

既然是在公有云驗證過的產品,為什麼私有化部署還會出現這麼多的功能不可用(或者稱之為質量缺陷)?我覺得有如下兩點:

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

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

存在的問題:可運維性

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

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

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

如何解決存在的問題呢?

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

  • 第一步,對部署流程進行原子化拆分;

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

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

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

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

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

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

我們是如何將 ToB 服務的交付能力優化 75%? 2

值得注意的關鍵點

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

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

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

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

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

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

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

最終效果

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

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

我們是如何將 ToB 服務的交付能力優化 75%? 3

下一步發展計劃

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

操作平台,將日常運維工作中的各類場景(包括但不限於日常巡檢,故障處理,版本升級、預案執行、問題定位、配置變更、補丁升級),進行標準化的文檔改造並錄入到操作平台,然後按照使用頻率和重要性逐步將各類場景進行自動化和智能化的升級,減少運維人員需要介入的頻次。

可視化,運維人員的主要工作從執行變為監督,因此可視化會變為主要的使用工具。通過各類大屏,將系統的運行狀態、健康度、核心指標、容量數據等關鍵信息進行實時展示,便於運維人員了解情況。