FinOps 8 — Thực hành & lộ trình cho ngân hàng

Từ kỹ thuật rời rạc tới một chương trình

Bảy bài trước của series đã trải ra một kho vũ khí: cách tính phí và tối ưu data warehouse, phân tầng lưu trữ, compute pipeline, streaming, giám sát & phát hiện bất thường, và chi phí Kubernetes. Mỗi bài là một đòn bẩy riêng. Nhưng một tập kỹ thuật rời rạc không phải là FinOps — nó chỉ là danh sách mẹo. FinOps trở thành chương trình khi có con người chịu trách nhiệm, có quy trình lặp lại, có ưu tiên rõ ràng, và có sự trưởng thành theo thời gian.

Bài cuối này không giới thiệu kỹ thuật mới. Nó lắp ráp cả series thành một lộ trình triển khai thực tế cho nền tảng dữ liệu NCB: tổng hợp mọi đòn bẩy vào một bảng "vấn đề → đòn bẩy → mức tiết kiệm điển hình", dựng tổ và vai trò FinOps, đi giai đoạn Crawl → Walk → Run, ưu tiên theo tác động, tránh tối ưu quá đà, và cân bằng ba trục sinh tử của một ngân hàng: chi phí – hiệu năng – tuân thủ. Ai đọc hết series nên rời bài này với một kế hoạch hành động, không phải thêm lý thuyết.

Tổng hợp đòn bẩy: vấn đề → đòn bẩy → mức tiết kiệm

Đây là bản đồ cô đọng nhất của toàn series — mỗi hàng gom một họ vấn đề chi phí, đòn bẩy tương ứng, và mức tiết kiệm điển hình quan sát được trong ngành. Lưu ý: các con số dưới đây là khoảng minh họa, phụ thuộc mạnh vào workload cụ thể — dùng để định hướng ưu tiên, không phải cam kết.

Ba nhóm quick win luôn nên làm trước tiên vì gần như không rủi ro và không cần dự án: (1) tắt tài nguyên nhàn rỗi (cụm dev/UAT ngoài giờ, warehouse auto-suspend), (2) dọn zombie — tài nguyên cấp phát rồi bỏ quên (đĩa mồ côi, snapshot cũ, cluster idle), (3) áp tag để mọi chi phí về sau đều truy được chủ. Không có tag, mọi phân tích ở các bài sau đều mù.

Lập tổ & vai trò FinOps

FinOps không phải việc của một người, cũng không phải một phòng ban tách biệt — nó là mô hình vận hành chung nối ba thế giới thường không nói cùng ngôn ngữ. Với quy mô NCB, không cần đội lớn; cần đúng ba vai trò và một người điều phối:

Điểm cốt lõi: practitioner không tự tối ưu tất cả — họ tạo visibility và khích lệ để chính đội kỹ thuật (người tạo ra chi phí) tự tối ưu, và để tài chính quy được trách nhiệm. Đây là mô hình phi tập trung có bệ đỡ tập trung (centralized enablement, decentralized accountability), đúng tinh thần FinOps Foundation đã nêu ở bài mở màn.

Lộ trình Crawl → Walk → Run

Không tổ chức nào nhảy thẳng lên tự động hóa toàn phần. FinOps trưởng thành theo ba giai đoạn — mỗi giai đoạn phải vững trước khi lên bậc kế: visibility trước → tối ưu → tự động hóa & văn hóa.

• Crawl (nhìn thấy): mục tiêu duy nhất là visibility. Bật cost export, ép tag, dựng dashboard trả lời "ai tiêu bao nhiêu". Chưa vội cắt gì — bạn không thể tối ưu thứ không đo được. Kết thúc giai đoạn khi tag coverage > 90% và mỗi domain thấy được hóa đơn của mình (showback).
• Walk (tối ưu): bắt đầu cắt — nhưng có ưu tiên. Làm quick wins, rồi tấn công khoản chi lớn nhất. Song song, dựng lớp OPERATE: budget, cảnh báo forecast, anomaly detection baseline (bài 6) để tiết kiệm không trôi ngược.
• Run (tự động & văn hóa): thiết chế hóa. Tài nguyên idle tự tắt, query vượt ngưỡng tự kill, cost check gài trong CI/CD, chargeback thật vào trung tâm chi phí. Quan trọng nhất là văn hóa cost-aware: engineer coi chi phí là một chỉ số chất lượng như latency hay uptime.

