Chaos drills, SLO, backup/restore
Chứng minh hệ thống phục hồi từ lỗi có kiểm soát.
Nắm bản chất
Một chaos drill có mục tiêu rõ: dừng Redis, Worker hoặc PostgreSQL, quan sát ảnh hưởng rồi khôi phục. Redis down nhưng Postgres còn sống: API có thể nhận job vào outbox; Postgres down: readiness 503 và API không nên trả 202 giả. Dừng Worker: Redis pending/backlog tăng.
Backup PostgreSQL bằng pg_dump -Fc, restore vào database kiểm thử
riêng và kiểm tra dữ liệu. Bảo vệ offsite backups và có RPO/RTO thực tế. Nếu
Redis mất stream entries đã đánh dấu published, lab chưa tự khôi phục mọi jobs;
cần viết runbook về gap đó.
Luồng hoạt động
Hãy tự giải thích mỗi mũi tên: dữ liệu, quyền hoặc tín hiệu nào được truyền qua bước này?
Lệnh & cấu hình mẫu
bash scripts/chaos-compose.sh redis-stop
curl -s http://127.0.0.1:8088/api/stats
bash scripts/chaos-compose.sh recover
bash scripts/backup.sh
bash scripts/restore_verify.sh backups/REAL_DUMP.dump
Lệnh có placeholder hoặc phụ thuộc môi trường thì cần thay thông tin thực tế, kiểm tra quyền và chỉ thực hiện trên tài nguyên được phép.
Bài tập 10–20 phút
Điền bảng: failure injected, thời gian phát hiện, error rate, backlog, bước khôi phục và trạng thái dữ liệu cuối cùng. Chỉ chạy trên lab, không production.
Lỗi dễ mắc
Backup file tồn tại chưa đủ. Restore verification cần tách khỏi DB đang phục vụ traffic và đối chiếu business invariants.
Tự kiểm tra
Khi Redis down, API có nên luôn báo 503 không trong kiến trúc Outbox?Xem đáp án ↗
Không nhất thiết; nếu Postgres còn nhận job/outbox bền vững, API có thể trả 202 theo contract, còn processing tạm bị trễ.
Học thêm qua lab
Có project thực hành đúng với chương này, kèm README và những giới hạn môi trường cần lưu ý.
↓ Tải mã nguồn thực hành chương 20Đối chiếu tài liệu gốc
Cú pháp và khả năng hỗ trợ có thể thay đổi theo phiên bản. Trước khi dùng Production, hãy kiểm tra tài liệu tương ứng.
Mở tài liệu chính thức ↗