Lãnh đạo tư tưởng
Bắt đầu chuẩn bị ngay cho sự cố đám 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 trăm 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ật tệ cho các đội ngũ CNTT toàn cầu. Tất nhiên, đây cũng là thảm họa đám mây toàn cầu tồi tệ nhất kể từ sự cố trước đó… 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 phần 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 thì, các đội sẽ gặp thảm họa khi 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信任 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 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, khu vực US-EAST-1 của AWS, nguyên nhân của sự cố trong tuần này, đã gây ra các 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à khu vực í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ì khu vực này có chi phí thấp và cung cấp nhiều. Nhưng given sự cố, không thể không xem xét làm thế nào nhiều công ty đã bị bất ngờ hoàn toàn – và chắc chắn đã chọn các khu vực đá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 khu vực AWS khác chỉ sau khi có kinh nghiệm xấu với US-EAST-1 trong quá khứ.
Bài học ở đây là phải làm việc nhà khi nói đến các tùy chọn cơ sở hạ tầng đám mây, bất kể bạn đang sử dụng đá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视图 lịch sử về các sự cố từ các công cụ Health của hyperscaler.
Chọn di động hơn đám mây bản địa.
Khi bạn thiết kế các cấu hình đám mây, con đường đơn giản hơn là đi đám mây bản địa. Nhưng trong khi nó tiện lợi khi chọn các ứng dụng đã được xây dựng sẵn bởi và cho nhà cung cấp đám mây của bạn, các tùy chọn đám mây bản địa này sẽ để lại cho bạn thêm một lớp phụ thuộc vào đám mây nếu đám mây của bạn gặp sự cố.
Để 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 các ví dụ dưới đây:
|
Thể loại |
Ví dụ về dịch vụ bản địa |
Các thay thế mã nguồn mở bao gồm… |
|
Xác thực & Định danh |
AWS Cognito |
Keycloak |
|
Tìm kiếm |
Azure Monitor |
Elasticsearch |
|
Cơ sở dữ liệu quan hệ |
Google Cloud SQL |
PostgreSQL |
|
Cơ sở dữ liệu NoSQL |
AWS DynamoDB |
MongoDB |
|
Đồng bộ hóa container |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
Giám sát & Quan sát |
Google Cloud Monitoring |
Prometheus + Grafana |
|
Hàng đợi tin nhắn |
AWS SQS/SNS |
Apache Kafka |
|
Lưu trữ đối tượng |
Azure Blob Storage |
MinIO |
|
Cổng API |
Google Cloud API Gateway |
Kong |
Để chắc chắn, xây dựng nhiều hơn trong 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 và hoạt động trên một đám mây bản địa. Và các lợi ích về tính bền vững – không kể đến giảm sự phụ thuộc vào đám mây – làm cho các tùy chọn độc lập rất đáng giá.
Kỹ sư cho sự cố.
Cho dù các sự cố đám mây sẽ xảy ra, hãy đảm bảo thiết kế các sản phẩm của bạn với sự cố đá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 vấ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 để có sẵn dữ liệu tốt 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 ở quy mô lớn. Một nơi tuyệt vời để bắt đầu trong hành trình của bạn là theo dõi 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 việ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 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 gia về mỗi đá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ố đám mây 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, kỹ sư cho sự cố, và sử dụng “đám mây kép” như một bước đệm để đa dạng hóa đám mây thực sự, các công ty có thể linh hoạt hơn rất nhiều 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.












