[DE Blog #19] Data Reliability Engineering: Thiết Lập SLA/SLO/SLI, Xử Lý Khủng Hoảng Sự Cố Pipeline & Văn Hóa Blameless Post-Mortem

1. Bối cảnh thực tế (Context & Problem Statement)

Trong kỹ nghệ phần mềm truyền thống (SRE - Site Reliability Engineering), khi một Web Service bị sập, người dùng sẽ nhận ngay mã lỗi HTTP 500 và đội ngũ On-call được cảnh báo tức thì.

Tuy nhiên, trong Data Engineering, sự cố thường diễn ra trong im lặng tuyệt đối (Silent Failures):

Pipeline vẫn báo trạng thái SUCCESS, nhưng do hệ thống thanh toán mới cập nhật đổi tên trường amount_cents thành amount_usd, số liệu doanh thu trong Data Warehouse bị chia nhỏ 100 lần suốt 10 ngày qua.
Khi CFO phát hiện số liệu báo cáo tài chính bị sai lệch nghiêm trọng, toàn bộ ban lãnh đạo mất niềm tin vào hệ thống dữ liệu.

Data Reliability Engineering (DRE) ra đời nhằm mang lại các tiêu chuẩn độ tin cậy nghiêm ngặt của SRE vào thế giới dữ liệu: Đo lường chất lượng bằng SLI/SLO, tự động cô lập dữ liệu lỗi, có quy trình khắc phục sự cố rõ ràng và xây dựng văn hóa Post-Mortem không đổ lỗi (Blameless).

2. Các Khái Niệm & Cơ Chế Cốt Lõi

2.1. Bộ Ba Chỉ Số Độ Tin Cậy Dữ Liệu: SLI vs. SLO vs. SLA

SLI (Service Level Indicator - Chỉ số thực tế): Đại lượng đo lường thực tế mức độ hoạt động của dữ liệu. $\text{SLI} = \frac{\text{Số lượng bản ghi hợp lệ / đúng giờ}}{\text{Tổng số bản ghi}} \times 100\%$
SLO (Service Level Objective - Mục tiêu nội bộ): Mức độ tin cậy mà đội ngũ Data tự cam kết đạt được (ví dụ: $99.5\%$ dữ liệu nạp đúng giờ trong 30 ngày qua).
SLA (Service Level Agreement - Cam kết pháp lý/nghiệp vụ): Thỏa thuận chính thức với các bên kinh doanh hoặc khách hàng ngoài, có kèm theo chế tài xử phạt nếu vi phạm (ví dụ: Nếu dữ liệu báo cáo trễ quá 08:00 sáng quá 3 lần/tháng, đội Data bị trừ KPI/thưởng).

2.2. Cơ Chế Cô Lập Dữ Liệu Lỗi: Quarantine Tables & Circuit Breakers

Khi dữ liệu từ hệ thống nguồn có vấn đề (Schema bị lệch, tỷ lệ Nulls tăng đột biến):

Không nên: Để pipeline tiếp tục chạy và ghi dữ liệu bẩn vào các bảng Gold/Analytics phục vụ kinh doanh.
Nên áp dụng Data Circuit Breaker (Cầu dao dữ liệu):
- Tự động ngắt luồng chuyển đổi nếu tỷ lệ lỗi vượt quá ngưỡng cho phép (ví dụ $> 5\%$ số dòng bị lỗi kiểu dữ liệu).
- Đưa các dòng dữ liệu lỗi vào một bảng cách ly (Quarantine Table / Dead Letter Table) để đội ngũ kỹ thuật điều tra, trong khi các dòng dữ liệu sạch vẫn được xử lý bình thường.

[Raw Data Stream] ---> [Data Quality Validation Gate]
                                |
             +------------------+------------------+
             | (PASS)                              | (FAIL / Corrupted)
             v                                     v
   [Silver / Gold Tables]                [Quarantine Table (DLQ)]
   (Phục vụ Dashboard BI)                (Bắn cảnh báo On-call để xử lý)

2.3. Kỹ Thuật Backfill An Toàn Ở Quy Mô Lớn (Safe Backfilling at Scale)

Khi cần tính toán lại dữ liệu của 6 tháng trước ( $50\text{ TB}$ ) để sửa lỗi:

Nguyên tắc "Tách biệt tài nguyên" (Resource Isolation): Chạy job Backfill trên một cụm Virtual Warehouse / Spark Cluster độc lập để không chiếm dụng CPU/RAM của các pipeline Production đang chạy hàng ngày.
Nguyên tắc "Atomic Partition Swap":
1. Ghi kết quả tính toán lại vào một bảng tạm trung gian: fct_orders_backfill_temp.
2. Chạy bộ kiểm tra chất lượng dữ liệu (Data Quality Tests) trên bảng tạm.
3. Nếu tất cả đều PASS, thực hiện lệnh tráo đổi phân vùng nguyên tử (Atomic Swap / Replace Partition):
```
-- Trên Snowflake / BigQuery / Delta Lake:
ALTER TABLE fct_orders REPLACE PARTITION (date = '2026-08-01') 
USING TABLE fct_orders_backfill_temp;
```
4. Người dùng đang xem Dashboard sẽ không bao giờ nhìn thấy trạng thái bảng bị rỗng (Empty Table) hoặc dữ liệu bị thiếu trong quá trình nạp lại.

3. Các Bảng Markdown So Sánh Chi Tiết

📊 Bảng 1: Ma Trận Thiết Lập SLI / SLO / SLA Cho Data Platforms

Khía cạnh chất lượng	Service Level Indicator (SLI)	Service Level Objective (SLO)	Service Level Agreement (SLA)
Freshness (Độ tươi mới)	Thời gian từ lúc sự kiện xảy ra đến khi xuất hiện trên Gold Table	$99\%$ các ngày dữ liệu sẵn sàng trước 07:00 AM	Dữ liệu sẵn sàng trước 08:30 AM (Trễ quá 3 lần/tháng phạt KPI)
Completeness (Độ đầy đủ)	Tỷ lệ số dòng nạp thành công so với hệ thống nguồn	$\ge 99.9\%$ số lượng giao dịch được nạp trong ngày	Không thất thoát quá $0.01\%$ số lượng giao dịch
Validity (Tính hợp lệ)	Tỷ lệ bản ghi vượt qua các bài kiểm tra schema/rules	$\ge 99.99\%$ các trường bắt buộc không bị `NULL`	$100\%$ các cột khóa chính (`Primary Key`) không trùng lặp
Query Latency (Độ trễ BI)	Thời gian phản hồi truy vấn P95 trên Dashboard	$95\%$ các câu truy vấn hoàn thành trong $< 3\text{ giây}$	$99\%$ các câu truy vấn hoàn thành trong $< 10\text{ giây}$

📊 Bảng 2: So Sánh 3 Chiến Lược Phản Ứng Khi Gặp Dữ Liệu Bất Thường

Chiến lược	Cơ chế xử lý	Rủi ro phát sinh	Khi nào nên áp dụng?
Fail-Stop (Dừng toàn bộ)	Ngắt pipeline ngay lập tức, không nạp bất kỳ dữ liệu nào	Báo cáo bị trễ giờ (Miss SLA Freshness)	Báo cáo Tài chính, Quyết toán doanh thu, Thanh toán (Sai 1 ly đi 1 dặm)
Quarantine & Continue	Cách ly dòng lỗi vào DLQ, tiếp tục xử lý các dòng sạch	Số liệu có thể bị thiếu một phần nhỏ	Clickstream Logs, IoT Metrics, User Behavior Tracking
Auto-Impute / Default	Tự động gán giá trị mặc định cho trường lỗi (e.g. `category='Unknown'`)	Làm méo mó phân phối dữ liệu nếu lỗi kéo dài	Dữ liệu làm đầu vào cho mô hình gợi ý (ML Inference)

📊 Bảng 3: Cấu Trúc Mẫu Báo Cáo Sự Cố (Blameless Post-Mortem Template)

Mục nội dung	Yêu cầu thông tin chi tiết
1. Tóm tắt sự cố (Executive Summary)	Mô tả ngắn gọn: Chuyện gì xảy ra, thời gian kéo dài bao lâu, mức độ ảnh hưởng kinh doanh (Impact).
2. Dòng thời gian (Timeline)	Liệt kê chi tiết từng mốc giờ: Thời điểm lỗi bắt đầu phát sinh $\rightarrow$ Thời điểm phát hiện $\rightarrow$ Các bước xử lý $\rightarrow$ Khắc phục hoàn toàn.
3. Phân tích nguyên nhân gốc (5 Whys)	Hỏi "Tại sao" 5 lần liên tiếp để tìm ra lỗ hổng quy trình/hệ thống thay vì quy kết lỗi cá nhân.
4. Các điểm làm tốt & Cần cải thiện	Đội ngũ đã phản ứng nhanh ở khâu nào? Khâu nào bị chậm trễ do thiếu tài liệu/công cụ?
5. Kế hoạch hành động phòng ngừa (Action Items)	Danh sách công việc cụ thể có người chịu trách nhiệm (Owner) và thời hạn hoàn thành (Deadline).

4. Best Practices & Kỹ Thuật Vận Hành Thực Chiến (Pro-Tips)

💡 Quy trình phản ứng sự cố lúc nửa đêm (Data Incident Playbook)

Khi nhận cảnh báo khẩn cấp từ PagerDuty/Opsgenie:

Bước 1 - Xác nhận & Đánh giá mức độ (Triage): Xác định sự cố thuộc Severity 1 (Hỏng báo cáo tài chính/CEO) hay Severity 3 (Bảng log nội bộ ít dùng).
Bước 2 - Thông báo chủ động (Communicate Early): Đăng thông báo lên kênh Slack chung: "Đội Data đang điều tra sự cố trễ dữ liệu bảng X, dự kiến cập nhật tiếp theo lúc 08:00 AM". Tránh để người dùng tự phát hiện ra lỗi trước!
Bước 3 - Cầm máu (Containment): Tạm dừng pipeline hoặc chuyển hướng sang sử dụng bảng dữ liệu Snapshot ngày hôm trước (Fallback to previous partition).
Bước 4 - Khắc phục & Sửa lỗi (Fix & Backfill): Sửa code logic trên nhánh hotfix, chạy test trên Staging và tiến hành backfill an toàn.
Bước 5 - Viết Blameless Post-Mortem trong vòng 48 giờ.

5. Góc Ôn Luyện Phỏng Vấn (Interview Corner)

❓ Câu hỏi 1: Sự khác biệt giữa SLI, SLO và SLA trong Data Engineering là gì? Hãy cho ví dụ cụ thể về việc thiết lập các chỉ số này cho một Data Pipeline phục vụ báo cáo tài chính hàng ngày.

Gợi ý trả lời:
- Định nghĩa ngắn gọn:
  - SLI là thước đo thực tế (Chúng ta đang đạt được bao nhiêu?).
  - SLO là mục tiêu nội bộ (Chúng ta muốn đạt được bao nhiêu để hệ thống khỏe mạnh?).
  - SLA là cam kết với khách hàng/nghiệp vụ (Nếu không đạt mức này, chúng ta sẽ phải đền bù thiệt hại).
- Ví dụ thực tế cho Financial Data Pipeline:
  - SLI: Thời gian hoàn thành nạp bảng fct_financial_ledger mỗi sáng (đo bằng timestamp thực tế).
  - SLO: $99.5\%$ các ngày trong năm, bảng phải sẵn sàng và vượt qua 100% bài kiểm tra Data Quality trước 06:30 AM.
  - SLA: Bảng phải sẵn sàng chậm nhất là 08:00 AM. Nếu trễ sau 08:00 AM quá 2 lần trong 1 quý, đội Data phải giải trình trước ban kiểm toán và chịu chế tài trừ điểm đánh giá hiệu suất.
  - Khoảng đệm (Buffer) giữa 06:30 AM và 08:00 AM chính là Error Budget giúp đội Data có 1.5 giờ để sửa chữa nếu có lỗi xảy ra mà vẫn không vi phạm SLA!

❓ Câu hỏi 2: Hãy kể về một sự cố dữ liệu nghiêm trọng (Data Incident) mà bạn từng xử lý. Bạn đã điều tra, khắc phục và ngăn ngừa sự cố đó tái diễn như thế nào? (Kỹ thuật trả lời theo khung STAR)

Gợi ý khung trả lời mẫu (STAR Method):
- Situation (Tình huống): Trong một đợt Black Friday, bảng doanh thu bán hàng fct_sales trên Snowflake bị tính thiếu $25\%$ doanh thu do một payment gateway mới được thêm vào ứng dụng nhưng gửi mã tiền tệ ở dạng viết thường (usd thay vì USD), khiến câu lệnh CASE WHEN currency = 'USD' bị bỏ qua.
- Task (Nhiệm vụ): Tôi là người trực chính (On-call Lead), chịu trách nhiệm cô lập sự cố, sửa chữa dữ liệu cho 3 ngày cao điểm và ngăn chặn việc tái diễn.
- Action (Hành động đã thực hiện):
  1. Thông báo: Ngay lập tức gửi cảnh báo cho đội Finance về việc số liệu đang bị tạm dừng cập nhật.
  2. Hotfix: Sửa câu lệnh chuẩn hóa UPPER(TRIM(currency)) và bổ sung bài test accepted_values trong dbt.
  3. Safe Backfill: Chạy job backfill trên một compute warehouse riêng biệt và thực hiện Atomic Partition Replace cho 3 ngày bị ảnh hưởng.
  4. Phòng ngừa: Thêm bài kiểm tra tự động cảnh báo nếu xuất hiện giá trị currency mới chưa từng thấy trong hệ thống nguồn.
- Result (Kết quả): Khôi phục dữ liệu chính xác 100% trước giờ làm việc của ban giám đốc, toàn bộ quy trình được tổng hợp lại thành một bản Blameless Post-Mortem giúp đội ngũ thống nhất chuẩn định dạng với đội Backend.

❓ Câu hỏi 3: Khi cần Backfill lại dữ liệu của 6 tháng trước (khoảng 50TB) trên bảng Fact đang phục vụ cho Dashboard Production 24/7, bạn sẽ lập kế hoạch như thế nào để không làm gián đoạn người dùng và không làm sập cluster?

Gợi ý trả lời theo 4 bước:
1. Tách biệt tài nguyên tính toán (Compute Isolation): Khởi tạo một Virtual Warehouse / cụm Spark riêng dành riêng cho Backfill để không tranh chấp CPU/RAM với các truy vấn của Dashboard người dùng.
2. Chia nhỏ phạm vi xử lý (Chunking / Batching): Không chạy một lệnh duy nhất cho cả 6 tháng. Chia thành từng chu kỳ nhỏ (ví dụ chạy từng tuần một hoặc từng ngày một) và điều phối qua Airflow DAG có giới hạn số lượng task song song (max_active_runs = 3).
3. Ghi ra vùng đệm tạm thời (Shadow Staging Tables): Nạp kết quả tính toán vào bảng fct_orders_temp và chạy bộ test so sánh checksum/tổng doanh thu đối chiếu.
4. Áp dụng Atomic Partition Overwrite: Sử dụng câu lệnh ghi đè theo từng phân vùng (INSERT OVERWRITE partition(date = '...') trên Iceberg/Delta Lake) để cập nhật dữ liệu một cách nguyên tử trong 1 mili-giây mà không làm đứt quãng trải nghiệm của người dùng đang xem báo cáo.

6. Tóm Tắt Ghi Nhớ Nhanh (Key Takeaways)

DRE (Data Reliability Engineering) tập trung vào việc biến chất lượng dữ liệu thành các chỉ số định lượng có thể đo lường được (SLI/SLO/SLA).
Thiết lập Error Budget giữa SLO nội bộ và SLA kinh doanh để có thời gian phản ứng trước khi vi phạm cam kết.
Áp dụng Data Circuit Breakers & Quarantine Tables để ngăn chặn dữ liệu bẩn lây lan vào các bảng báo cáo chính thức.
Luôn tuân thủ nguyên tắc Compute Isolation và Atomic Partition Swap khi thực hiện Backfill dữ liệu lịch sử quy mô lớn.
Xây dựng văn hóa Blameless Post-Mortem để biến sự cố thành cơ hội nâng cấp sự vững chắc của toàn bộ hệ thống.