FinOps là gì: Giải pháp tối ưu chi phí đám mây không phải ai cũng biết

Bạn có đang đau đầu với hóa đơn đám mây?

Chào bạn, mình là Minh, một người đã lăn lộn với đủ thứ server game, hosting, cloud từ những ngày đầu. Nói thật, cái cảm giác mở hóa đơn cuối tháng ra mà cứ như mở "hộp Pandora" thì ai làm vận hành chả ít nhất một lần gặp phải. Có những lúc, mình cứ ngỡ là đã "cân đo đong đếm" kỹ lắm rồi, nhưng rồi đâu đó một con dịch vụ nhỏ, một cái máy ảo chạy quên tắt, hoặc một vài GB dữ liệu chuyển đi chuyển lại… nó cũng đủ làm mình "méo mặt".

Hồi trước, mình cứ nghĩ chỉ cần biết tắt cái gì không dùng, nâng cấp gói khi cần là đủ. Nhưng đến khi quản lý nhiều dự án, nhiều server hơn, đặc biệt là khi chuyển hẳn sang "chơi lớn" với đám mây, mình nhận ra: cách làm đấy không ổn. Nó không hiệu quả. Cái mình cần không phải là "giảm giá" hay "tiết kiệm", mà là "tối ưu giá trị". Tức là làm sao để mỗi đồng mình bỏ ra trên cloud, nó phải "đẻ" ra giá trị tương xứng cho công việc mình làm.

Đó cũng là lúc mình bắt đầu tìm hiểu về FinOps. Nghe có vẻ "chanh sả" và hơi "business" đúng không? Nhưng tin mình đi, nó là thứ mà mọi người làm vận hành, từ anh em admin server game cho tới mấy ông quản lý hạ tầng lớn đều nên biết.

FinOps, nghe lạ mà quen

FinOps nói nôm na là "Kỹ thuật tài chính đám mây". Nó là một cái tên khá mới, nhưng bản chất thì vẫn xoay quanh việc quản lý chi phí. Khác cái là, nó không còn là chuyện của mỗi ông kế toán hay ông sếp ngồi duyệt chi nữa. FinOps là sự hợp tác giữa ba "nhà": tài chính, kỹ thuật và kinh doanh.

Thay vì chỉ đơn thuần là "cắt giảm", FinOps giúp mình nhìn xuyên suốt hơn vào chi phí. Hiểu xem tiền của mình đang chảy đi đâu. Tốn vào cái gì. Cái nào cần. Cái nào không. Quan trọng hơn, nó giúp mình biến các số liệu chi phí thành những quyết định "có giá trị" cho công việc.

Một ông bạn trên diễn đàn nước ngoài mình hay theo dõi từng nói: "Cloud cho chúng ta khả năng mở rộng vô hạn, nhưng cũng cho chúng ta khả năng đốt tiền vô hạn". Thật đúng quá. FinOps chính là cái "phao" giúp mình không bị "chết chìm" trong mớ hóa đơn đó.

"Thẻ bài" tài nguyên: Chìa khóa vàng để kiểm soát chi phí

Nếu bạn đã và đang dùng cloud, chắc hẳn bạn biết tới cái gọi là "tag" hay "thẻ" tài nguyên. Lúc đầu mình cũng nghĩ nó rườm rà. Gắn thẻ làm gì cho mệt? Nhưng đến khi hóa đơn nhảy nhót lung tung, mình mới hiểu: tag chính là chìa khóa để mình thực sự thấy được tiền của mình đang đi đâu. Đây chính là điểm mình muốn "khoan sâu" một chút.

Thử hình dung thế này: Bạn có 5 cái máy ảo, 3 cái database, 2 cái storage… Nếu không gắn tag, tất cả chi phí cứ đổ vào một đống chung. Lúc đó mình chỉ biết "tổng" là bao nhiêu, chứ không thể biết "cái máy ảo chạy server A" tốn bao nhiêu, "database của server B" tốn bao nhiêu. Rồi project này, project kia. Cứ gọi là "nhức cái đầu".

Một trong những "best practice" mà mình đọc được từ tài liệu của AWS về quản lý tài chính đám mây là phải xây dựng một "từ điển thẻ" (tagging dictionary) và thống nhất các giá trị của tag. Nghe có vẻ to tát, nhưng đơn giản là: mình sẽ quy định những loại tag nào cần có (ví dụ: `Project`, `Environment`, `Owner`, `CostCenter`), và mỗi loại tag thì có những giá trị nào được phép (ví dụ: `Project` có thể là `GameServerA`, `GameServerB`; `Environment` có thể là `Production`, `Development`, `Staging`).

Khi mình vào `AWS Cost Explorer`, mình có thể dùng những tag này để lọc và nhóm chi phí. Ví dụ:

DIMENSION: TAG, KEY: Project, VALUE: GameServerA

Cái "chiêu" này giúp mình thấy ngay lập tức: à, hóa ra chi phí cho GameServerA tháng này là X USD. Hoặc thậm chí, mình có thể nhóm theo cả `Project` và `Environment` để biết server production của GameServerA đang "ngốn" bao nhiêu. Điều này hoàn toàn không thể làm được nếu mình không có hệ thống tag rõ ràng.

Mình từng gặp một case, hồi mình "chuyển nhà" cho một cái world Minecraft 4GB từ một máy ảo cũ sang máy mới cấu hình cao hơn. Tưởng là xong. Vài tháng sau, tự dưng thấy hóa đơn tăng "vọt". Tìm mãi không ra. Mãi sau mới phát hiện: mình quên không tắt cái máy ảo cũ. Nó cứ nằm đấy, chạy rề rề, không ai dùng nhưng tiền thì cứ đều đặn "chảy". Nếu lúc đó mình có tag `Environment: Development` hay `Status: Obsolete`, rồi lọc trên `Cost Explorer` thì đã phát hiện ra ngay.

