Triển khai FinOps không đơn giản: Những thách thức và cách vượt qua

Hồi mới bén duyên với mấy cái server game, cloud miết, mình cũng từng thấy chóng mặt vì hóa đơn cuối tháng. Số tiền thì nhảy nhót không ngừng, lúc cao lúc thấp, mà tra mãi không biết tiền nó đi đâu. Mấy anh em dev thì cứ bảo “server cần cấu hình mạnh để chịu tải game,” còn sếp tài chính thì nhíu mày hỏi “sao chi phí IT tăng liên tục thế em?” Nói thật: mình đứng giữa chẳng biết giải thích sao cho xuôi cả hai bên.

Đó là câu chuyện của nhiều năm về trước. Giờ thì mình đã quen hơn với mớ bòng bong này. Mà cái gì khiến mình bớt đau đầu hơn á? Chính là FinOps. Nghe thì có vẻ cao siêu, nhưng thực chất, nó là cách mình học được để “bắt” tiền cloud làm việc hiệu quả hơn, chứ không phải cứ chạy vù vù rồi tháng sau than trời. Nhưng mà, triển khai nó không hề đơn giản đâu nhé. Có những lúc mình cũng muốn buông xuôi lắm.

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

Đầu tiên, phải nói thẳng: FinOps không phải là một phần mềm hay một công cụ thần thánh nào cả. Nó là một văn hóa, một cách mình thay đổi suy nghĩ về tiền bạc trên cloud. Thử tưởng tượng mà xem, bên kỹ thuật thì muốn chạy nhanh, triển khai cái mới liên tục; bên tài chính thì muốn kiểm soát chặt, chi đồng nào xắt ra đồng đó. FinOps là cầu nối giữa hai thế giới này.

Theo định nghĩa từ FinOps Foundation, nơi quy tụ nhiều chuyên gia đầu ngành, FinOps là “một khuôn khổ vận hành và thực hành văn hóa nhằm tối đa hóa giá trị kinh doanh của công nghệ, cho phép ra quyết định dựa trên dữ liệu kịp thời, và tạo ra trách nhiệm tài chính thông qua sự hợp tác giữa các đội ngũ kỹ thuật, tài chính và kinh doanh.” Nghe hơi dài, đúng không? Nhưng cốt lõi là vậy đó: mọi người cùng có trách nhiệm với chi phí và giá trị công nghệ mang lại.

Cái tên FinOps cũng nói lên tất cả: là sự kết hợp của “Finance” (tài chính) và “DevOps” (phát triển và vận hành). Nó không chỉ là tiết kiệm tiền, mà là làm sao để mỗi đô la mình chi ra trên cloud đều mang lại giá trị lớn nhất cho business. Tiết kiệm là một phần, nhưng hiểu rõ “tại sao” lại chi từng đó tiền và “nó mang lại cái gì” mới là cái quan trọng hơn nhiều.

Điểm chết lớn nhất: Ai cũng thấy khó hiểu

Khi mình nói chuyện với các bạn dev về FinOps, nhiều người cứ nghĩ “lại thêm một cái quy trình rắc rối để kiểm soát tụi mình.” Còn các bạn tài chính thì cứ muốn “ngừng hết mấy cái server không cần thiết đi.” Đúng là một mớ bòng bong.

Thách thức lớn nhất mình thấy khi bắt đầu với FinOps là thiếu sự rõ ràng. Ai cũng thấy cloud là đắt đỏ, nhưng tiền đi đâu, về đâu thì lại mờ mịt. Hồi trước, mình cũng từng có một case dở khóc dở cười. Server game của mình chạy trên một cụm máy ảo khá lớn, và đến cuối tháng, hóa đơn tăng vọt không báo trước. Khi đào sâu vào, mình phát hiện ra một team dev đã lỡ tay bật thêm vài con VM cấu hình khủng để test một tính năng mới, rồi quên tắt. Mấy con VM đó chạy ầm ầm cả tuần, ngốn hết sạch tiền mà không ai biết.

Một báo cáo của Flexera năm 2025 cũng chỉ ra rằng, nhiều doanh nghiệp coi việc tối ưu chi phí cloud là ưu tiên hàng đầu, nhưng tình trạng vượt ngân sách vẫn diễn ra thường xuyên. Đây là bằng chứng rõ nhất cho thấy FinOps là cần thiết, nhưng lại không hề dễ dàng.

