FinOps 6 — Giám sát chi phí & phát hiện bất thường

Từ dọn dẹp một lần sang canh gác liên tục

Bốn bài trước của series đã đi qua các đòn bẩy OPTIMIZE: right-sizing warehouse, storage tiering, tối ưu pipeline compute, cắt chi phí streaming. Nhưng tối ưu là một sự kiện, còn chi phí là một dòng chảy. Bạn dọn sạch tài nguyên bỏ quên hôm nay, ba tuần sau một analyst mới lại để cụm dev chạy qua đêm; bạn viết lại query đắt hôm nay, tháng sau một dashboard auto-refresh xấu lại xuất hiện. Không có cơ chế canh gác, mọi khoản tiết kiệm đều trôi ngược lại — hiện tượng dân FinOps gọi là cost creep (chi phí bò lên âm thầm).

Đây là địa hạt của pha OPERATE — pha thứ ba trong vòng lặp INFORM → OPTIMIZE → OPERATE đã dựng ở bài mở màn. OPERATE thiết chế hóa việc quản trị chi phí thành một quy trình vận hành tự động và liên tục, thay vì một chiến dịch dọn dẹp mỗi quý. Ba trụ cột: visibility (nhìn thấy chi phí gần thời gian thực), budget & cảnh báo (đặt trần và báo động khi vượt/sắp vượt), và anomaly detection (bắt chi phí tăng đột biến trước khi nó thành hóa đơn sốc cuối tháng).

Với NCB, nơi hàng trăm analyst và hàng chục pipeline cùng dùng một nền tảng dữ liệu, một query lỗi vòng lặp có thể đốt hàng trăm triệu VND trong một đêm mà không ai hay tới khi kỳ hạch toán đóng. Mục tiêu của bài này là dựng được hệ thống thần kinh cho chi phí: cảm nhận sớm, cảnh báo đúng người, điều tra nhanh, và khép vòng phản hồi về tối ưu.

Visibility — không đo thì không quản

Nền tảng của OPERATE vẫn là visibility (nhìn rõ chi phí). Khác với INFORM ở chỗ INFORM dựng visibility một lần để hiểu, còn OPERATE duy trì nó liên tục để canh. Chuỗi giá trị đi từ dữ liệu thô tới hành động:

1. Thu thập dữ liệu chi phí

Nguồn sự thật là billing/cost export do nhà cung cấp cloud xuất ra — thường dưới dạng file hoặc bảng nạp định kỳ:

• AWS: Cost and Usage Report (CUR) — bản kê chi tiết nhất, từng dòng theo service, resource, tag, theo giờ hoặc ngày.
• GCP: Billing export sang BigQuery — mỗi dòng là một mục chi phí kèm labels.
• Azure: Cost Management exports / Amortized cost.
• Snowflake / Databricks: các view/bảng nội bộ (ACCOUNT_USAGE, system.billing) cho credit tiêu theo warehouse/user/query — mức chi tiết vàng cho nền tảng dữ liệu.

Điểm mấu chốt: dữ liệu billing luôn trễ và không đầy đủ trong ngày (nhà cung cấp cập nhật dần, số cuối cùng chỉ chốt sau vài giờ tới một ngày). Mọi dashboard và alert phải tính đến độ trễ này để không báo động giả vì "ngày hôm nay thấp bất thường" (thực ra chỉ vì dữ liệu chưa về đủ).

2. Phân bổ theo tag / team / domain / dự án

Dữ liệu thô vô dụng nếu không quy được về ai tiêu. Đây là lúc kỷ luật tagging (đã bàn ở bài 1) trả cổ tức: mỗi dòng chi phí mang team, domain, environment, cost_center, owner. Từ đó dựng hai mô hình phân bổ:

• Showback — cho thấy mỗi domain tiêu bao nhiêu, tạo nhận thức mà không trừ tiền thật.
• Chargeback — tính tiền thật vào trung tâm chi phí từng team.