Ưu tiên theo tác động

Sai lầm phổ biến nhất là tối ưu thứ dễ thấy thay vì thứ tốn tiền nhất. Nguyên tắc vàng: bắt đầu từ khoản chi lớn nhất. Trên hầu hết nền tảng dữ liệu, đó là warehouse/compute — nên đây thường là nơi có ROI cao nhất. Một cách hình dung là ma trận tác động × công sức:

Quy trình thực dụng theo quý: (1) xé hóa đơn theo dịch vụ, tìm 3–5 khoản lớn nhất (nguyên lý Pareto — 80% chi phí thường nằm ở 20% tài nguyên); (2) với mỗi khoản, hỏi "đòn bẩy nào ở series áp được?"; (3) ước lượng tiết kiệm × công sức, xếp vào ma trận; (4) làm ô 🥇 trước, lên kế hoạch cho 🥈, phớt lờ 🚫.

Tìm "điểm nóng chi phí" bằng SQL

Trên billing thật, bước đầu tiên của attribution luôn là nhóm chi phí theo một chiều và xếp hạng. 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 ẩn dụ cho một "cost feed" — coi mỗi dòng như một mục chi phí, amount là số tiền. Kỹ thuật xếp hạng dưới đây giống hệt cách bạn tìm warehouse/query/bảng tốn kém nhất trên bảng cost export thật.

Câu đầu tiên tìm tài khoản tạo nhiều "chi phí" nhất — tương tự tìm warehouse/user đốt nhiều credit nhất — kèm tỷ trọng trên tổng và tỷ trọng cộng dồn để lộ ra nhóm Pareto:

-- ▶ Chạy được
WITH per_account AS (
    SELECT a.id                 AS account_id,
           c.full_name          AS customer,
           SUM(t.amount)        AS total_amount,
           COUNT(*)             AS txn_count
    FROM transactions t
    JOIN accounts  a ON a.id = t.account_id
    JOIN customers c ON c.id = a.customer_id
    GROUP BY a.id, c.full_name
),
ranked AS (
    SELECT account_id, customer, total_amount, txn_count,
           SUM(total_amount) OVER () AS grand_total,
           SUM(total_amount) OVER (ORDER BY total_amount DESC
                                   ROWS UNBOUNDED PRECEDING) AS running_total
    FROM per_account
)
SELECT customer,
       total_amount,
       txn_count,
       ROUND((total_amount / NULLIF(grand_total, 0) * 100)::numeric, 1)   AS pct_of_total,
       ROUND((running_total / NULLIF(grand_total, 0) * 100)::numeric, 1)  AS cumulative_pct
FROM ranked
ORDER BY total_amount DESC
LIMIT 20;

Câu thứ hai tổng hợp theo loại (kind) — tương tự phân rã hóa đơn theo dịch vụ (warehouse vs storage vs streaming) để biết họ chi phí nào đáng tấn công trước:

-- ▶ Chạy được
SELECT kind,
       COUNT(*)                                              AS txn_count,
       SUM(amount)                                           AS total_amount,
       ROUND(AVG(amount)::numeric, 2)                        AS avg_amount,
       ROUND((SUM(amount) / SUM(SUM(amount)) OVER () * 100)::numeric, 1) AS pct_of_total
FROM transactions
GROUP BY kind
ORDER BY total_amount DESC;

Cả hai câu minh họa nguyên lý attribution cốt lõi: nhóm theo một chiều, tính tỷ trọng, xếp hạng giảm dần, đọc từ trên xuống. Trên billing thật chỉ cần thay transactions bằng bảng cost export, amount bằng chi phí, và kind/customer bằng service/warehouse/domain — logic không đổi. Cột cumulative_pct chính là cách phát hiện nhóm Pareto: thường vài dòng đầu đã chiếm phần lớn tổng.

Tránh tối ưu quá đà

