DataOps nâng cao 7 — Data Platform Engineering & Self-service

Vì sao cần một nền tảng, không chỉ nhiều pipeline

Sau sáu bài của series, ta đã có kiến trúc, dbt, Airflow, CI/CD, data contract và observability — đủ để một đội dựng một data product tốt. Vấn đề của quy mô là: NCB không có một đội, mà có nhiều domain (thẻ, tín dụng, huy động, rủi ro, kênh số). Nếu mỗi domain tự dựng lại toàn bộ stack — tự cấu hình warehouse, tự viết framework dbt, tự dựng Airflow, tự nghĩ cách làm CI, tự lo mã hoá và quyền — thì ta có N cách làm khác nhau, N chất lượng khác nhau, N chỗ rò rỉ PII khác nhau, và mỗi data product mới tốn hàng tuần chỉ để dựng khung.

Bài này đi sâu hơn Data Mesh 5 — Nền tảng tự phục vụ ở góc platform engineering thuần kỹ thuật: làm sao xây một nền tảng dùng chung để mỗi domain tạo pipeline và data product nhanh và tuân thủ sẵn, với một đội platform nhỏ. Đây là chỗ DataOps chuyển từ "làm tốt một lần" sang "làm tốt hàng loạt".

Platform as a Product: nền tảng là sản phẩm nội bộ

Sai lầm phổ biến là coi nền tảng dữ liệu như một dự án hạ tầng: dựng xong là hết việc. Đúng ra, nền tảng là một sản phẩm, và khách hàng của nó là người dùng nội bộ — data engineer và analyst của các domain. Suy nghĩ này thay đổi mọi thứ:

• Có roadmap, có backlog, có phiên bản; nghe phản hồi người dùng như nghe phản hồi khách hàng.
• Đo bằng developer experience và thời gian tạo data product (time-to-first-pipeline), không đo bằng số server hay số dòng Terraform.
• Nền tảng phải dễ dùng hơn tự làm. Nếu domain thấy tự dựng nhanh hơn dùng nền tảng, họ sẽ đi vòng (shadow IT) và ta thua.

Vài chỉ số sức khoẻ nền tảng đáng theo dõi:

Chỉ số quan trọng nhất là ticket giảm dần: nếu mỗi domain mới vẫn phải mở ticket nhờ platform team làm hộ, nghĩa là nền tảng chưa thực sự self-serve.

Các năng lực nền tảng cung cấp dưới dạng self-service

Nền tảng gói các quyết định lặp lại thành năng lực (capability) mà domain tự lấy dùng, không cần platform team can thiệp thủ công. Danh mục năng lực điển hình cho NCB:

• Môi trường & compute: warehouse/lakehouse chuẩn hoá (ví dụ một cụm warehouse dùng chung với schema tách theo domain, hoặc lakehouse trên object storage + engine truy vấn). Domain xin một môi trường dev/staging/prod và được cấp compute theo quota.
• Ingestion / EL chuẩn: một khung Extract-Load thống nhất (connector từ core banking, card switch, file batch) để domain khai báo nguồn thay vì tự viết loader. Chuẩn hoá cách landing, cách đặt tên, cách bắt CDC.
• Khung dbt chung: một project template dbt với macro chung (chuẩn hoá tiền tệ, mã hoá PII, quy ước phân lớp staging/marts), test mặc định, cấu hình profiles trỏ đúng môi trường. Domain dbt init từ template là có sẵn best practice.
• Orchestration: Airflow được quản lý (managed) — platform team vận hành cụm, domain chỉ deploy DAG qua repo của mình. Không domain nào tự dựng và vá Airflow. Nền tảng vận hành xem Airflow 7 — Production ops.
• CI/CD template: pipeline mẫu (lint → compile → slim CI → test → deploy) dán vào repo là chạy, kế thừa từ DataOps nâng cao 4 — CI/CD analytics.
• Data quality & observability tích hợp sẵn: data contract, test dbt, freshness và anomaly detection bật mặc định — kế thừa DataOps nâng cao 5 — Quality & contracts và DataOps nâng cao 6 — Observability & DRE.
• Catalog & lineage: mọi model đăng ký tự động vào catalog, lineage sinh từ dbt, không phải khai tay — xem Governance — Catalog & lineage.
• Access control: cấp quyền theo vai trò/domain, chuẩn hoá phân tầng dữ liệu nhạy cảm.

