初創公司的FinOps之路：兩年內雲成本節省80%，無需專職團隊！

小猿姐發表於2024-12-04
閱讀完本文耗時將大於 20 分鐘，作者總結了較大篇幅的實戰經驗，非常有收藏價值，初次閱讀建議您可以先跳過該章節（已標記 TL;NR ）。
標題裡的這家公司就是杭州雲猿生資料，這家公司在近兩年，使用 FinOps 工具、流程和策略，雲資源節省了 80% 以上成本。

在取得該成效的過程中，和大公司不同的地方，沒有投入一個專門團隊做所謂“降本增效”戰役，也未高價購入 FinOps 產品或者引入專業的成本最佳化供應商，完全以內部研發團隊興趣小組的方式，自建共享迭代最佳化，且在 FinOps 過程中以零打攪研發效率為目標。

如您也希望如此，可以展開閱讀以下。

也可新增雲猿生小助手加入交流群，一起探討 FinOps 成長之路～

掃碼新增小助手，備註「FinOps」

什麼是 FinOps，為什麼企業需要 FinOps？

FinOps（Financial Operations）是一種雲財務管理實踐，旨在幫助企業最佳化其雲端計算支出，同時提高業務敏捷性和創新能力。隨著雲服務的普及，企業在雲上的支出日益增長，而 FinOps 透過跨部門協作（如財務、技術和業務團隊）來管理和最佳化這些支出。

FinOps 的核心目標包括：

  1. 可見性：提供對雲支出的透明度，讓不同團隊瞭解自己的使用情況和成本。
  2. 最佳化：透過技術、財務和流程上的改進來減少不必要的支出，提高成本效益。
  3. 協作：財務團隊和技術團隊共同制定和實施成本管理策略。

FinOps 的關鍵原則：

  1. 團隊所有權：每個團隊對自己的雲使用和成本負責。
  2. 速度與成本平衡：在控制成本的同時，不犧牲業務的速度和創新。
  3. 持續改進：隨著雲環境和需求的變化，持續最佳化和調整支出。

FinOps 結合了技術和財務的最佳實踐，使組織能夠更好地預測、控制和最佳化其雲資源的使用。

以 NBA 比賽為例，如果說企業的核心業務是 NBA 得分球星邁克喬丹，那麼 FinOps 就是讓企業在商業競爭中能撐得更久的 NBA 籃板王大蟲羅德曼。

如何在企業從零到一做好 FinOps 工作？

本文的目標讀者，是需要在企業從零到一做好 FinOps 工作的負責人以及相關干係人。

基於雲猿生 2 年從零到一的 FinOps 實踐經驗看，將多雲管理從：“無度量”、“失控”的初始狀態，調協到：“全顆粒度”、“充分掌控”的狀態，達成將用雲成本降低 50% 以上的 KPI 目標，是完全可行的。

在您閱讀本文之前，或許您已經瞭解到 FinOps 是一個系統工程，雖然關於 FinOps 的各類技術分享、網路分享已經汗牛充棟，但是仔細閱讀這些文章，您會發現大多數都是隻講述一個簡單的點，沒有系統的、實操性質的可落地企業一線並直接帶來重要改變的方案。因此當您閱讀完這些文章之後，大部分情況你只是知道了這一個小知識，而與此同時，您線上上執行的各種雲資源並未因為您的知識增長而對您有所畏懼，依然無情地吞噬著企業極為珍貴的資金。

本文將會基於這個目標展開：如何在企業從零到一做好 FinOps 工作？讓您真正且快速成為一個拯救企業命運的英雄，即使您對 FinOps 現在一無所知。

雲猿生的用雲基本情況

麻雀雖小，五臟俱全。雲猿生雖然是一家初創公司，但是用雲範圍幾乎已全面覆蓋市場上的主流雲，以及擁有私有化的 IDC 機房和自建的 Lab 機房。

雲猿生使用雲原生技術對於負載的排程，比如 K8s, Terraform, Karpenter。

如果貴司用雲的正規化也是如此，那麼您應該能體會多雲管理和成本最佳化的複雜度。

雲猿生的用雲基本原則

和大企業不一樣，雲猿生是一家矽谷風格的科技創業公司，崇尚工程師文化和效能，因此用雲的基本原則是：不審批，開放用雲。

基於這個用雲基本原則，極大地減少了用雲管理成本，並且讓全員都解鎖了用雲知識，使得雲猿生公司快速具備能夠處理多雲使用和管理複雜度的人才廣度。也基於此，雲猿生推出多雲混合雲資料庫管理平臺，基於該平臺，使用者可自主選擇公有云提供商的例項折扣計劃，讓雲資料庫的成本最多節省 75%。

