3 Lessons Learned From Implementing Chaos Engineering at Enterprise

CapitalOne · 2020 · 3. Quy mô lớn · Độ khó: Cơ bản — bài gốc

Bài quan điểm của một enterprise architect về resiliency, không kể một hệ cụ thể hay số liệu; mọi nhận định dưới đây là theo CapitalOne (tác giả).

Bối cảnh

Tác giả hỗ trợ nhiều delivery team đưa chaos engineering vào các hệ cloud native phân tán của CapitalOne. Theo tác giả, chỉ performance và stress test là kỹ thuật cũ, không đủ để lộ điểm yếu; chaos engineering là chuỗi thí nghiệm có kiểm soát phá trạng thái ổn định.

Mục tiêu không phải 100% tin cậy: đầu tư thời gian, công sức, công cụ cho chaos phải cân với SLO và độ quan trọng của hệ.
Phủ rộng các kiểu lỗi, dựa trên failure mode analysis: ngoài bốn nhóm công cụ hay nhắm (tài nguyên, mạng, dependency, ứng dụng/tiến trình) còn có:
- Môi trường: cạn IP, đường truy cập để xử lý sự cố, và automation tự chữa phải được kiểm xem thứ nó dựa vào có sẵn khi cần.
- Bảo mật: đổi chuỗi tin cậy của chứng chỉ có thể gây hậu quả bất ngờ.
- Con người: phụ thuộc vào kiến thức trong đầu chuyên gia thay vì tài liệu tự phục vụ làm tăng MTTR.
- Quy trình: quy trình khôi phục ít dùng phải được diễn tập định kỳ.
- Kiểm nhiều lỗi cùng lúc để thấy hiệu ứng dây chuyền; luôn có đường rollback cho chính thí nghiệm; bắt đầu nhỏ.
Observability là điều kiện tiên quyết: cần baseline trạng thái ổn định theo từng phiên bản ứng dụng, sau một khoảng ổn định không thay đổi; đầu ra của chaos là chỉnh lại monitor, log, trace, alert.

Theo tác giả, giả định về độ tin cậy của dependency (nội bộ và bên ngoài) thường không được kiểm; chaos biến giả định thành bằng chứng.

Danh sách lỗi cần thử không dừng ở máy và mạng: chứng chỉ, quy trình khôi phục, người trực cũng là điểm hỏng.
Không có baseline thì không đọc được kết quả thí nghiệm.