在互聯網早期迅速發展時，相關領域企業更多注重于擴展業務，為了迅速占領市場，往往會投入較高的成本。然而，随着互聯網人口紅利逐漸消退，以及近幾年的疫情影響，越來越多企業開始重視成本管理，從“粗放式經營”轉變為“精細化運營”模式，成本優化成為企業重點關注事項。

本文将從一位中型企業運維總監的視角來展現一個較完整的成本優化實戰案例，希望為讀者提供可參考借鑒的成本優化思路。

本文的主人公小王（化名）在某電商公司擔任運維總監，他所在公司自建 IDC 機房，其中總共 1000 台業務服務器（在線 離線），由 3 名運維人員管理。機器規格大部分為 8 核 32G，整體 CPU 利用率僅 10% 左右，每年花銷在 1000 萬以上。

CTO 希望在現有業務市場條件不變的情況下，以業務穩定性為基本前提，将 IT 成本降低至少 30%，且将此定為小王今年的 KPI。

收到任務後，小王先将 IT 成本拆解為算力成本和人力成本兩個部分。

目前 IT 成本主要由自建 IDC 機房承載，存在如下問題：

• 自建 IDC 機房機器數量缺乏彈性機制，不便于後期對算力做靈活伸縮；
• 自建 IDC 機房機器進入攤銷末期，機型老舊且故障頻繁，運維人力成本高。

基于以上分析，考慮到公有雲機型更新便捷、基本免維護、可彈性的特點，小王計劃先将業務遷移上雲。

目前雲廠商主要提供了預留實例（包年包月）、按需實例（彈性）、競價實例三種方式：

• 包年包月：主要針對中長期穩定需求，優點是價格整體比較低，缺點是資源必須長期持有，靈活性差；
• 按需實例：針對短期彈性需求，按秒計費，靈活精準，避免浪費，但價格比較高；
• 競價實例：以一定幅度的折扣購買，但可能會随時被系統自動回收的實例。價格最低可達到按需實例價格的 10%。由于此類實例随時可能被搶占，所以需要部署的服務應當盡量為無狀态服務且有完備的保活和流量調配機制。

為确保系統穩定且盡量減少研發感知，小王先後采取了以下幾項措施：

1. 将大部分無狀态在線服務和一部分離線服務所在的大概 800 台機器，以包年包月的形式遷移到同等配置的公有雲機器上；
2. 騰退相應私有機房機器，并将公有雲與私有機房通過專線打通。這樣既能保證在線服務上雲之後的快速伸縮，又能兼顧數據傳輸成本及安全方面的考量；
3. 接入公有雲相應的部署發布、監控告警、限流自愈等附屬功能，從而節省出一個運維的人力。

在上雲過程中，小王一方面根據公司需求對比多家公有雲廠商後選擇最匹配的雲資源，另一方面将 CPU 品牌從 Intel 換成 AMD，兩者疊加後，降低了 7% 左右的成本。

完成混合雲改造後，小王進一步将算力成本拆解為服務算力成本和基礎設施資源成本：

• 服務資源指業務服務程序所消耗的 CPU、内存、磁盤、帶寬等算力資源，相應成本取決于業務特征、業務運營行為、研發水平等多個因素；
• 基礎設施資源成本指大數據、存儲、中間件等底層組件和平台的成本。

結合公司目前的成本占比情況，服務算力成本占了其中的 60% 以上。

算力成本來源占比如下圖所示：

圖 1 算力成本來源占比

基于二八原則，小王決定以運維第三方視角，本着少侵入業務的前提，集中精力節省服務算力成本。

小王首先檢查公司已上雲的典型業務的算力特征。由于公司業務偏計算型，所以他選擇通過常見性能指标 CPU 利用率來觀察算力消耗情況，發現公司業務常在中午 12 點左右和晚上 8 點左右迎來算力消耗高峰。

如下圖所示：

圖 2 CPU 利用率指标算力圖

根據上面的業務算力模型，小王發現即使業務完全處于高峰，所需要的機器數也不到現有數量的 80%。在公有雲彈性的保證下，小王分階段釋放了曆史高峰未觸及的 200 多台 8 核 32G 包年包月冗餘機器，節省了 20% 左右成本。

