Chaos Testing a Distributed System with Jepsen

Appian · 2019 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Phần 2 của series; phần 1: Appian 2019. Phần 3 (lỗi tìm được) không tìm thấy.

Bối cảnh

Sau khi chọn Jepsen, việc khó là đưa nó vào hạ tầng thật: hệ cần test (SUT) phụ thuộc Kafka và Zookeeper, binary và thư viện nằm trong kho nội bộ có xác thực, và test phải chạy liên tục chứ không chỉ trên máy dev.

Dịch vụ đi kèm ngoài tầm Jepsen: Kafka và Zookeeper chạy HA ở production nhưng không phải đối tượng test, nên thêm vào docker-compose của Jepsen dưới dạng container một node mà nemesis không đụng tới.
Tải binary từ kho nội bộ: hàm install-archive của Jepsen không nhận credential; Appian sửa Jepsen (gửi PR lên upstream) để nhận username/password. Credential truyền vào container qua biến môi trường từ script khởi động, không commit vào repo; thư viện client lấy từ Artifactory qua cấu hình project.clj của Leiningen đọc biến môi trường.
Đưa vào Jenkins Pipeline: job nhận tham số phiên bản, thời lượng, số node (3 hoặc 5); chỉ chạy trên master (có cờ ép chạy nhánh khác); một script Python chờ mọi container healthy rồi mới chạy test; copy kết quả ra và lưu artifact.
Phân loại kết quả: :valid? false → UNSTABLE (test chạy hết và phát hiện vi phạm linearizability); nemesis crash, hết bộ nhớ hay không có file kết quả → FAILURE (kết quả không đáng tin, phải chạy lại). Lý do: nemesis chết giữa chừng thì test có thể "qua" chỉ vì hệ không bị gây lỗi.

Theo Appian, chạy Jepsen trên mỗi thay đổi vào master làm tăng độ tin cậy vào hệ; container hoá để local và CI giống nhau.

Một test chaos phải tự kiểm rằng chaos đã thật sự xảy ra; "xanh" khi tác nhân gây lỗi chết là dương tính giả.
Tách ba trạng thái kết quả (đúng, phát hiện lỗi, test hỏng) để người đọc CI biết phải sửa hệ hay sửa test.