Report on our investigation of the 2025-10-20 incident in AWS us-east-1

PlanetScale · 2025 · 3. Quy mô lớn · Độ khó: Nâng cao — bài gốc

Bối cảnh

• 20/10/2025, AWS us-east-1 gặp sự cố lớn bắt đầu từ cấu hình DNS sai ở một nhà cung cấp. Sau đó là nhiều giờ thiếu năng lực và mạng chập chờn.
• PlanetScale (DB managed: Vitess/MySQL, Postgres) thiết kế theo nguyên tắc cô lập và static stability: data plane chạy tiếp được khi control plane chết.

Diễn biến

• Giai đoạn 1 (7:13–9:30 UTC): control plane gần như sập hoàn toàn.
  • service tạo, đổi cỡ, cấu hình branch nằm ở us-east-1 và phụ thuộc dịch vụ upstream, nên không chạy được;
  • dashboard (host ở một nhà cung cấp cũng chạy trên us-east-1), SSO và cả trang status đều chập chờn;
  • không branch DB nào mất năng lực hay kết nối. Kỹ sư không can thiệp gì; tự hồi phục khi upstream hồi phục.
• Giai đoạn 2 (từ 10:05 UTC): không launch được EC2 mới ở us-east-1. Yêu cầu tạo hoặc resize branch xếp hàng, nhưng server đang chạy vẫn sống. Rủi ro lớn nhất: khách autoscale vtgate theo ngày sắp vào đỉnh thứ Hai với chưa tới một nửa năng lực. Họ:
  • tạm cấm tạo DB mới ở us-east-1, đổi region mặc định sang us-east-2;
  • hoãn hoặc huỷ backup (vì backup của họ launch thêm một replica);
  • khuyên khách giảm tải (hoãn queue, dừng ETL);
  • không trả lại máy nào: dừng việc thay máy cũ hơn 30 ngày, giữ máy trống để dùng lại;
  • bin-pack vtgate chặt hơn, chạy gần trần CPU để đủ năng lực cho ngày làm việc ở Mỹ.
• Phân vùng mạng một phần (khoảng 14:30–19:30 UTC): có server DB vẫn ra được Internet nhưng không nói chuyện được với AZ khác. Họ chủ động reparent primary sang AZ khoẻ hoặc cùng AZ với ứng dụng của khách. Sau khi mạng lành, vài process (edge load balancer, vtgate) không tự hồi phục được và phải restart. Đóng sự cố lúc 20:32 UTC.

Rút ra (theo PlanetScale)

• Tách control plane khỏi data plane là lý do control plane sập mà DB của khách không bị ảnh hưởng. Failover tự động đưa primary về phía đa số của phân vùng mạng.
• Cần hiểu và chịu được lỗi của các SaaS mình phụ thuộc (CI/CD, SSO, hosting web, kênh thông báo sự cố); giảm phụ thuộc lúc chạy vào dịch vụ nội bộ và AWS.
• 3 AZ chỉ chịu được mất 1 AZ nếu mạng giữa 2 AZ còn lại ổn. Phân vùng mạng là kiểu lỗi khó suy luận và khó test nhất; us-east-1 có 6 AZ và họ đang xem cách tận dụng.

Bài học cho SWE

• Static stability: thứ đang chạy phải chạy tiếp mà không cần control plane. Khi đó sự cố control plane chỉ còn là "không đổi được cấu hình".
• Lúc nhà cung cấp thiếu năng lực: giữ chặt máy đang có, hoãn việc không cấp bách (backup), xếp chặt hơn. Đây là giảm cầu và giữ cung, giống bài học "tăng cung hay giảm cầu" của Discord (Sự cố và postmortem).
• Kênh liên lạc khi sự cố (trang status) không được nằm chung failure domain với hệ thống của mình (Độ tin cậy và multi-region).
• Cùng một sự cố, góc nhìn khác: Render (Render 2025).

Liên quan

• Sự cố và postmortem
• Độ tin cậy và multi-region
• Cùng công ty: PlanetScale 2026