Minh bạch chi phí đám mây: FinOps giúp doanh nghiệp kiểm soát ngân sách như thế nào?

Bỗng dưng "bay màu" 12.000 đôla: Chuyện gì đang xảy ra?

Mình vẫn nhớ như in cái cảm giác "toát mồ hôi hột" khi nghe về câu chuyện này. Có lần mình từng đọc được một case trên Medium của NAT-Insight, một team dev đã "giật mình" với con số chi phí đám mây tháng đó: nguyên `12.402,18 đô la`! Chỉ trong tháng đó thôi, đâu đó mỗi tiếng đồng hồ là `150 đô la` cứ thế "bốc hơi". Một con số không hề nhỏ, nhất là khi nó đến từ những cái lỗ hổng mà mình tin nhiều anh em vận hành game server hay bất kỳ hệ thống cloud nào cũng có thể gặp phải.

Vậy thì làm sao để biến những "cú sốc" tài chính trên đám mây thành những con số dễ hiểu, dễ quản lý và quan trọng nhất là dễ kiểm soát? Đó chính là lúc FinOps bước vào cuộc chơi.

FinOps là gì? Đừng phức tạp hóa!

Nói thật, nhiều lúc mình thấy mấy cái từ chuyên ngành nghe ghê gớm quá. FinOps cũng vậy. Nghe thì có vẻ phức tạp, nhưng thực ra nó là sự kết hợp giữa Finance (tài chính) và Operations (vận hành). Đơn giản mà nói, FinOps là một bộ các nguyên tắc và thực hành giúp các tổ chức quản lý chi phí đám mây một cách hiệu quả nhất, nhưng không phải bằng cách cắt giảm mù quáng mà là tối ưu hóa giá trị.

Hồi trước, mình cứ nghĩ quản lý chi phí cloud là việc của mấy ông kế toán. Nhưng không. FinOps nhấn mạnh "trách nhiệm chung". Tức là từ anh em dev viết code, đội vận hành deploy, đến cả các sếp bên tài chính, ai cũng có vai trò trong việc hiểu và kiểm soát tiền bạc trên cloud. Mọi người đều phải hiểu rằng đám mây bây giờ không chỉ là chỗ để chạy code, mà nó là cả một "kiến trúc tài chính" luôn.

Zombie GPU, thuế egress: Những "kẻ cắp" thầm lặng

Cái ví dụ `12.000 đô la` ở trên không phải tự nhiên mà có. Nó đến từ nhiều nguồn khác nhau, thường là những thứ "thầm lặng" mà mình hay bỏ qua. Để mình kể vài cái điển hình mà mình thấy các team hay gặp:

• "Zombie" GPU Instances (8.700 đô la): Đây là "kẻ thù" số một. Mình từng đọc thấy trường hợp một con GPU instance cứ chạy "vô duyên" mà không ai dùng tới. Chạy được 3 ngày cuối tuần, mỗi giờ `12 đô la` cứ thế trôi đi. Đến lúc tính tiền thì nó đã "đục" của team NAT-Insight `8.700 đô la` rồi. Hồi mình còn làm vận hành game server, cũng có đợt mình tự tay kiểm tra lại các server đang chạy. Mình mở console lên, vào phần quản lý EC2 (hoặc tương đương ở nhà cung cấp khác), lọc những instance có trạng thái 'running' nhưng chỉ số CPU/GPU usage lẹt đẹt dưới 5% trong 3 ngày cuối tuần. Thấy con nào không dùng mà vẫn chạy, đó chính là zombie. Nó vẫn tính tiền vì nó vẫn được cấp phát tài nguyên, cho dù chẳng ai sờ tới.
• Thuế Egress liên vùng (2.200 đô la): Cứ nghĩ data di chuyển trong cloud là miễn phí ư? Sai lầm lớn. Ví dụ của team NAT-Insight là `2.200 đô la` bay mất chỉ vì hàng triệu cuộc gọi API nhỏ xíu nhưng lại kéo data qua lại giữa các vùng khác nhau. Tưởng rẻ mà hóa đắt.
• Nghĩa địa kỹ thuật số của EBS Volumes (1.500 đô la): Có ai hay quên không tích vào ô "delete on termination" khi tạo EC2 không? Mình biết nhiều ông bị rồi đấy. Hậu quả là `1.500 đô la` đội nón ra đi vì có tới 400 cái ổ cứng EBS 100GB cứ nằm "chỏng chơ" trong tài khoản, chẳng làm gì cả ngoài việc… chờ tính tiền.
• "Mix Shift" và Tăng đột biến egress ngoài dự kiến: Một case khác mình đọc trên Medium của Jeya Prakash I, cả team đã đối mặt với khoản chi "đội" `170.870 đô la` trong một tháng. `120.250 đô la` trong số đó đến từ việc team engineering "chuyển dịch" workload sang các instance GPU P4d mạnh mẽ để phục vụ cho các dự án AI/ML lớn. Tăng tài nguyên thì tăng tiền, nhưng đôi khi sự chuyển dịch này diễn ra nhanh quá, không có kế hoạch chi phí rõ ràng là cũng dễ vỡ quỹ lắm. Rồi còn `22.050 đô la` do egress tăng vọt ở us-east-1, liên quan trực tiếp đến việc tăng đột biến lượng traffic người dùng. Đây là cái mà mình hay gọi là "chi phí phát sinh do thành công" – traffic tăng thì mừng, nhưng tiền cũng tăng theo chóng mặt nếu không có chiến lược tối ưu.

