A postmortem of our July 14, 2026 incident

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

Sự cố thứ hai của Coinbase trong năm 2026 có trong wiki; sự cố trước: Coinbase 2026.

Bối cảnh

Một cụm Kubernetes production dùng chung chứa các service hạ tầng lõi; lưu lượng vào cụm đi qua Istio ingress gateway.
Ở Coinbase, tiền di chuyển qua các workflow bất đồng bộ: khớp xong giao dịch, chuyển tiền, uỷ quyền thẻ đều là workflow, và chúng cần gọi các service hạ tầng trong cụm này.

12:34: một thay đổi cấu hình thường lệ (thuộc đợt migrate sang mô hình deploy service mới) được review và đi qua pipeline chuẩn như một thay đổi rủi ro thấp.
Do trùng tên resource mà kiểm tra trước production không phát hiện, thay đổi vô tình sửa resource của ingress gateway, làm gateway ngừng hoạt động. 12:37: mọi lưu lượng vào cụm dừng; gần như mọi workflow nội bộ tạm dừng trên toàn nền tảng.
Ảnh hưởng khoảng 50 phút: không chuyển tiền ra/vào được (giao dịch đang bay hiện là "kẹt" chứ không lỗi, và xong sau khi hồi), thẻ debit bị từ chối, swap onchain qua DEX không dùng được, chuyển tiền và settlement của Exchange/Prime lỗi hoặc trễ, khách developer platform không nạp/rút được.
13:20 gateway phục hồi, 13:23 coi như đã giảm thiểu; backlog workflow chạy hết trong vài giờ sau. Theo Coinbase, tiền của khách không lúc nào gặp rủi ro.

Cách sửa đơn giản: deploy lại gateway bản ổn định gần nhất. Hai thứ làm nó khó:

Phụ thuộc vòng: truy cập mạng của kỹ sư tới công cụ deploy lại đi qua chính ingress gateway vừa hỏng, nên không rollback được theo quy trình thường.
Đường break-glass có ma sát có chủ đích: kỹ sư phải gọi tay workflow rollback trong cloud provider bằng quyền đặc quyền cấp tạm (just-in-time). Đường này chạy được, nhưng các bước kiểm tra quyền và thủ tục làm tốn thêm thời gian.

Mở rộng guardrail lúc deploy để phát hiện và chặn trùng tên resource, để một deploy không thể sửa resource của thành phần bên cạnh; stress-test các guardrail này.
Tăng độ dư giữa công cụ deploy và hạ tầng nó quản lý, để công cụ cần dùng trong sự cố không bị chính sự cố đánh sập.
Kiểm toán và diễn tập định kỳ đường break-glass để nó nhanh và chắc khi cần.

"Thay đổi rủi ro thấp" trên cụm dùng chung có thể chạm thành phần dùng chung; kiểm tra phạm vi ảnh hưởng (resource bị đổi) chứ không chỉ nội dung thay đổi (Deploy và release an toàn).
Đường phục hồi không được đi qua thứ đang hỏng: công cụ deploy, truy cập của kỹ sư phải có lối riêng (Sự cố và postmortem).
Break-glass mà không diễn tập thì chậm đúng lúc cần nhanh; ma sát an ninh cần được cân với thời gian phục hồi.
Workflow bất đồng bộ giúp giao dịch "chờ" thay vì "hỏng": khách thấy kẹt, nhưng không mất việc.