DataOps 1 — Tổng quan & nguyên tắc

Chiều thứ Sáu, phòng Tài chính cần một báo cáo mới: dư nợ theo sản phẩm, cắt theo chi nhánh, để nộp Ban điều hành sáng thứ Hai. Đội data nhận yêu cầu, viết vài query, kéo dữ liệu, xuất Excel. Thứ Hai báo cáo lên bàn sếp — và một con số lệch 3% so với báo cáo tháng trước. Không ai biết vì sao: query đã sửa tay ba lần, không ai lưu bản nào; một bảng nguồn thay đổi cột từ tuần trước mà đội data không hay; và người viết query đã nghỉ phép. Ba ngày sau mới truy ra nguyên nhân. Trong ba ngày đó, niềm tin vào toàn bộ số liệu của đội data bị bào mòn.

Đây không phải lỗi của một cá nhân, mà là triệu chứng của cách làm việc thiếu kỷ luật vận hành: không version, không test, không automation, không monitor, không ai sở hữu rõ ràng. DataOps ra đời để chữa đúng căn bệnh này.

Đây là bài mở đầu series DataOps & Vận hành nhóm dữ liệu, đi qua cộng tác Agile, version bằng Git, testing & chất lượng, CI/CD, observability & xử lý sự cố, tài liệu & catalog, và thực hành đội nhóm. Bài này đặt nền: DataOps là gì, vì sao cần, khác DevOps ra sao, các nguyên tắc, ba vòng lặp, vai trò và văn hoá.

DataOps là gì

DataOps (Data Operations) là một tập hợp thực hành nhằm rút ngắn thời gian và tăng độ tin cậy khi giao dữ liệu/phân tích (analytics) từ nguồn tới người dùng cuối, bằng cách áp dụng ba trường phái đã chứng minh giá trị:

• Agile — làm việc theo vòng lặp ngắn, giao giá trị liên tục, phản hồi nhanh từ người dùng nghiệp vụ thay vì gom một dự án lớn 6 tháng rồi mới bàn giao.
• DevOps — tự động hoá, CI/CD (Continuous Integration / Continuous Delivery), coi hạ tầng và pipeline là code, phá bỏ ranh giới giữa "người xây" và "người vận hành".
• Lean / Quản lý chất lượng thống kê (SPC — Statistical Process Control) — coi pipeline dữ liệu như một dây chuyền sản xuất: đo lường, kiểm soát chất lượng ngay trên dây chuyền, giảm lãng phí và "phế phẩm" (dữ liệu sai).

Điểm mấu chốt: DataOps không phải một công cụ bạn mua về cài. Nó là sự kết hợp của con người + quy trình + công cụ để đạt một mục tiêu duy nhất: giao dữ liệu đáng tin, nhanh hơn, lặp lại được. Một định nghĩa gọn: DataOps là DevOps cho vòng đời dữ liệu, cộng thêm việc kiểm soát chính bản thân dữ liệu.

Lưu ý phân biệt: DataOps khác MLOps. MLOps tập trung vòng đời của mô hình học máy (train, deploy, monitor drift). DataOps tập trung vòng đời của dữ liệu và pipeline phân tích — là nền móng mà MLOps đứng lên. Xem thêm MLOps — pipeline.

Vì sao ngân hàng cần DataOps

Pipeline dữ liệu ngân hàng có ba đặc tính khiến nó rất dễ vỡ:

1. Phức tạp và nhiều tầng. Dữ liệu chảy từ core banking, hệ thống thẻ, LOS (loan origination system), CRM, ví điện tử… qua CDC (change data capture), qua staging, qua nhiều lớp transform, tới warehouse, tới báo cáo và mô hình. Một thay đổi nhỏ ở đầu nguồn có thể làm hỏng hàng chục báo cáo ở cuối nguồn.
2. Nhiều bên tham gia và tiêu thụ. Data engineer xây pipeline, analyst viết query, data scientist train mô hình, cán bộ nghiệp vụ đọc dashboard, kiểm toán và cơ quan quản lý soi số. Mỗi bên có kỳ vọng khác nhau về cùng một con số.
3. Yêu cầu tuân thủ khắt khe. Số nộp Ngân hàng Nhà nước, báo cáo IFRS 9, tính CAR (hệ số an toàn vốn)… sai là có hậu quả pháp lý, không chỉ "làm lại cho đúng".

