Platform Engineering 8 — Nền tảng dữ liệu ngân hàng end-to-end

Bảy bài trước của series đã dựng từng mảnh riêng lẻ. Bài kết này ghép chúng lại thành một nền tảng dữ liệu (data platform) end-to-end cho một team dữ liệu ngân hàng như NCB — nơi mà "tự phục vụ" (self-service) và "tuân thủ" (compliance) không đối chọi nhau mà được cài đặt cùng một chỗ. Điểm mấu chốt xuyên suốt Platform Engineering — Tổng quan vẫn giữ nguyên: platform tồn tại để giảm gánh nặng nhận thức (cognitive load) cho data engineer, để họ giao pipeline nhanh mà vẫn an toàn theo mặc định, chứ không phải để thêm một lớp quan liêu nữa.

Từ code đến production: các mảnh ghép lại

Hãy nhìn vòng đời một thay đổi dữ liệu đi qua đủ các trạm đã học:

• Hạ tầng dưới dạng code (IaC): mọi tài nguyên — bucket lưu trữ, cluster xử lý, database, IAM role — được khai báo bằng Terraform như trong IaC với Terraform. Không ai bấm tay trên console. Trạng thái hạ tầng là code, review được, rollback được.
• Triển khai bằng GitOps: Git là nguồn sự thật duy nhất. Argo CD đồng bộ trạng thái mong muốn trong Git về cluster như ở GitOps & Argo CD. Mọi thay đổi production đều là một commit/PR có người duyệt — đây chính là nền của audit trail.
• CI/CD an toàn: pipeline trong CI/CD Pipelines build, test, quét bảo mật, ký artifact và tạo SBOM trước khi bất cứ thứ gì chạm production.
• Quan sát (observability): metrics, logs, traces chuẩn hóa qua OpenTelemetry như Observability với OTel, để biết pipeline có chạy đúng SLA hay không.
• Bí mật & policy: Vault/External Secrets và policy-as-code (OPA/Kyverno) từ Secrets & Policy đảm bảo không có secret trong Git và không manifest nào vi phạm luật lọt qua.
• Cổng tự phục vụ: portal Backstage trong IDP với Backstage là mặt tiền — nơi data engineer bấm nút "tạo pipeline mới" thay vì đọc bảy tài liệu và mở năm ticket.

Mỗi mảnh có giá trị riêng, nhưng giá trị cấp số nhân đến khi chúng được xâu thành một golden path — con đường được lát sẵn mà đi theo là đúng và an toàn.

Kiến trúc nền tảng dữ liệu ngân hàng

Đọc sơ đồ từ trên xuống: data engineer chỉ tương tác với lớp tự phục vụ. Bên dưới, năng lực platform làm việc nặng và đóng vai lan can (guardrail) — policy-as-code gắn vào cả CI lẫn GitOps để chặn vi phạm; secrets bơm lúc runtime chứ không nằm trong Git; observability tự thu tín hiệu. Dưới cùng là hạ tầng do IaC dựng, với IAM và mạng tách môi trường. Lan can nằm ở giữa nghĩa là engineer không thể "quên" tuân thủ, vì con đường mặc định đã tuân thủ sẵn.

Golden path "tạo pipeline dữ liệu mới"

Golden path là một Software Template trong portal đóng gói toàn bộ quyết định đúng. Khi engineer điền form (tên pipeline, nguồn dữ liệu, mức phân loại dữ liệu, chủ sở hữu), template tự động sinh ra:

