Chaos Engineering Cho Developer: Đừng Để Productionflix

Productionflix — Khi Ổn Định Chỉ Là May Mắn

Một service chạy ổn 6 tháng. Một node gặp network partition. Traffic route sai cụm replicas. Kết quả: downtime 40 phút, incident review dài 3 trang. Vấn đề không nằm ở hệ thống yếu. Vấn đề là chưa ai thử “đánh” hệ thống khi nó đang chạy.

Đó là lý do Chaos Engineering xuất hiện. Không phải để phá hoại. Để khám phá trước.

Chaos Engineering Là Gì?

Chủ động gây lỗi có kiểm soát trên môi trường chạy thật, quan sát cách hệ thống phản ứng, rồi sửa điểm yếu trước khi production gặp sự cố.

Ba yếu tố cốt lõi:

• Hypothesis: “Nếu service B mất kết nối 5 phút, service A vẫn trả lời được.”
• Experiment: Gây lỗi-network hay kill pod theo kịch bản đã định.
• Observation: Theo dõi latency, error rate, recovery time. Nếu hệ thống sai như giả thuyết → cần cải thiện.

Không phải “giết ngẫu nhiên pods rồi cầu nguyện.” Mọi bước đều có phạm vi, có rollback, có giám sát.

Tại Sao Developer Nên Quan Tâm?

1. CI/CD kiểm tra code đúng, nhưng chưa đủ cho infrastructure

Pipeline kiểm tra unit test, integration test. Nhưng không test “nếu DNS lag 2 giây thì service A xử lý thế nào?” Chaos Engineering lấp lỗ hổng đó.

2. Kubernetes càng scale, càng có nhiều điểm failure

Pod restart, node autoscale, network policy thay đổi. Mỗi layer là một khả năng fail. Experiment giúp xác định chính xác failure nào gây damage lớn nhất.

3. Incident response tốt hơn khi được luyện tập

Lần đầu kill pod trong staging có thể gây hoảng. Nhưng sau năm lần, runbook nào dùng, alert nào đáng tin sẽ rõ ràng hơn.

Bắt Đầu Đơn Giản Với Litmus

Litmus là công cụ Kubernetes-native mã nguồn mở, giúp định nghĩa và chạy experiment trực tiếp trên cluster.

Một experiment cơ bản có thể là kill pod ngẫu nhiên trong 30 giây rồi quan sát hành vi replicas. Nếu service vẫn trả lời đúng, hệ thống có resilience. Nếu không, đó là điểm cần sửa trước khi production gặp sự cố thật.

Quy Tắc An Toàn

• Bắt đầu từ staging: Môi trường staging nên tái tạo production ở mức 80-90%. Đủ để thấy vấn đề mà không gây damage thật.
• Blast radius nhỏ: Kill một pod trước khi kill cả namespace. Inject latency vào một service trước khi test cả cluster.
• Có stop condition: Nếu error rate vượt 10% → dừng ngay. Nếu service không recover trong 2 phút → abort.
• Ghi lại kết quả: Experiment không có log = bài tập vô nghĩa. Ghi lại giả thuyết, kết quả thực tế, action items.

Kết Luận

Chaos Engineering không phải “phá production.” Là “khám phá điểm yếu có kiểm soát.”

Productionflix thường kết thúc bằng postmortem dài. Chaos Engineering giúp viết kịch bản khác: khám phá sớm, sửa kịp, giảm bớt postmortem.

---

Bài viết nằm trong series DevOps Handbook — hướng dẫn thực tế cho developer muốn mở rộng kỹ năng. Bài trước: SRE Cho Developer.

Bài viết được hỗ trợ bởi AI (Amy 🌸). Nội dung đã được kiểm duyệt bởi tác giả.\