Tối ưu đâu phải cứ "cắt" là được?

Mục tiêu của FinOps không phải là cấm cản dev hay vận hành làm gì cả. Ngược lại. FinOps hướng đến việc tạo ra một quy trình mà ở đó, các nhà phát triển vẫn có thể truy cập tài nguyên nhanh chóng để triển khai tính năng mới, còn đội tài chính và nền tảng thì vẫn có "rào chắn" để tiền không bị đốt vô tội vạ. Mình thấy cách này hay ở chỗ, nó không bắt dev phải bó tay bó chân, mà là tối ưu hóa cách dùng tài nguyên.

Một trong những "chìa khóa" quan trọng ở đây là tagging (gắn thẻ). Cứ thử tưởng tượng nhé, cả trăm con server, bao nhiêu cái database, bao nhiêu cái bucket S3… làm sao mà biết cái nào thuộc dự án nào, của team nào? Gắn thẻ đầy đủ sẽ giúp mình phân loại và biết tiền đang chảy về đâu. Ban đầu, các kỹ sư của team NAT-Insight đã "than phiền mười phút" khi bị yêu cầu gắn thẻ cho tất cả tài nguyên. Nhưng sau đó thì sao? Họ cũng phải học cách gắn thẻ thôi. Bởi vì nếu không có nó, việc truy vết chi phí là gần như không thể.

À, một cái nhiều bạn hay quên, đó là guardrails (rào chắn tự động). Spacelift.io có nói đến việc nhúng "policy-as-code" như Open Policy Agent (OPA) vào các quy trình IaC (Infrastructure as Code). Tức là, ngay từ bước mình định cấp phát tài nguyên, hệ thống sẽ kiểm tra xem cấu hình đó có "đúng chuẩn" không. Ví dụ: mình không được phép dùng loại hardware tier chưa được duyệt, hoặc cái tài nguyên mình sắp tạo sẽ khiến team vượt quá ngân sách được giao. Nếu vi phạm, nó sẽ tự động chặn lại. "Phòng bệnh hơn chữa bệnh" mà.

FinOps trong hành động: Biến tiền "ngu" thành tiền "khôn"

Vậy thì làm sao để biến những bài học trên thành hành động cụ thể, giúp mình kiểm soát ví tiền đám mây tốt hơn? Dưới đây là vài thứ mình thấy rất hiệu quả:

1. Thiết lập cảnh báo chi phí và phát hiện "điều bất thường"

Đây là thứ cơ bản nhất mà ai cũng nên làm. AWS Budgets (hoặc các dịch vụ tương tự của nhà cung cấp khác) cho phép mình đặt ngưỡng chi phí. Ví dụ, mình có thể thiết lập cảnh báo khi chi phí của tài khoản vượt quá một con số nhất định, hoặc khi chi phí dự kiến (forecasted) sẽ vượt ngưỡng vào cuối tháng. Mình có thể cấu hình để nhận thông báo qua email cho cả team vận hành và team tài chính.

Còn hơn thế, có cả AWS Cost Anomaly Detection, nó sẽ gửi cảnh báo khi phát hiện những "điều bất thường" trong chi phí. Ví dụ, tự nhiên hôm nay tiền egress tăng vọt mà mình không hề có chiến dịch hay sự kiện gì đặc biệt. Những cảnh báo này giúp mình phản ứng nhanh, không để tiền cứ thế "chảy" hàng giờ.