在粗略去除明顯冗餘算力後，小王觀察到業務算力即使在忙時利用率也不高，尤其是内存閑置較為嚴重。

接下來小王和業務一起進行了一次壓測，最後得出業務機器規格保持在 8 核 3G 的配比，使用率相對均衡。而公有雲機器 CPU 核數和内存配比一般是 1:2 或 1:4 的固定比例，所以小王按照公有雲廠商的标準配置先将機器規格從 8 核 32G 降為 8 核 16G，節省了 20% 的成本。

第一階段的優化手段較為常規，取得了一些效果，小王總共節省了 40% 左右的成本，以較低成本吃到了第一波降本紅利。

基于第一階段的優化經驗，小王總結出以下待改進點：

1. 根據 CPU 消耗所衡量出的算力消耗情況和業務的實際情況之間仍有一定差距。比如，經常會出現 CPU 消耗偏高但實際業務依然穩定、無需擴容的情況，這說明需要更加精準的算力度量指标。
2. 業務算力模型明顯有波峰波谷，但是資源消耗的模型并未較好匹配，雖去除了未觸達的冗餘算力，但仍是以最高峰配置全時段占用算力，導緻閑時浪費明顯。
3. 公有雲機器規格中，CPU 與内存的比例有明顯限制，導緻算力資源使用無法進一步均衡，造成浪費。

基于上述分析，小王分析出需要依次解決的三個問題：

1. 以更精準的業務指标，替代以 CPU 消耗為核心的物理指标；
2. 持續采集該指标，精準匹配算力波動曲線并實時聯動擴縮容；
3. 獲得更匹配實際業務的機器算力規格，提高資源利用率。

針對以上問題，小王對業界現有解決方案進行了調研，發現并無能直接借鑒的普适方法和經驗，大部分實現方式都與特定業務場景綁定且需要研發深度參與。

為了能按期實現目标，小王嘗試使用雲原生基礎治理平台 SchedulX 開始第二階段的深入優化。

小王借助 SchedulX 系統，在不讓業務大規模改造的前提下，引入了 MetricsQPS 指标。該指标将 QPS 中不同請求對機器資源占用的時長納入了考量，通過對 QPS 按時長進行分段并配以相應的權重最終拟合而成。相對于普通 QPS 指标，MetricsQPS 更能精确地反映出業務實際負載情況。該指标基本計算公式如下：

圖 3 MetricsQPS 公式

小王利用這一指标執行了第一階段的“優化低頻冗餘算力”操作，再次下線 60 台機器，節省約 10% 成本。

接下來，小王比較了公有雲 8 核 16G 包年包月價格（約 600 元 / 月）與彈性機器價格（約 1.20 元 / 小時），發現包月機器 1 天的費用是彈性機器 30 天費用的 70% 左右。

由此推斷，對于每天峰值時長低于總時長 30%（約 8 小時）的機器，可以用彈性代替包年包月。

如下圖所示：

圖 4 短時高峰彈性代替包年包月

對于其它規格的服務器，小王延伸推導如下:

設彈性擴容一台同規格機器 1 小時的成本為 Y 元，高峰時總機器數為 K1 台，高峰時段為 H 小時，包年包月合理機器數為 K2 台，則從省成本角度考慮，需要保證滿足以下條件：

（K1-Ｋ2）* H * Y < （X / 30）*（K1 -Ｋ2） => H * Y < (X / 30)

由于 X、Y 均為相對固定值，所以按照此不等式可計算出适合彈性的業務峰值理論時長。于是，在留出一定的安全邊際的前提下，小王借助 SchedulX 的度量和彈性能力再下線 50 多台機器，節省約 10% 成本。

面對剩餘的包年包月機器，小王發現還是有優化空間的。從波形覆蓋面積上來看，空洞波形面積（藍色陰影面積）至少占到紅框中矩形面積的 1/3 以上，如圖所示：

圖 5 包年包月算力低峰共享

