Sau những sự cố gián đoạn, khả năng và cách thức nhà cung cấp dịch vụ phục hồi — chứ không phải sự hoảng loạn hay vội vã mang hệ thống trở về hạ tầng riêng — mới nên là kim chỉ nam cho hành động tiếp theo của bạn.

Tác giả: Lydia Leong 

Xem bài viết gốc tại: Don’t Let the AWS Outage Erode Your Trust in the Cloud

Ngày đăng: 20 tháng 10, 2025

Sự cố ngừng hoạt động của 1 AWS Region vào ngày 20 tháng 10 năm 2025 vừa qua là một hồi chuông cảnh tỉnh, nhưng không phải là lý do để chúng ta “từ bỏ”.

Vào khoảng 3 giờ sáng (giờ Miền Đông Hoa Kỳ), khu vực Northern Virginia (US-East-1) đã gặp sự cố DNS, gây ảnh hưởng lan truyền đến các dịch vụ cốt lõi như DynamoDB. Đối với nhiều tổ chức, điều này khiến hiệu suất của ứng dụng bị ảnh hường hoặc ngừng hoạt động trong vài giờ.

Nhưng đây mới là điều quan trọng nhất: Đây không phải là một sự kiện chưa từng có tiền lệ, cũng không phải là bằng chứng cho thấy bản chất của “đám mây” là không đáng tin cậy.

Thực tế, sự cố này diễn ra theo một kịch bản khá quen thuộc mà chúng ta đã thấy từ tất cả các nhà cung cấp đám mây hàng đầu trong thập kỷ qua: một sự cố ở cấp độ khu vực, kéo dài chưa đến một ngày, bắt nguồn từ sự phụ thuộc vào hệ thống mạng, nhưng không ảnh hưởng trực tiếp đến các máy ảo đang chạy.

Việc di chuyển khối lượng công việc ra khỏi AWS, hay chuyển sang các nhà cung cấp dịch vụ nhỏ hơn, sẽ không phải là tấm lá chắn thần kỳ giúp bạn tránh khỏi các sự cố trong tương lai. Trên thực tế, những động thái này thường mang đến những rủi ro mới và thậm chí có thể làm chậm quá trình phục hồi của bạn khi sự cố thực sự xảy ra.

Hãy tránh những phản ứng bộc phát. Việc xây dựng khả năng phục hồi thực sự đòi hỏi tính kỷ luật về mặt kiến trúc.

Không một nhà cung cấp đám mây nào có thể cam kết sẽ không bao giờ bị gián đoạn (zero downtime). Điều tạo nên sự khác biệt của các lãnh đạo CNTT không phải là việc họ có tránh được hoàn toàn sự cố hay không, mà chính là cách họ chuẩn bị và ứng phó.

Luôn thiết kế với tâm thế: Sự cố chắc chắn sẽ xảy ra

Các ứng dụng hiện đại được xây dựng cho đám mây (cloud-native) nên phân phối khối lượng công việc trên nhiều vùng khả dụng (availability zones) và sẵn sàng chuyển đổi dự phòng nhanh chóng sang một khu vực (region) khác khi cần.

Vấn đề không phải là loại bỏ hoàn toàn rủi ro; mà là giảm thiểu phạm vi ảnh hưởng (blast radius) và thời gian khôi phục.

Điều đó có nghĩa là phải hiểu rõ sự phụ thuộc giữa các dịch vụ (như cơ sở dữ liệu hay DNS), duy trì các cẩm nang vận hành (runbooks) luôn được cập nhật, và thực hành diễn tập chuyển đổi dự phòng (failover drills) trước khi sự cố xảy ra.

Các ứng dụng cũ cần được quan tâm đặc biệt

Nếu bạn vẫn đang vận hành các khối lượng công việc cũ (legacy workloads) quan trọng trên đám mây, đừng mặc định rằng khả năng phục hồi là thứ “có sẵn”.

Hãy đảm bảo các bản sao lưu luôn sẵn có ở các khu vực dự phòng (secondary regions) và bạn thực sự có thể khôi phục chúng khi sự cố ập đến.

