Chiều tối ngày 31 tháng 8 năm 2026 theo giờ quốc tế, Microsoft ghi nhận một sự cố lớn trên Exchange Online và gán mã theo dõi EX1464935. Các dịch vụ khác bị kéo theo được gom vào mã MO1465074.
Người dùng gặp thư gửi đi chậm hoặc thất bại, thư đến không tới, tìm kiếm trong hộp thư không trả kết quả. Nhiều người còn gặp lỗi xác thực khi cố mở hộp thư. Danh sách dịch vụ bị lan sang dài bất thường. Teams, Microsoft Graph, OneDrive for Business, SharePoint Online, Purview, Defender XDR, Universal Print, Copilot, và cả trung tâm quản trị Microsoft 365.
Sự cố được đóng lúc 10 giờ sáng ngày 3 tháng 9. Tính từ lúc bắt đầu là gần ba ngày, không phải vài giờ như nhiều bản tin đầu tiên mô tả. Microsoft có báo xu hướng hồi phục sau chừng hai mươi hai giờ, nhưng phần khắc phục dứt điểm kéo thêm hai ngày nữa.
Một cấu hình không triển khai được tới nơi
Microsoft truy nguyên nhân về cấu hình xác thực lõi mà nhiều dịch vụ nội bộ trong hạ tầng Exchange Online cùng dùng chung. Theo mô tả của hãng, cấu hình đó không triển khai được như dự kiến tới một phần hạ tầng.
Cách khắc phục nói lên quy mô. Kỹ sư phải kiểm thử thủ công trên từng máy chủ để đặt lại cấu hình. Không có nút bấm nào đảo ngược trong một lần, và đó là lý do của gần ba ngày.
Điểm chung với các lần trước là chúng không phải hỏng hóc vật lý ở một trung tâm dữ liệu đơn lẻ. Chúng nằm ở lớp cấu hình và lớp điều phối dùng chung, tức lớp mà cơ chế dự phòng theo vùng địa lý không đỡ được. Khi một thành phần dùng chung hỏng, mọi vùng hỏng theo.
Đỉnh thấp hơn nhưng dài hơn nhiều
Số liệu độc lập cho một góc nhìn khác. Trên Downdetector, báo cáo bắt đầu dồn về khoảng 11 giờ 30 theo giờ miền Đông nước Mỹ. Tới 14 giờ đã vượt năm nghìn lượt, và đỉnh hơn sáu nghìn lượt cùng lúc cho riêng Outlook.
Đặt cạnh sự cố ngày 23 tháng 1 năm 2026 thì thấy rõ khác biệt. Lần đó Downdetector ghi đỉnh mười lăm nghìn báo cáo, gấp hơn hai lần, nhưng sự cố chỉ kéo dài khoảng mười tiếng. Nguyên nhân khi ấy là một phần hạ tầng dịch vụ ở Bắc Mỹ không xử lý lưu lượng như dự kiến.
Giữa năm còn một lần nữa, khi đường ống luân chuyển thư trục trặc. Thư của khách hàng doanh nghiệp bị chặn hoặc chậm nặng ở Bắc Mỹ, châu Á Thái Bình Dương và châu Âu cùng lúc. Giới phân tích đếm sự cố cuối tháng 8 là lần lớn thứ ba trong năm, dù Microsoft không xác nhận cách đếm đó.
Chi tiết đáng nhớ hơn con số đếm nằm ở ngày hôm sau. Ngày 4 tháng 9, đúng một ngày sau khi đóng sự cố lớn, Microsoft mở tiếp mã EX1467029 cho tình trạng thư từ tên miền ngoài gửi tới bị chậm.
Về phía cam kết, hãng nói sẽ rà soát lại cấu hình xác thực lõi và xem lại hệ thống giám sát. Bản tường trình sơ bộ hẹn trong hai ngày làm việc, bản cuối trong năm ngày làm việc.
Đổi lấy tiện lợi là mất quyền tự xử lý
Rất nhiều doanh nghiệp trong nước đã chuyển toàn bộ hộp thư lên Microsoft 365 vì những lý do hợp lý. Đỡ nuôi máy chủ, đỡ lo bảo mật, đỡ lo sao lưu. Đánh đổi là khi nhà cung cấp gặp sự cố thì công ty không còn cách nào tự xoay. Không có nút nào để bấm, không nhật ký nào để đọc, chỉ còn cách vào trang trạng thái dịch vụ và chờ.
Lần này sự cố chạm cả lớp xác thực nên nó không dừng ở chuyện thư chậm. Nhân viên đăng nhập không được vào Teams, mở tệp trên SharePoint không được. Bộ phận quản trị mất luôn quyền vào trung tâm quản trị để xem chuyện gì đang xảy ra.
Đây không phải lý do để quay lại tự nuôi máy chủ thư. Bài toán an toàn và chi phí vẫn nghiêng hẳn về dịch vụ đám mây. Nhưng nó là lý do rất rõ để nghĩ về đường lui, và gần ba ngày là quãng đủ dài để đường lui đó phải có thật.
Câu hỏi hay nhất sau mỗi lần một nhà cung cấp lớn gặp sự cố không phải là nên đổi sang ai. Nó là công ty mình chịu được bao lâu nếu chuyện đó lặp lại vào tuần sau. Trả lời được câu đó thì phần còn lại chỉ là chọn phương án.
