Xuất bản vào

Một ngày không có Outlook là một phép thử về sự phụ thuộc.

Tác giả

Listen to this article · Một ngày không có Outlook là một phép thử về sự phụ thuộc.

0:00 / 0:00

Watch in English · Một ngày không có Outlook là một phép thử về sự phụ thuộc.

Sự cố gián đoạn toàn cầu của Microsoft kéo dài quá một ngày, làm sập Exchange Online, Teams, SharePoint, Copilot 365 và Defender, và đến 3 giờ sáng giờ Hà Nội, công ty vẫn chưa thể nói khi nào email sẽ hoạt động bình thường trở lại. Sự cố này là bằng chứng rõ ràng nhất gần đây cho một thực tế mà hầu hết các tổ chức đã thôi tranh cãi: chúng ta phụ thuộc vào công nghệ, và sự phụ thuộc đó sẽ không biến mất. Điều có thể lựa chọn là liệu sự phụ thuộc đó có được thiết kế để hỏng một cách an toàn hay không.

Vào lúc 3 giờ 05 phút sáng thứ Bảy, giờ Hà Nội, Microsoft đã đăng tải câu quan trọng hơn bất kỳ chi tiết kỹ thuật nào: họ vẫn chưa thể nói khi nào mọi thứ sẽ trở lại bình thường.

“Truy cập dịch vụ có thể hoạt động trước khi việc gửi và nhận email trở lại bình thường,” tài khoản Microsoft 365 Status viết. Công ty cho biết việc đăng nhập và truy cập đang được cải thiện trong khi các tin nhắn trong hàng đợi và việc cân bằng lưu lượng đang được khắc phục. Họ không đưa ra ước tính nào về việc phục hồi hoàn toàn.

Sự cố bắt đầu vào chiều ngày 12 tháng 11 và kéo dài hơn một ngày. Exchange Online, hạ tầng email đằng sau Outlook, chịu ảnh hưởng nặng nề nhất: người dùng không thể truy cập hộp thư của mình. Teams, SharePoint Online, Copilot 365 và Defender XDR cũng bị suy giảm theo. Lúc 21:17 ngày 13 tháng 11, Microsoft cho biết lượng tồn đọng trong một số hàng đợi đã giảm đáng kể và đang gần trở lại bình thường, trong khi trang tình trạng dịch vụ của chính họ vẫn liệt kê tình trạng bất ổn định.

Sự cố Microsoft: truy cập Outlook trên điện thoại

Microsoft đã “thành thật” xin lỗi về sự gián đoạn và bác bỏ rõ ràng suy đoán cho rằng các tác nhân AI đã gây ra sự cố. Charles Lamanna, phó chủ tịch điều hành phụ trách Copilot, các tác nhân AI và nền tảng, cho biết vào ngày 13 tháng 11 rằng các nhóm đang xem xét điều gì đã xảy ra và cách ngăn chặn một sự việc tương tự.

1+ ngày
dịch vụ bị suy giảm, từ chiều ngày 12 tháng 11
5
các dịch vụ chính bị ảnh hưởng: Exchange Online, Teams, SharePoint Online, Copilot 365, Defender XDR
0
ước tính khôi phục mà Microsoft sẵn sàng đưa ra tính đến 3:05 ngày 14 tháng 11

Phần không còn ai tranh cãi nữa

Sự thật khó xử bên trong sự cố này không phải là Microsoft đã thất bại. Các hệ thống lớn vẫn thất bại. Sự thật khó xử nằm ở hình thái của sự phụ thuộc: hàng đợi email của một nhà cung cấp duy nhất quyết định việc lịch trực bệnh viện, phê duyệt thanh toán của ngân hàng, bàn giao ca của nhà máy và thư từ liên lạc của văn phòng chính phủ có diễn ra đúng giờ hay không.

Sự phụ thuộc đó từng là một lựa chọn, được tạo nên qua từng đợt di chuyển một, và đó là một sự đánh đổi tốt: độ tin cậy trên mỗi đô la mà không phòng IT nội bộ nào có thể sánh được. Giờ đây nó cũng mang tính cấu trúc. Không tổ chức nghiêm túc nào quay lại Exchange tại chỗ chỉ vì một tuần tồi tệ.

  1. Giả định nhà cung cấp gặp sự cố

    Không phải "nếu". Thiết kế quy trình để một ngày không có hệ thống thư chính vẫn có thể sống sót.

  2. Cô lập phạm vi ảnh hưởng

    Một nhà cung cấp không bao giờ được là con đường duy nhất cho phê duyệt, cảnh báo, đăng nhập hoặc liên hệ khách hàng.

  3. Suy giảm, đừng dừng lại

    Truy cập chỉ đọc, ghi được xếp hàng, kênh thứ cấp và phương án dự phòng được ghi lại tốt hơn việc dừng hoàn toàn.

  4. Phục hồi có chủ đích

    Một kế hoạch đã được kiểm thử với người chịu trách nhiệm, mốc thời gian và diễn tập — không phải cuống cuồng ứng biến sau khi sự việc xảy ra.

Thế nào là ‘an toàn’ khi bạn không thể tránh khỏi sự phụ thuộc.