FinOps không phải là cắt chi phí bằng mọi giá — đó là tối ưu giá trị. Cắt quá đà gây phản tác dụng khi nó chạm vào hiệu năng, độ tin cậy hoặc tuân thủ:

• Đừng cắt tới mức chậm báo cáo NHNN: nếu right-size warehouse quá tay khiến pipeline báo cáo giám sát (chốt số cuối ngày, báo cáo Ngân hàng Nhà nước) trễ hạn nộp, khoản tiết kiệm vài chục triệu không đáng với rủi ro tuân thủ. SLA nghiệp vụ là ràng buộc cứng.
• Đừng bóp nghẹt việc kinh doanh: nếu chi phí tăng vì khối lượng giao dịch tăng thật (ra mắt sản phẩm, chiến dịch), đó là chi phí đúng — điều chỉnh ngân sách, đừng cắt. Unit cost (chi phí/giao dịch, /khách hàng) mới là thước đo hiệu quả thật; tổng chi tăng mà unit cost giảm là thắng lợi.
• Cẩn thận spot/preemptible với tải nhạy cảm: rẻ 50–80% nhưng có thể bị thu hồi. Dùng cho batch chịu gián đoạn; đừng dùng cho streaming online hay job có deadline cứng.
• Đừng tối ưu vi mô: bỏ hàng tuần để bóp một khoản chi vài trăm nghìn là lãng phí công sức đắt hơn tiền tiết kiệm.

Nguyên tắc bao trùm: mọi tối ưu phải có "phanh" — một ngưỡng hiệu năng/SLA mà dưới đó bạn dừng cắt. Tối ưu tốt là tối ưu đến ngay trước điểm đau, không vượt qua nó.

Cân bằng chi phí – hiệu năng – tuân thủ

Với ngân hàng, mọi quyết định FinOps đứng trên một tam giác ràng buộc. Tối ưu là tìm điểm cân bằng, không phải cực đại hóa một đỉnh:

• Chi phí: đè OpEx xuống.
• Hiệu năng: đáp ứng SLA — báo cáo đúng giờ, dashboard đủ nhanh, mô hình rủi ro kịp chấm điểm.
• Tuân thủ: dữ liệu ngân hàng phải giữ theo luật (retention bắt buộc theo quy định lưu trữ chứng từ), phải kiểm soát truy cập, và tùy chính sách nội bộ có thể không được lên public cloud.

Hệ quả trực tiếp lên các đòn bẩy đã học:

• Không cắt lưu trữ bừa: phân tầng cho phép đẩy dữ liệu cũ xuống archive rẻ hơn nhưng vẫn giữ — không được xóa dữ liệu còn trong thời hạn retention bắt buộc. Xác định retention theo luật trước, mới tối ưu bên trong ràng buộc đó.
• On-prem vs cloud: dữ liệu nhạy cảm nhất (PII khách hàng, dữ liệu giao dịch chi tiết) có thể phải nằm on-prem hoặc private cloud theo chính sách. FinOps vẫn áp dụng — chỉ đổi "đơn giá" (khấu hao phần cứng, điện, vận hành thay vì hóa đơn cloud) và bài toán tận dụng công suất. Nhiều ngân hàng chạy hybrid: workload nhạy cảm on-prem, analytics/dev có thể lên cloud.
• Kiểm soát truy cập là điều kiện tiên quyết: showback/chargeback và tag cần đi cùng phân quyền chặt — xem Kiểm soát truy cập. Ai thấy được chi phí của ai cũng là vấn đề quản trị.

Showback / chargeback tạo trách nhiệm

Đòn bẩy hành vi mạnh nhất của FinOps không phải kỹ thuật mà là quy chi phí về đúng người tạo ra nó:

• Showback: cho thấy mỗi domain tiêu bao nhiêu, tạo nhận thức, không trừ tiền thật. Ít ma sát, hợp giai đoạn Crawl/Walk. Chỉ riêng việc chủ domain nhìn thấy hóa đơn của mình đã đủ đổi hành vi.
• Chargeback: tính tiền thật vào trung tâm chi phí từng khối. Tạo trách nhiệm mạnh nhất nhưng đòi tag chính xác và sự đồng thuận tài chính — hợp giai đoạn Run.