在關於 FinOps 的各類技術分享中，很少考慮這個用雲的管理成本，它們其實就是在玩轉移複雜度的遊戲，只減肚子上的肥肉而不考慮內臟裡的脂肪肝。雲猿生在“不審批，開放用雲”的基本原則上，執行 FinOps 同時也用技術和更簡單開放透明的管理方式做到幾乎為零的管理成本。

  • 技術管理方式比如：使用多雲統一登入解決方案。

    使用多雲統一登入，使得全體員工可以無需逐一申請建立每個雲的 IAM User 就可以直接一鍵登入訪問任意雲，並且可以更方便進行用雲審計和自動化雲資源分賬，兼顧了成本、效率和合規。

  • 更簡單開放透明的管理方式比如：

    制定《用雲規約》，讓全體員工在規約的基礎上使用雲。

    《用雲規約》公告了成本優選的用雲順序、贈金額度情況、折扣和優惠、通用約定規則、以及每個雲的特殊規則。基於規約，即使是新員工也可以做到無人指導的情況下像 FinOps 專家一樣找到划算的用雲方式。

對以上管理方式有興趣的客戶，我司可以提供免費技術指導。

如何自動化的落地 FinOps?

擁有原則並不能保證 FinOps 的落地。FinOps 是一個持續性的工作，特別是基於我司用雲正規化的複雜度，沒有工具只靠各個雲的管控平臺，已無法保障。

因此雲猿生內部開發了一個 FinOps 副產品：Apepipe。實現對多雲多賬號的統一 FinOps 自動化。目前該產品已經有以下能力，並可以私有化部署：

Apepipe Bot

透過飛書和 Slack 等機器人（有需要也可以支援釘釘、企業微信等），實現 FinOps 功能的互動。

比如推送 FinOps 賬單和最佳化提醒：

Apepipe Bot 也可以用 ChatOps 的方式呼叫 CLI 的所有命令，比如檢視雲資源、刪除雲資源、或查例項的價格，這樣當你躺在沙灘上時，隨便開啟飛書、Slack 等就可以輕鬆管理所有云的雲資源了：

Apepipe Bot 接入現在流行的 AI，FinOps 起來就更趁手了：

Apepipe CLI

透過 CLI 可以在命令列下做統一多雲資源查詢和管理。

Apepipe CLI 還整合了一些效能工具，比如當你不再需要使用這個雲賬號時，使用 nuke 這個工具可以把賬號裡的資源一鍵清理乾淨。

Apepipe Dashboard

透過 dashboard 可以大屏一覽所有云資源的情況，也可以詳細定位查詢某個雲資源，無需在多雲多賬號中切換。

零程式碼可以自定義的 Dashboard:

Apepipe Operators

部署在 k8s 中，按 FinOps 規則進行自動資源最佳化的執行器。FinOps 最大的敵人是時間，只要資源在那裡，雲賬單每分每秒都在增加計費，這些執行器可以在後臺持續執行，無需人工介入，在每分每秒為你消除浪費的雲資源，並按規則合理地最佳化資源。比如：

  1. 自動清理掉不用的磁碟
  2. 自動將 AWS GP2 轉為 GP3
  3. 自動最佳化 AWS EC2 例項的 credit 設定
  4. 自動在週末關機測試用的雲主機
  5. 自動清理不再使用的日誌專案

雲猿生 FinOps 實戰經驗（TL;NR）

限於公眾號篇幅，以下篩選了一些常見的 FinOps 實戰，更多的分享總結在《FinOps Zero 2 Hero》電子書中，將在之後整理公開分享出來。

雲伺服器成本

1.1 使用 Spot 例項節省 50～90% 成本

對於開發測試非穩定性要求的需求，建議使用 Spot 例項節省雲伺服器成本。

其中，GCP 的 spot 例項可以只停止不刪除，特別推薦使用。（AWS 的 spot 例項當被平臺回收時，例項繫結的系統盤也會一併被回收，如果盤上有資料，將無法找回）

GCP spot 例項成本是 standard 的 1/3。

1.2 長駐需求的雲伺服器使用預留例項

預留例項選用的技巧：

相關變數：1. 是否預付費；2. 是否可變；3. 週期（Term）；4. 範圍（Scope）

