降本30%+增效40%，這樣落地FinOps省錢又省力！

作者：鐘仕駿 2023-09-05 07:21:47

開發架構

通過FinOps優化成本后，整體開銷的趨勢走向如上圖（已脫敏）。相比以往總體成本最高的時期，當前成本下降近一半，這是FinOps平臺最顯著的效果。

一、FinOps平臺初期問題

新東方成立至今已有30年，但基于IT和運維平臺的基礎設施建設，近些年才逐漸形成規模。

1.面臨困境

圖片

煙囪效應：早期發展過程中，各個業務平臺都有專門的研發方向，比如服務器部門專攻服務研發，網絡部門專攻網絡研發，安全部門專攻安全研發。這種“各個團隊深挖自己擅長領域”的研發模式，導致內部系統煙囪林立，難以進行數據互聯互通。
數據孤島：新業務新市場的拓展過程中各內部系統沒法直接復用和迭代，產生的新數據無法與原有的數據互通，加劇了數據孤島的問題。
組織熵增：各個平臺功能單一化，平臺與平臺之間的協調配合、數據交互異常混亂，隨著企業核心業務增長，卻帶來了效率低下的問題。

基于以上三方面問題，產生了建立統一化對外平臺的需求。

2.初期構想

問題1：哪些獨立功能需要集成？

下圖展示了平臺初期的7項業務重點。

圖片

資源申請：這是開發平臺時設想的新功能，研發人員通過平臺自助申請資源，同時資源支持自動納管。
信息檢索：當同業務線的人員檢索服務器、PaaS類內容等信息，可獲得精確數據。
流程操作：規劃流程模式，用于資源申請、業務流程創建。
業務上線：即大家熟知的CI/CD。
成本控制：將在后文詳述。
數據安全
高效穩定

問題2：集成后如何方便地進行資源成本分攤？

圖片

根據上述概念，如何針對云教室、東方甄選、小課堂等應用項目，進行資源的成本分攤呢？

第一，申請流程。目前已經搭建起平臺，就通過云主機、云盤或數據庫資源等進行申請。流程創建的同時，這些資源掛載到對應的服務樹上，相當于在數據庫層面進行關聯。

第二，通過平臺分攤資源成本。

平臺搭建前已有的數據，如何轉移到平臺呢？

資源獲取：物理層面，通過數據納管腳本，將物理層的數據中心、機架、服務器的物理機，以及硬件配置納管；混合云層面，阿里云、騰訊云和微軟云等公有云，以及VMware的VSphere和OpenStack等私有云的數據，通過API進行同步或官方SDK拉取。
資源位置：物理機是IDC，VSphere屬于私有云，微軟、阿里、騰訊屬于公有云。
資源類型：目前支持通過平臺（阿里ECS和RDS，騰訊CVM和CDB等），申請云主機、數據庫、對象存儲等資源類型。

圖片

Redis、ES、Kafka、RocketMQ等中間件的資源，用于實現緩存或服務隊列等輔助功能。

3.解決辦法——服務樹

如何將這些資源分配到各個業務線呢？這涉及到服務樹的概念（前文介紹業務的成本分攤時亦有提及）。服務樹與人力資源樹不同，人力資源樹更關注公司的部門關系和組織架構，而服務樹更關注企業的業務應用。

經過長時間的整理工作，我們形成了新東方集團的服務樹，共分為5個層級。

圖片

第一級-集團：即新東方集團，它是所有業務的根節點；
第二級-業務線：包含地方校、機構和子公司等；
第三級-項目集：一類高度關聯項目的集合；
第四級-項目：各類業務研發的立項；
第五級-應用：包含開發模塊、 App組件、各種微服務等內容，這是服務樹的最小粒度。

4.通過服務樹關聯集成業務功能

圖片

根據上述5個層級，可以通過服務樹數據，關聯具體的應用功能，并為用戶角色分配服務樹節點。同時，服務樹節點對應服務API，通過賦予角色不同的action權限，達成集中授權的功能。這是服務樹結合應用的案例之一。

二、數據和安全建設

1.案例：實時計算平臺

1）大數據實時計算架構

圖片

第一個案例是數據平臺中比較重點的項目——實時計算平臺。實時計算，與在離線數據分析的概念相似。

如上圖所示，左邊是RDBMS和分布式數據庫，基于CDC進行數據采集，中間是類似于Kafka的數據通道，右邊是一個存算分離的架構、一個實時數倉，以及在離線計算的任務和存儲。最終，數據到達數據分析平臺，用于BI統計和計算。

我們負責研發實時計算平臺的中間部分，其功能包括SQL任務和JAR包任務。

2）上下游通過流程串聯

圖片

我們希望業務用戶進入平臺之后，能夠以一種簡單的方式，發現、實時Job計算，故目前提供2種選擇：