1. Repo Git theo cấu trúc chuẩn: code pipeline (ví dụ dbt/Spark job), catalog-info.yaml để đăng ký service vào catalog, sẵn cấu hình linting và test.
2. Pipeline CI đã cắm sẵn: unit test, kiểm thử chất lượng dữ liệu (data quality test), quét lỗ hổng, ký artifact và sinh SBOM.
3. Manifest GitOps cho từng môi trường (dev/staging/prod) trong repo cấu hình, để Argo CD đồng bộ — mặc định deploy vào dev, còn prod cần duyệt.
4. Quyền truy cập (RBAC) cấp theo nhóm và theo mức phân loại dữ liệu, không cấp thủ công từng người.
5. Observability gắn sẵn: dashboard, alert rule và định nghĩa SLO (ví dụ "độ trễ dữ liệu < 30 phút", "tỉ lệ record lỗi < 0,1%") được tạo cùng service.
6. Policy & nhãn: service bắt buộc mang nhãn phân loại dữ liệu; policy-as-code từ chối triển khai nếu thiếu nhãn hoặc nhãn không hợp lệ.

Kết quả: từ ý tưởng đến một pipeline chạy ở dev, có CI, có quan sát, có tuân thủ — chỉ trong vài phút thay vì vài tuần. Tự phục vụ, nhưng luôn nằm trong lan can.

Yêu cầu đặc thù ngân hàng

Một data platform ngân hàng khác một platform SaaS thông thường ở chỗ mặc định phải chứng minh được sự tuân thủ. Các yêu cầu dưới đây định hình cách thiết kế, và nhiều thứ đã được đề cập trong Governance — Tổng quan.

SoD (Separation of Duties — phân tách nhiệm vụ) là điểm mà GitOps tỏa sáng: quy trình "code → PR → review → merge → sync" tự nhiên tách người tạo thay đổi khỏi người phê duyệt và khỏi hệ thống thực thi (Argo CD). Không ai một mình đẩy được thay đổi lên prod. Đồng thời, vì Git là bất biến, mọi thay đổi đều để lại dấu vết không xóa được — đây chính là audit trail mà kiểm toán viên NHNN cần: không phải một file log ai đó có thể chỉnh, mà là lịch sử ký được của cả tổ chức.

Về dữ liệu nhạy cảm, platform không chỉ trông cậy con người nhớ gắn nhãn. Nhãn phân loại (ví dụ public/internal/confidential/restricted) là trường bắt buộc trong template; policy-as-code từ chối triển khai service thiếu nhãn; và các quy tắc bảo vệ (che dữ liệu, tokenize, giới hạn truy cập) được gắn theo nhãn. Chi tiết về quyền riêng tư và tuân thủ nằm ở Privacy & Compliance.

Đo lường: platform có thực sự tốt không?

Platform là sản phẩm, nên phải đo bằng dữ liệu chứ không bằng cảm tính. Bốn nhóm chỉ số bổ sung cho nhau:

• DORA metrics — sức khỏe giao hàng: deployment frequency (tần suất triển khai), lead time for changes (thời gian từ commit đến prod), change failure rate (tỉ lệ thay đổi gây lỗi), time to restore (thời gian khôi phục). Golden path tốt kéo lead time và change failure rate xuống rõ rệt.
• DX (Developer Experience) — trải nghiệm người dùng platform: đo bằng khảo sát định kỳ và tín hiệu định lượng (thời gian onboard một pipeline mới, số ticket thủ công phải mở). Nếu engineer né golden path, con số này sẽ nói.
• SLO — chất lượng vận hành: platform tự có SLO (ví dụ độ sẵn sàng của portal, độ trễ pipeline CI), và mỗi data pipeline cũng có SLO riêng về độ tươi và độ chính xác dữ liệu.
• FinOps — chi phí: gắn nhãn chi phí theo team/pipeline để quy trách nhiệm, phát hiện tài nguyên bỏ quên, tối ưu cluster xử lý. Không cần cầu kỳ ngay từ đầu, nhưng cần nhìn thấy chi phí ai đang tạo ra.

Một chỉ số riêng của platform-as-product cần theo dõi là mức độ áp dụng golden path (adoption): bao nhiêu phần trăm pipeline mới đi qua template chuẩn thay vì tự dựng. Adoption thấp là tín hiệu sớm cho thấy golden path chưa đủ tốt, chứ không phải engineer "bướng".