說明：

  1. 是否預付費： 選預付費就是提前把錢支付掉；如果選用不預付費的方式結算，月底和供應商拉賬單月結；預付費的價格會更低；
  2. 是否可變：可變是指在預定週期內，可以變化例項型別。不可變的叫標準模式（Standard）。
  3. 週期（Term）：預定的時長，一般有 1 年和 3 年；3 年便宜很多。
  4. 範圍（Scope）: Region 和 Zone，Zone 的一般更便宜。

如果確定性強的需求，可以選用：預付費 + 不可變 +3 年，這樣成本是最低的。

1.3 在相互不干擾的情況下，儘可能合用資源

1.4 使用定時任務，配置 VM，晚上不用時自動關機，早上使用時自動開機，節省費用

使用定時任務，也可以設定週末定時停機。

1.5 暫時不用的例項，打成機器映象

當例項暫時不用的時間超過 1 周或者當例項的塊儲存的費用比較高時，相比於僅停機，打成機器映象然後刪除例項，可以節省塊儲存費用。需要的時候，用機器映象恢復就可以了。

1.6 節省停機模式

阿里雲的停機方式有兩種，普通停機模式，成本還是一樣在扣減的，建議當雲伺服器暫時不用時，選用節省停機模式。

節省停機模式介紹:

  1. 節省停機模式下，計算資源（vCPU 和記憶體）、固定公網 IP 和頻寬不再收費。
  2. 仍舊收費的資源有：系統盤、資料盤、彈性公網 IP 和頻寬（固定頻寬模式）、收費映象。

1.7 可用區也會影響成本

選可用區的小技巧：三短一長選長的，三長一短選短的；兩長兩短選擇 B，長短不齊就選 BC。有一種“民間偏方”叫做選 C。

這個小技巧，特別對於使用 spot 的例項的時候效果明顯。在 2 年的 AWS，GCP 等雲的 Spot 例項回收機率分析後，A 可用區的回收機率遠遠高於 B,C 和之後的其他可用區。

因此，想要省錢，可用區的選擇也是有講究的哦。

1.8 Spot 例項的回收訊息裡的寶藏

Spot 例項的回收是一個機率事件，透過分析不同例項型別、不同可用區的回收機率，可以最佳化調整 Spot 的部署，就可能用 10% 的成本（Spot）來達成需求的同時有很高的穩定性。

2. 公網 IP 成本

目前幾乎所有云的公網 IP 都已經單獨計費，因此，對於可以不用公網訪問的情況，不配置公網 IP。減少公網 IP 使用的另一個好處是，減少被公網惡意流量攻擊的可能。

3. 流量成本

3.1 AWS 在同一個 region 內，不同 az 的 EC2 之間的網路流量，等同於跨 region，也是需要同樣的流量成本

真實案例：某公司專案組因為不瞭解該資訊，多 AZ 的 EC2 之間幾天跑出了 7 萬多的流量成本。

3.2 流量儘量走內部，公網流量很貴

比如：阿里雲 ECS 讀寫 OSS，一個 1TB 的 bucket，如果走公網 endpoint，流量 0.25 元 /GB，讀完這個 bucket，250 塊就沒了（數字舉例純屬精確且巧合）。

4. 物件儲存成本

4.1 S3: 如何正確刪除一個 S3 bucket，當檔案數量大到無法手工清理的時候

我們經常會遇到測完 S3 後面要刪資料，bucket 刪除前會提示先刪除裡面的資料，當檔案數量大到無法手工清理的時候，怎麼辦？

這麼多大檔案，需要用 lifecycle 來刪除，不要直接 delete，不然刪除也會產生較大的流量費用。

s3api put-bucket-lifecycle --bucket %s --lifecycle-configuration '{
"Rules": [
    {
        "ID": "delete-all",
        "Status": "Enabled",
        "Prefix": "",
        "Expiration": {
            "Days": 1
        }
    }
  ]
}'

4.2 阿里雲 OSS：用 ZRS 會比 LRS 貴 25%，開發測試沒有特殊需求的話，建議用 LRS

4.3 定時清理不再使用的 bucket

按量計費的物件儲存，隨著時間的累計，也是一筆不小的費用。應該定時清理不再使用的 bucket。

不清理出了儲存本身的成本，更危險的是：公有云上的黑暗森林法則出現了：只要你的 S3 物件儲存桶名暴露，任何人都有能力刷爆你的雲賬單。

https://medium.com/@maciej.pocwierz/how-an-empty-s3-bucket-ca...

5. 塊儲存成本

5.1 停止的例項，可以把塊儲存轉成快照節省成本

5.2 阿里雲塊儲存的選用：performance_level PL1 要比 PL0 貴一倍

