<mark id="oztn4"></mark>
0
前幾日，騰訊云委托Forrester Consulting推出一臺 “計算器”，能直接算出使用騰訊云TKE后投資回報率（ROI）。這個計算器成功吸引了劉飛的注意，他試了試，并輸入一系列關鍵信息：當前的計算資源成本、預期的容器化比例、運維和研發人員的數量、以及年營收......
隨著鼠標輕點，計算器迅速處理著這些數據，最后屏幕上跳出了ROI預估值：三年期投資回報率預估298%。
這個投資回報率讓劉飛很欣喜，前幾日，劉飛匯報云原生改造方案時，剛好被老板靈魂拷問了一番：“上云要花的錢是真真實實要從我賬上劃走的，但我得到了什么？”
眼下，這個計算思路給了他一些下次回答老板上云成本問題的啟發。
不僅是劉飛，可能大多技術決策者都有類似感受。過去，老板對IT投入可能還沒那么敏感，但這兩年，由于外部經濟環境承壓，企業經營壓力劇增，IT又容易被視作成本中心而非利潤中心，很多老板自然對IT開銷關注度大大提升，一些IT負責人也被下達必須進一步降本增效的指令。
到底如何降本增效？IT負責人要思考的問題不少，首要是成本，要找出成本支出大項，做進一步優化。
“計算資源成本支出往往是被最先盯上的。”劉飛說道。
由于種種原因，一些企業還是采用的“買箱子”方式，投入大筆資金購置硬件設備以及建設數據中心，一個數據中心少則幾百萬，多則上億元，極大影響到了公司現金流。
資源成本之上，被重點關注還有開發成本。傳統開發大都是“手工作業”，手動擰緊數據庫、服務器和應用依賴的每一顆螺絲。功能開發完畢，便迎來手動測試的長隊，然后是小心翼翼的部署過程。這種方式不僅效率低下，而讓公司開發部門臃腫，人力成本也高居不下。
此外，運維成本也是不可忽視的一項大開支，尤其是隨著企業業務的不斷增多，IT系統不斷升級不同年代型號設備品牌不一，協調不同廠商發現并解決故障，運維復雜度、成本也在攀升。
如何對這些成本項進行節省改造，成為了技術決策者每年重要的KPI。與此同時，除控成本外，技術決策者也還需兼顧思考業務。“所有的IT改造要能靈活地響應市場變化，支持業務的發展。”劉飛說道。
過去幾年隨著市場教育增多、企業認知的提升，很多企業技術決策者最終把目光落腳了云原生改造，嘗試選用云技術架構來降本增效。
云最大的特點就是彈性，大家都希望能通過云彈性能降低企業資源成本，劉飛表示。此前也有從業者直言，中國很多的公司固定需要用的機器，使用時長不會超過1/3，剩下的2/3其實都是可以用彈性來解決的。
這是決策者選擇云原生的一大原因，不過資源成本外，決策者也希冀通過容器、微服務等云原生技術快速構建、交付應用的特點，進一步降低IT開發、運維成本。
Forrester 撰寫的《騰訊云容器服務總體經濟影響?報告》中，模擬出一家業務范圍覆蓋全國、年營收4.5億人民幣左右的復合式組織，并直接測算了該組織使用騰訊云TKE后的成果。
報告顯示，該組織計算資源成本節省超過70%，日常運維負擔降低50%以上，峰值運維負擔降低98%。企業應用開發迭代效率提升90%。服務穩定性提升，每年服務中斷時間減少42.6小時。
此外，在劉飛看來，云原生技術的敏捷性和快速迭代特性，的確能讓企業在面對市場變化時，能夠迅速調整策略。騰訊會議這個案例就曾令他印象深刻。
當時剛推出時，它只是常規辦公場景中的應用廣泛，在疫情期間，遠程辦公需求激增，導致業務量急劇上升。騰訊會議利用云原生技術實現了難以想象的快速擴容。在一天之內，其支撐能力就從幾百萬用戶迅速擴展到了超過一千萬用戶，擴容過程變得迅速高效。而在疫情結束，峰值過去之后，業務也可以快速地縮容。
在降本增效的加持下，這兩年企業進行云原生改造的動力增加了不少。
云原生技術改造方案中，其中重要一項技術改造就是——容器，它也被稱作是云原生的技術底座。
如果用一個比喻，容器就好比一個智能交通調度系統，在一個繁忙的交通樞紐，如果沒有智能交通系統時，就需要大量人力指揮車輛，效率低下且成本高。有智能交通控制系統后，它能自動監控交通流量，實時調整信號燈，優化車輛路線，甚至預測并應對高峰時段。這不僅減少了交通指揮員的數量，還提高了道路的使用效率，減少了擁堵和空駛，最終使得整個交通系統的運行成本大幅降低。
這幾年已經有企業陸續開展容器化的改造。不過改造的路徑有所不同，有的選擇自己干，有的選擇直接采用成熟的云廠商容器產品。
“我們兩種方法都試過。”貝殼云技術中心系統研發部高級經理楊菁偉對雷峰網(公眾號：雷峰網)坦言。早在2020年，他們曾試圖在云上自建并管理Kubernetes集群。
一路摸索下來，楊菁偉表示，如果企業選擇自行搭建K8s面臨兩個問題：一個是成本不低，尤其是一家不是特別大型的企業，如果要在基礎設施上自研，是要砸不少重金，養頗為龐大的研發團隊。但實際上，其實企業還是應該優先把落腳點放在業務端。第二是自研過程也是一個探索過程，中途不可避免走一些彎路，起初搭建的產品不一定很成熟，會有很多的試錯成本。
在經過一番自我摸索之后，2022年貝殼找房選擇和騰訊云TKE合作。
主要原因還是看中了騰訊TKE積累的技術實踐。自2018年騰訊啟動整體戰略升級以來，明確了“開源協同”和“自研上云”兩大技術戰略。其中，在自研上云領域明確提出基于容器，微服務和CICD等云原生技術來構建面向未來的技術架構。
在過去幾年，騰訊云TKE的落地規模已經超過5000萬核，累計為騰訊節省數十億元成本。除了支撐集團內部業務全面上云，騰訊TKE還服務小紅書、快手、招行、銀聯、富途、作業幫、榮耀等數十萬家客戶，覆蓋電商、游戲、金融、教育、政務等多個領域。
此次與騰訊TKE合作中，貝殼找房也量化出了兩個重要的資源利用率標準：維持在40%以上以保證成本下降，同時不超過60%以防節點穩定性受影響。
“當時我的心里是心存疑慮，心里打鼓的，騰訊云能否充分理解和適應貝殼找房的具體業務場景，并作出相應的調度器優化。”楊菁偉對雷峰網說道。
在與 TKE 團隊深入交流后了解到，TKE 原生節點本身就可以通過調度時和運行時水位線來控制節點的真實利用率，讓集群中的節點利用率保持在較高水位上，并保障節點穩定。
不過實際落地過程中，楊菁偉稱，也出現過一些與預期不符的現象，“好在 TKE 團隊和我們保持密切溝通，深入了解貝殼的業務情況和使用場景后，做了個性化的參數調整及優化，最終這一目標得以順利實現。”
對于具體的效果，楊菁偉舉例說，假如貝殼找房2023年初設定的全年點擊流量預期為300億次，然而年末的實際流量增長了10%，但服務器投入卻僅只增加了4萬核，相較于預期減少1萬核服務器的算力供應，即使在流量增長的情況下仍實現了成本的有效控制。
盡管以容器為代表的云原生技術有望顯著降低企業IT成本，不過，當下大型企業內部容器化的普及程度仍有待提高，據騰訊云以及一些分析機構提供的數據，目前大型企業容器技術滲透率僅為45%-50%，這一數字并不算高。
尤其是受近期推特下云事件影響，更是有一撥人站出來稱上云不一定節省成本。但實際上企業用云成本高昂的原因有多種——在認知層面，某些企業可能對云服務的真正價值和潛在成本缺乏充分認知，直接超買。
Gartner此前的一項研究數據，引起了不少廠商的關注：45%的企業由于缺乏優化措施，在直接遷移上云的過程中會超買 55%的資源，并且在上云初期的18個月內多花費70%。
這符合人們的一貫思路，就好比提前囤積物資，以備不時之需。可事實上，把這種舊想法原封不動地帶進“云時代”，正是造成云成本超支的“元兇”之一。
除“囤貨思維”導致的超買外，沒有搭配好合適自己的計費方案又是另一大云成本增加的“殺手”。
眾所周知，云服務的計費模式復雜多樣，最常見的兩種是按量計費和包年包月，按量計費比包年包月單價貴很多，企業基本是搭配購買云資源。但出現一個問題是，如果包年包月量太大，可能花不完，造成了資源浪費。但如果包的太少，一些公司因為業務波峰波谷差異大，又不得不擴大按量計費，這又導致云支出成本可能比較高。
這兩年，云成本優化也成為了行業研究的重點。2020年12月，信通院就牽頭成立了FinOps產業推進方陣，推進規模化實踐
與此同時，各個云廠商也在加速跟進，其中騰訊云也在不遺余力研究和實踐怎么幫企業省錢。
2021年11月底，騰訊云宣布加入FinOps基金會，成為國內首家FinOps基金會的頂級成員，并且基于FinOps推出的國內首個云原生成本優化開源項目 Crane，將自身內部云資源優化流程方法和工具做系統性輸出。
“Crane致力于推薦資源和智能彈性配置，業務人員無需再為業務需要多少資源，自動擴縮容應該如何配置等問題而煩惱，Crane會基于業務的時序變動數據給出最優解。”騰訊云FinOps產品負責人孟凡杰在此前采訪表示。
據了解，Crane已經在騰訊內部自研業務實現了大規模落地，部署數百個Kubernetes集群、管控CPU核數達百萬，在降本增效方面取得了階段性成果。
以騰訊某部門集群優化為例，通過使用Crane，該部門在保障業務穩定的情況下，資源利用率提升了3倍，騰訊另一自研業務落地Crane后，在一個月內實現了總CPU規模40萬核的節省量，相當于成本節約超1000萬元/月。
在經濟蓬勃發展時期，企業的IT預算曾如同擰松的水龍頭，資金流動自由而充沛。
然而，在當前緊縮的環境下，這個水龍頭已經明顯被擰緊。企業決策者迫切希望看到每筆支出背后的確切回報，他們尋求的不僅是對技術的信心，更是對成本結構的清晰計算和深入理解。
在這樣的背景下，技術決策者們必須拿出賬本，對成本結構進行細致的梳理，以此作為說服管理層的關鍵。騰訊云與Forrester聯合推出的“云成本計算器”正是在這樣的需求下應運而生，這一實踐，為企業提供了一種新的視角和方法，幫助他們在云的浪潮中穩健航行，確保每一分錢都花在刀刃上。
注：劉飛為化名
雷峰網原創文章，未經授權禁止轉載。詳情見轉載須知。
