DataOps 8 — Xây dựng & vận hành nhóm dữ liệu

Từ công cụ đến con người

Bảy bài trước của series DataOps nói về cách làm: Agile, Git & analytics as code, testing, CI/CD, observability và tài liệu/catalog. Nhưng công cụ tốt trong tay một đội tổ chức sai vẫn cho ra kết quả tệ: pipeline đầy đủ CI nhưng không ai chịu trách nhiệm khi số sai; catalog đẹp nhưng analyst vẫn phải mở ticket chờ hàng tuần.

Bài cuối này bàn về con người và tổ chức — mảnh ghép quyết định liệu tất cả kỹ thuật ở trên có thực sự tạo ra giá trị hay không. Trong ngân hàng, câu hỏi không chỉ là "làm sao giao dữ liệu nhanh" mà còn "làm sao đội dữ liệu vừa nhanh vừa đứng vững trước rủi ro, tuân thủ và kiểm toán".

Các vai trò trong nhóm dữ liệu

Nhiều ngân hàng gộp tất cả vào một chức danh "cán bộ dữ liệu" và trông đợi mỗi người làm hết. Đây là nguồn gốc của quá tải và chất lượng thấp. Một đội trưởng thành phân định vai trò rõ ràng:

Khác biệt cốt lõi thường bị nhầm lẫn:

• Data Engineer vs Analytics Engineer: engineer lo đưa dữ liệu về và làm nó chạy được; analytics engineer lo biến nó thành mô hình đúng nghĩa nghiệp vụ. Analytics engineer sống ở tầng dbt/SQL, gần analyst hơn hạ tầng.
• Data Analyst vs Data Scientist: analyst trả lời "chuyện gì đã/đang xảy ra"; scientist trả lời "sẽ xảy ra gì, vì sao" bằng mô hình.
• Data Scientist vs ML Engineer: scientist xây mô hình; ML engineer làm nó chạy ổn định 24/7 trong production (xem ml-08-deployment-mlops).

Ở đội nhỏ, một người kiêm nhiều vai — điều đó bình thường. Vấn đề chỉ phát sinh khi không ai biết mình đang đội mũ nào, dẫn tới việc quan trọng (governance, hạ tầng) bị bỏ rơi vì "ai cũng tưởng người khác lo".

Ba mô hình tổ chức

Cách xếp các vai trò trên vào sơ đồ tổ chức quyết định tốc độ và chất lượng của cả đội.

Tập trung (Centralized)

Toàn bộ nhân sự dữ liệu ngồi trong một phòng dữ liệu duy nhất, nhận yêu cầu từ các khối nghiệp vụ (bán lẻ, doanh nghiệp, rủi ro, tài chính).

• Ưu: chuẩn kỹ thuật thống nhất, dễ chia sẻ tri thức, dễ kiểm soát/tuân thủ — phù hợp môi trường ngân hàng.
• Nhược: trở thành nút cổ chai. Nghiệp vụ không hiểu sâu bài toán, đội dữ liệu không hiểu sâu ngữ cảnh; mọi thứ qua ticket, thời gian đáp ứng dài.

Phi tập trung / Nhúng (Embedded/Decentralized)

Analyst và engineer được đặt trong từng khối nghiệp vụ, báo cáo cho lãnh đạo nghiệp vụ.

• Ưu: gần khách hàng nội bộ, hiểu ngữ cảnh sâu, phản ứng nhanh.
• Nhược: mỗi khối tự làm một kiểu — trùng lặp pipeline, định nghĩa "nợ xấu" mỗi nơi một khác, không ai lo hạ tầng chung, tri thức không lan toả. Đây chính là "silo dữ liệu" phiên bản tổ chức.

Hub-and-Spoke (thường tối ưu)

Kết hợp cả hai: một hub trung tâm sở hữu nền tảng, chuẩn và governance; các spoke là analyst/analytics engineer nhúng trong nghiệp vụ nhưng dùng chung nền tảng của hub.

