FinOps là một thực hành quản trị, trong đó kỹ sư, bộ phận tài chính và người phụ trách kinh doanh cùng chịu trách nhiệm về chi tiêu đám mây, dựa trên dữ liệu chi phí gần như theo thời gian thực, để mỗi đồng chi ra tạo được giá trị tương xứng. Mục tiêu của FinOps không phải là chi ít nhất, mà là chi có chủ đích: có lúc tăng chi để ra sản phẩm nhanh hơn là quyết định đúng.
Thực hành này ra đời vì đám mây phá vỡ quy trình mua sắm cũ. Trước đây, mua máy chủ phải qua phê duyệt ngân sách, đấu thầu, ký hợp đồng; giờ một kỹ sư có thể tạo tài nguyên trị giá hàng chục triệu đồng mỗi tháng bằng vài dòng lệnh. Quyền chi tiêu đã phân tán xuống người viết mã, nên trách nhiệm chi tiêu cũng phải phân tán theo.
Thuật ngữ được định hình bởi FinOps Foundation, thành lập năm 2019 và về sau trở thành một dự án của Linux Foundation, cùng cuốn Cloud FinOps của J.R. Storment và Mike Fuller (O'Reilly, 2019). Bài này giải thích ba giai đoạn của vòng FinOps, các vai trò, cách phân bổ chi phí và lộ trình áp dụng cho doanh nghiệp Việt Nam cỡ vừa.
Vì sao chi phí đám mây cần một cách quản trị riêng
Ba đặc điểm khiến chi phí đám mây khác chi phí công nghệ truyền thống. Thứ nhất là biến đổi: hoá đơn thay đổi theo giờ, theo tải và theo từng quyết định kỹ thuật nhỏ như chọn cỡ máy, chọn lớp lưu trữ, bật nhật ký chi tiết. Thứ hai là phân tán: người ra quyết định chi tiêu là kỹ sư, không phải phòng mua sắm, và họ thường không thấy giá khi ra quyết định. Thứ ba là phức tạp: một hoá đơn có thể có hàng trăm nghìn dòng, với đơn vị tính khác nhau cho tính toán, lưu trữ, truyền dữ liệu, yêu cầu gọi hàm.
Hệ quả điển hình ở doanh nghiệp mới lên đám mây là cuối tháng phòng tài chính nhận hoá đơn cao bất thường, hỏi phòng kỹ thuật, và không ai trả lời được khoản tăng thuộc về dự án nào. Phản ứng tự nhiên là siết phê duyệt, quay về quy trình mua sắm cũ, và đánh mất chính tốc độ là lý do lên đám mây.
FinOps đi theo hướng ngược lại: không lấy lại quyền chi tiêu từ kỹ sư, mà trả cho họ thông tin chi phí kịp thời và gắn với hệ thống họ phụ trách, đồng thời cho tài chính và kinh doanh một ngôn ngữ chung để nói về đánh đổi giữa chi phí, tốc độ và chất lượng.
Ba giai đoạn: Inform, Optimize, Operate
Inform — thấy và phân bổ. Mục tiêu là trả lời được câu hỏi "ai chi bao nhiêu cho việc gì". Việc chính là gắn thẻ tài nguyên theo dự án, sản phẩm, môi trường và trung tâm chi phí; xây báo cáo theo các chiều đó; phân bổ cả những khoản dùng chung như mạng, giám sát, hỗ trợ kỹ thuật. Không có giai đoạn này, mọi nỗ lực tối ưu sau đó đều là đoán.
Optimize — tối ưu. Khi đã thấy, tìm cách giảm lãng phí và tăng hiệu quả: thu nhỏ máy dư công suất, tắt tài nguyên mồ côi, chuyển dữ liệu ít truy cập sang lớp lưu trữ rẻ, mua cam kết sử dụng cho phần tải nền ổn định. Mỗi đề xuất tối ưu cần được người phụ trách hệ thống xác nhận, vì họ biết máy nào nhàn rỗi thật và máy nào đang chờ một đợt tải.
Operate — vận hành liên tục. Đưa các thực hành trên thành quy trình: ngân sách và cảnh báo cho từng nhóm, chính sách bắt buộc gắn thẻ, đánh giá chi phí trong thiết kế kiến trúc, họp định kỳ giữa kỹ thuật và tài chính, chỉ số theo dõi được đưa vào mục tiêu của các nhóm. Đây là giai đoạn biến những đợt "dọn dẹp" rời rạc thành văn hoá.
Đây là vòng lặp, không phải bậc thang. Một doanh nghiệp có thể đang ở giai đoạn vận hành với hệ thống cũ nhưng lại quay về giai đoạn thấy và phân bổ với một sản phẩm mới. FinOps Foundation cũng mô tả mức độ trưởng thành theo ba cấp "crawl, walk, run", khuyên bắt đầu nhỏ và chỉ nâng cấp khi giá trị thu về xứng đáng.
Showback hay chargeback: hai cách trả chi phí về cho các nhóm
Sau khi phân bổ được chi phí, doanh nghiệp phải chọn mức độ "trả hoá đơn" về cho các nhóm. Hai cách phổ biến có tác động hành vi khác nhau.
| Tiêu chí | Showback | Chargeback |
|---|---|---|
| Bản chất | Báo cho các nhóm biết họ đã dùng bao nhiêu | Trừ thật vào ngân sách hoặc kết quả kinh doanh của nhóm |
| Yêu cầu dữ liệu | Phân bổ đủ tốt, chấp nhận sai số | Phân bổ chính xác, có quy tắc chia chi phí chung được đồng thuận |
| Tác động hành vi | Tạo nhận thức, dựa vào động lực tự thân | Tạo động lực mạnh, nhưng dễ sinh tranh cãi về cách chia |
| Rủi ro | Bị lờ đi nếu không ai hỏi đến | Nhóm né dịch vụ dùng chung có lợi cho toàn công ty để bớt chi phí của mình |
| Hợp với | Giai đoạn đầu, doanh nghiệp một sản phẩm | Tập đoàn nhiều đơn vị kinh doanh có hạch toán riêng |
Đa số doanh nghiệp nên bắt đầu bằng showback trong vài quý, cho tới khi tỷ lệ chi phí được gắn thẻ đủ cao và các nhóm tin vào con số. Chuyển sang chargeback khi dữ liệu còn nhiều khoản "không xác định" thường làm các cuộc họp chuyển từ tối ưu sang cãi nhau về cách chia.
Phần chi phí dùng chung (mạng lõi, giám sát, đội nền tảng, hợp đồng hỗ trợ) nên được chia theo một quy tắc đơn giản, công bố trước, ví dụ theo tỷ lệ chi phí trực tiếp của từng nhóm. Quy tắc đơn giản và ổn định có giá trị hơn quy tắc chính xác nhưng đổi liên tục.
Chỉ số đơn vị: thước đo quan trọng nhất của FinOps
Tổng hoá đơn đám mây tăng chưa chắc là tin xấu. Nếu doanh nghiệp thương mại điện tử tăng gấp đôi số đơn hàng mà hoá đơn chỉ tăng một nửa, chi phí trên mỗi đơn đã giảm. Vì vậy FinOps khuyến khích theo dõi chi phí đơn vị: chi phí hạ tầng chia cho một đại lượng nghiệp vụ như đơn hàng, người dùng hoạt động hằng tháng, giao dịch, giờ video phát, hồ sơ xử lý.
Ví dụ giả định: một ứng dụng giao hàng có hoá đơn đám mây tháng 3 là 400 triệu đồng với 2 triệu đơn, tức 200 đồng mỗi đơn. Tháng 9, hoá đơn lên 560 triệu đồng nhưng số đơn đạt 3,5 triệu, chi phí mỗi đơn giảm còn 160 đồng. Nhìn tổng hoá đơn, tài chính sẽ lo; nhìn chi phí đơn vị, đây là dấu hiệu kiến trúc đang co giãn tốt. Ngược lại, chi phí đơn vị tăng dần trong khi tải ổn định là tín hiệu lãng phí đang tích tụ.
Chọn đại lượng mẫu số là một quyết định kinh doanh, không phải kỹ thuật. Nó phải là thứ lãnh đạo quan tâm và gắn với doanh thu hoặc giá trị. Với nền tảng phần mềm cho doanh nghiệp, chi phí trên mỗi khách hàng trả phí giúp tính được biên lợi nhuận gộp theo từng gói; với hệ thống nội bộ, chi phí trên mỗi nhân viên sử dụng giúp so sánh với phương án mua phần mềm dịch vụ.
Vai trò và ai làm gì
FinOps không phải một phòng ban mà là sự phối hợp. Ở doanh nghiệp vừa, một vài người kiêm nhiệm là đủ; ở tổ chức lớn mới cần một nhóm chuyên trách.
- Người thực hành FinOps (FinOps practitioner): xây báo cáo, duy trì quy tắc gắn thẻ và phân bổ, tìm cơ hội tối ưu, điều phối họp định kỳ. Thường là người hiểu cả hoá đơn đám mây lẫn kế toán quản trị.
- Kỹ sư và trưởng nhóm sản phẩm: chịu trách nhiệm chi phí của hệ thống mình, xem xét đề xuất tối ưu, đưa chi phí vào tiêu chí thiết kế cùng với hiệu năng và độ tin cậy.
- Tài chính: lập ngân sách và dự báo theo cách chi biến đổi, hạch toán cam kết sử dụng dài hạn, đối soát hoá đơn, hiểu rằng ngân sách đám mây không thể cố định như ngân sách thiết bị.
- Mua sắm: đàm phán hợp đồng khung, chiết khấu theo cam kết, điều khoản thoát và phí truyền dữ liệu.
- Lãnh đạo: đặt mục tiêu chi phí đơn vị, quyết định đánh đổi khi tốc độ và chi phí xung đột, bảo vệ văn hoá không đổ lỗi khi phát hiện lãng phí.
Điểm cuối cùng quan trọng hơn vẻ ngoài của nó. Nếu mỗi lần phát hiện một cụm máy quên tắt là một lần tìm người chịu phạt, kỹ sư sẽ học cách giấu chi phí thay vì báo cáo. Các tài liệu FinOps nhấn mạnh trách nhiệm chung và minh bạch hơn là kiểm soát.
Lộ trình 90 ngày cho doanh nghiệp cỡ vừa
Lộ trình dưới đây giả định doanh nghiệp đã chạy đám mây được một thời gian, hoá đơn đủ lớn để đáng quan tâm nhưng chưa có ai phụ trách chi phí.
- Tuần 1–2: chỉ định một người phụ trách, có quyền xem toàn bộ dữ liệu hoá đơn. Xuất dữ liệu chi tiết vào một kho phân tích để không bị giới hạn bởi bảng điều khiển của nhà cung cấp.
- Tuần 3–4: thống nhất bộ thẻ tối thiểu, thường là dự án, môi trường, chủ sở hữu và trung tâm chi phí. Đo tỷ lệ chi phí đã gắn thẻ hiện tại làm mốc.
- Tuần 5–8: gắn thẻ bù cho tài nguyên cũ, bật chính sách bắt buộc gắn thẻ cho tài nguyên mới, gửi báo cáo showback hằng tuần cho từng nhóm.
- Tuần 9–10: chạy một đợt tối ưu tập trung vào ba nguồn lãng phí dễ nhất: tài nguyên mồ côi, môi trường thử nghiệm chạy ngoài giờ, máy dư công suất rõ rệt.
- Tuần 11–12: chọn một chỉ số chi phí đơn vị, đặt ngân sách và cảnh báo cho từng nhóm, lên lịch họp tháng giữa kỹ thuật và tài chính.
Sau 90 ngày, chỉ số nên theo dõi là tỷ lệ chi phí được phân bổ, số tiền tối ưu đã thực hiện so với đề xuất, và xu hướng chi phí đơn vị. Mua cam kết dài hạn nên để sau khi đã dọn dẹp, vì cam kết trên tải đang lãng phí là khoá chặt lãng phí trong một đến ba năm.
Câu hỏi thường gặp
FinOps có phải chỉ dành cho doanh nghiệp có hoá đơn đám mây rất lớn?
Không. Nguyên tắc thấy, phân bổ và chịu trách nhiệm áp dụng được ở mọi quy mô; chỉ mức đầu tư khác nhau. Doanh nghiệp nhỏ có thể làm FinOps bằng quy tắc gắn thẻ, cảnh báo ngân sách và một buổi xem hoá đơn mỗi tháng, không cần công cụ hay nhân sự riêng.
Công cụ của nhà cung cấp có đủ cho FinOps không?
Đủ cho giai đoạn đầu: xem chi phí theo thẻ, đặt ngân sách, nhận gợi ý thu nhỏ máy. Khi dùng nhiều nhà cung cấp hoặc cần phân bổ chi phí dùng chung phức tạp, doanh nghiệp thường xuất dữ liệu ra kho riêng hoặc dùng công cụ bên thứ ba để có một góc nhìn thống nhất.
FOCUS là gì trong FinOps?
Đó là một đặc tả dữ liệu chi phí dùng chung do FinOps Foundation khởi xướng, nhằm chuẩn hoá cách các nhà cung cấp đám mây và phần mềm mô tả dòng hoá đơn. Mục tiêu là để doanh nghiệp gộp chi phí từ nhiều nguồn mà không phải viết bộ chuyển đổi riêng cho từng nhà cung cấp.
Dự báo chi phí đám mây thế nào khi tải thay đổi liên tục?
Tách hoá đơn thành phần nền ổn định và phần biến đổi theo đại lượng nghiệp vụ. Phần nền dự báo theo xu hướng; phần biến đổi dự báo bằng kế hoạch kinh doanh nhân với chi phí đơn vị. Cách này giúp tài chính hiểu vì sao hoá đơn tăng khi doanh số tăng.
Ai nên sở hữu ngân sách đám mây: phòng công nghệ hay các đơn vị kinh doanh?
Xu hướng chung là đơn vị nào hưởng lợi từ hệ thống thì chịu chi phí của hệ thống đó, còn phòng công nghệ sở hữu phần nền tảng dùng chung. Mô hình này chỉ chạy khi dữ liệu phân bổ đủ tin cậy, nên thường đi sau một thời gian showback.
FinOps có liên quan gì đến phát thải carbon không?
Ngày càng liên quan. Nhiều nhà cung cấp đã đưa ra ước tính phát thải theo mức dùng, và các tài nguyên lãng phí vừa tốn tiền vừa tốn điện. Tuy vậy, phương pháp ước tính giữa các nhà cung cấp chưa thống nhất, nên con số phát thải nên được dùng để so xu hướng hơn là so tuyệt đối.