Liderzy opinii
Rozpocznij przygotowania do następnej awarii chmury

Duże incydenty chmurowe, takie jak ten z tego tygodnia z AWS, są nieuniknione. Poniżej przedstawiam cztery metody, które mogą pomóc Twojej firmie w przezwyciężeniu trudności.
Z licznymi godzinami utraconej produktywności, systemy finansowe zakłócone dla milionów użytkowników, oraz potencjalnie setki miliardów dolarów utracone, awaria AWS z tego tygodnia była niewątpliwie bardzo złym dniem dla globalnych zespołów IT. Oczywiście, było to również najgorsze globalne katastrofy chmurowe od ostatniego… i do następnego.
Niezależnie od tego, czy jesteś na AWS, GCP, Azure, czy na innej platformie, duże awarie są daną rzeczywistości chmury. Co więc może zrobić Twoja firma, aby złagodzić skutki? Poniżej przedstawiam cztery kroki, które Twoja firma może podjąć natychmiast.
Przynieś swoją sceptyczność – i zrób swoje zadanie domowe.
Często zespoły wpadają w pułapkę, wchodząc w układy chmurowe, zakładając, że duże korporacje chmurowe są niezawodne. Oczywiście, najbardziej zaufane firmy zdobyły swoją reputację z powodu. Jednak każda chmura i hyperscaler oferuje szeroki wybór opcji infrastruktury – AWS North America alone ma 31 Availability Zones and 31 Edge Network Locations – i niektóre z nich są znacznie bardziej niezawodne niż inne.
W rzeczywistości, region US-EAST-1 AWS, który był przyczyną awarii z tego tygodnia, był odpowiedzialny za duże zakłócenia w 2020, 2021 i 2023 roku, i był znany w pewnych kręgach IT jako najmniej niezawodny region. Wiele firm prawdopodobnie zrozumiało sytuację, ale podjęło kalkulowane ryzyko ze względu na niski koszt i obfite oferty regionu. Jednak ze względu na zakres awarii, nie można nie rozważyć, ile firm zostało całkowicie zaskoczonych – i z pewnością wybrałoby bardziej niezawodne regiony, gdyby były świadome kompromisów. Osobiście spotkałem się z liderami IT, którzy zdecydowali się przenieść do innych regionów AWS tylko po negatywnych doświadczeniach z US-EAST-1 w przeszłości.
Lekcja płynąca z tego jest taka, aby wykonać zadanie domowe, gdy chodzi o opcje infrastruktury chmurowej, niezależnie od tego, z jaką chmurą pracujesz. Miejsca, w których można zacząć, to bezpłatne narzędzia, takie jak cloudprice, Cloudping, oraz historyczne widoki incydentów z narzędzi Cloud Service Health dostarczonych przez hyperscalery.
Wybierz przenośność zamiast rodzimej chmury.
Gdy projektujesz konfiguracje chmurowe, prostszą drogą jest wybranie rodzimej chmury. Jednakże, chociaż jest wygodnie wybrać aplikacje gotowe przez i dla Twojego dostawcy chmury, te rodzime opcje chmury pozostawiają Cię bardziej narażonym na awarie chmury.
Aby uniknąć dodatkowej warstwy zależności od chmury, wybierz niezależne i/lub otwarte produkty, gdzie jest to możliwe. Kilka przykładów zastąpień to poniżej:
|
Kategoria |
Przykład rodzimej oferty |
Otwarte alternatywy obejmują… |
|
Uwierzytelnianie i tożsamość |
AWS Cognito |
Keycloak |
|
Wyszukiwanie |
Azure Monitor |
Elasticsearch |
|
Relacyjne bazy danych |
Google Cloud SQL |
PostgreSQL |
|
Bazy danych NoSQL |
AWS DynamoDB |
MongoDB |
|
Orkiestracja kontenerów |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
Monitorowanie i obserwowalność |
Google Cloud Monitoring |
Prometheus + Grafana |
|
Kolejki wiadomości |
AWS SQS/SNS |
Apache Kafka |
|
Magazyn obiektów |
Azure Blob Storage |
MinIO |
|
Brama API |
Google Cloud API Gateway |
Kong |
Oczywiście, budowanie większości Twojej chmury od podstaw oznacza więcej pracy dla Twoich zespołów. Jednak w moim doświadczeniu, raz gdy masz infrastrukturę działającą, nie ma prawie żadnej różnicy między dodaniem obciążenia do ustanowionej, domowej infrastruktury a pracą na infrastrukturze rodzimej chmury. A korzyści w zakresie odporności – nie wspominając o zmniejszonym ryzyku uzależnienia od chmury – sprawiają, że niezależne opcje są bardzo warte.
Inżynieria na wypadek awarii.
Uwzględniając, że awarie chmurowe będą się zdarzać, upewnij się, że Twoje produkty są zaprojektowane z myślą o awariach chmurowych. Jednym z przykładów jest Datadog: w 2023 roku firma nagle straciła dostęp do ponad połowy swoich węzłów Kubernetes w produkcji i całkowicie przeprojektowała swój podejście do awarii. Zmiany obejmowały usunięcie architektonicznych wąskich gardeł i rozwiązanie problemu technicznego długu, aby częściowe awarie nie przenosiły się przez system, poprawę pobierania i przechowywania danych w celu zwiększenia dostępności danych podczas awarii, oraz budowę systemów do automatycznego odzyskiwania na dużą skalę. Jednym z dobrych miejsc do rozpoczęcia Twojej podróży jest podążanie za zaleceniem Datadog, aby „zaczynać od tego, co jest ważne dla użytkownika końcowego”, i budować zabezpieczenia, aby chronić to, co jest najważniejsze.
Uruchom na co najmniej dwóch chmurach.
Oczywiście, najlepszym sposobem, aby nie być uzależnionym od awarii chmurowych, jest redundancja wielu chmur. Osiągnięcie prawdziwej płynności wielu chmur jest ogromnym przedsięwzięciem dla wielu firm, ponieważ jest bardzo trudno przetłumaczyć infrastrukturę z jednej chmury na inną. Jednak budowanie infrastruktury na dwóch chmurach jest silnym – i często wykonalnym – miejscem do rozpoczęcia. Kluczowe do tego, aby to działało, jest posiadanie zespołu z ekspertem w każdej z chmur, na których działa się.
Oczywiście, nic nie może całkowicie uchronić firmy przed skutkami ogromnej awarii, jakiej widzieliśmy w tym tygodniu. Jednak z odpowiednim due diligence, podejściem przenośnym chmury, inżynierią na wypadek awarii i używaniem „dwóch chmur” jako stopnia do prawdziwej wielochmurowości, firmy mogą być znacznie bardziej elastyczne, gdy następna (i niestety nieunikniona) duża awaria chmurowa wystąpi.