“Tiền đi đâu hết thế?” – Tìm thủ phạm bằng cách nhìn vào ‘cây thư mục’

Cái lúc mình phát hiện ra mấy con VM bị lãng quên kia, mình nghĩ ngay đến việc phải làm sao để không bao giờ gặp lại nữa. Và đó là lúc mình học được cách “gắn thẻ” (tagging) tài nguyên. Nó giống như việc mình dán nhãn cho từng thùng đồ trong nhà kho vậy. Thùng nào của team A, thùng nào của dự án B, thùng nào dùng để test, thùng nào là production.

Đây là một phần cực kỳ quan trọng trong giai đoạn Inform (Thu thập thông tin) của FinOps. Nó không chỉ là nhìn vào báo cáo số liệu chung chung đâu. Mình phải nhìn sâu vào từng tài nguyên. Thử hình dung một dòng lệnh đơn giản thế này:

aws resourcegroupstaggingapi get-resources --resources-per-page 100 --no-tag-filters

Dòng lệnh này (tạm bỏ qua chi tiết về nhà cung cấp) giúp mình liệt kê ra các tài nguyên không được gắn thẻ. Lúc mình chạy nó lần đầu, kết quả trả về dài dằng dặc. Đủ loại server, database, bộ nhớ từ mấy tháng trước, có cái của team cũ, có cái chẳng biết ai dùng. Nhìn thấy cái danh sách này, mình mới giật mình: ồ, hóa ra nhiều tài nguyên cứ “vô chủ” chạy mãi mà không ai hay.

Sau đó, mình ngồi lại với từng team, giải thích về tầm quan trọng của việc gắn thẻ. Kiểu như “anh em mình code xong, deploy xong, làm ơn dán cái nhãn Project A, Owner X, Environment Dev vào giùm mình cái nha.” Nghe thì đơn giản, nhưng để mọi người nhớ và làm đều đặn, đó là một hành trình dài. Mình phải tạo ra quy tắc, rồi kiểm tra, rồi nhắc nhở liên tục. Có khi phải dùng đến cả những công cụ tự động để “cấm” không cho tạo tài nguyên mà không có tag nữa cơ.

Gắn thẻ giúp mình làm được gì? Nó giúp mình phân bổ chi phí về đúng nơi, đúng người. Từ đó, mình có thể tạo ra những báo cáo chi phí cụ thể cho từng dự án, từng team. Kiểu như:

• Báo cáo cho team dev: “Đấy, tháng này team mình tiêu hết X tiền cho mấy con server test, nếu tắt bớt thì có thể tiết kiệm được Y tiền đó.”
• Báo cáo cho sếp tài chính: “Dự án A tháng này tăng chi phí do có chiến dịch marketing mới, nhưng ROI cũng tăng lên Z%.”

Khi có dữ liệu rõ ràng, mọi người sẽ dễ dàng ngồi lại với nhau để bàn bạc, thay vì chỉ trích lẫn nhau. Đó là bước đầu tiên để FinOps thực sự có tác dụng.

Ba giai đoạn vận hành FinOps: Inform, Optimize, Operate

FinOps Foundation cũng đưa ra ba giai đoạn chính mà mình cứ lặp đi lặp lại để quản lý chi phí cloud hiệu quả:

1. Inform (Thu thập thông tin): Như mình vừa kể đó. Phải biết tiền đi đâu đã. Gắn thẻ, thu thập dữ liệu, tạo báo cáo, làm mọi cách để mọi người đều nhìn thấy bức tranh tài chính trên cloud một cách rõ ràng và kịp thời. Nếu dữ liệu không đủ chi tiết, đừng hòng làm gì tiếp theo.
2. Optimize (Tối ưu hóa): Khi đã biết tiền đi đâu rồi, bắt đầu tìm cách “cắt giảm” những thứ không cần thiết hoặc dùng những gói cước thông minh hơn. Chẳng hạn, tắt mấy con server không dùng buổi tối, chuyển sang dùng gói Reserved Instances hoặc Savings Plans nếu mình biết chắc sẽ dùng lâu dài. Hay như, chuyển một số dịch vụ từ máy ảo sang serverless để tiết kiệm. Quan trọng là đừng để nó ảnh hưởng đến hiệu năng của game hay ứng dụng nhé.
3. Operate (Vận hành liên tục): Cái này khó nhất. Tối ưu xong không có nghĩa là xong. Cloud thì cứ thay đổi liên tục, nhu cầu của business cũng vậy. Mình phải biến FinOps thành một phần của công việc hàng ngày. Đặt ra các chính sách tự động, tạo cảnh báo khi chi phí vượt ngưỡng, và quan trọng nhất là thường xuyên ngồi lại với nhau (team dev, team tài chính, team vận hành) để xem xét, điều chỉnh.

