Cuối tuần mang lap ra gõ, đã lâu chưa viết bài chia sẻ. Do qua đột nhiên nghĩ đến chủ đề mà nhiều anh em có thể dính khi bắt đầu kiểu soát sâu hơn hệ thống về mặt chi phí trong thực tế.

Mình có một thói quen là cứ gần cuối tháng là mình mở cloud bill ra xem trước khi ai đó ping trong group. Nói chung cũng không phải tự nhiên mà có thói quen này, mà vì mình đã từng dính một cú cũng đáng nhớ :))

Hồi đó team mình có các bộ phận là tagging, cost dashboard, có cả người phụ trách FinOps ngồi tổng hợp số liệu mỗi tuần. Thế mà chỉ sau một lần release khá bình thường, chi phí log ingestion nhảy vọt. Lúc đầu nhìn chart thì ai cũng đoán do traffic tăng, do campaign, do user nhiều hơn. Nhưng bóc tiếp mới thấy traffic tăng nhẹ, còn bill tăng như kiểu có ai mở vòi nước.

Cuối cùng nguyên nhân lại đến từ một thay đổi nhỏ làm log volume tăng, cộng thêm retention bị giữ lại, cộng thêm vài service retry hơi bừa khiến request và log bị nhân lên. Cái hay là FinOps nhìn ra được service nào tăng, account nào tăng. Cái dở là không ai trong engineering coi đó là bug phải sửa ngay. Mọi người nhìn nó là chuyện bình thường, kiểu tháng này lỡ, tháng sau tính.

Từ lần đó mình chốt một quan điểm, FinOps không cứu được chi phí nếu engineering không coi cost là bug.

Với mình, cost là bug

Mình không coi bug chỉ là service down.

Bug là bất cứ thứ gì làm hệ thống vượt khỏi ràng buộc đã cam kết. Ràng buộc không chỉ có uptime, mà còn có performance và cost.

• Performance bug: p95 tăng 2x
• Reliability bug: error rate tăng
• Cost bug: unit cost tăng mà không ai chịu trách nhiệm

Điểm mấu chốt nằm ở unit cost, tức là chi phí cho một đơn vị giá trị của sản phẩm. Mình gặp nhiều nơi nhìn tổng bill theo tháng, rồi ngồi tranh luận xem tháng này cao do gì.

Unit cost có thể là:

• cost / 1 giao dịch
• cost / 1 active user
• cost / 1k requests
• cost / 1 GB ingested
• cost / 1 job

Khi có unit cost, mình mới trả lời được liệu release này có làm chi phí trên mỗi đơn vị giá trị của sản phẩm tăng lên hay không.

Vì sao FinOps không cứu được chi phí?

Mình đánh giá FinOps rất quan trọng. Nhưng mình cũng thấy rõ giới hạn của nó.

FinOps giỏi ở việc đo, phân bổ, tối ưu kiểu tài chính như commitment và discount, và gợi ý những chỗ có thể giảm. Tuy nhiên FinOps không thể sửa thay engineering những thứ nằm trong design và vận hành.

1) Chi phí tăng nhiều khi là do design

Đây là các kiểu mình gặp đi gặp lại ở môi trường production:

• Bật log hoặc tracing quá mức, log ingestion tăng tuyến tính theo traffic
• Retry policy tệ tạo retry storm, QPS ảo tăng, autoscaling lên, tiền lên, rồi latency lại tệ hơn
• Kiến trúc chatty giữa services, data transfer và egress âm thầm tăng ngân sách
• Query thiếu index, N+1, database scale vì code chứ không phải vì user tăng

FinOps có thể nói cho bạn biết chỗ nào tăng. Nhưng chuyện tại sao nó tăng và sửa như thế nào là phần engineering phải chịu.

2) Không có ngưỡng lỗi cho chi phí

Nhiều team nói chuyện SLO và error budget rất nghiêm túc, nhưng tới cost lại không có một ràng buộc nào đủ rõ để hành động.

Mình hay hỏi:

• Unit cost target của service này là bao nhiêu?
• Tăng bao nhiêu % thì coi là regression?
• Có alert rule cho cost spike theo giờ hoặc theo ngày không?

Nếu không có mấy thứ đó, cost sẽ luôn bị đẩy thành câu chuyện cuối tháng. Mà tới cuối tháng thì thường chỉ còn hai lựa chọn tệ là cắt bừa hoặc đổ lỗi.