Kinh nghiệm chung: bắt đầu bằng showback, chỉ lên chargeback khi tag coverage cao và tổ chức đã quen. Chargeback áp quá sớm khi phân bổ còn sai sẽ gây tranh cãi nội bộ và mất niềm tin vào cả chương trình.

KPI & báo cáo cho lãnh đạo

Lãnh đạo không quan tâm bạn viết lại bao nhiêu query — họ quan tâm tiền tiết kiệm được và rủi ro có tăng không. Báo cáo FinOps cho cấp trên nên gọn, đúng ngôn ngữ kinh doanh:

Mẹo báo cáo: quy tiết kiệm ra tiền và ra đơn vị kinh doanh ("giảm 300 triệu/quý, tương đương chi phí dữ liệu cho X triệu giao dịch"), và luôn kèm một câu về rủi ro ("không ảnh hưởng SLA báo cáo NHNN") để lãnh đạo yên tâm rằng tối ưu không đánh đổi tuân thủ.

Đặc thù ngân hàng

Gói lại các ràng buộc riêng của một ngân hàng — chúng định hình mọi quyết định FinOps ở trên:

• Tuân thủ & retention bắt buộc: dữ liệu chứng từ, giao dịch phải giữ theo thời hạn luật định. Tối ưu lưu trữ = phân tầng rẻ hơn, không xóa sớm.
• Dữ liệu nhạy cảm & chính sách cloud: PII và dữ liệu giao dịch có thể bị chính sách buộc on-prem/private cloud. Kiến trúc hybrid là bình thường; FinOps áp cho cả hai phía.
• Phê duyệt & kiểm soát thay đổi: cắt/tắt tài nguyên trong môi trường sản xuất ngân hàng thường cần quy trình duyệt (change management) — không tự tiện auto-kill trên prod nhạy cảm. Tự động hóa ở giai đoạn Run phải tôn trọng hàng rào này.
• SLA nghiệp vụ cứng: báo cáo giám sát, chốt sổ, chấm điểm rủi ro có deadline pháp lý — là ràng buộc bất khả xâm phạm khi right-size.

Checklist & anti-pattern

Checklist FinOps (dùng như bảng kiểm quý):

• Mọi tài nguyên có tag (team, domain, environment, owner) — coverage > 95%
• Cost export/billing được nạp và dashboard hoạt động; mỗi domain thấy showback của mình
• Warehouse có auto-suspend; dev/UAT tự tắt ngoài giờ
• Không còn zombie: đĩa mồ côi, snapshot cũ, cluster idle đã dọn
• Bảng lớn đã partition/cluster; storage cũ đã tiered đúng (trong ràng buộc retention)
• Tải ổn định đã phủ reserved/committed use; batch dùng spot khi hợp lý
• Budget theo domain + cảnh báo forecast + anomaly detection baseline đang chạy
• Có bộ KPI (unit cost, waste ratio, tag coverage) báo cáo định kỳ cho lãnh đạo
• Mỗi tối ưu có "phanh" SLA; không cắt tới mức trễ báo cáo NHNN

Anti-pattern cần tránh:

• Tối ưu không đo trước: cắt mù khi chưa có visibility → phá thứ đang cần.
• Chỉ tối ưu một lần: dọn dẹp mỗi quý mà không có OPERATE → cost creep, tiết kiệm trôi ngược.
• Chargeback áp quá sớm: khi tag còn sai → tranh cãi, mất niềm tin.
• Tối ưu vi mô, bỏ quên khoản lớn: bận rộn với chi phí nhỏ trong khi warehouse đốt phần lớn hóa đơn.
• Auto-kill bừa trên prod nhạy cảm: bỏ qua change management → sự cố tuân thủ.
• Coi FinOps là việc của một người: practitioner ôm hết, engineer không thấy trách nhiệm → không bền.

Tổng kết series: bản đồ 8 bài

Use case thực tế