小王計劃将這部分機器利用起來，作為公司整體的共享資源池，供公司其它周期性及離線任務進行錯峰使用。因為涉及面較廣，小王請 CTO 一起出面推動協調，最終借助 SchedulX 系統貼合業務算力模型曲線實時擴縮容，共節省了 10% 的成本。

小王在完成以 MetricsQPS 指标按橫向時序的算力優化後，再次将注意力集中到機器規格對業務需求的精準匹配上。

小王采用了公有雲上的高規格裸金屬服務器，借助 SchedulX 對公有雲裸金屬原材料進行了二次切割。雖然公有雲上的裸金屬也是按固定算力資源比例售賣，但是經過切割後的算力規格能夠精準匹配業務 8 核 3G 的規格需求。同樣是 500 台機器，相對原來的 8 核 16G 雲主機，經過切割得出的 8 核 3G 機器能節省超過 15% 的成本。

做完機器規格的精準裁剪匹配後，現在基本上單體算力規格和時序算力數量與類型都已經完成了優化，小王又将目光放到了算力的地域差異方面。他了解到公有雲上西部機房同規格的算力比東部機房更便宜，通過将近 100 台離線服務器遷移到西部機房，同時借助 SchedulX 快速大批量數據遷移的能力實現東數西算，節省成本 10%。

第二階段基本解決了第一階段遺留的精準度量算力、精準匹配模型、精準切割規格三大問題。兩階段下來，CPU 利用率上升至 60%，總共節省成本将近 70%，實現并超出 CTO 預期。

綜合兩階段，小王的整體優化流程如下圖所示：

圖 6 降本流程圖

為了順利推進成本優化，小王除了設計操作各種算力增減外，還借助了以下一些配套措施和系統：

1. 需要明确算力衡量指标體系，前期可以粗略使用 CPU 利用率等系統指标，後期需要借助精準的業務指标，比如 QPS 及單請求的耗時結合的複合指标。
2. 降本過程需要有較完備的監控告警系統及容災 SOP，防止在優化過程中出現意外情況。比如在優化低頻冗餘算力環節，小王在下機器的時候，提前根據 CPU 等指标設置好了擴縮容策略，在系統保持一周無異常後才将下線的機器清退。
3. 為了精準量度業務算力，需要搭配壓測系統及方案。前期為盡量減少業務投入成本，主要是基于以下思路來操作：測試環境 ->線上日志回放 ->mock 調用接口 ->采集算力衡量指标 ->逐步放大調用壓力 ->響應超時的服務器達到一定比例時結束壓測。後期可以逐步叠代為全鍊路壓測，從網關到調用鍊路到存儲全隔離的形态，衡量效果會更精準，當然相應研發成本和投入也會更重。
4. 為了充分體現每一步的優化成果，需要有成本看闆，對每一階段優化前後的機器資源和成本消耗進行環比或橫比展示。成本看闆主要針對中高層人群，所以信息要簡明扼要，成本信息突出。

小王在推進降本過程中，還總結了一些遇到的非技術問題及主要解法：