Một thực tế đau đầu: chi phí không gắn tag (untagged/shared). Luôn có phần dùng chung — catalog, orchestration, network — không thuộc riêng ai. Cách xử lý phổ biến là phân bổ tương ứng (proportional split) theo tỷ lệ dùng, hoặc dồn vào một "domain nền tảng" và showback minh bạch.

3. Dashboard & phân rã chi phí

Dashboard chi phí là bề mặt vận hành hằng ngày. Nó nên trả lời được ngay ba câu:

• Đang tiêu bao nhiêu so với ngân sách và so với kỳ trước?
• Phân rã (breakdown) theo chiều nào: service, environment (prod/dev/UAT), domain, thời gian?
• Xu hướng (trend) đang đi lên hay xuống, và cái gì đang kéo nó?

Kỹ thuật quan trọng là phân rã đóng góp (contribution analysis): khi tổng tăng 15%, nó tăng ở đâu — service nào, môi trường nào, ngày nào? Một biểu đồ tổng đi lên vô nghĩa cho tới khi bạn xé nó thành các thành phần và tìm ra thủ phạm. Dashboard chi phí thường sống chung hệ sinh thái quan sát với dashboard hạ tầng — xem thêm nguyên tắc trực quan hóa và cảnh báo ở Observability — Tổng quan.

Budget & cảnh báo — đặt trần và báo động

Nhìn thấy chi phí là chưa đủ; phải có ngưỡng để biết khi nào cần hành động. Budget (ngân sách) là cam kết định lượng "domain này/tháng này không nên vượt X", còn cảnh báo là cơ chế bắn tín hiệu khi tới gần hoặc dự báo sẽ vượt.

Đặt ngân sách nhiều tầng

Budget hiệu quả không phải một con số toàn cục mà phân tầng: theo domain, theo môi trường, theo dự án. Ngân sách càng gần người ra quyết định càng dễ quy trách nhiệm. Ví dụ minh họa (số giả định) cho nền tảng NCB:

Hai loại cảnh báo: ngưỡng thực tế và dự báo

• Cảnh báo theo % ngưỡng (actual): bắn khi chi tiêu đã đạt 80%/95% ngân sách. Đơn giản, nhưng phản ứng chậm — khi đạt 95% thì thường đã quá muộn để phanh trong tháng đó.
• Cảnh báo theo dự báo (forecast): ngoại suy tốc độ chi hiện tại tới cuối kỳ; bắn khi dự báo sẽ vượt ngân sách dù hiện tại mới ở 40%. Đây là loại giá trị hơn hẳn vì cho bạn thời gian hành động. Forecast đơn giản có thể là tuyến tính (run-rate: tổng-tới-nay ÷ số ngày đã qua × số ngày trong tháng), tinh vi hơn thì tính đến chu kỳ tuần (cuối tuần thường thấp) và xu hướng.

Các cloud cost tool (AWS Budgets, GCP Budgets & alerts, Azure Cost Management) đều hỗ trợ cả hai loại out-of-the-box. Nguyên tắc vận hành: cảnh báo phải tới đúng người có thể hành động (owner của domain, không phải một mailbox chung không ai đọc) và không quá ồn (alert fatigue giết chết mọi hệ cảnh báo — nếu 90% cảnh báo là nhiễu, người ta sẽ tắt hết).

Phát hiện bất thường chi phí (anomaly detection)

Budget bắt được chi phí vượt trần đã biết. Nhưng nhiều sự cố chi phí nguy hiểm nhất lại nằm trong ngân sách nhưng bất thường về hành vi — một cú tăng đột biến so với chính nó ngày thường. Đó là việc của anomaly detection (phát hiện bất thường): so hành vi hôm nay với baseline (mức nền bình thường) và báo động khi lệch quá xa.

Các "thủ phạm" điển hình

Baseline thống kê vs ML

Có hai lớp kỹ thuật, đi từ đơn giản đến tinh vi:

• Baseline thống kê: tính trung bình (mean) và độ lệch chuẩn (standard deviation) của chi phí trong cửa sổ gần (ví dụ 7–28 ngày trượt), rồi báo động khi giá trị hôm nay lệch quá k lần độ lệch chuẩn (z-score), thường k = 2 hoặc 3. Ưu điểm: minh bạch, dễ giải thích, chạy được ngay bằng SQL. Nhược điểm: nhạy với mùa vụ (seasonality) — cuối tháng ngân hàng chốt sổ nên chi phí cao bình thường, baseline phẳng sẽ báo giả.
• ML / thống kê nâng cao: các dịch vụ như AWS Cost Anomaly Detection dùng mô hình học chu kỳ (ngày trong tuần, cuối tháng), tách xu hướng khỏi mùa vụ, và ước lượng "mức đáng lẽ phải là" để so. Bắt được bất thường tinh vi hơn mà ít báo giả hơn. Cùng nền tảng phát hiện bất thường này áp dụng được cho cả chuỗi thời gian nghiệp vụ khác (khối lượng giao dịch, độ trễ) — nếu team đã có sẵn hạ tầng phát hiện bất thường chuỗi thời gian thì tái dùng chung là hợp lý.

Nguyên tắc thực dụng: bắt đầu bằng baseline thống kê (rẻ, nhanh, minh bạch), chỉ leo lên ML khi báo giả do mùa vụ trở thành vấn đề thật.

Minh họa phát hiện bất thường bằng SQL

Sandbox của chúng ta là PostgreSQL chỉ đọc với bảng transactions(id, account_id, amount, kind, created_at). Ta mượn nó làm phép ẩn dụ cho một "cost feed": coi mỗi dòng như một mục chi phí, amount là số tiền, created_at là thời điểm phát sinh. Kỹ thuật baseline dưới đây giống hệt cách bạn áp lên bảng billing thật.

Câu đầu tiên tính tổng theo ngày, rồi so với trung bình trượt 7 ngày trước đó bằng window function — cột pct_vs_baseline cho biết ngày đó cao/thấp hơn baseline bao nhiêu phần trăm:

-- ▶ Chạy được
WITH daily AS (
    SELECT date_trunc('day', created_at)::date AS d,
           SUM(amount)  AS total_amount,
           COUNT(*)     AS txn_count
    FROM transactions
    GROUP BY 1
),
with_baseline AS (
    SELECT d,
           total_amount,
           txn_count,
           AVG(total_amount) OVER (
               ORDER BY d
               ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING
           ) AS baseline_7d
    FROM daily
)
SELECT d,
       total_amount,
       txn_count,
       ROUND(baseline_7d::numeric, 2) AS baseline_7d,
       ROUND(((total_amount - baseline_7d) / NULLIF(baseline_7d, 0) * 100)::numeric, 1)
           AS pct_vs_baseline
FROM with_baseline
ORDER BY d;

Câu thứ hai đi xa hơn: dùng z-score để chấm điểm bất thường. Nó tính trung bình và độ lệch chuẩn của 14 ngày trước mỗi ngày, rồi gắn cờ ALERT cho ngày nào lệch quá 2 độ lệch chuẩn — chính là baseline thống kê mô tả ở trên, viết bằng SQL thuần:

-- ▶ Chạy được
WITH daily AS (
    SELECT date_trunc('day', created_at)::date AS d,
           SUM(amount) AS total_amount
    FROM transactions
    GROUP BY 1
),
stats AS (
    SELECT d,
           total_amount,
           AVG(total_amount) OVER w    AS mean_14d,
           STDDEV(total_amount) OVER w AS sd_14d
    FROM daily
    WINDOW w AS (ORDER BY d ROWS BETWEEN 14 PRECEDING AND 1 PRECEDING)
)
SELECT d,
       total_amount,
       ROUND(mean_14d::numeric, 2) AS mean_14d,
       ROUND(
           ((total_amount - mean_14d) / NULLIF(sd_14d, 0))::numeric, 2
       ) AS z_score,
       CASE
           WHEN sd_14d IS NULL THEN 'warmup'
           WHEN ABS((total_amount - mean_14d) / NULLIF(sd_14d, 0)) > 2 THEN 'ALERT'
           ELSE 'ok'
       END AS flag