Khi thiếu kỷ luật vận hành, tổ chức tích luỹ "analytics debt" (nợ phân tích) — tương tự nợ kỹ thuật (technical debt): những query sửa tay không lưu, những pipeline không ai hiểu, những định nghĩa "nợ xấu" khác nhau giữa các phòng. Nợ này khiến mọi yêu cầu mới đều chậm và mọi kết quả đều thiếu tin cậy. DataOps là cách trả nợ đó một cách có hệ thống.

DataOps khác DevOps ở chỗ nào

DataOps kế thừa gần như toàn bộ DevOps, nhưng bổ sung một chiều hoàn toàn mới: DỮ LIỆU.

Trong phần mềm truyền thống, thứ thay đổi là code; dữ liệu (input của người dùng) thay đổi nhưng logic xử lý là cố định và đã được test. Trong hệ thống dữ liệu, cả code lẫn dữ liệu đều thay đổi và bạn không kiểm soát dữ liệu: một hệ nguồn có thể đổi schema, một chi nhánh nhập sai đơn vị tiền tệ, một ngày lễ khiến khối lượng giao dịch sụt bất thường. Code đúng vẫn có thể cho ra kết quả sai vì dữ liệu đầu vào đã đổi.

Khía cạnh	DevOps (phần mềm)	DataOps (dữ liệu)
Thứ thay đổi	Chủ yếu là code	Cả code và dữ liệu
Kiểm soát đầu vào	Input được validate, logic cố định	Dữ liệu nguồn thay đổi ngoài tầm kiểm soát
Test cái gì	Test code (unit, integration)	Test code + dữ liệu + mô hình/logic nghiệp vụ
Người tiêu thụ	Người dùng ứng dụng	Nhiều bên: analyst, scientist, nghiệp vụ, kiểm toán
"Lỗi" nghĩa là gì	Ứng dụng crash / bug logic	Con số trông đúng nhưng sai — nguy hiểm hơn
Artifact	Bản build, container	Bản build + dataset + schema + định nghĩa metric

Hệ quả quan trọng nhất: trong DataOps, test dữ liệu quan trọng ngang test code. Một pipeline có thể chạy "xanh" (không lỗi kỹ thuật) mà vẫn giao ra số sai. Vì vậy DataOps yêu cầu kiểm thử cả hình dạng dữ liệu (schema, kiểu, độ đầy đủ) lẫn ý nghĩa nghiệp vụ (dư nợ không âm, tổng chi nhánh khớp tổng toàn hàng). Chủ đề này được đào sâu ở bài testing & chất lượng và liên hệ chặt với chất lượng dữ liệu.

Các nguyên tắc cốt lõi

Theo tinh thần DataOps Manifesto, có thể chưng cất thành các nguyên tắc thực chiến sau:

1. Giao giá trị liên tục. Thước đo thành công là sự hài lòng của người dùng nghiệp vụ, thể hiện qua việc liên tục giao ra phân tích đáng tin, không phải số dòng code hay số pipeline.
2. Coi analytics là code. Mọi thứ — SQL transform, cấu hình pipeline, định nghĩa metric, hạ tầng — đều được viết dưới dạng code và đưa vào version control (Git). Không sửa tay trên production. Xem version bằng Git.
3. Tự động hoá & CI/CD. Việc lặp đi lặp lại (build, test, deploy pipeline) phải được máy làm. Con người dành sức cho việc cần tư duy. Xem CI/CD & automation.
4. Kiểm thử mọi thứ. Mỗi thay đổi phải qua test tự động cho code, cho dữ liệu, cho logic nghiệp vụ trước khi lên production.
5. Giám sát pipeline và dữ liệu (monitor / observability). Không chỉ theo dõi "job chạy hay lỗi", mà cả "dữ liệu có bất thường không" — độ trễ (freshness), khối lượng (volume), phân bố (distribution). Xem observability & sự cố và observability tổng quan.
6. Chất lượng tích hợp sẵn, không kiểm ở cuối. Kiểm soát chất lượng đặt ngay trên dây chuyền (như SPC), không phải kiểm tra thủ công sau khi đã bàn giao. Bắt lỗi sớm rẻ hơn bắt lỗi muộn hàng chục lần.
7. Cộng tác & phá silo. Engineer, analyst, scientist, nghiệp vụ làm việc chung, chia sẻ ngữ cảnh, dùng chung định nghĩa. Xem cộng tác Agile.
8. Lặp nhanh (iterate). Vòng lặp ngắn, phản hồi sớm, điều chỉnh liên tục thay vì "big bang" một lần.
9. Tính lặp lại được (reproducibility). Cho cùng một input và cùng một phiên bản code, pipeline phải cho ra cùng một kết quả — điều kiện tiên quyết để audit và debug. Đòi hỏi version cho cả code, cấu hình, và ảnh chụp dữ liệu (data snapshot).