阿里雲 ACK 預設的 essd 的 SC 會選用 PL1，一般非效能測試需求的開發測試，PL0 的效能已經足夠用了。阿里雲 ACK 可以新配置一個 essd 的 SC，加上 performanceLevel: PL0 的引數。

6. GPU 成本

6.1 使用“平替”的 GPU 型號

Nvidia L4 機型的成本比 A100 便宜非常多，但 Cap 甚至高於 A100，對於頻寬要求不高的情況，可以考慮作為平替。

6.2 GCP 巧妙解決專案 GPU 的 quota 限制

GCP 的 billing 是基於專案維度的，不同的專案可以繫結不同的支付方式。GCP 的 quota 和支付方有關係，比如某公司 GCP 賬號的供應商支付的 A100 GPU quota 有 16 個， 為了獲得這個 quota 的同時並且用 GCP 初創公司贈金，操作如下：

新建一個專案，透過先繫結到供應商 billing 獲得 16 個 quota，然後切到自己的贈金 billing

另外，on-demand 和 spot 的 quota 都是獨立的，在一類 quota 滿的時候，可以試試換一類使用。

7. 快照成本

7.1 快照存檔

當快照需要長期儲存（>90 days），將快照進行歸檔可以節省 75% 的成本，參考：
https://docs.aws.amazon.com/ebs/latest/userguide/snapshot-arc...

8. 日誌成本

8.1 關閉不需要的日誌生成

比如 eks, gke 等雲託管的 k8s 都會預設生成日誌；雲上的日誌系統，無論是 AWS 的 cloudwatch，還是 GCP 的 logs storage，日誌一開，費用就刷刷去了。比如某公司專案 gke 因為大量刷 error log 產生了 10 個 T 的日誌，消耗了 6,877.65 美金。

8.2 縮短日誌儲存週期

日誌的每 GB 儲存費用遠高於物件儲存。因此儘可能減短 Retention period，以 GCP log storage 為例，最短可以配置成 1 天。

9. 容器服務成本

9.1 eks 需要保持 k8s 版本升級，不然擴充套件支援需要支付額外費用

10. AWS 專區

10.1 積分規範

積分規範：t3 /t4g 支援 cpu 突發，比如核數跑滿的話，會額外消耗 cpu credit，動用額外的核來支援計算，這個超出自己賬號省出來的 cpu credit 後，會額外收費，0.342 CNY per vCPU-Hour of T3 CPU Credits，因此建議普通開發測試需求，設定“積分規範”的模式為"standard"，這樣可以避免額外收費。

10.2 KMS 的成本最佳化

使用 terraform 建立 EKS，當銷燬時，和 eks 一起建立的 KMS key 的預設刪除週期是 30 天，在 terraform 配置里加上下面這句配置，將可以節省 KMS key 在等待刪除週期裡的 75% 的成本：

deletion_window_in_days = 7

11. GCP 專區

11.1 建議選擇 us-central1（VM 價格最便宜），可以諮詢 Google 官方瞭解價格表：

  • https://cloud.google.com/compute/all-pricing
  • https://www.instance-pricing.com/provider=gcp/cheapest/
  • https://googlecloudplatform.github.io/region-picker/

11.2 在 GKE 上執行費用經過最佳化的 Kubernetes 應用的最佳做法：

  • https://cloud.google.com/architecture/best-practices-for-runn...

11.3 整理一份 GCP 例項規格，並標註了 FinOps 推薦的機型

12. 擁有自己的資料中心和私有云

為了提高穩定性和備份能力，雲猿生選擇了多雲架構，目前已支援阿里雲、AWS、Azure、GCP、電信雲、騰訊雲、百度雲、火山引擎，並與 SealOS 進行了合作；與此同時雲猿生也有私有云的投資，儘管私有云的機器部署要比公有云更為繁瑣，但我們認為擁有自己的資料中心和私有云是一項長期的投資決策，可以降低每年的雲服務費用。

End

KubeBlocks 已釋出 v0.9.2！歡迎體驗！

小猿姐誠邀各位體驗 KubeBlocks，也歡迎您成為產品的使用者和專案的貢獻者。跟我們一起構建雲原生資料基礎設施吧！

💻 官網: www.kubeblocks.io

🌟 GitHub: https://github.com/apecloud/kubeblocks

🚀 Get started: https://cn.kubeblocks.io/docs/preview/user-docs/try-out-on-pl...

☁️ Cloud 試用：https://console.apecloud.cn/

關注小猿姐，一起學習更多雲原生技術乾貨。

相關文章