Khoảng 16 giờ quốc tế ngày 29/10/2025, khách hàng dùng Azure Front Door bắt đầu gặp trục trặc: độ trễ cao, hết thời gian chờ, lỗi kết nối.
Front Door là lớp định tuyến lưu lượng toàn cầu của Microsoft, đứng trước gần như mọi thứ hãng bán. Danh sách bị kéo theo vì thế rất dài. Cổng quản trị Azure, Exchange Online, Outlook, Teams, SharePoint, Intune, Entra ID, Power Platform, Defender, Purview, Copilot, Windows 365, Xbox Live, Minecraft.
Danh sách bên ngoài Microsoft còn dài hơn. Starbucks, Costco, Walmart, Capital One, Zoom, hệ thống bệnh án MyChart, nền tảng học tập Canvas và hãng hàng không Alaska Airlines đều dừng theo. Không đơn vị nào trong số đó tự làm gì sai.
Dịch vụ được khôi phục vào khoảng 0 giờ 40 sáng hôm sau. Tổng thời gian, tuỳ cách đo, từ tám tiếng rưỡi tới mười bốn tiếng.
Chuỗi nguyên nhân
Bản tường trình sơ bộ của Microsoft mô tả một thay đổi cấu hình vốn hợp lệ của khách hàng. Nó được xử lý qua các phiên bản phần mềm mặt điều khiển không tương thích với nhau. Phần siêu dữ liệu sinh ra từ đó chạm vào một lỗi tiềm ẩn ở lớp xử lý dữ liệu tại biên. Tiến trình sập, kéo theo lỗi phân giải tên miền và hết thời gian chờ.
Nhưng nguyên nhân thật sự nằm ở câu tiếp theo trong bản tường trình. Thay đổi ấy lan ra toàn cầu vì một khiếm khuyết trong chính hệ thống an toàn triển khai. Cơ chế đáng ra phải chặn cấu hình rủi ro lại không chặn.
Hạ tầng quy mô này luôn có lỗi tiềm ẩn nằm im đâu đó — không đội nào loại hết được. Thứ giữ cho lỗi tiềm ẩn không thành sự cố toàn cầu là lớp kiểm tra trước khi triển khai và cơ chế thả từng phần. Khi chính lớp đó hỏng, một cấu hình sai đi thẳng ra mọi điểm hiện diện cùng lúc.
Vì sao khôi phục mất tám tiếng chứ không mất ba mươi phút
Cách xử lý của Microsoft là dừng toàn bộ thay đổi cấu hình, rồi triển khai lại một bản đã biết là tốt. Bản thân việc đẩy cấu hình cũ về dự kiến chỉ mất khoảng nửa tiếng.
Phần còn lại của tám tiếng nằm ở chỗ khác. Họ phải bật lại theo từng đợt trên phạm vi toàn cầu chứ không bật một lượt. Chính cơ chế thả một lượt là thứ vừa gây ra sự cố. Lưu lượng phải cân lại bằng tay giữa các điểm hiện diện. Cổng quản trị Azure phải tách khỏi Front Door để đội vận hành lấy lại quyền điều khiển.
Rồi tới phần không ai điều khiển được: bản ghi tên miền đã nằm trong bộ nhớ đệm ở nhà mạng, ở trình duyệt, ở các lớp đệm trung gian. Phiên làm việc phải thiết lập lại từ đầu. Hạ tầng lành trở lại không có nghĩa người dùng hết lỗi ngay.
Khôi phục an toàn luôn chậm hơn khôi phục nhanh. Lựa chọn ấy đúng, nhưng phải giải thích được với khách hàng đang đếm từng phút.
Ba sự cố, một hình dạng
Sự cố này xảy ra đúng một tuần sau vụ AWS mất phân giải tên miền nội bộ ở vùng us-east-1. Hai nhà cung cấp hạ tầng lớn nhất thế giới gãy cách nhau bảy ngày, vì hai lý do kỹ thuật khác nhau nhưng cùng một hình dạng.
Thêm hai vụ của Cloudflare cuối 2025 nữa thì thành một mẫu rõ ràng. Cả bốn đều bắt đầu từ một thay đổi đi ra toàn hệ thống gần như tức thì. Cả bốn đều chạm vào một lỗi có sẵn mà chưa ai gặp. Và trong cả bốn, phần khó không phải tìm ra nguyên nhân mà là gỡ hậu quả.
Lớp định danh hỏng thì mọi cửa đều khoá
Doanh nghiệp trong nước dùng Microsoft 365 và Entra ID để đăng nhập vào nhiều hệ thống khác. Điểm đó dễ bị bỏ qua nhất. Khi lớp định danh trục trặc, nhân viên không đăng nhập được vào cả những ứng dụng chẳng liên quan gì tới Microsoft. Lý do đơn giản: chúng dùng tài khoản công ty để xác thực. Một điểm hỏng kéo theo cả chuỗi.
Kịch bản mất đăng nhập tập trung đáng để diễn tập ít nhất một lần. Câu hỏi rất cụ thể: nếu ngay bây giờ toàn công ty không vào được thư điện tử và hệ thống nội bộ thì sao? Ai có tài khoản dự phòng, tài khoản đó lưu ở đâu, và bộ phận vận hành liên lạc với nhau bằng kênh nào?
Câu trả lời cho ba câu hỏi ấy không nên nằm trong chính hệ thống vừa ngừng.