Dòng thời gian cho thấy vì sao bước cuối cùng lại quan trọng. Các cập nhật của chính Microsoft đã chuyển từ "đã áp dụng biện pháp giảm thiểu" sang "hàng đợi đang rút bớt" rồi sang "không có ước tính" trong vòng mười tám giờ. Một tổ chức có kế hoạch là "chờ trang trạng thái" thì thực chất không có kế hoạch nào.

Cuộc tái tổ chức bên dưới

Sự cố xảy ra ngay giữa lúc tái cơ cấu. Tháng trước, Microsoft đã đề nghị nghỉ việc tự nguyện kèm trợ cấp thôi việc cho 60.000 nhân viên, khoảng 27% tổng số nhân sự toàn cầu của hãng, sau đợt cắt giảm 4.800 người được công bố vào tháng Bảy. Hiện chưa rõ bao nhiêu người đã chấp nhận. Khi đợt cắt giảm tháng Bảy được công bố, giám đốc nhân sự Amy Coleman nói rằng các vị trí bị ảnh hưởng sẽ không được thay thế bằng AI.

Không có điều nào trong số đó gây ra sự cố ngừng dịch vụ, và Microsoft đã nói đúng như vậy. Đó là bối cảnh, và bối cảnh chính là điểm mấu chốt: các nhóm vận hành những hệ thống rất lớn đang được yêu cầu làm việc đó với ít người hơn, trong khi cũng chính những công ty ấy bán AI khiến khách hàng ngày càng phụ thuộc vào họ hơn.

60k
nhân viên được đề nghị nghỉ việc tự nguyện vào tháng trước, 27% tổng số nhân sự toàn cầu
5k
các vị trí bị cắt giảm vào tháng 7, với việc công ty nói rằng chúng không được thay thế bằng AI
13
Tháng 11: ngày Microsoft cho biết các nhóm đang xem xét điều đã xảy ra

Điều chúng ta thực sự rút ra từ việc này

Phản xạ sau một sự cố ngừng dịch vụ lớn như thế này là nói về khả năng phục hồi như một thứ để mua: mua vùng thứ hai, mua công cụ giám sát của bên thứ ba, mua trang DR. Những thứ đó có ích. Chúng cũng là phần dễ, vì chúng chỉ là các mục chi phí.

Phần khó nằm ở quy trình, và nó rẻ: biết những quy trình kinh doanh nào dừng khi email ngừng hoạt động, có một kênh thứ hai được kiểm chứng thay vì mặc định là có, ghi rõ ai là người quyết định chuyển kênh, và diễn tập mỗi năm một lần với mức độ nghiêm túc như diễn tập phòng cháy chữa cháy. Hầu hết tổ chức không thể trả lời "cái gì hỏng trước" mà không cần họp.

Chúng ta phụ thuộc vào công nghệ nhiều hơn mỗi năm, và điều đó không thể đảo ngược — năng suất là thật và các lựa chọn thay thế còn tệ hơn. Nhưng phụ thuộc không phải là rủi ro. Phụ thuộc chưa từng được kiểm chứng mới là.

ABN Asia xây dựng phần mềm cho những tổ chức đã quyết định rằng hệ thống của họ phải sống sót qua một ngày tồi tệ: kiến trúc với đường chuyển đổi dự phòng được diễn tập thực tế, chứ không chỉ nằm trên tài liệu; khả năng quan sát cho biết quy trình nào đang hỏng thay vì máy chủ nào đang báo đỏ; runbook xử lý sự cố có tên người phụ trách và mốc thời gian; và các kế hoạch di chuyển bao gồm cả lối ra. Chúng tôi không thể ngăn một nhà cung cấp đám mây siêu quy mô trải qua một tuần tồi tệ. Chúng tôi có thể đảm bảo doanh nghiệp của bạn không phải chờ trên trang trạng thái của họ để biết hôm nay hệ thống có hoạt động không.

Nguồn: VnExpress, "Microsoft: 'Chưa thể xác định thời gian khôi phục hoàn toàn'" (14 tháng 11 năm 2026); các cập nhật trạng thái Microsoft 365 ngày 13–14 tháng 11 năm 2026; phát biểu của Charles Lamanna và Amy Coleman.

Liên hệ: [email protected]

TÁC GIẢ

Về ABN Asia: Ai-Banking-NetworkSecurity (ABN), ABN Asia được thành lập từ năm 2012, là một công ty xuất phát từ học thuật, do những giảng viên, cựu du học sinh Hungary, Hà Lan, Nga, Đức, và Nhật Bản sáng lập. Chúng tôi chia sẻ đam mê chung và tầm nhìn vững chắc về công nghệ, mang đến sự đổi mới và chất lượng đỉnh cao cho khách hàng. Phương châm của chúng tôi là: Tốt hơn. Nhanh hơn. An toàn hơn. Trong nhiều trường hợp: Rẻ hơn.

Hãy liên hệ với chúng tôi khi Quý doanh nghiệp có các nhu cầu về dịch vụ công nghệ thông tin, tư vấn chuyển đổi số, tìm kiếm các giải pháp phần mềm phù hợp, hoặc nếu Quý doanh nghiệp có đấu thầu CNTT (RFP) để chúng tôi tham dự. Quý doanh nghiệp có thể liên hệ với chúng tôi qua địa chỉ email [email protected]. Chúng tôi sẵn lòng hỗ trợ với mọi nhu cầu công nghệ của Quý doanh nghiệp.

ABNAsia.org

© ABN ASIA