Using Fault Injection Testing to Improve DoorDash Reliability
Bài tóm tắt DoorDash 2022 3. Quy mô lớn Độ khó: Trung bình
DoorDash · 2022 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc
Bài của một nghiên cứu sinh CMU (tác giả công cụ Filibuster) về kỳ thực tập ở DoorDash; kết quả mới ở mức prototype trên hai service. Nhận định ghi "theo tác giả".
Bối cảnh
- DoorDash viết backend theo microservice; một request từ app có thể đi qua hàng chục tới hàng trăm service, nên phải xử lý lỗi một phần (một dependency chậm, lỗi, hay vừa deploy kèm bug).
- Chaos engineering ở production (kiểu Netflix) theo tác giả là không thực tế với DoorDash: một khách bị rơi vào nhóm thử nghiệm có thể mất đơn đồ ăn. Chạy chaos ở staging thì hợp để tập dượt on-call, runbook, nhưng thí nghiệm do người tự nghĩ ra và chọn ngẫu nhiên dễ bỏ sót đúng lỗi gây sự cố, và chỉ nhìn được "service sập/chậm" chứ không thấy ứng dụng xử lý từng loại lỗi trả về thế nào.
Thay đổi chính
- Filibuster (fault injection mức service): phân tích tĩnh tìm mọi lỗi có thể xuất hiện ở từng chỗ gọi RPC; rồi tiêm lỗi một cách có hệ thống, từng lỗi một rồi theo tổ hợp, trong khi chạy lại test chức năng end-to-end có sẵn, tới khi hết không gian lỗi.
- Test chức năng thường không có kỳ vọng cho lúc dependency lỗi, nên khi assertion thất bại, developer buộc phải quyết định hệ thống nên làm gì rồi ghi lại bằng assertion có điều kiện ("service X sập thì trả mã Y"). Tác giả gọi đây là phát triển dẫn dắt bởi độ bền.
- Phát lại tất định (xuất file phản ví dụ để viết test hồi quy cho sự cố cũ) và chọn lỗi lúc chạy (dev local chỉ chạy lỗi phổ biến, CI mỗi commit hoặc build đêm chạy danh sách đầy đủ).
- Đưa vào DoorDash: mở rộng từ Python/Flask/HTTP sang Kotlin trên JVM và gRPC (phải sửa thuật toán lõi cho RPC trong code đồng thời); thêm instrumentation động thay vì sửa code ứng dụng. Cuối kỳ: chạy được trên hai service ở môi trường dev local.
Bài học cho SWE
- Chaos ngẫu nhiên kiểm tra phản ứng của tổ chức; tiêm lỗi có hệ thống theo từng chỗ gọi kiểm tra hành vi của code. Hai thứ bổ sung nhau.
- Tìm lỗi độ bền lúc phát triển rẻ hơn ở production, nhất là khi khách không chấp nhận làm "chuột thí nghiệm".
Liên quan
Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định)Monolith và microservices — đi và quay lại
#Fault injection#Chaos engineering#Filibuster#Service-level fault injection#Static analysis#Partial failure#Kotlin#gRPC#Deterministic replay#Resilience-driven development
Được nhắc tới trong
Chủ đề (2)
Công ty (1)