Moving e2e testing into production with multi-tenancy for increased speed and reliability

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

Bối cảnh

• Thời monolith, nhu cầu test end-to-end được đáp ứng bằng sandbox. Sang microservices, chạy hết các service trên một máy không nổi, nên dựng môi trường staging riêng (bản sao production không có PII).
• Staging dần không đáng tin: không có observability và alert cho luồng e2e (từng service có, nhưng không ai đảm bảo chúng chạy ăn khớp); không có cách mô phỏng dữ liệu production (chép thẳng thì PII lọt vào staging, vi phạm tuân thủ); không có SLO nên người ta deploy bản chưa ổn định lên staging để thử service riêng lẻ. Kết quả: nhiều team bỏ qua staging, rollout thẳng lên production, staging càng lệch xa.
• Developer tự chế cách test trong production: allowlist tài khoản nhân viên, script tạo user test và cấu hình runtime riêng, logic lọc user test khỏi analytics; mỗi người một kiểu, tốn công bảo trì.

Thay đổi chính

• Không sửa staging vì: thêm observability e2e cho hàng trăm microservice là việc của cả tổ chức; không có công cụ mô phỏng dữ liệu; ép staging dùng bản ổn định là thay đổi văn hoá lớn. Ngược lại production đã có observability, SLA và chỉ chạy bản ổn định.
• Multi-tenancy: thêm tenant DoorTest trong production. Giá trị tenant hai cấp <L0:L1> (L0 là ngành dọc sản phẩm như DoorDash, DoorTest, Drive; L1 phân loại bên trong, ví dụ sandbox của một developer). App mobile/web đặt tenant vào header HTTP; ở CDN header được đổi sang định dạng baggage và truyền qua mọi service bằng OpenTelemetry.
• Cô lập dữ liệu: database riêng cho DoorTest (cô lập vật lý ở L0), cột tenant-id trên mọi bảng liên quan user (cô lập logic ở L1), lớp định tuyến query chọn database và thêm điều kiện lọc tenant. Nới ràng buộc: phone_number được null trong database DoorTest để tạo user test không cần số điện thoại duy nhất.
• Guardrail: CDN xoá header tenant DoorTest nếu IP không thuộc VPN; khách test không đặt được đơn ở cửa hàng thật và ngược lại; shipper test không nhận đơn của cửa hàng thật và ngược lại.
• Công cụ: UI (và cùng chức năng qua gRPC cho test tự động) để tạo user test, giả vị trí, đặt đơn từ cửa hàng test dựng sẵn, tạo ca làm cho shipper và tự gán đơn.

Vì sao

• Theo DoorDash: test e2e trong production đáng tin hơn hẳn vì dựa trên observability và alert sẵn có; bỏ được việc chép dữ liệu và các mẹo tự chế; chuẩn hoá cho phép làm công cụ chung. Cơ chế cô lập này còn là nền cho công cụ shift-left (Signadot) để test e2e ngay lúc phát triển (hẹn bài sau).

Bài học cho SWE

• Staging chỉ có giá trị khi được đối xử như production (observability, SLO, bản ổn định, dữ liệu giống thật); nếu không, nó lệch dần và bị bỏ qua.
• Test trong production cần một ngữ cảnh tenant truyền qua mọi hop (tái dùng hạ tầng tracing) cộng cô lập dữ liệu và guardrail tách luồng test khỏi luồng thật, chặn ngay ở biên.
• Khi thấy nhiều team tự chế cùng một mẹo, đó là tín hiệu cần một cơ chế chuẩn của nền tảng.

Liên quan

• Multi-tenancy và cô lập tenant
• DoorDash 2022 · Miro 2023 · Stripe 2026 · Atlassian 2020 · Tinder 2020
• Kiểm thử độ tin cậy (chaos, fault injection, mô phỏng tất định) · Monolith và microservices — đi và quay lại