第一種方式：將Java程序打包后，用提交Jar包任務來提供計算服務。由于大數據和數分Java工程師比較多，他們會寫基于Flink的Job；
第二種方式：直接在平臺的在線Web IDE中，用SQL語句寫DDL或DML語句，生成Source表或Sink表功能，用于處理實時計算的過程數據。這是整體的上下游關聯流程架構，任務提交前通常由 DBA來審核。

3）數據處理能力升級-實時數據研發平臺

下圖呈現了實時計算平臺中，任務SQL語句生成的表結構、Job實時任務的操作（可以進行Job暫停、重啟、拉起、停止等操作，以及類似的模板功能等）、Source表和Sink表結構等。

圖片

開發實時計算平臺的預想目標是，建立一個自動化的研發的數據模型，集成原有割裂的實時計算存儲和計算，通過服務樹與業務庫表關聯，提升整體研發效率。

2.案例：安全項目驅動開發

第二個案例是安全類項目，我們曾參與6項安全類研發項目。

圖片

紅藍對抗：并非內部人員組成紅軍藍軍，而是邀請外部安全公司，進行安全打擊測試。
滲透測試：基于單個項目，針對某些平臺進行安全類檢測，用于輸出和修復未處理的漏洞、事件和風險。
敏感數據檢測：針對可能涉及到敏感數據的項目進行檢測，比如用戶真實姓名、身份證號、電話號碼等等，利用定期掃描任務，通過敏感數據識別模板進行識別，來協調開發人員對敏感數據進行加密存儲和傳輸。
安全中心：內部提供一些功能，比如說像安全管理、內部政策法規類的平臺。

接下來我將重點說明后兩個項目：安全 APP合規平臺、內部CA認證。

1）案例：安全APP合規平臺

圖片

APP合規檢測，是針對新東方自研APP，從管理和技術兩方面，進行安全合規檢測，以減少風險。我們對這些APP進行安全左移的第三方檢測，并評分。如果未達到安全評分，比如檢測到安全風險或漏洞，安全團隊會在平臺上提交APP漏洞，提示業務線安全加固，否則不能上架。

圖片

安全合規檢測項目對APP業務非常重要。針對東方甄選、托福等重點項目，我們會進行APP合規檢測，并列出高危風險、低危風險等詳細信息。

2）案例：CA認證中心

為什么要構建內部的CA中心？

平臺具有在線終端功能，在瀏覽器頁面通過調用web socket自動登錄到服務器黑屏操作上（類似xshell和crt），自動登錄需要進行登錄認證。

圖片

初期為了方便，使用了第一種方案：傳統的密碼認證，但由于密碼非常容易拷貝和背誦，風險系數非常高。

所以改用第二種方案：公私鑰的密鑰對認證。它解決了密碼易于拷貝和背誦的問題（公私鑰包括好幾百個字節，數據串很長，一般人難以背誦），但是這個方案忽略了一個問題——公私鑰依然是可以傳遞的。

后來我們調研了第三種方案：CA認證，搭建了內部CA認證中心，實現了平臺端的三方認證，即平臺-用戶-CA憑證。用戶操作具體頁面時，需要上傳CA憑證（內含針對用戶的算法哈希值）。

CA認證有效且通過用戶hash驗證后，下一步需判斷CA憑證是否超期、與服務端憑證是否相符等，如有一項不滿足，則判定為非法請求，拒絕后續操作。

圖片

上圖為我們開發的CA認證流程圖。調研 CA認證時，曾考慮過采購商業版本的，但很多安全公司尚未具備CA認證的完整流程，所以只能自行搭建。

CA認證的詳細流程：

第一步：用戶登錄之后，操作CA關聯的應用時，判斷用戶憑證是否處于認證有效期內，有效期內（例如7天）則不用重復認證，否則需要重新認證。這種邏輯對關聯的功能模塊非常友好，用戶不必反復登錄認證，體驗類似SSO。
第二步：判斷服務端是否真實存在認證證書，如認證證書不存在，用戶需申請并重新下載。
第三步：判斷證書在服務端是否已經被吊銷，如被吊銷或刪除，需重新認證。

圖片

完成以上三步，用戶即通過認證，可以進行下一步工作。由此可以理解為，我們將CA認證功能集成于一個請求的中間件。

三、成本中心一體化

1.FinOps的概念和本質

圖片

FinOps基金會對FinOps的定義是，讓研發、財務、業務等各個團隊共同配合，從數據和資源層面，放大業務利用價值，實現降本增效。

圖片

上圖是我們目前的FinOps框架圖，上面部分包括多云賬單管理、預算管理、成本優化分析，報警等迭代功能；中間部分是云單元管理、云CMDB、權限管理等平臺；下面部分是使用的混合公有云的基礎設施（阿里、騰訊、微軟）。

2.FinOps一體化平臺組成

圖片

