Get in touch
or send us a question?
CONTACT

Chaos Engineering: Test Ứng Dụng Bằng Cách… Phá Nó 😈

Tester thường được dạy:

“Test để đảm bảo hệ thống chạy đúng.”

Chaos Engineering thì nói:

“Không. Hãy phá nó trước khi người dùng phá.”

Nghe có vẻ phản diện, nhưng chaos testing là một trong những cách kiểm thử thực tế nhất để biết hệ thống của bạn có thật sự bền hay chỉ đang… may mắn.


1. Chaos Engineering là gì? (Nói ngắn cho dễ hiểu)

Chaos Engineering là kỹ thuật:

  • Cố tình gây lỗi cho hệ thống

  • Trong môi trường có kiểm soát

  • Để quan sát xem:

    • Hệ thống phản ứng ra sao?

    • Có tự phục hồi không?

    • Người dùng có “toang” không?

📌 Mục tiêu không phải phá cho sập,
mà là học cách hệ thống thất bại.


2. Nguyên tắc cốt lõi: “Phá để biết bền”

Chaos Engineering dựa trên 3 câu hỏi rất “tester mindset”:

  1. Nếu một phần chết → hệ thống có sống không?

  2. Lỗi này có lan ra chỗ khác không?

  3. User có hiểu chuyện gì đang xảy ra không?

👉 Một hệ thống tốt không phải không lỗi,
mà là lỗi nhưng không sập dây chuyền.


3. Chaos Testing khác gì test thông thường?

Test thường Chaos Testing
Test case rõ ràng Tình huống bất ngờ
Expect kết quả đúng Quan sát hành vi
Focus happy path Focus failure path
“Nếu input A thì output B” “Nếu B chết thì A còn sống không?”

👉 Chaos testing không tìm bug nhỏ.
👉 Nó tìm lỗ hổng kiến trúc.


4. Dead-End Scenario là gì? Vì sao tester hay bỏ sót?

Dead-end scenario = tình huống mà:

  • Người dùng không đi tiếp được

  • Không có hướng dẫn

  • Không có rollback

  • Không có đường thoát

Ví dụ:

  • Thanh toán xong nhưng không hiện kết quả

  • API timeout → UI loading vô hạn

  • Upload fail → không retry, không message

  • Session hết hạn giữa chừng → user mất dữ liệu

💀 Không crash, nhưng user “chết lâm sàng”.


5. Chaos Testing trong thực tế (Ví dụ cụ thể)

🎯 Case: Ứng dụng e-commerce

Bạn chủ động tạo chaos:

  • Tắt service Payment trong 30 giây

  • Giả lập network chập chờn

  • Inject latency vào API Order

  • Kill random pod (Kubernetes)

Quan sát:

  • UI có thông báo rõ không?

  • Có retry không?

  • Có rollback đơn hàng không?

  • Dữ liệu có bị lệch không?

👉 Đây là thứ manual test thường không đụng tới
👉 Nhưng user ngoài đời thì… gặp suốt


6. Tester nên tham gia Chaos Engineering thế nào?

Tester không cần viết tool phá hệ thống.
Nhưng tester rất mạnh ở:

  • Phân tích rủi ro

  • Đặt câu hỏi “nếu… thì sao?”

  • Nhìn từ góc độ người dùng

Checklist tester trong chaos testing:

  • Nếu service A chết → user thấy gì?

  • Có message dễ hiểu không?

  • Có retry / fallback không?

  • Có log / alert cho team không?

  • Dữ liệu có nhất quán không?

📌 Tester là người hỏi đúng câu hỏi, không phải người bấm nút “phá”.


7. Chaos Testing có đáng làm không?

❌ Không cần cho app nhỏ, ít user
⚠️ Cần cân nhắc nếu hệ thống chưa ổn định
✅ Rất nên cho:

  • Microservices

  • Cloud / Kubernetes

  • High-traffic system

  • Payment, banking, booking, SaaS

👉 Không test chaos = hy vọng prod sẽ hiền.
Thường thì prod… không hiền.


8. Kết luận

Chaos Engineering dạy tester một bài học quan trọng:

Không phải hệ thống chạy được lúc bình thường là tốt,
mà là sống sót khi mọi thứ sai.

Tester giỏi không chỉ test:

  • Cái đúng
    mà còn test:

  • Cái sai một cách xấu nhất

😈 Phá có kiểm soát hôm nay, để tránh sập không kiểm soát ngày mai.