Lộ trình xây platform theo giai đoạn

Sai lầm kinh điển là xây "platform hoàn hảo" trong hai năm rồi mới cho ai dùng. Cách đúng là tăng dần, mỗi giai đoạn giải một nỗi đau thật.

• Giai đoạn 1 — chuẩn hóa nền: thống nhất CI/CD và module IaC dùng chung. Mục tiêu: mọi team build/test/deploy theo cùng một khuôn, hết cảnh "mỗi repo một kiểu".
• Giai đoạn 2 — GitOps + policy: đưa triển khai về Git là nguồn sự thật, thêm vài policy quan trọng nhất (bắt buộc nhãn, cấm image chưa quét). Đây là lúc SoD và audit trail thành sự thật.
• Giai đoạn 3 — quan sát + bí mật: chuẩn hóa OTel và tập trung secrets. Giờ mới có đủ tín hiệu để nói pipeline khỏe hay yếu.
• Giai đoạn 4 — portal + golden path: khi các năng lực đã ổn định, mới gói chúng vào một Software Template để tự phục vụ. Portal đến sau năng lực, không phải trước.
• Giai đoạn 5 — mở rộng: thêm FinOps, đóng vòng phản hồi DX, tăng số golden path theo nhu cầu thật.

Nguyên tắc xuyên suốt: team platform là một product team, không phải trung tâm dịch vụ nhận ticket. Họ có backlog, có người dùng nội bộ (data engineer), có chỉ số adoption. Và họ phải chống cám dỗ over-engineering — chỉ trừu tượng hóa thứ đã lặp lại đủ nhiều, chỉ tự động hóa thứ đủ đau. Một golden path dùng được hôm nay hơn mười golden path hoàn hảo năm sau.

Rủi ro và cách giảm

Rủi ro lớn nhất về mặt tổ chức là platform chặn thay vì bôi trơn. Lan can tuân thủ phải được thiết kế để đường đúng là đường dễ nhất — nếu tuân thủ khiến mọi việc chậm hơn, engineer sẽ tìm cách lách, và khi đó platform vừa mất adoption vừa mất tuân thủ.

Minh họa: golden path cho "new data service"

Đoạn dưới chỉ mang tính minh họa cấu trúc catalog-info.yaml mà template sinh ra để đăng ký một data pipeline mới vào catalog, với nhãn phân loại và chủ sở hữu — không phải cấu hình chạy thật:

# Minh họa — không phải config chạy thật
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: cust-txn-daily
  tags: [dbt, pipeline]
  annotations:
    data.ncb/classification: confidential   # nhãn phân loại bắt buộc
spec:
  type: data-pipeline
  owner: team-data-risk
  lifecycle: production
  system: customer-360

Và một truy vấn quan sát chất lượng dữ liệu mà pipeline có thể chạy để tự kiểm — đếm số giao dịch bất thường theo loại tiền tệ, phục vụ SLO "tỉ lệ record lỗi thấp":

-- ▶ Chạy được
SELECT a.currency,
       COUNT(*) AS so_giao_dich,
       ROUND(AVG(t.amount)::numeric, 2) AS trung_binh
FROM transactions t
JOIN accounts a ON a.id = t.account_id
GROUP BY a.currency
ORDER BY so_giao_dich DESC;

Cùng một service, qua một template, đã kéo theo repo chuẩn, CI có kiểm thử chất lượng, manifest GitOps, RBAC theo nhãn, SLO và alert — tất cả những mảnh của bảy bài trước xâu lại thành một trải nghiệm liền mạch.

Use case thực tế