DevOps平臺和FinOps平臺，通過服務樹（節點）進行連接，由此判斷服務樹內存在哪些應用、資源，這些資源關聯哪些賬單，甚至細分到具體服務器的粒度層面。

3.FinOps云成本優化業務組成

圖片

以上是業務圖，上方是云課堂、東方甄選類似的業務應用，我們為其提供報表和業務賬單；中間部分是成本中心和運維門戶；下方是依賴，使用公有云官方的API，私有云就是各個廠商（比如VMware、OpenStack等）提供的SDK組件。

4.案例

1）案例：FinOps月賬單

圖片

上圖是項目月度賬單報表（已脫敏），包括現金賬單和攤銷賬單。

現金賬單：企業單位實際支出費用，財務與商務比較關心這部分內容。
攤銷賬單：多租戶使用、不方便直接生成賬單的部分，比如MySQL、Redis或存儲，就按照主機使用率百分比，將使用支出分散到各個業務線上，以便業務通過使用率和攤銷情況進行對賬。

2）案例：阿里云RDS報表

圖片

如上圖所示，這份阿里云RDS報表（通過阿里公有云API獲取）包含幾個重要指標，比如涉及服務器的高開支項目集中于哪些部分，哪些是實例，實例規格配置如何（比如2C4G、4C8G等），實例規格花銷如何，花銷分攤對應項目的具體數目。

3）案例：移課通報表賬單

圖片

由于涉及課程的營銷推廣，所以新東方具有客服業務，分為短信和會話兩種套餐。

新東方具有多個子公司和地方校，各個學校的通信費用、使用個數和開銷構成了其套餐費用。我們重點關注移課通賬單開銷，使用逐步優化的FinOps分賬算法，形成各地方校和子公司的賬單優化閉環。

5.FinOps成本優化閉環

圖片

賬單閉環優化的邏輯如上圖。

付費合理性預測：基于IT賬單，判斷目前消費環節的有效性、合理性，是否符合預期，是否存在超預算的必要支出。
降本節約性建議：基于合理性預測，結合算法檢查付費方式（RDS 按月/按量、移課通套餐一/套餐二）在不影響業務的前提下，選擇更有助于優化成本的付費方式。
成本結果集觀測：基于降本節約性建議，優化付費方式，生成業務月賬單現金成本的結果集，實現成本支出的可觀測性，作為預算參考。

具備預算參考后，需要基于生成的結果集賬單，再次判斷合理性預算，整體形成云成本優化的閉環。

1）案例：業務線月度費用報表-費用預算和最終賬單參考

圖片

上圖是費用預算和最終賬單的參考（已脫敏），內容包含具體日期、負責人部分花銷、各項目和主機的分攤費用。云成本方面，內容則包括涉及的公有云類型，比如阿里 ECS、RDS、CDN的詳細賬單，以及服務器運行時長等。

2）案例：云實例規格配置管理

圖片

因為不同云主機的規格配置有多個版本，一條配置可能包含幾十條規格名稱。用戶在平臺申請云主機或RDS數據庫時，可能面對上千條規格配置，導致選擇困難。

基于以上問題，我們設計了云實例規格的收斂方案，通過資源實例配置管理，進行自定義規格列表，同時支持配置優先級。處理人為錯選或配置冗余的情況，優先提供更具性價比、目前線上應用更多的實例配置。

由此，提供給用戶幾個不同配置的定制化選項，并且使用人性化規格名稱，用戶可以根據需求選擇，既節約時間，又避免了晦澀難懂的規格名稱混淆用戶選擇。

3）案例：閑置率報表及成本黑名單

圖片

2021年頒布的雙減政策對教育業務打擊很大，各大公司均收緊業務、裁員降本。以往未曾注意的資源浪費問題，如今越發凸顯，加之裁撤業務和項目，作為運維重要開銷的云成本問題較為棘手。

所以，我們利用長期運行但資源利用率閑置的主機，額外采集系統監控數據，列出由高到低排名前五的業務線黑名單，向每條業務線的負責人發送郵件報表，敦促業務負責人盡快處理。處理方式推薦以下三種：

退租：即機器無人使用、業務無人接手；
混布：CPU密集但內存消耗少的服務，可以與內存密集但CPU消耗少的服務進行混布，提高資源利用率；
遷移：將閑置資源轉移給其他業務，變更機器所屬服務樹，盤活閑置資源。關于閑置率，并非關注節約多少成本，而是關注每種資源都實現其應用價值。

6.優化步驟與成本考核

圖片

前文提到，根據業務成本分攤結果，統計并處理閑置率主機，優化云資源規格的優先級、包年或流量套餐選擇。最終，結合業務線成本輸出，形成一種考核模式，目的是提高利用率，確保各個業務線ROI處于較高的水平。

1）案例：年度IT各類費用趨勢

圖片