Lưu từ tháng 10 năm 2019

Kiểm tra sau sự cố: hai mươi sáu phút đăng nhập thất bại, ngày 19 tháng 1 năm 2026

Một thay đổi kho phiên mà chúng tôi phân loại là cấu hình đã khóa mọi khách hàng khỏi bảng điều khiển và API trong hai mươi sáu phút. Các instance đang chạy không bao giờ bị ảnh hưởng.

Tóm tắt

Ngày 19 tháng 1 năm 2026, từ 14:02 đến 14:28 UTC, khoảng hai phần ba số lần đăng nhập vào bảng điều khiển hoặc xác thực qua API đều thất bại. Các phiên hiện có cũng bị vô hiệu hóa ngẫu nhiên. Các phiên bản đang chạy, mạng lưới và lưu lượng của chúng không bị ảnh hưởng trong suốt thời gian đó. Việc cung cấp tạm dừng trong hai mươi sáu phút và sau đó được giải phóng; không có đơn hàng nào bị mất.

Dòng thời gian

Tất cả thời gian theo UTC, ngày 19 tháng 1 năm 2026.

Thời gianSự kiện
14:02Thay đổi lược đồ token phiên được áp dụng cho control plane. Việc triển khai được đánh dấu là cấu hình, vì vậy nó lan truyền đến tất cả sáu nút bảng điều khiển cùng một lúc.
14:03Tỷ lệ lỗi đăng nhập tăng từ gần như bằng không lên sáu mươi mốt phần trăm. Cảnh báo tự động có cửa sổ hai phút nên chưa kích hoạt.
14:06Cảnh báo kích hoạt. Kỹ sư trực được gọi.
14:08Người ứng cứu đầu tiên trực tuyến. Thấy tỷ lệ lỗi, không có triển khai nào trong nhật ký thay đổi mã, bắt đầu xem xét cơ sở dữ liệu.
14:14Kỹ sư thứ hai tham gia, kiểm tra nhật ký thay đổi cấu hình thay vì nhật ký mã và tìm thấy mục nhập 14:02.
14:16Nguyên nhân được hiểu: hai nút đang xác thực token bằng phiên bản đầu đọc cũ.
14:19Bắt đầu cuộn lại.
14:24Token phát hành và xác thực chính xác trên cả sáu nút. Tỷ lệ lỗi giảm xuống còn không.
14:28Các tác vụ cung cấp đang xếp hàng được giải phóng. Khôi phục hoàn tất.
15:10Trang trạng thái được cập nhật. Trễ bốn mươi hai phút, đó là một thất bại riêng và sẽ được đề cập ở phần sau.

Nguyên nhân gốc

Token phiên có thêm một trường. Bộ ghi phát ra định dạng mới ngay lập tức; bộ đọc trên hai trong sáu nút bảng điều khiển chưa được khởi động lại và từ chối bất cứ thứ gì mang trường mới. Các yêu cầu được phân phối trên tất cả sáu nút, vì vậy một phiên được tạo trên nút mới có khoảng một phần ba cơ hội bị xác thực bởi nút cũ trong bất kỳ yêu cầu nào. Kết quả trông giống như không liên tục, đó là lý do sáu phút chẩn đoán đầu tiên đi vào cơ sở dữ liệu thay vì vào nhật ký triển khai.

Nguyên nhân sâu xa là một quy tắc chúng tôi viết vào năm 2023. Các thay đổi chạm vào tệp lược đồ thay vì mã ứng dụng được phân loại là cấu hình, và cấu hình bỏ qua giai đoạn canary với lý do rằng, trích dẫn, chỉ là giá trị. Quy tắc đó hợp lý khi các tệp lược đồ duy nhất là cờ tính năng. Không ai xem xét lại khi định nghĩa về tệp lược đồ được mở rộng, và thay đổi này được phân loại chính xác theo một quy tắc đã âm thầm trở nên sai.

Đó không phải là lỗi của kỹ sư áp dụng nó. Việc phân loại được tuân theo chính xác như đã viết.