FROM stats
ORDER BY d;

Hai câu này minh họa nguyên lý cốt lõi: so hiện tại với quá khứ gần bằng window function, chuẩn hóa độ lệch, gắn cờ khi vượt ngưỡng. Trên billing thật bạn chỉ thay transactions bằng bảng cost export và amount bằng chi phí — logic không đổi. Lưu ý STDDEV/AVG cần một "cửa sổ khởi động" (warmup) trước khi baseline đáng tin.

Điều tra nguyên nhân (attribution)

Cảnh báo mới là nửa việc; nửa còn lại là điều tra nhanh để tìm gốc rễ (root cause). Một cảnh báo "chi phí domain Risk tăng 40% hôm qua" vô ích nếu mất ba ngày mới tìm ra vì sao. Quy trình attribution nên đi từ thô đến tinh:

1. Chiều nào tăng? Phân rã cú tăng theo service → environment → warehouse/user → query. Contribution analysis chỉ thẳng vào thủ phạm.
2. Ai/cái gì gây ra? Từ tag và log truy vấn, quy về đúng warehouse, user, hoặc job. Với nền tảng dữ liệu, QUERY_HISTORY/query log là mỏ vàng: query nào scan nhiều bytes nhất, chạy bao lần.
3. Vì sao lúc này? Đối chiếu mốc thời gian tăng với sự kiện: deploy pipeline mới, thay đổi cấu hình warehouse, tăng đột biến lưu lượng nghiệp vụ (chốt sổ cuối tháng, chiến dịch marketing).
4. Là bất thường hay bình thường mới? Quyết định: khắc phục (rollback config, kill query, tắt tài nguyên) hay chấp nhận và cập nhật baseline/ngân sách.

Bước 4 quan trọng mà hay bị bỏ: không phải mọi cú tăng đều xấu. Nếu ngân hàng ra mắt sản phẩm mới khiến khối lượng giao dịch tăng thật, chi phí tăng theo là đúng — việc cần làm là điều chỉnh ngân sách, không phải cắt.

KPI FinOps — đo sự trưởng thành của chương trình

Để biết chương trình OPERATE có thực sự hiệu quả, đo bằng một bộ KPI chứ không cảm tính:

Bộ KPI này biến FinOps thành một chương trình đo được: mỗi quý xem tag coverage có tăng, waste ratio có giảm, forecast có sát hơn không. Unit cost là KPI vua — nó cho biết bạn đang tối ưu hiệu quả chứ không chỉ đè tổng chi xuống bằng cách bóp nghẹt việc kinh doanh.

Tối ưu liên tục & vòng phản hồi

OPERATE không phải điểm cuối mà là điểm quay vòng. Mỗi bất thường bắt được, mỗi ngân sách vượt, mỗi KPI xấu đi đều là dữ liệu mới nuôi lại pha INFORM, dẫn tới một vòng OPTIMIZE tiếp theo. Sự trưởng thành thể hiện ở mức độ tự động hóa vòng này:

• Crawl: người xem dashboard thủ công mỗi tuần, cảnh báo email.
• Walk: cảnh báo ngưỡng + forecast tự động, anomaly detection baseline, KPI theo dõi hằng tháng.
• Run: anomaly detection ML, tự động hành động (auto-suspend tài nguyên idle, kill query vượt ngưỡng bytes), kiểm tra chi phí gài trong CI/CD, chargeback đầy đủ.

Công cụ

Với workload chạy trên Kubernetes — ngày càng phổ biến cho pipeline và job ML — OpenCost và Kubecost cho phép xé hóa đơn cụm về tận namespace/pod/label, thứ mà cloud cost tool không thấy được vì với chúng cả cụm chỉ là mấy máy ảo. Chủ đề này được mổ xẻ riêng ở FinOps 7 — Chi phí Kubernetes.

Use case thực tế