3) Không có guardrails trong quy trình deploy

Mình thấy nhiều tổ chức có guardrails cho security và Infrastructure as Code, nhưng cost thì không.

Trong thực tế, cost regression thường lọt qua các cửa sau:

• Terraform plan sinh thêm NAT gateway hoặc load balancer mà review chỉ nhìn xem có chạy được không
• Retention của log hoặc metrics tăng từ 7 ngày lên 90 ngày vì ai đó muốn debug cho tiện
• CronJob đổi lịch chạy dày hơn, hoặc job bị chạy lại vì timeout, tạo thêm load và thêm bill

Nếu không có gate cho cost impact, chuyện này xảy ra là bình thường. Không phải vì ai xấu, mà vì quy trình không coi cost là một loại rủi ro.

Mình muốn cost là bug

Mình không thích các chương trình tối ưu chi phí kiểu rầm rộ một tháng rồi thôi. Mình thích đưa cost thành một phần của engineering routine, giống như performance và reliability.

1) Một unit cost gắn với sản phẩm

Mình thường chọn 1 hoặc 2 unit cost đủ sát với value để ai cũng hiểu.

Ví dụ:

• cost / 1k requests
• cost / active user
• cost / order
• cost / GB ingested

Nếu không chốt unit cost, mọi cuộc nói chuyện về cost sẽ bị trôi về tổng bill và cảm giác.

2) Allocation phải ra được owner

Tagging và labels không phải để đẹp dashboard. Mục tiêu là truy ngược được chi phí theo:

• service nào
• environment nào
• team nào
• workload nào như job hoặc tenant

Không allocation được tới owner thì bạn sẽ tối ưu tù mù. Tối ưu tù mù rất dễ biến thành cắt bừa, và cắt bừa thì sớm muộn sẽ trả giá bằng performance hoặc reliability.

3) Đưa cost vào CI/CD

Mình không cần làm quá phức tạp. Chỉ cần vài thứ đủ tạo thay đổi hành vi:

• PR checklist có mục cost impact, ai merge thì phải trả lời được impact nằm ở đâu
• Infrastructure as Code có policy-as-code chặn các pattern hay gây bill sốc, ví dụ oversized node, NAT gateway bạt mạng, egress mở rộng, retention vô tội vạ
• Alert rule cho cost spike theo rate, tăng 30% trong 2 giờ thường đáng sợ hơn bill cao cuối tháng
• Postmortem cho cost spike giống như incident reliability: nguyên nhân, remediation, owner, deadline

Điều mình thích ở cách làm này là nó biến cost từ chuyện bàn bạc thành chuyện hành động.

4) Reward đúng để tránh xung đột giữa Dev và FinOps

Mình ghét hai kịch bản:

• Dev ship feature, bill tăng mạnh, rồi nói FinOps xử lý
• FinOps cắt giảm bừa, performance xuống, dev bị chửi

Cost là trade-off. Trade-off phải nằm trong tay người ra quyết định kỹ thuật, và quyết định đó phải có dữ liệu. FinOps nên giúp engineering nhìn thấy dữ liệu và ra quyết định nhanh hơn, chứ không phải đứng ra gánh thay.

Vậy FinOps đứng ở đâu?

Mình không phủ nhận vai trò của FinOps. Ngược lại, mình thấy FinOps rất mạnh nếu đứng đúng vị trí:

• enablement: visibility, allocation, governance
• leverage: commitment, discount
• coach: pattern tốt, benchmark, cảnh báo sớm

Nhưng nếu tổ chức dùng FinOps như đội dọn rác đứng sau engineering, thì câu chuyện không nằm ở tool hay con người. Nó nằm ở ownership model.

Kết

Nếu muốn giảm 20 đến 30% cloud bill một cách bền vững, mình không bắt đầu bằng savings.

Mình bắt đầu bằng việc coi chi phí tăng là regression. Regression thì phải có owner.

Mình hay tự nhắc một câu đơn giản:
Chi phí tăng cũng là một regression. Ai merge thì ai chịu trách nhiệm.

Mình không nghĩ có một phe đúng tuyệt đối. Có team đủ maturity để engineering ownership cost ngay, có team cần FinOps dẫn dắt một thời gian. Nhưng nếu cứ coi cost là việc của một nhóm khác, thì tới một lúc nào đó cost sẽ quay lại cắn vào reliability, performance và tốc độ ship.