Điểm chung: mỗi năng lực giấu độ phức tạp phía sau một giao diện đơn giản (một file khai báo, một lệnh CLI, một PR). Domain không cần biết Terraform bên dưới cấp warehouse thế nào.

Golden path / Paved road: con đường mặc định tốt

Golden path (còn gọi paved road — "đường đã trải nhựa") là con đường mặc định mà nền tảng khuyến nghị và làm cho nó dễ nhất: một bộ template + scaffolding để domain tạo pipeline/data product vừa nhanh vừa tuân thủ sẵn. Ý tưởng cốt lõi: giảm số quyết định lặp lại. Mỗi lần domain phải tự chọn "dùng warehouse nào, đặt tên schema ra sao, mã hoá PII kiểu gì, CI viết thế nào" là một lần có thể chọn sai và một lần tốn thời gian. Golden path đã chọn sẵn phương án tốt.

Sức mạnh của paved road không phải cấm đường khác, mà làm đường tốt trở thành đường dễ đi nhất. Domain vẫn có thể đi lệch (ví dụ cần một engine đặc thù cho ML), nhưng khi đó họ tự gánh trách nhiệm vận hành phần lệch đó — chi phí lệch đường là có thật và rõ ràng.

Một scaffolding CLI minh hoạ (không phải công cụ có thật, chỉ mô tả trải nghiệm mong muốn):

# minh hoạ — tạo data product mới theo golden path
$ ncb-dp new data-product \
    --domain the        \
    --name  card_txn_daily \
    --owner [email protected]

# công cụ sẽ scaffold ra:
#   repos/the-card_txn_daily/
#   ├── dbt_project.yml         # kế thừa macro & test chung
#   ├── models/staging/         # template staging layer
#   ├── models/marts/
#   ├── dags/                   # DAG mẫu deploy lên Airflow quản lý
#   ├── .github/workflows/ci.yml# CI template
#   ├── contracts/              # data contract mẫu
#   └── infra/                  # module Terraform xin schema + quota

Chỉ một lệnh, domain có repo đầy đủ: dbt đúng chuẩn, CI xanh, DAG khung, contract mẫu, và khai báo hạ tầng. Việc còn lại của họ là viết logic nghiệp vụ — đúng phần tạo giá trị — thay vì dựng khung.

IaC: Terraform và tự động cấp phát

Nền tảng chuẩn hoá tài nguyên bằng Infrastructure as Code (IaC) — hạ tầng mô tả bằng code, ở đây là Terraform. Thay vì platform team bấm tay trên console để tạo schema/role/quota (chậm, dễ lệch, không truy vết), ta viết module Terraform đóng gói "một môi trường domain chuẩn":

# minh hoạ — module chuẩn hoá một môi trường domain
module "domain_env" {
  source      = "git::ssh://git@ncb/platform/tf-modules//domain-env?ref=v2.3.0"

  domain      = "the"           # thẻ
  environment = "staging"
  owner_group = "team-the"

  warehouse_size = "small"      # quota compute mặc định
  storage_quota  = "500GB"
  pii_masking    = true         # bật mã hoá/mask cột nhạy cảm mặc định
  cost_center    = "CC-DATA-THE"
}

Module này sinh ra schema, role, grant quyền, quota, tag chi phí — tất cả đồng nhất giữa các domain. Sửa chuẩn một chỗ (bản v2.4.0), mọi môi trường tạo sau đều theo chuẩn mới.

Self-serve provisioning là mấu chốt: domain không xin qua ticket, mà qua PR hoặc portal. Quy trình:

1. Domain thêm/sửa một khối module "domain_env" trong repo IaC, mở PR.
2. CI chạy terraform plan, in ra diff hạ tầng sẽ tạo.
3. Platform team review (hoặc policy tự duyệt nếu trong giới hạn — quota nhỏ, tag đủ).
4. Merge → CD chạy terraform apply → tài nguyên được cấp trong ít phút.

Đây là "everything as code": hạ tầng, pipeline, quyền, chính sách chất lượng — tất cả đều là code trong Git, review được, rollback được, audit được. Với ngân hàng, chỉ riêng việc mọi thay đổi hạ tầng đều để lại dấu vết PR đã đáp ứng phần lớn yêu cầu kiểm toán.

Môi trường ephemeral