2. Tự động hóa việc "dọn dẹp"

Nhớ cái vụ EBS volume "mồ côi" với `1.500 đô la` không? Hay cái con GPU "zombie" `8.700 đô la`? Mình có thể tự động hóa việc "dọn dẹp" những tài nguyên không dùng tới. Bài của NAT-Insight kể họ đã viết một hàm Lambda function, cứ `6 tiếng` là quét toàn bộ môi trường. Nếu nó tìm thấy một tài nguyên nào đó không có các thẻ (tag) yêu cầu, nó sẽ tự động tắt hoặc xóa đi. Kết quả là chi phí "không phân bổ" (Unallocated Spend) của họ gần như về con số 0. Đây là một đoạn mã giả định mà mình nghĩ có thể trông giống như một phần trong log của hàm Lambda đó:

INFO: Scanning resources for missing tags...
WARNING: Resource 'i-xxxxxxxxxxxxxxxxx' (EC2 Instance) missing required tag 'Project'. Shutting down.
WARNING: Resource 'vol-yyyyyyyyyyyyyyyyy' (EBS Volume) missing required tag 'Owner'. Deleting.
INFO: Scan complete. Total 2 untagged resources remediated.

Cách này không tuyệt đối hoàn hảo, vì đôi khi có tài nguyên cần chạy nhưng vì lý do nào đó lại thiếu tag. Nhưng nó ép cả team phải có kỷ luật gắn tag, và quan trọng nhất là không để tài nguyên "chết" mà vẫn tính tiền.

3. Tối ưu hóa các cam kết sử dụng (Commitment Mapping)

Trong trường hợp chi phí tăng do việc "chuyển dịch" sang các loại instance đắt tiền như P4d GPU cho AI/ML, Jeya Prakash I có đề xuất sử dụng "Savings Plan" hoặc "Reserved Instances". Đại loại là, nếu mình biết chắc sẽ dùng một loại tài nguyên nào đó trong thời gian dài (1 hoặc 3 năm), mình có thể cam kết trước để được giảm giá rất nhiều, có thể lên đến `30%` so với giá on-demand. Đây là chiến lược giúp biến "chi phí cao" thành "chi phí hợp lý".

4. Tối ưu hóa CDN và Egress

Với những "cú sốc" từ egress, việc xem xét tối ưu CDN (Content Delivery Network) là cực kỳ cần thiết. Ví dụ, dùng CloudFront caching (của AWS) để giảm chi phí truyền tải dữ liệu. Càng nhiều dữ liệu được serve từ CDN gần người dùng, càng ít phải truyền tải từ vùng gốc, tiền egress sẽ giảm đáng kể.

Từ $12.000 bất ngờ đến ví tiền kiểm soát

Quay lại câu chuyện `12.000 đô la` ban đầu. Nếu team đó đã áp dụng các nguyên tắc FinOps, câu chuyện có thể đã khác rất nhiều. Các cảnh báo ngân sách có thể đã báo động sớm khi chi phí tăng đột biến do GPU "zombie" chạy không tải. Hàm Lambda tự động có thể đã tắt những instance không có tag, không để chúng ngốn `8.700 đô la` trong 3 ngày cuối tuần. Và việc theo dõi chi phí egress có thể đã chỉ ra khoản `2.200 đô la` "thuế liên vùng" sớm hơn, từ đó có chiến lược tối ưu hóa ngay lập tức.

Thực tế là, đám mây không còn là một nơi đơn thuần để "đẩy code lên" nữa. Nó là một kiến trúc tài chính mà bất kỳ ai làm việc với nó cũng cần phải hiểu. Mình thấy, nếu anh em kỹ sư không hiểu được chi phí của một câu truy vấn `JOIN` trong database hay cái phí egress khi dùng mô hình AI đa vùng, thì nói thật, họ không phải là những kỹ sư "senior" thực thụ – họ chỉ là những "người có sở thích tốn kém" mà thôi. FinOps không phải là một giải pháp "thần thánh" mà là một tư duy, một quy trình giúp mình và team biến những khoản chi bất ngờ thành chi phí có kiểm soát, từ đó khai thác được tối đa giá trị của đám mây.