Bắt đầu Chuẩn bị Ngay cho Sự cố Mây tiếp theo

Các sự cố đám mây lớn như sự cố của AWS trong tuần này là không thể tránh khỏi. Bốn phương pháp này có thể giúp công ty của bạn vượt qua.

Với hàng nghìn giờ sản xuất bị mất, hệ thống tài chính bị gián đoạn cho hàng triệu người dùng, và có thể hàng trăm tỷ đô la bị mất, sự cố của AWS trong tuần này đã trở thành một ngày thực sự khủng khiếp cho các đội ngũ CNTT toàn cầu. Tất nhiên, nó cũng là thảm họa đám mây toàn cầu tồi tệ nhất kể từ sự cố cuối cùng… và cho đến sự cố tiếp theo.

Cho dù bạn đang sử dụng AWS, GCP, Azure, hay bất kỳ nền tảng nào khác, các sự cố lớn là một thực tế của thực tế đám mây. Vậy công ty của bạn có thể làm gì để giảm thiểu tác động? Dưới đây, tôi sẽ đề xuất bốn bước mà nhóm của bạn có thể thực hiện ngay lập tức.

Mang sự hoài nghi của bạn – và làm việc nhà.

Thường xuyên, các đội sẽ gặp thảm họa bằng cách bước vào các thỏa thuận đám mây với giả định rằng các công ty đám mây lớn là đáng tin cậy. Để chắc chắn, các công ty được tín nhiệm nhất đã kiếm được danh tiếng của họ vì một lý do. Đồng thời, mọi đám mây và hyperscaler đều cung cấp một loạt các tùy chọn cơ sở hạ tầng – AWS Bắc Mỹ alone có 31 Availability Zones và 31 Edge Network Locations – và một số tùy chọn đáng tin cậy hơn những tùy chọn khác.

Thật vậy, Vùng US-EAST-1 của AWS, nguyên nhân của sự cố trong tuần này, đã gây ra các sự gián đoạn lớn vào năm 2020, 2021 và 2023, và nó đã được biết đến trong một số vòng tròn CNTT là vùng ít đáng tin cậy nhất. Nhiều công ty có thể đã hiểu tình hình nhưng đã chấp nhận rủi ro tính toán vì vùng này có chi phí thấp và nhiều dịch vụ. Nhưng given phạm vi của sự cố, điều đó là không thể không suy nghĩ về bao nhiêu công ty đã bị đánh úp hoàn toàn – và chắc chắn đã chọn các vùng đáng tin cậy hơn nếu họ đã biết về sự đánh đổi. Tôi đã gặp các nhà lãnh đạo CNTT đã chọn di chuyển đến các vùng AWS khác chỉ sau khi có những trải nghiệm tồi tệ với US-EAST-1 trong quá khứ.

Bài học ở đây là phải làm việc nhà của bạn khi nói đến các tùy chọn cơ sở hạ tầng đám mây, bất kể bạn đang làm việc với đám mây nào. Các nơi để bắt đầu bao gồm các công cụ miễn phí như cloudprice, Cloudping, và các views về sự cố lịch sử từ các công cụ Health của hyperscaler-provided Cloud Service.

Chọn di động hơn đám mây gốc.

Khi bạn đang thiết kế các cấu hình đám mây, con đường đơn giản hơn là đi đám mây gốc. Nhưng mặc dù nó thuận tiện khi chọn các ứng dụng sẵn sàng được xây dựng bởi và cho nhà cung cấp đám mây của bạn, các tùy chọn đám mây gốc này sẽ để lại bạn nhiều hơn nếu đám mây của bạn bị sập.

Để tránh thêm một lớp phụ thuộc vào đám mây, hãy chọn các sản phẩm độc lập và/hoặc mã nguồn mở khi có thể. Một số ví dụ về các thay thế bao gồm những cái dưới đây:

Để chắc chắn, xây dựng nhiều hơn ngăn xếp đám mây của bạn từ đầu có nghĩa là nhiều công việc hơn cho các đội của bạn. Tuy nhiên, trong kinh nghiệm của tôi, một khi bạn đã có cơ sở hạ tầng hoạt động, có rất ít hoặc không có sự khác biệt giữa việc thêm tải trọng vào cơ sở hạ tầng được thiết lập từ đầu so với hoạt động trên một đám mây gốc. Và các lợi ích về khả năng phục hồi – không đề cập đến việc giảm khóa đám mây – làm cho các tùy chọn độc lập rất đáng giá.

Thiết kế cho sự thất bại.

Cho rằng các sự cố đám mây sẽ xảy ra, hãy đảm bảo thiết kế sản phẩm của bạn với sự thất bại của đám mây trong tâm trí. Một ví dụ để xem xét là Datadog: trong một sự cố năm 2023, công ty này đã mất quyền truy cập vào hơn một nửa số nút Kubernetes trong sản xuất và hoàn toàn thiết kế lại cách tiếp cận thảm họa của mình. Các thay đổi bao gồm loại bỏ các nút thắt kiến trúc và giải quyết các khoản nợ kỹ thuật để các sự cố một phần không lan truyền qua hệ thống, cải thiện việc nhập và lưu trữ dữ liệu cho khả năng sẵn sàng dữ liệu lớn hơn trong thời gian ngừng hoạt động, và xây dựng các hệ thống để tự động phục hồi với quy mô. Một nơi tuyệt vời để bắt đầu trong hành trình của bạn là làm theo khuyến nghị của Datadog để “bắt đầu với những gì quan trọng đối với người dùng cuối,” và xây dựng các biện pháp an toàn để bảo vệ những gì quan trọng nhất.

Chạy trên ít nhất hai đám mây.

Tất nhiên, cách tốt nhất để không bị phụ thuộc vào các sự cố đám mây là sự dư thừa đám mây đa dạng. Để đạt được sự linh hoạt đám mây đa dạng thực sự là một nỗ lực lớn cho nhiều công ty, vì rất khó để dịch cơ sở hạ tầng từ một đám mây sang một đám mây khác. Nhưng xây dựng cơ sở hạ tầng trên chỉ hai đám mây là một nơi mạnh mẽ – và thường có thể thực hiện được – để bắt đầu. Điều quan trọng để làm cho điều này hoạt động là có một đội ngũ có chuyên môn về từng đám mây bạn đang chạy.

Để chắc chắn, không có gì có thể bảo vệ hoàn toàn các công ty khỏi tác động của một sự cố lớn như sự cố chúng ta thấy trong tuần này. Nhưng với sự chuẩn bị đúng đắn, một cách tiếp cận di động đám mây, thiết kế cho sự thất bại, và sử dụng “đa đám mây” như một bước đệm để đa đám mây thực sự, các công ty có thể linh hoạt hơn khi sự cố đám mây lớn tiếp theo (và không may là không thể tránh khỏi) xảy ra.