Hãy kiểm thử kịch bản khôi phục sau thảm họa (disaster recovery) một cách thường xuyên, để đội ngũ của bạn biết chính xác cần làm gì nếu khu vực chính của họ ngừng hoạt động.

Sự minh bạch xây dựng lòng tin

AWS đã luôn công khai về sự phụ thuộc lẫn nhau của các hệ thống toàn cầu và đã nỗ lực (kể từ sự cố tháng 12 năm 2021) để giảm thiểu các điểm lỗi đơn (single points of failure).

Sự cố tháng 10 năm 2025 vừa qua đã được khoanh vùng hoàn toàn trong khu vực US-East-1, cho thấy sự tiến bộ trong việc cô lập lỗi (fault isolation).

Sự minh bạch này mang lại cho các Giám đốc Công nghệ (CIO) dữ liệu thực tế để họ quản lý rủi ro, thay vì để họ phải phỏng đoán.

Đừng sa vào sự phức tạp của đa đám mây (multi cloud), trừ khi cơ quan quản lý yêu cầu

Chúng ta rất dễ nghĩ rằng đa đám mây là câu trả lời cho mọi vấn đề.

Những nghiên cứu của Gartner chỉ ra rằng, việc theo đuổi khả năng phục hồi bằng đa đám mây có thể “lợi bất cập hại” (tốn kém hơn lợi ích mang lại), làm gia tăng sự phức tạp về kỹ thuật mà không thực sự loại bỏ được rủi ro mang tính hệ thống.

Trước tiên, hãy tối ưu khả năng phục hồi trên một đám mây (single-cloud)

Đối với hầu hết các tổ chức — ngay cả những đơn vị đang phải tuân thủ các quy định nghiêm ngặt như Đạo luật về Khả năng Phục hồi Hoạt động Kỹ thuật số (DORA) — việc đầu tư vào các kiến trúc vững chắc trong phạm vi một đám mây sẽ mang lại thời gian hoạt động (uptime) tốt hơn và vận hành đơn giản hơn.

Điều này hiệu quả hơn là cố gắng xoay sở với nhiều nhà cung cấp, vốn có các API và quy trình khác biệt.

Tập trung đảm bảo kinh doanh liên tục bằng khả năng thay thế

Nếu doanh nghiệp của bạn tuyệt đối không thể chấp nhận sự gián đoạn (downtime) đối với một số chức năng nhất định, hãy cân nhắc đến khả năng thay thế ứng dụng (application substitutability).

Điều này có nghĩa là bạn luôn có sẵn các nền tảng thay thế hoặc các quy trình xử lý thủ công (manual workarounds) để kích hoạt ngay lập tức nếu hệ thống chính gặp sự cố.

Cách tiếp cận thực tế này thường vừa đáp ứng được nhu cầu kinh doanh, vừa thỏa mãn các yêu cầu giám sát pháp lý mà không làm phình to ngân sách CNTT.

Đừng để các dòng tít (headlines) dẫn dắt chiến lược. Hãy để dữ liệu tự lên tiếng

Sự cố đám mây gây ồn ào vì chúng ảnh hưởng đến quá nhiều người cùng một lúc, nhưng bối cảnh mới là điều quan trọng. Mọi nhà cung cấp lớn đều đã trải qua các sự kiện tương tự, từ Microsoft Azure đến Google Cloud Platform. Yếu tố tạo nên sự khác biệt thực sự chính là cách tổ chức của bạn lên kế hoạch và khôi phục tốt như thế nào trước những gián đoạn không thể tránh khỏi.

Điểm mấu chốt rất rõ ràng: Đám mây công cộng (Public cloud) vẫn là lựa chọn tốt nhất cho một hạ tầng có khả năng mở rộng (scalable), với điều kiện bạn đầu tư vào khả năng phục hồi ngay từ đầu — hoặc điều chỉnh lại các hệ thống hiện có nếu cần thiết.

Đừng để nỗi sợ hãi dẫn dắt bạn đến những lựa chọn thay thế tốn kém hoặc kém hiệu quả; thay vào đó, hãy tập trung mạnh mẽ hơn vào kiến trúc, tính kỷ luật trong quy trình, và mối quan hệ đối tác minh bạch với các nhà cung cấp của bạn.