Ba vòng lặp của DataOps

Một mô hình tư duy hữu ích của DataOps là ba vòng lặp lồng nhau. Hai vòng chạy trong hệ thống và một vòng phản hồi ràng buộc chúng.

• Vòng phát triển (dev / innovation pipeline): nơi ý tưởng biến thành pipeline mới. Analyst/engineer viết code trong nhánh riêng, test trên môi trường sandbox, review, rồi merge qua CI/CD. Mục tiêu: thay đổi an toàn, nhanh.
• Vòng giá trị (value pipeline): pipeline production chạy hằng ngày biến dữ liệu thô thành báo cáo/mô hình phục vụ nghiệp vụ. Vòng này được monitor và kiểm soát chất lượng liên tục. Mục tiêu: vận hành ổn định, số đáng tin.
• Vòng phản hồi (feedback): người dùng nghiệp vụ và hệ thống monitor gửi tín hiệu ngược lại vòng phát triển — báo cáo sai, chậm, thiếu chỉ số. Tín hiệu này định hướng ưu tiên cho vòng phát triển kế tiếp.

Sức mạnh của mô hình này là nó tách bạch "an toàn khi thay đổi" (dev pipeline) khỏi "đáng tin khi chạy" (value pipeline), đồng thời buộc hai vòng phải khép kín qua feedback — chính là điều mà cách làm tuỳ hứng ("sửa tay trên production") không có.

Vai trò trong tổ chức

DataOps cần nhiều vai phối hợp, không phải một siêu nhân:

Vai trò	Trách nhiệm chính trong DataOps
Data engineer	Xây và bảo trì pipeline, tự động hoá, đảm bảo reproducibility và hiệu năng
Data analyst	Viết transform/metric, kiểm chứng số với nghiệp vụ, viết test nghiệp vụ
Data scientist	Xây feature & mô hình trên nền dữ liệu tin cậy, phối hợp với MLOps
Data steward	Sở hữu định nghĩa & chất lượng dữ liệu của một miền (domain), duyệt data contract
Platform / DataOps engineer	Cung cấp nền tảng self-serve: CI/CD, môi trường, công cụ test & monitor

Nguyên tắc tổ chức: mỗi dataset/báo cáo quan trọng phải có một người sở hữu (owner) rõ ràng. Không owner nghĩa là không ai chịu trách nhiệm khi số sai — đúng tình huống mở đầu bài.

Văn hoá DataOps

Công cụ và quy trình chỉ phát huy khi văn hoá đúng. Ba trụ cột văn hoá:

• Blameless (không đổ lỗi). Khi sự cố xảy ra, hỏi "quy trình nào đã cho phép lỗi này lọt qua?" thay vì "ai làm sai?". Chỉ khi an toàn tâm lý, người ta mới báo lỗi sớm và trung thực — điều kiện để cải tiến. Post-mortem tập trung vào hệ thống, không vào cá nhân.
• Chia sẻ (transparency). Định nghĩa metric, code pipeline, tài liệu, dashboard chất lượng — tất cả công khai trong đội. Không có "black box" mà chỉ một người hiểu. Xem tài liệu & catalog.
• Đo lường (measure). Cải tiến cái gì đo được. Theo dõi các chỉ số như thời gian từ yêu cầu đến giao (lead time), tần suất triển khai, tỷ lệ pipeline lỗi, thời gian khôi phục sau sự cố (MTTR), số lỗi dữ liệu bắt được trước khi tới người dùng.

Lộ trình series

Bài này là điểm khởi đầu. Các bài tiếp theo đi sâu từng mảnh:

Bài	Nội dung
02 — Cộng tác Agile	Sprint, kanban, backlog cho đội data; làm việc với nghiệp vụ
03 — Version bằng Git	Coi analytics là code; branch, review, quản lý cấu hình
04 — Testing & chất lượng	Test code + dữ liệu + logic; kiểm soát chất lượng inline
05 — CI/CD & automation	Đường ống triển khai tự động cho pipeline dữ liệu
06 — Observability & sự cố	Monitor freshness/volume/distribution; xử lý incident
07 — Tài liệu & catalog	Tri thức không nằm trong đầu một người; data catalog
08 — Thực hành đội nhóm	Ghép mọi thứ thành cách làm việc thực tế của một đội

Use case thực tế

Bối cảnh. Đội data một ngân hàng cỡ vừa giao báo cáo dư nợ theo sản phẩm và chi nhánh cho phòng Tài chính hằng ngày (nộp lãnh đạo) và định kỳ tổng hợp lên báo cáo Ngân hàng Nhà nước. Trước khi áp dụng DataOps:

• Query dư nợ được sửa tay trực tiếp trên môi trường production, không lưu lịch sử.
• Không có test; một lần hệ nguồn LOS đổi cột product_code, báo cáo âm thầm sai suốt 9 ngày mới bị nghiệp vụ phát hiện.
• Trung bình mỗi tháng có 3 sự cố số sai, mỗi lần mất khoảng nửa ngày điều tra vì không ai truy được thay đổi nào gây ra.
• Một yêu cầu báo cáo mới mất trung bình 6 tuần để ra bản đầu tiên.

Áp dụng DataOps theo 5 bước:

1. Đưa toàn bộ SQL/transform vào Git — mỗi thay đổi có review, có lịch sử, không sửa tay production nữa (analytics là code).
2. Thêm test dữ liệu — kiểm tra product_code luôn thuộc danh mục hợp lệ, dư nợ không âm, tổng theo chi nhánh khớp tổng toàn hàng ±0. Test chạy trước mỗi lần deploy.
3. CI/CD — mọi thay đổi qua pipeline tự động: chạy test trên sandbox, chỉ merge & deploy khi xanh.
4. Monitor freshness & volume — cảnh báo nếu bảng dư nợ không cập nhật đúng giờ hoặc số bản ghi lệch bất thường so với hôm trước.
5. Owner & post-mortem blameless — mỗi báo cáo có một owner; mỗi sự cố có post-mortem tập trung vào lỗ hổng quy trình.

Kết quả sau một quý (số minh hoạ điển hình cho loại chuyển đổi này):

Chỉ số	Trước	Sau
Thời gian phát hiện lỗi schema nguồn	~9 ngày	Ngay lần chạy tiếp theo (test bắt)
Sự cố số sai / tháng	~3	< 1
Thời gian điều tra mỗi sự cố	~nửa ngày	~30 phút (truy Git + log)
Lead time yêu cầu mới	~6 tuần	~1–2 tuần

Câu chốt cho nghiệp vụ: cùng con người, cùng công cụ — chỉ thay cách vận hành — đội data giao số nhanh hơn và đáng tin hơn, đúng điều mà môi trường tuân thủ của ngân hàng đòi hỏi.

Ghi nhớ

• DataOps = Agile + DevOps + Lean/SPC áp vào vòng đời dữ liệu; là con người + quy trình + công cụ, không phải một sản phẩm mua về.
• Mục tiêu duy nhất: giao dữ liệu/phân tích đáng tin, nhanh hơn, lặp lại được.
• Khác DevOps ở chiều dữ liệu: cả code lẫn dữ liệu đều thay đổi và dữ liệu ngoài tầm kiểm soát → phải test cả dữ liệu, không chỉ code. "Lỗi" nguy hiểm nhất là số trông đúng mà sai.
• Ngân hàng cần DataOps vì pipeline phức tạp, nhiều bên, và yêu cầu tuân thủ; thiếu kỷ luật sinh "analytics debt" → chậm & thiếu tin cậy.
• Nguyên tắc cốt lõi: analytics là code, tự động hoá & CI/CD, kiểm thử mọi thứ, monitor pipeline lẫn dữ liệu, chất lượng inline (không kiểm ở cuối), cộng tác phá silo, lặp nhanh, reproducibility.
• Ba vòng lặp: dev pipeline (an toàn khi thay đổi), value pipeline (đáng tin khi chạy), feedback (khép kín hai vòng kia).
• Cần owner rõ ràng cho mỗi dataset/báo cáo; văn hoá blameless, minh bạch, đo lường được.
• DataOps là nền cho MLOps và governance — không có dữ liệu tin cậy thì mô hình và báo cáo đều vô nghĩa.