Bối cảnh NCB. Trước khi có platform, mỗi lần team Data Risk cần một pipeline mới (ví dụ tổng hợp giao dịch khách hàng theo ngày phục vụ mô hình rủi ro), quy trình là: mở ticket xin repo, ticket xin quyền dữ liệu, ticket xin tài nguyên hạ tầng, tự viết pipeline CI, tự cấu hình dashboard, rồi chờ team bảo mật review thủ công về nhãn dữ liệu. Lead time điển hình khoảng 3–4 tuần, với ước lượng hơn 10 bước thủ công rải qua 3–4 đội, và nhãn phân loại dữ liệu thường bị quên, phải sửa sau khi kiểm toán nội bộ nhắc.

Sau khi có golden path. Data engineer vào portal, chọn template "New Data Pipeline", điền tên, nguồn, mức phân loại confidential và chủ sở hữu team-data-risk. Trong vài phút, hệ thống sinh repo chuẩn, cắm CI (test + data quality + quét + ký), tạo manifest GitOps deploy vào dev, cấp RBAC theo nhóm, dựng dashboard + SLO, và gắn nhãn phân loại. Policy-as-code từ chối merge nếu thiếu nhãn, nên nhãn không thể bị quên. Lên prod cần một PR có reviewer khác duyệt — SoD được đảm bảo tự động, và mỗi thay đổi để lại audit trail ký được trong Git.

Kết quả ước lượng (minh họa nội bộ): lead time cho một pipeline mới từ ~3–4 tuần xuống còn 1–2 ngày; số bước thủ công từ hơn 10 xuống còn 2–3 (điền form + duyệt PR prod + xác nhận SLO); tỉ lệ pipeline thiếu nhãn phân loại khi kiểm toán giảm về gần 0 vì policy chặn từ đầu; và khi thanh tra hỏi "ai đổi pipeline này, ai duyệt", câu trả lời là một link commit thay vì một cuộc truy tìm email. Adoption golden path đạt mức cao vì đường đúng cũng là đường nhanh nhất.

Ghi nhớ

• Nền tảng dữ liệu ngân hàng là sự ghép mảnh: IaC → GitOps → CI/CD → observability → secrets/policy → portal, xâu thành một golden path chứ không phải bảy công cụ rời.
• Golden path "tạo pipeline mới" cài sẵn tuân thủ và quan sát: tự phục vụ nhưng luôn trong lan can — engineer không thể quên tuân thủ vì con đường mặc định đã tuân thủ.
• Yêu cầu ngân hàng đặc thù: SoD, audit mọi thay đổi (GitOps giúp), phân loại dữ liệu nhạy cảm, tách môi trường, DR/BCP, chủ quyền dữ liệu, quản lý bí mật, chuẩn NHNN.
• Đo bằng DORA + DX + SLO + FinOps + adoption golden path; platform là product, phải đo chứ không đoán.
• Lộ trình theo giai đoạn: CI/CD + IaC chuẩn trước, GitOps, rồi mới portal — tránh over-engineering, portal đến sau năng lực.
• Rủi ro lớn nhất là platform thành nút cổ chai hoặc adoption thấp; giảm bằng tự phục vụ thật, lan can bắt đầu ở chế độ cảnh báo, và đối xử với platform như sản phẩm có người dùng.

Nguồn tham khảo

• CNCF Platforms White Paper — "Platforms for Cloud Native Computing" (Cloud Native Computing Foundation, TAG App Delivery)
• Matthew Skelton & Manuel Pais, Team Topologies: Organizing Business and Technology Teams for Fast Flow (IT Revolution, 2019) — platform-as-a-product, giảm cognitive load
• Nicole Forsgren, Jez Humble & Gene Kim, Accelerate: The Science of Lean Software and DevOps (IT Revolution, 2018) — nền tảng lý thuyết của DORA metrics
• Kubernetes Documentation (The Kubernetes Authors, CNCF)
• Argo CD Documentation (Argo Project, CNCF)
• HashiCorp Vault Documentation (HashiCorp)
• Backstage Documentation — Software Templates (Backstage, CNCF)
• Open Policy Agent (OPA) Documentation (OPA project, CNCF)