Mô hình này cân bằng: tốc độ (spoke gần nghiệp vụ) đi cùng nhất quán (hub giữ chuẩn). Analyst trong khối rủi ro tự viết mart của mình nhưng dùng bảng nguồn đã chuẩn hoá và định nghĩa chỉ tiêu thống nhất từ hub. Đây cũng là tinh thần của data mesh: coi mỗi domain nghiệp vụ là chủ sở hữu "data product" của mình, còn platform team cung cấp nền tảng tự phục vụ để họ tự làm được — thay vì một đội trung tâm ôm hết.

Vai trò của Platform Team

Trong hub-and-spoke, platform team là đòn bẩy nhân sự lớn nhất: thay vì làm hộ, họ xây công cụ để người khác tự làm. Trách nhiệm gồm nền tảng lưu trữ/tính toán, framework CI/CD, quản lý quyền và chi phí, chuẩn hoá pattern (template pipeline, template dbt project), và cung cấp golden path — con đường "đúng" mà ai đi theo cũng an toàn. Một platform team tốt được đo bằng việc các đội khác tự làm được bao nhiêu mà không cần gõ cửa họ.

Self-service: chìa khoá mở rộng

Không đội trung tâm nào tuyển kịp tốc độ nhu cầu dữ liệu của cả ngân hàng. Cách duy nhất để scale là tự phục vụ (self-service): người cần dữ liệu tự lấy được, trong lằn ranh an toàn.

Self-service không phải "mở toang cho ai muốn làm gì thì làm", mà là hạ tầng có kiểm soát:

• Catalog & glossary để tự tìm bảng, hiểu cột (xem dataops-07).
• Mart & metrics layer chuẩn hoá để analyst không phải tự join lại từ raw.
• Template & golden path để tạo pipeline/model mới nhanh, đúng chuẩn.
• Quyền theo vai trò để mở quyền đọc rộng nhưng kiểm soát ghi/PII chặt.

Kết quả: platform team giảm tải khỏi việc lặp lại, tập trung nâng nền tảng; đội dữ liệu chuyển từ "người gác cổng" sang "người tạo đòn bẩy".

Quy trình vận hành — kết tinh cả series

Quy trình chuẩn của một đội DataOps trưởng thành thực chất là hợp lưu của toàn bộ series:

Mỗi mũi tên là một bài trong series. Điểm quan trọng: đây là vòng lặp, không phải đường thẳng — observability phát hiện vấn đề lại quay về backlog, docs cập nhật lại làm mượt yêu cầu tiếp theo.

Đo lường hiệu quả nhóm dữ liệu

"Đội mình làm tốt không?" không thể trả lời bằng cảm tính. Bốn DORA metrics (vốn dùng cho DevOps) áp được cho data:

Ngoài DORA, đội dữ liệu cần thêm nhóm chỉ số riêng:

• Chất lượng dữ liệu: tỷ lệ test pass, số incident chất lượng/tháng, độ tươi (freshness).
• Độ hài lòng người dùng: khảo sát nghiệp vụ, số câu hỏi lặp lại (dấu hiệu docs kém).
• Thời gian đáp ứng yêu cầu: median lead time của ticket ad-hoc.
• Độ phủ tài liệu & test: % bảng có mô tả, % model có test.

Lưu ý phản-mẫu: đừng đo bằng "số dòng SQL" hay "số dashboard" — chúng khuyến khích làm nhiều thay vì làm đúng.

Bản thân đội cũng nên theo dõi vài "metric vận hành" đơn giản ngay trên dữ liệu. Ví dụ minh hoạ, đếm số sự kiện theo loại (đại diện cho việc thống kê khối lượng công việc) trên sandbox — cùng ý tưởng, đội có thể thay bằng bảng công việc thực tế của mình rồi nhóm theo team:

-- ▶ Chạy được
SELECT kind, COUNT(*) AS so_luong, SUM(amount) AS tong_gia_tri
FROM transactions
GROUP BY kind
ORDER BY so_luong DESC;

Văn hoá — thứ khó sao chép nhất

Công cụ mua được, văn hoá thì không. Đây là yếu tố phân biệt đội "làm được việc" với đội "cháy máy liên tục".

Ownership (làm chủ): mỗi bảng/pipeline/chỉ tiêu có chủ sở hữu rõ ràng, không phải "của chung ai cũng sửa được và không ai chịu trách nhiệm". Ownership gắn với data product: người sở hữu chịu trách nhiệm cả chất lượng lẫn tài liệu.

Blameless (không đổ lỗi): khi số liệu sai, tập trung vào hệ thống/quy trình để sao lỗi đó xảy ra được, không truy cá nhân. Blameless postmortem (xem observability) là điều kiện để người ta dám báo lỗi sớm thay vì giấu.

Chia sẻ tri thức: demo nội bộ, code review là dịp dạy nhau, pairing khi onboarding, viết ADR/runbook thay vì giữ trong đầu.

Cân bằng giao nhanh vs chất lượng/nợ kỹ thuật: áp lực giao nhanh luôn có, nhưng bỏ qua test/docs sẽ tích nợ kỹ thuật (technical debt) — vay tốc độ hôm nay, trả lãi bằng sự cố ngày mai. Đội trưởng thành dành ngân sách cố định (ví dụ ~20% sprint) để trả nợ.

Chống burnout — vấn đề sống còn

Đội dữ liệu ngân hàng đặc biệt dễ kiệt sức vì bị "băm" bởi yêu cầu ad-hoc và trực sự cố. Biện pháp thực chiến:

• Quản lý ad-hoc: gom yêu cầu vào một hàng đợi có ưu tiên, cắt cử một người "trực analyst" luân phiên để phần còn lại tập trung làm việc sâu — thay vì ai cũng bị ngắt quãng.
• Giới hạn WIP (Work In Progress): giới hạn số việc đang làm đồng thời; làm xong mới nhận tiếp. Giảm chuyển ngữ cảnh, tăng thông lượng thực.
• On-call bền vững: lịch trực rõ, xoay vòng công bằng, mọi alert trực đều phải hành động được (nếu không thì sửa/tắt alert đó); sau ca trực căng có nghỉ bù.

Tuyển dụng & phát triển kỹ năng

• Tuyển theo mô hình tổ chức: hub cần người mạnh nền tảng/governance; spoke cần người mạnh giao tiếp nghiệp vụ + SQL/dbt. Ưu tiên T-shaped: sâu một mảng, biết rộng các mảng lân cận.
• Lộ trình phát triển: có nhánh chuyên gia (individual contributor) song song nhánh quản lý, để người giỏi kỹ thuật không buộc phải làm quản lý mới thăng tiến.
• Onboarding chuẩn hoá: dựa trên catalog/docs để người mới tự học, rút thời gian "biết việc" từ vài tháng xuống vài tuần.

Đặc thù ngân hàng

Mọi thứ trên áp cho ngân hàng đều phải nhìn qua lăng kính kiểm soát:

• Phối hợp ba tuyến phòng vệ: đội dữ liệu (tuyến 1) làm việc chặt với quản lý rủi ro/tuân thủ (tuyến 2) và kiểm toán nội bộ (tuyến 3). Mọi chỉ tiêu rủi ro, mọi mô hình scorecard đều cần validation độc lập.
• Môi trường quản lý chặt: phân tách môi trường dev/prod, kiểm soát quyền truy cập PII (xem gov-07-privacy-compliance), lưu vết thay đổi (audit trail) — chính là lý do Git, CI/CD và catalog không phải "tuỳ chọn" mà là bắt buộc.
• Cân bằng đổi mới & kiểm soát: không thể "move fast and break things" với số liệu báo cáo NHNN. Nhưng cũng không được lấy tuân thủ làm cớ đóng băng. Hub-and-spoke giúp cân bằng: hub giữ kiểm soát/chuẩn, spoke đổi mới nhanh trong lằn ranh an toàn.

