AWS Miał Awarię… i bardzo się z tego powodu cieszę!

AWS miał awarię. Co teraz? Koniec świata. Jak żyć?
Normalnie. Ba. Nawet dobrze, że tak się stało.
Zacznijmy jednak od początku.

Co się wydarzyło 28 lutego?

O 9:37 osobnik X użył złego zestawu poleceń. O 13:54 wszystko wróciło do normy.

W międzyczasie usługa S3 – odpowiadająca za przechowywanie plików w regionie Northern Virginia była niedostępna. Tu więcej o tej sytuacji. Pliki nie zniknęły, ale zapisy i odczyty odbywały się z problemem, unieruchamiając pół Internetu.

Firmy na swoich stronach z raportami zwalały winę na dostawcę usług – jak np. moja ulubiona Canva (która to opóźniła publikację mojego vloga).

Firmy te powinny napisać na swoich stronach: Daliśmy ciała w projektowaniu naszej aplikacji. Przepraszamy za zaistniały problem.

Everything fails all the time

Te słowa wypowiedział Werner Vogels – CTO Amazon. Słowa te oddają ważny element współczesnego świata IT. Wszystko ulega awarii. Dostawcy chmury podając dostępność na poziomie X (często 99,99% w skali roku) nie zakładają, że usługa będzie działała cały czas. Zakładają, że czasami stanie się coś złego.

Pracownicy IT powinni przestać narzekać na dostawców IaaS, PaaS, SaaS, ale świadomie podejmować swoje decyzje i zamieniać swoje DUŻE wypłaty na systemy, które są odporne na awarię środowiska, które nie zapewnia 100% dostępności.

Jednak nie jest to takie proste. Potrzebna jest wiedza, potrzebne jest zrozumienia jak działa chmura, potrzebna jest wiedza jak zaprojektować system w środowisku muli-region, potrzebna są pieniądze na podwójne standardy, potrzebni są managerowie, którzy to rozumieją…

A może nic z tych rzeczy nie jest potrzebne?

Może dalej powinniśmy budować tak jak budujemy, zwalając na dostawcy chmur publicznych?

Brzmi jak głupia idea, ale jednak coś w niej jest. Odpowiem na to pytanie później.

Dlaczego cieszę się z awarii AWS?

1. To się już więcej nie powtórzy.

Z chmurami publicznymi jest jak z liniami lotniczymi. Po awarii wykonywane są wszelakie możliwe kroki, aby takiej sytuacji już nie dopuścić. Każda awaria przybliża nas do bardziej bezpiecznego korzystania.

2. Żadne dane nie zostały utracone.

Co utwierdza mnie w przekonaniu, że sposób zapisu i przechowywania danych jest na najwyższym poziomie.

3. Obnażyło to błędy architektoniczne wielu firm.

Wspominałem o tym. Zła architektura firm, które wyceniane są w setkach milionów dolarów, to coś czemu warto się przyjrzeć. Jeżeli godzimy się na wykorzystywanie jednego regionu lub jednej zony, jednego web serwisu, to wiedzmy co się za tym kryje.

4. Pokazało jak przezroczystość jest ważna.

Przyznać się do błędu pracownika to nie lada wyczyn. Można było to ukryć. Jednak każdy, zdrowo myślący człowiek wie, że problemem nie był tu człowiek, lecz system, który umożliwił na wprowadzenie złego parametru. Pisanie o czymś takim świadczy o dużej dojrzałości firmy. Tu jeden minus – dashboard nie pokazywał awarii od razu, gdy awaria wystąpiła.

5. Wykazało solidarność dostawców chmury.

Nie słyszałem (po za jednym komentarzem) uszczypliwych uwag od innych dostawców chmury. To się zdarzyło (zdarzy się) każdemu z nich. Wspólne budowanie świadomości jest bardzo ważne.

Jak się zabezpieczyć przed kolejną awarią?

1. Ucz się.

Często problemem w architekturze takiej, a nie innej (a tym bardziej w komentarzach w gazetach) jest brak zrozumienia jak działa dana chmura. Brak zrozumienia czym jest region, czy zmiana w danym regionie wpływa na inny region, czy dane między regionami się przenoszą. Zauważ, że nie działał tylko jeden region… jeden z czternastu.

2. Testuj.

Jeżeli Twoja aplikacja jest mega krytyczna, to może czas przetestować, “co się stanie gdy”. Łatwo napisać własne rozwiązanie lub skorzystać z pakietu Netflix – Simian Army.



Testuj awarie, szczególnie w poniedziałek o 14:00. Wtedy będziesz gotowy na awarie, a Twoi ludzie będą pracować z większą pewnością.

3. Pomyśl o środowisku multi-cloud (chociaż ostrożnie).

Tu się nie rozpędzajmy. Czasami będzie to dobre rozwiązanie, ale miejmy wiedzę o ograniczeniach. Nie zawsze skorzystamy z przewagi technologicznej dostawcy A. Nie zawsze będzie łatwo zbudować wiedzę o dostawcy B. Pomagają kontenery, pomaga wejście w wyższą warstwę, ale nie zawsze to najlepsze rozwiązanie. (stary obrazek z architekturą Auth0)



4. Nic nie rób i zwolnij ludzi.

Nie żartuję. Ostatnio usłyszałem, że niektóre firmy mają politykę polegającą na ograniczaniu kosztów w braku budowania architektury odpornej na awarię, budując procedury pisania dobrych artykułów, gdy pojawia się awaria, zwalając na danego dostawcę.

Może to również rozwiązanie dla Ciebie. Olać inwestycję w dobre IT, a zainwestować w dobre działy Public Relations!