Cái vòng lặp này không phải là làm một lần rồi bỏ. Mình cứ làm, cứ cải thiện dần dần. Ban đầu thì “Crawl” (bò), sau đó là “Walk” (đi), rồi mới đến “Run” (chạy). Đừng vội vàng.

Khó khăn lắm, nhưng mình đã vượt qua thế nào?

Mình thấy, những cái khó của FinOps thường xoay quanh con người và thói quen. Đôi khi, mình cũng chán nản lắm. Nhưng cứ nghĩ đến hóa đơn cuối tháng, mình lại có động lực để tìm cách.

• Vấn đề: Team dev nói “tụi em không có thời gian để gắn thẻ hay quan tâm chi phí.”

  Cách mình làm: Mình không bắt các bạn dev phải thành chuyên gia tài chính. Mình chỉ yêu cầu họ cung cấp đủ thông tin để mình gắn thẻ. Ví dụ, khi tạo một project mới, mình yêu cầu điền một form ngắn gọn về mục đích, team phụ trách. Sau đó, mình và team Ops sẽ lo phần gắn thẻ tự động. Quan trọng là cho họ thấy được lợi ích: “Nếu gắn thẻ đầy đủ, tháng sau mình sẽ biết chính xác dự án X tiêu hết bao nhiêu, từ đó có thể đề xuất lên sếp tăng ngân sách cho team mình.” Hoặc là, “nhờ gắn thẻ mà mình phát hiện ra chi phí test tăng vọt, anh em mình cùng tìm cách tối ưu, giảm gánh nặng cho cả team.”

• Vấn đề: Chỉ tập trung vào công cụ, quên mất văn hóa.

  Cách mình làm: Hồi đầu, mình cũng nghĩ cứ mua cái phần mềm quản lý chi phí xịn xò là xong. Ai dè, công cụ chỉ là công cụ. Nó cung cấp số liệu, nhưng không tự động thay đổi hành vi con người. Mình phải tổ chức các buổi training nhỏ, hoặc là buổi “cà phê FinOps” hàng tuần, mỗi lần chỉ 15-20 phút thôi. Cùng nhau xem cái dashboard chi phí, chỉ ra những điểm sáng, những chỗ còn “tiền rơi”. Đôi khi một câu chuyện về “tiền rơi” của một dự án khác lại là động lực cho team mình thay đổi.

• Vấn đề: “Mình không có quyền quyết định, sao mà tối ưu được?”

  Cách mình làm: Đây là lúc cần sự hỗ trợ từ cấp quản lý. Mình trình bày rõ ràng với sếp về tình trạng chi phí, về những gì mình đã tìm ra nhờ việc “Inform” (thu thập thông tin). Ví dụ, mình đưa ra con số cụ thể: “Hàng tháng, có X triệu đồng đang bị lãng phí do các tài nguyên không sử dụng.” Khi có con số, sếp sẽ dễ dàng ủng hộ mình hơn trong việc tạo chính sách, cấp quyền để mình có thể “Optimize” (tối ưu hóa). Cái này cần mình kiên trì thuyết phục, và bằng chứng phải thật cụ thể.

Nói thật, FinOps không phải là một công thức kỳ diệu để giải quyết mọi vấn đề. Nó là một hành trình dài của sự hợp tác, của việc học hỏi từ dữ liệu và điều chỉnh liên tục. Nhưng mình tin, nếu cứ kiên trì theo đuổi, mình sẽ không còn phải đau đầu với những hóa đơn cloud nhảy múa nữa đâu.

Hóa đơn server game tháng vừa rồi của mình? À, nó vẫn tăng đấy, vì game có nhiều người chơi hơn mà. Nhưng mình biết chính xác tiền đó đi đâu, mang lại giá trị gì. Mình có thể tự tin báo cáo cho sếp rằng “chi phí tăng, nhưng doanh thu cũng tăng tương ứng, và chúng ta đang sử dụng tài nguyên rất hiệu quả.” Đó là cái mà FinOps mang lại.