Dựng "hàng rào" ngân sách: Không sợ "vỡ nợ"

Gắn thẻ xong thì mình có "bản đồ" chi phí rồi. Giờ cần cái "hàng rào" để không bị "chạy quá đà". Đó chính là ngân sách (budget) và dự báo (forecast). Mình dùng `AWS Budgets` để làm việc này.

Cái hay của việc thiết lập ngân sách là nó không chỉ là một con số khô khan. Mình có thể đặt "ngưỡng" cho từng dịch vụ, từng khu vực, thậm chí là từng cái tag mà mình đã gắn ở trên. Ví dụ:

Set budget: 500 USD
Time period: Monthly
Filter: Service = EC2, Region = ap-southeast-1, Tag: Environment = Production

Tức là mình chỉ muốn chi 500 USD/tháng cho tất cả các máy EC2 chạy production ở khu vực Singapore thôi. Nếu chi phí ước tính (forecasted cost) hoặc chi phí thực tế (actual cost) sắp vượt quá ngưỡng này (ví dụ, đạt 80% hoặc 100%), hệ thống sẽ tự động gửi email hoặc thông báo cho mình.

Ngân sách thường cố định trong một khoảng thời gian (ví dụ một năm), nhưng dự báo thì linh hoạt hơn nhiều. Nó dùng các thuật toán dựa trên lịch sử chi phí hoặc các yếu tố "động" (như ra mắt sản phẩm mới, mở rộng khu vực) để đưa ra con số ước tính. Điều này giúp mình chủ động hơn trong việc điều chỉnh kế hoạch, thay vì "há hốc mồm" khi hóa đơn về tay.

Mình nhớ có lần đọc một case trên GitHub issue của một plugin Minecraft. Một bạn admin phàn nàn là server của bạn ấy "ngốn" tiền S3 khủng khiếp, vượt xa dự kiến. Sau đó, một người khác chỉ cho bạn ấy cách dùng `AWS Budgets` để đặt cảnh báo. Vài ngày sau, bạn ấy phát hiện ra một script backup cũ, chạy hằng giờ và cứ thế đẩy data lên S3 không kiểm soát. Nhờ cái cảnh báo vượt ngưỡng, bạn ấy đã kịp thời phát hiện và dừng lại trước khi "bay" thêm vài trăm đô la vô ích. Đó là sức mạnh của việc "theo dõi chi phí một cách chủ động" (monitor cost proactively) mà tài liệu của AWS nhắc tới.

Vận hành FinOps: Đâu chỉ là số má

Công cụ, thẻ, ngân sách… tất cả đều quan trọng. Nhưng FinOps không chỉ là chuyện của các con số hay cấu hình. Nó là một "văn hóa". Phải, là văn hóa "nhận thức chi phí" (cost-aware culture) trong toàn bộ đội ngũ.

Tức là không phải mỗi mình mình hay ông sếp phải đau đáu chuyện tiền nong. Mà từ người dev viết code, người vận hành triển khai, cho đến người quản lý sản phẩm… ai cũng cần hiểu hành động của mình sẽ ảnh hưởng thế nào đến chi phí. Có thể là một dòng code tối ưu hơn, một cách dùng tài nguyên hợp lý hơn, hay đơn giản là "nhớ tắt máy ảo dev khi không dùng nữa" (cái này mình hay dặn team lắm, toàn quên!).

Tài liệu của AWS cũng nhấn mạnh việc "xây dựng một team FinOps" hoặc ít nhất là chỉ định người chịu trách nhiệm. Team này cần có người từ tài chính, kỹ thuật và kinh doanh, cùng nhau xây dựng chương trình giáo dục, các tiêu chuẩn chung về monitoring và reporting. Nghe thì có vẻ "to tát" nhưng mình nghĩ, với các team nhỏ, ít nhất là mình và một hai đồng nghiệp hiểu và cùng áp dụng các nguyên tắc này là đủ.

Đừng phức tạp hóa. Hãy bắt đầu từ những việc nhỏ như gắn tag, đặt budget, và thường xuyên nhìn vào `Cost Explorer`.

Kết cục cho "cơn đau đầu" buổi sáng

Quay lại câu chuyện "hộp Pandora" hóa đơn đầu tháng mà mình kể ban đầu. Sau khi áp dụng các nguyên tắc của FinOps, dù chưa thể nói là "hoàn hảo" nhưng ít nhất, mình đã không còn cái cảm giác hồi hộp, lo sợ khi mở email thông báo chi phí nữa. Mình có thể dễ dàng kiểm tra chi phí của từng server game, từng dịch vụ, và quan trọng hơn là mình biết "tại sao" nó lại như thế.

Có những lúc, chi phí tăng là đúng, vì mình vừa mở thêm server mới, mở rộng ra khu vực khác. Nhưng có những lúc chi phí tăng bất thường, và mình có thể nhận ra ngay nhờ các thông báo từ `AWS Budgets` hay việc lọc trên `Cost Explorer` với các tag đã định nghĩa. Nó không phải là "giải pháp thần kỳ" để không phải trả tiền cloud, mà là "giải pháp thông minh" để tiền mình bỏ ra được dùng đúng và hiệu quả nhất.

Vậy nên, nếu bạn cũng đang vật lộn với chi phí đám mây, đừng ngần ngại tìm hiểu và bắt đầu áp dụng FinOps. Từ những cái "tag" nhỏ nhất, cho đến việc thiết lập những "ngân sách" cụ thể. Tin mình đi, đầu tháng bạn sẽ nhẹ nhõm hơn nhiều.