• 項目切入時機問題：
• 降本工作不僅僅是運維部門或基礎架構部門的工作，同時還需要成本管理部門、财務部門、業務部門等多部門協同。降本工作的推進也會影響穩定性保障、業務研發等工作，所以降本工作需要先成為公司的重點項目或者産研團隊的 KPI。
• 由于改造的投入成本和機會成本都很高，所以要求改造帶來的收益要足夠大。
• 立項及項目團隊組建：
• 公司确定降本工作是重點項目後，還需要在公司層面或者産研層面進行正式立項，指定項目負責人、項目技術負責人等，并明确項目的目标，以及項目人員的溝通。原則上所有受降本影響的部門都要派出自己的代表，實際可以确保所有的職能都派出代表，這樣既能控制項目組規模又有足夠的代表性。
• 比較好的項目組核心人員組合是，由收益最大或工作量最大的部門作為項目的負責方并派出項目負責人，受影響最大的部門派出技術負責人。
• 成本變革問題：
• 雲化、彈性等都會帶來新的預算管理和成本核算方式，需推動公司内部成本管理機制升級。在項目早期，就要對降本項目的優化效果進行量化。隻有明确的、量化的目标和明顯的收益，方能為各個部門提供足夠動力配合推進。
• 項目推進中的故障問題：
• 項目在推進的過程中，如果出現嚴重故障，會極大影響公司對項目的信心以及各部門的支持力度，最壞的情況下甚至會導緻項目流産。項目組成員一定要包括試點業務的相關負責人或代表。試點業務要适中，過小的業務沒有代表性，而如果業務過大，一旦出現問題，後果會很嚴重。
• 在試點業務成功實踐之後，再推動到公司的核心業務。核心業務有足夠的代表性和說服力，隻有在核心業務落地才可能在全公司全面落地。核心業務落地的關鍵點是做好包括回滾方案在内的各項預案，做到即使出問題也不要影響到核心業務。這也需要項目組與核心業務密切配合，核心業務的負責人或代表最好就是項目負責人或者技術負責人。
• 項目如何推廣到全公司：
• 項目在單個業務落地後，需要繼續往全公司推廣，此時會遇到各個部門的支持問題，需要先找一兩個典型業務作為标杆，等标杆業務有了效果再繼續往其他業務推廣。
• 通過技術沙龍等方式對項目進行介紹和宣傳，讓标杆客戶一同參與宣講，并廣泛邀請潛在的業務部門參與。
• 項目在公司 30% 以上的業務推廣開後，可以尋求高層的支持加快項目的推廣，有了試點效果後高層更樂于協助推進。
• 項目完成後的日常保障：
• 項目完成後需要由職能團隊負責日常的維護和保障工作。通常會放到項目負責人所屬的團隊，但也可能按照項目成員所在部門進行保障分工。總的原則是，項目推進期間公司比較重視參與的人也多可以跨職能，而項目完成後項目組成員多數回歸原團隊，保障工作分配盡量契合原有職能分工。
• 項目的收益分配問題：
• 針對項目收益分配，比較好的做法是把各種收益進行拆分，然後再依據分别的貢獻進行分配。比如項目整體榮譽歸項目組、項目管理的收益歸項目負責人及其所在部門、項目技術上的收益歸技術負責人及其所在部門、各模塊的收益歸模塊負責人及其部門。在晉升時也需要項目負責人協調好各自的邊界，避免相互沖突的情況。
• 項目負責人及其所在部門要把更多的利益分給項目組中其他的部門，從而更好地激勵大家積極參與之後的其他改造與建設項目。

回顧整個降本之路，除了之前總結的執行中技術 / 非技術的問題外，還有以下幾個點值得提出：

• 在推動層級方面，公司成本優化總體來說是一把手工程，過程中難免需要各部門的協同配合及利益分攤，所以由 CTO 發起并提供支持是小王完成成本優化目标的重要前提。
• 在優化手段方面，和小王相同場景的公司在第一階段通過一些成熟的業界通用做法就能取得還不錯的降本效果，可以此作為讓全公司認可降本價值的敲門磚，這樣在第二階段引入外部系統做深入優化就能更順利。
• 在優化節奏方面，建議先從成本占比、優化難度、優化效果、是否核心等維度對業務進行排序打分，先從成本占比大，優化難度小，優化效果明顯、非核心的業務開始優化。

在互聯網下半場的今天，降本增效作為企業大勢所趨，甚至上升到了公司核心競争力的層面。在林林總總的成本優化路徑和手段面前，誰先朝正确的方向踏出一步，誰就有可能領先對手占據先機。本文綜合講述了一個典型腰部企業的降本之路，希望能對讀者有所啟發。如果讀者有成本優化技術手段相關的需求，可以聯系我們共同探讨。

本文大部分内容摘自《星漢未來雲原生 IT 成本優化白皮書》，其中提到的 SchedulX 是由星漢未來打造的一站式雲原生基礎治理平台，目前已推出社區版，通過此鍊接即可獲取白皮書、免費試用 SchedulX 社區版。

作者介紹

舒超，星漢未來 CTO。前美團基礎研發負責人，存儲中心總架構師，負責美團公司級雲原生服務治理系統的開發及演進；前騰訊微博微群及消息流廣告負責人。

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部