Vì môi trường là code, ta có thể tạo và xoá nó theo nhu cầu. Môi trường ephemeral (tạm thời, sống ngắn) rất hợp cho CI: mỗi PR lớn có thể spin-up một schema ci_pr_1234 cô lập để chạy dbt build trên dữ liệu mẫu, rồi teardown khi PR đóng. Không đụng dữ liệu chung, không để rác. Terraform + tag TTL (time-to-live) giúp dọn tự động các môi trường quá hạn.

Governance & Security by default

Điểm khác biệt lớn nhất của nền tảng ngân hàng: baseline bảo mật và tuân thủ phải nhúng sẵn, không để domain tự nhớ. Đây là governance-by-default — làm đúng là mặc định, làm sai phải cố ý:

• Mã hoá: dữ liệu at-rest và in-transit mã hoá mặc định ở lớp hạ tầng, domain không cần cấu hình.
• Quyền tối thiểu: role sinh từ module chỉ cấp quyền vừa đủ cho domain đó; không có quyền chéo domain trừ khi khai báo tường minh.
• PII: macro dbt chung tự động mã hoá/mask cột nhạy cảm (số CMND, số thẻ, sđt) khi vào lớp marts dùng chung; policy tag PII gắn tự động trong catalog — nền tảng Governance — Privacy & compliance.
• Không lộ: mặc định schema domain private; muốn chia sẻ ra ngoài phải qua data contract công bố (published), có phê duyệt.

Nguyên tắc: domain khó làm sai bảo mật hơn làm đúng, vì đường mặc định (golden path) đã an toàn. Đó là cách một đội platform nhỏ vẫn giữ được tuân thủ trên hàng chục data product.

Chi phí & FinOps

Nền tảng dùng chung dễ trở thành hố tiền nếu không kiểm soát. IaC giúp gắn FinOps ngay từ lúc cấp tài nguyên:

• Tag bắt buộc: mỗi tài nguyên có domain, cost_center, environment — không tag thì terraform plan fail. Nhờ đó chi phí quy được về đúng domain (showback/chargeback).
• Quota: warehouse size và storage quota mặc định vừa phải; vượt phải xin nâng qua PR (thấy rõ ai tiêu gì).
• Ephemeral + auto-suspend: warehouse tự ngủ khi không dùng, môi trường CI tự xoá.

Chi tiết mô hình chi phí xem FinOps — Tổng quan. Điểm cốt lõi: FinOps không phải việc làm sau, mà là thuộc tính của golden path — dùng đường mặc định là đã tối ưu chi phí sẵn.

Kiến trúc năng lực & golden path

Đọc sơ đồ: domain chỉ chạm vào phần trên (logic nghiệp vụ + golden path). Mọi thứ dưới golden path — năng lực và baseline — do IaC dựng chuẩn hoá, domain không phải tự lo.

Tránh nền tảng thành nút thắt mới

Nghịch lý cần cảnh giác: nền tảng sinh ra để gỡ nút thắt (mỗi domain tự làm rời rạc), nhưng nếu làm sai, chính platform team lại trở thành nút thắt mới — mọi domain phải chờ platform team làm hộ. Dấu hiệu và cách tránh:

Ba trụ tránh nút thắt: self-serve thật (không có bước tay bắt buộc trên đường mặc định), tài liệu tốt (golden path documented để domain tự đi), và không gác cổng thủ công (thay review người bằng policy-as-code chỗ nào an toàn). Một đội platform 3-4 người chỉ phục vụ được 20 domain nếu họ xây đường, không dắt tay từng người.

Phân tách trách nhiệm: platform team vs domain team

Ranh giới trách nhiệm phải rõ để không đùn đẩy:

Nguyên tắc: platform team sở hữu "cách làm" (paved road), domain team sở hữu "cái gì" (nội dung dữ liệu). Platform không chịu trách nhiệm về đúng-sai số liệu của domain; domain không chịu trách nhiệm vận hành Airflow. Đây là mô hình phân quyền của Data Mesh — Nền tảng tự phục vụ đưa xuống mức thực thi kỹ thuật.

Lộ trình xây nền tảng: bắt đầu nhỏ, chuẩn hoá dần

Cạm bẫy lớn nhất là big-bang platform: dành một năm xây "nền tảng hoàn hảo" trước khi ai dùng — thường xây sai vì chưa biết domain thực sự cần gì. Cách đúng là rút golden path từ thực tế:

1. Làm chung với domain tiên phong. Chọn một domain (ví dụ thẻ), cùng họ dựng một data product end-to-end. Chưa cần template, chỉ cần chạy được.
2. Trích xuất pattern lặp lại thành template. Những gì làm ở bước 1 (cấu trúc dbt, CI, cách mã hoá PII) đóng gói thành template và module IaC v1.
3. Domain thứ hai dùng lại template. Đo time-to-first-pipeline. Chỗ nào còn tay → tự động hoá tiếp.
4. Golden path hoá. Khi 2-3 domain dùng chung một cách, đó chính thức là paved road; viết tài liệu, làm CLI scaffolding.
5. Nới self-serve & policy. Chuyển các bước review tay sang policy-as-code; mở portal/PR provisioning; thêm ephemeral env.
6. Mở rộng năng lực theo nhu cầu. Thêm catalog, observability, FinOps khi số domain đủ lớn để đáng đầu tư.

Chuẩn hoá dần nghĩa là mỗi bước chuẩn hoá phải xuất phát từ pain thật của người dùng, không từ ý thích kiến trúc. Nền tảng tốt là nền tảng được rút ra từ việc làm thật, không áp từ trên xuống.

Use case thực tế

Bối cảnh. NCB có đội platform 4 người, phục vụ 6 domain (thẻ, tín dụng, huy động, rủi ro, kênh số, kế toán). Trước khi có nền tảng: mỗi data product mới tốn trung bình 3 tuần dựng khung (tự cấu hình warehouse, tự viết CI, tự lo mã hoá PII), và 2 vụ rò rỉ số thẻ ra schema dùng chung do domain quên mask.

Triển khai golden path (6 tháng).

• Cùng domain thẻ dựng data product card_txn_daily end-to-end, rồi trích template dbt + module Terraform + CI.
• Đóng gói macro mask_pii() vào khung dbt chung, bật mặc định cho cột số thẻ/CMND ở lớp marts.
• Viết CLI ncb-dp new scaffold repo đầy đủ; provisioning chuyển sang PR trên repo IaC, terraform apply tự động sau merge.
• Airflow chuyển sang cụm quản lý tập trung; domain chỉ push DAG.

Kết quả sau 6 tháng.

Điểm mấu chốt: platform team không lớn hơn, nhưng thoát vai "làm hộ" để làm "xây đường". Sự cố PII về 0 không nhờ nhắc nhở mà nhờ mask mặc định trong template — governance-by-default. Vận hành cụm dùng chung tham chiếu thêm Kubernetes 8 — Production ops cho phần hạ tầng chạy Airflow/engine.

Ghi nhớ

• Platform as a product: khách hàng là người dùng nội bộ (data engineer/analyst domain); đo bằng developer experience và time-to-first-pipeline, không đo bằng số server. Nền tảng phải dễ hơn tự làm.
• Năng lực self-service: compute, ingestion/EL, khung dbt chung, Airflow quản lý, CI/CD template, quality/observability, catalog, access — mỗi năng lực giấu độ phức tạp sau giao diện đơn giản.
• Golden path / paved road: template + scaffolding để domain tạo data product nhanh và tuân thủ sẵn; giảm quyết định lặp lại; làm đường tốt thành đường dễ nhất, không cấm đường khác.
• IaC (Terraform): chuẩn hoá tài nguyên bằng module; self-serve provisioning qua PR/portal, apply tự động; everything as code (audit/rollback được); môi trường ephemeral cho CI.
• Security & governance by default: mã hoá, quyền tối thiểu, mask PII, không lộ — nhúng sẵn trong golden path để domain khó làm sai hơn làm đúng.
• FinOps là thuộc tính của golden path: tag bắt buộc, quota, auto-suspend — dùng đường mặc định là đã tối ưu chi phí.
• Tránh nút thắt mới: self-serve thật (không bước tay bắt buộc), tài liệu tốt, không gác cổng thủ công (policy-as-code thay review người).
• Phân tách trách nhiệm: platform sở hữu "cách làm" (paved road), domain sở hữu "cái gì" (logic & chất lượng dữ liệu).
• Lộ trình: bắt đầu nhỏ với domain tiên phong, rút template từ thực tế, chuẩn hoá dần — tránh big-bang platform.