Lộ trình trưởng thành DataOps

Không đội nào nhảy thẳng lên đỉnh. Đây là bản đồ tự đánh giá và cải tiến dần:

Cách dùng: định vị đội đang ở đâu, chọn một điểm yếu lớn nhất để cải tiến trong quý tới, đo bằng chỉ số ở trên, rồi lặp lại. Trưởng thành DataOps là hành trình liên tục, không phải đích đến.

Bản đồ tổng kết series

Use case thực tế

Bối cảnh: Phòng Dữ liệu một ngân hàng cỡ vừa có 12 người, tổ chức tập trung. Backlog tồn 60+ yêu cầu, lead time trung bình một ticket phân tích là 18 ngày; hai analyst kỳ cựu ôm 70% việc và cả hai đều có dấu hiệu burnout; ba khối nghiệp vụ định nghĩa "tỷ lệ nợ xấu" khác nhau, kiểm toán từng phàn nàn.

Chuyển đổi sang hub-and-spoke trong 2 quý:

1. Lập hub (5 người): 2 platform/infra + 1 governance + 2 analytics engineer lõi. Nhiệm vụ đầu tiên: chuẩn hoá bảng nguồn và định nghĩa "nợ xấu" duy nhất trong glossary.
2. Đẩy 6 analyst thành spoke: nhúng 2 người/khối vào bán lẻ, rủi ro, tài chính; vẫn báo cáo chuyên môn về hub nhưng ưu tiên do nghiệp vụ đặt.
3. Chống quá tải: áp WIP limit = 2 việc/người; lập hàng đợi ad-hoc luân phiên trực; đưa on-call thành lịch xoay 6 người.
4. Đo lường: thiết lập dashboard DORA cho data + 4 chỉ số chất lượng/hài lòng.

Kết quả sau 2 quý (minh hoạ): lead time ticket giảm từ 18 xuống 6 ngày; ba khối dùng chung một định nghĩa nợ xấu, kiểm toán không còn phàn nàn về sai lệch số; tải của hai analyst kỳ cựu giảm còn ~35% nhờ self-service. Chi phí: 2 quý xây nền tảng và một giai đoạn chuyển đổi chậm lại — đánh đổi xứng đáng.

Ghi nhớ

• Phân định vai trò rõ (engineer, analytics engineer, analyst, scientist, ML engineer, platform, governance, product) để việc quan trọng không bị bỏ rơi; đội nhỏ kiêm nhiệm được nhưng phải biết mình đội mũ nào.
• Hub-and-spoke thường tối ưu: hub giữ nền tảng/chuẩn/governance, spoke nhúng trong nghiệp vụ để nhanh — cân bằng tốc độ và nhất quán, đúng tinh thần data mesh.
• Platform team & self-service là đòn bẩy scale: xây công cụ để người khác tự làm, thay vì làm hộ.
• Đo bằng DORA áp cho data (deploy frequency, lead time, change failure rate, MTTR) cộng chất lượng dữ liệu, hài lòng người dùng, độ phủ docs/test — tránh đo bằng "số lượng".
• Văn hoá quyết định: ownership rõ ràng, blameless, chia sẻ tri thức, cân bằng giao nhanh vs nợ kỹ thuật.
• Chống burnout chủ động: quản lý ad-hoc, WIP limit, on-call bền vững — vấn đề sống còn ở đội dữ liệu ngân hàng.
• Đặc thù ngân hàng: phối hợp ba tuyến phòng vệ (rủi ro/tuân thủ/kiểm toán), môi trường kiểm soát chặt, cân bằng đổi mới và kiểm soát.
• Trưởng thành DataOps là hành trình: tự định vị mức 1→4, chọn một điểm yếu lớn nhất cải tiến mỗi quý, đo và lặp lại.