Kỹ nghệ Phần mềm Thực tế: Từ CI/CD Không Downtime đến Di trú Hệ thống Legacy

Trở thành một kỹ sư phần mềm chuyên nghiệp không chỉ dừng lại ở việc học cú pháp của một ngôn ngữ lập trình hay biết cách giải quyết các bài toán thuật toán cô lập. Trên môi trường production thực tế của doanh nghiệp, chúng ta phải đối mặt với các vấn đề lớn hơn nhiều: làm sao để triển khai code an toàn không gián đoạn dịch vụ, xử lý dữ liệu lớn như thế nào và làm thế nào để di trú các hệ thống cũ (legacy systems) mà không gây lỗi.

1. Thiết kế Pipeline CI/CD an toàn và Zero-Downtime

Một quy trình CI/CD chuyên nghiệp là xương sống của phát triển phần mềm hiện đại, đảm bảo mọi thay đổi code đều được kiểm thử tự động trước khi tới tay người dùng. Một pipeline chuẩn bao gồm các chặng: Code Push -> Linter & Formatting -> Unit/Integration Tests -> Docker Build -> Security Scanning -> Artifact Push -> Deploy.

Để triển khai code mới mà không làm gián đoạn dịch vụ của khách hàng (Zero-Downtime Deployment), các kỹ sư thường áp dụng ba chiến lược sau:

Rolling Update: Thay thế dần dần các container cũ bằng container mới theo từng cụm nhỏ. Thích hợp cho các hệ thống có tài nguyên máy chủ hạn chế.
Blue-Green Deployment: Duy trì hai môi trường giống hệt nhau (Blue - Môi trường chạy chính thức, Green - Môi trường chạy code mới). Khi Green test ổn định, Load Balancer chỉ việc trỏ router chuyển hướng toàn bộ traffic sang Green. Nếu có lỗi, rollback lập tức bằng cách trỏ lại về Blue.
Canary Deployment: Triển khai code mới cho một nhóm nhỏ người dùng trước (ví dụ 5% traffic). Nếu không phát hiện lỗi gì bất thường qua hệ thống giám sát (monitoring), ta mới dần dần tăng tỷ lệ lên 100%.

2. Nghệ thuật di trú dữ liệu và cải tạo hệ thống Legacy

Một trong những task thử thách nhất khi vào dự án thực tế là nhận ticket di trú hệ thống (Migration). Quy trình xử lý cần tuân thủ nghiêm ngặt các bước:

Vẽ bản đồ phụ thuộc (Dependency Mapping): Đọc hiểu mã nguồn cũ, xác định rõ dữ liệu đi từ đâu đến đâu để tránh ngắt kết nối giữa các module.
Bẫy Múi Giờ (Timezone Trap): Lỗi di trú phổ biến nhất là lệch giờ ghi nhận giao dịch.
Nguyên tắc cốt lõi: Luôn lưu trữ thời gian dưới dạng múi giờ chuẩn quốc tế UTC ở tầng Database. Chỉ thực hiện chuyển đổi sang múi giờ địa phương (local timezone) tại tầng hiển thị ở Client (Frontend).
Áp dụng Strangler Fig Pattern: Thay vì đập đi xây lại toàn bộ (Big Bang migration - rất rủi ro), hãy bẻ nhỏ và thay thế từng dịch vụ một, để hệ thống cũ và mới chạy song hành cho đến khi hệ thống mới hoàn toàn thay thế hệ thống cũ.

3. Kiến trúc dữ liệu hiện đại với Databricks & Lakehouse

Khi lượng dữ liệu doanh nghiệp bùng nổ lên mức Terabytes/Petabytes, các mô hình lưu trữ cũ sẽ bị quá tải. Kiến trúc Data Lakehouse (được dẫn dắt bởi Databricks) ra đời để kết hợp ưu điểm của:

Data Lake: Lưu trữ dữ liệu thô dạng file phẳng giá rẻ (S3, GCS).
Data Warehouse: Hỗ trợ giao dịch ACID, schema chặt chẽ và truy vấn nhanh.

Với sự bổ trợ của Delta Lake và công cụ xử lý phân tán Apache Spark, kỹ sư dữ liệu có thể dễ dàng thiết kế các đường ống ETL (Extract - Transform - Load) chuẩn chỉnh đi từ: Raw Data (Bronze) -> Cleaned Data (Silver) -> Business Insights (Gold) phục vụ cho cả phân tích thống kê truyền thống lẫn AI/Machine Learning.

4. Harness Engineering: Giới hạn tầm ảnh hưởng của lỗi

Trong kỹ nghệ phần mềm, ta luôn phải ghi nhớ triết lý: "Mọi thứ rồi sẽ hỏng vào một thời điểm nào đó" (Everything fails all the time). Kỹ thuật Harness Engineering là việc thiết kế hệ thống sao cho khi một module bị lỗi, hậu quả của nó (blast radius) phải được khoanh vùng nhỏ nhất có thể, tránh kéo sập toàn bộ hệ thống.

Các công cụ đắc lực bao gồm: Circuit Breaker (ngắt kết nối tới service đang quá tải), Rate Limiter (ngăn chặn spam request), và Feature Flags (bật/tắt nhanh các tính năng lỗi mà không cần redeploy code).

5. Kỹ thuật cào dữ liệu và đối phó với API Limits

Khi viết script crawl dữ liệu quy mô lớn, ta thường xuyên đối mặt với các lỗi Timeout hoặc bị chặn IP từ phía máy chủ mục tiêu. Để viết một script crawl chuyên nghiệp, hãy áp dụng:

Exponential Backoff: Khi bị lỗi hoặc dính Rate Limit (HTTP 429), script sẽ tự động chờ tăng dần theo cấp số nhân (ví dụ: chờ 1s, rồi 2s, 4s, 8s...) trước khi thử lại thay vì spam liên tục làm sập server hoặc bị block vĩnh viễn.
Request Chunking & Concurrency Control: Chia nhỏ khoảng dữ liệu cần crawl và giới hạn số lượng request song song đồng thời (concurrency limit) để giữ cho script hoạt động ổn định và bền bỉ.