Bối cảnh: Nền tảng dữ liệu NCB đã qua các vòng OPTIMIZE (bài 2–5) và ổn định ở mức ~1,5 tỷ VND/tháng. Đội dữ liệu muốn giữ mức đó và không muốn lại rơi vào cảnh giải trình hóa đơn sốc. Họ dựng chương trình OPERATE.

Triển khai:

1. Visibility (tuần 1–2): Nạp Snowflake ACCOUNT_USAGE và billing export vào một bảng chi phí ngày, phân bổ theo domain/environment từ tag warehouse. Dựng dashboard Grafana: tổng theo ngày, phân rã theo domain, so với ngân sách. Tag coverage lúc đầu chỉ 78% → siết policy bắt buộc tag, đạt 96% sau ba tuần.

2. Budget & cảnh báo (tuần 3): Đặt ngân sách theo domain (Risk 450tr, Marketing 280tr, dev/UAT gộp 200tr). Bật cảnh báo forecast: nếu run-rate dự báo vượt 100% ngân sách → bắn Slack tới owner domain.

3. Anomaly detection (tuần 4): Chạy job hằng ngày tính z-score chi phí compute theo warehouse trên cửa sổ 14 ngày (đúng logic hai câu SQL ở trên, áp lên bảng cost thật). Ngưỡng cảnh báo z > 2,5.

Sự cố thật bắt được: Một sáng thứ Hai, job anomaly gắn cờ warehouse WH_RISK_ETL z-score = 4,1 — chi phí cuối tuần cao gấp ~3 lần baseline. Attribution: một pipeline mới deploy chiều thứ Sáu có lỗi vòng lặp WHILE, quét lại bảng giao dịch 320 lần suốt hai ngày, đốt ~140 triệu VND. Nhờ cảnh báo sáng thứ Hai (thay vì phát hiện cuối tháng), đội chỉ mất một phần chi phí một cuối tuần, kill query và rollback trong 30 phút.

Kết quả sau 6 tháng: waste ratio từ ~12% xuống 4%; thời gian phát hiện bất thường trung bình 18 giờ; forecast sai số 7%. Quan trọng nhất: hóa đơn dự báo được, tài chính không còn bất ngờ, và mỗi domain tự canh ngân sách của mình.

Ghi nhớ

• OPERATE là pha thứ ba của FinOps: biến quản trị chi phí thành quy trình tự động, liên tục thay vì dọn dẹp mỗi quý — chống cost creep (chi phí bò lên lại sau tối ưu).
• Visibility: thu thập billing/cost export → phân bổ theo tag/domain/env (showback/chargeback) → dashboard với phân rã đóng góp để tìm thủ phạm khi tổng tăng. Nhớ dữ liệu billing trễ trong ngày.
• Budget: đặt ngân sách phân tầng (domain/env/dự án); cảnh báo theo % ngưỡng (actual, phản ứng chậm) và quan trọng hơn là theo forecast (dự báo vượt, cho thời gian hành động). Cảnh báo phải đúng người, không ồn.
• Anomaly detection: so hôm nay với baseline (mean ± k×stddev, z-score) hoặc mô hình ML học mùa vụ; bắt query lỗi/vòng lặp, đổi cấu hình, tài nguyên quên tắt, scan bùng nổ. Bắt đầu bằng baseline thống kê, chỉ leo ML khi mùa vụ gây báo giả.
• Attribution: chiều nào tăng → ai/cái gì → vì sao lúc này → bất thường hay bình thường mới; không phải cú tăng nào cũng xấu.
• KPI FinOps: unit cost (vua), % tag coverage, coverage cam kết, waste ratio, thời gian phát hiện bất thường, độ chính xác forecast — biến chương trình thành thứ đo được.
• Công cụ: cloud cost tools cho budget/forecast/anomaly; view nội bộ warehouse cho chi tiết query; OpenCost/Kubecost cho K8s (bài 7); Grafana/Metabase cho dashboard.
• Vòng phản hồi: mỗi bất thường/vượt ngân sách nuôi lại INFORM → OPTIMIZE; trưởng thành đi Crawl → Walk → Run (tay → tự động cảnh báo → tự động hành động).