Phạm vi ảnh hưởng

  • Đăng nhập bảng điều khiển: tỷ lệ thất bại sáu mươi mốt phần trăm trong hai mươi sáu phút.
  • API tokens: cùng tỷ lệ thất bại, cùng cửa sổ. Khóa idempotency đảm bảo các lần tạo lại không bị trùng lặp.
  • Phiên bản đang chạy: không bị ảnh hưởng. Không mất gói tin, không khởi động lại, không ảnh hưởng lưu trữ.
  • Cung cấp: tạm dừng, không thất bại. Bốn đơn hàng được xử lý trong cửa sổ và cả bốn đều hoàn thành trước 14:28.

Những gì chúng tôi đã thay đổi

  1. Giai đoạn canary hiện là vô điều kiện. Bất cứ thứ gì được triển khai, dù phân loại nào, đều đi đến một nút trong năm phút với lưu lượng tổng hợp trước khi đi bất cứ đâu khác. Hoàn thành ngày 21 tháng 1.
  2. Bộ đọc chấp nhận định dạng trước đó trong ba mươi ngày. Xác thực token giờ được phiên bản hóa rõ ràng với cửa sổ chồng lấn, do đó việc triển khai một phần sẽ không gây suy giảm gì. Hoàn thành ngày 23 tháng 1.
  3. Một lần đăng nhập tổng hợp chạy mỗi mười lăm giây từ bên ngoài mạng của chúng tôi, tại ba khu vực, và gọi trang khi thất bại thứ hai liên tiếp thay vì sau cửa sổ trung bình hai phút. Hoàn thành ngày 22 tháng 1.
  4. Trang trạng thái tự động xuất bản khi lần đăng nhập tổng hợp thất bại hai lần, mà không chờ con người viết câu. Một câu của con người sẽ theo sau. Hoàn thành ngày 26 tháng 1.

Những gì chúng tôi không thay đổi, và tại sao

Chúng tôi vẫn không ghi lại IP máy khách hoặc nội dung yêu cầu cho lưu lượng bảng điều khiển. Nếu có, chúng sẽ cho thấy sự phân phối một phần ba trên các nút ngay lập tức và có thể tiết kiệm chín phút. Chín phút không đáng để lưu trữ vĩnh viễn nơi mỗi khách hàng đăng nhập từ đó. Bảng lưu giữ trên trang ghi nhật ký vẫn không thay đổi.

Chúng tôi không chuyển phiên vào một kho lưu trữ dùng chung giữa các trang web. Một kho phiên duy nhất bao phủ mọi trang web sẽ tránh được vấn đề bộ đọc hỗn hợp hoàn toàn bằng cách chỉ có một bộ đọc. Nó cũng sẽ tạo ra chính xác bản ghi tập trung, luôn nóng về ai đang kết nối với cái gì mà chúng tôi đã dành sáu năm để không xây dựng.

Chúng tôi không thêm một kênh thông báo ngừng hoạt động bên ngoài trang trạng thái. Một số người đề xuất mạng xã hội. Trang trạng thái là thứ duy nhất chúng tôi vận hành mà chúng tôi có thể cam kết giữ chính xác, và thêm một bề mặt thứ hai có nghĩa là có một bề mặt thứ hai sẽ trở nên lỗi thời.

Khoản bồi hoàn

SLA bao phủ tính khả dụng của phiên bản. Các phiên bản khả dụng trong suốt hai mươi sáu phút, vì vậy theo hợp đồng không ai được bồi thường. Chúng tôi áp dụng khoản bồi hoàn một ngày cho mọi tài khoản có xác thực thất bại trong cửa sổ, tổng cộng khoảng ba nghìn một trăm euro, bởi vì tranh luận về sự khác biệt với những người không thể truy cập máy chủ của họ là sử dụng buổi chiều của mọi người một cách tồi tệ hơn.

Sẵn sàng khi bạn cần

Chọn thành phố. Chọn kích thước. Thanh toán bằng coin.

Không có biểu mẫu về bạn là ai, không chờ đợi con người phê duyệt, không gọi điện thoại để xác minh bất cứ điều gì. Hóa đơn được thanh toán và thông tin đăng nhập sẽ vào hộp thư của bạn.