Bối cảnh: Đầu năm, khối dữ liệu NCB đối mặt hóa đơn nền tảng ~2 tỷ VND/tháng và tăng đều ~8%/quý mà không ai giải trình được. Ban lãnh đạo yêu cầu "kiểm soát chi phí nhưng không được ảnh hưởng báo cáo giám sát". Đội quyết định chạy chương trình FinOps theo đúng lộ trình series.

Triển khai theo giai đoạn:

1. Crawl (tháng 1–2): cử một data engineer làm FinOps practitioner kiêm nhiệm. Nạp cost export, ép policy tag bắt buộc — coverage từ 61% lên 94%. Dựng dashboard showback theo domain. Phát hiện ngay: hai domain (Risk, Marketing) chiếm ~70% tổng chi (đúng Pareto, tìm ra bằng đúng logic SQL xếp hạng ở trên).

2. Walk (tháng 3–5): làm quick wins trước — auto-suspend warehouse, tắt cụm dev/UAT ngoài giờ, dọn 40+ đĩa/snapshot zombie → cắt ~9% gần như tức thì. Rồi tấn công khoản lớn nhất: right-size warehouse Risk (từ 4XL thường trực xuống L + auto-suspend), viết lại 5 query đắt nhất, chuyển pipeline chốt số sang incremental. Dựng budget theo domain + cảnh báo forecast + anomaly baseline (bài 6). Có phanh: mọi thay đổi trên pipeline báo cáo NHNN đều test giữ nguyên deadline nộp trước khi áp.

3. Run (tháng 6+): gài cost check trong CI/CD (chặn merge nếu ước tính query mới vượt ngưỡng bytes), auto-suspend triệt để, chuyển từ showback sang chargeback cho Risk và Marketing. Đưa 6 KPI vào báo cáo tháng cho ban lãnh đạo.

Kết quả sau 6 tháng: chi phí nền tảng từ ~2 tỷ xuống ~1,4 tỷ VND/tháng (giảm ~30%); waste ratio 13% → 4%; unit cost/giao dịch giảm 22% dù khối lượng giao dịch tăng; tag coverage 96%; forecast sai số 7%. Quan trọng nhất: không một báo cáo giám sát nào trễ hạn — tối ưu dừng đúng trước điểm đau SLA, và chương trình được lãnh đạo phê duyệt duy trì thành nghi thức quý.

Ghi nhớ

• FinOps thành chương trình khi có con người + quy trình + ưu tiên + trưởng thành, không chỉ là danh sách mẹo. Bài này lắp cả series thành lộ trình hành động.
• Tổng hợp đòn bẩy vào bảng vấn đề → đòn bẩy → tiết kiệm; luôn làm quick wins trước (tắt idle, dọn zombie, tag) vì gần như không rủi ro.
• Tổ chức: FinOps practitioner (điều phối, tạo visibility) + kỹ thuật (thực thi) + tài chính (ngân sách) + lãnh đạo (bảo trợ). Mô hình: enablement tập trung, trách nhiệm phi tập trung.
• Crawl → Walk → Run: visibility trước (tag, dashboard, showback) → tối ưu có ưu tiên + OPERATE (budget/anomaly) → tự động hóa & văn hóa cost-aware.
• Ưu tiên theo tác động: bắt đầu từ khoản chi lớn nhất (thường warehouse compute); dùng ma trận tác động × công sức; Pareto — 80% chi phí ở 20% tài nguyên.
• Tránh tối ưu quá đà: mọi tối ưu có "phanh" SLA — đừng cắt tới mức trễ báo cáo NHNN. Unit cost là thước đo thật, không phải tổng chi.
• Tam giác chi phí – hiệu năng – tuân thủ: dữ liệu ngân hàng giữ theo luật (không xóa bừa, chỉ tiered rẻ hơn); dữ liệu nhạy cảm có thể buộc on-prem/hybrid; thay đổi prod cần phê duyệt.
• Showback tạo nhận thức, chargeback tạo trách nhiệm — bắt đầu showback, lên chargeback khi tag đã chính xác.
• Báo cáo lãnh đạo bằng tiền + unit cost + tiết kiệm lũy kế, luôn kèm câu trấn an rủi ro/tuân thủ.