Nasz zespół uwielbia eksperymenty. Każdy Słorm to nie statyczne powtórzenie poprzednich, lecz refleksja nad doświadczeniem i przejście od dobrego do lepszego. Ale z postanowiliśmy zastosować całkowicie nowy format — dać uczestnikom warunki maksymalnie zbliżone do "bojowych".
Jeśli krótko opisać, czym się zajmowaliśmy na intensywie: "Budujemy, łamiemy, naprawiamy,
uczymy się". SRE wiele nie znaczy w nagiej teorii — tylko praktyka, realne rozwiązania, realne problemy.
Uczestnicy zostali podzieleni na zespoły, aby energetyczny duch rywalizacji nie pozwolił nikomu zasnąć lub uruchomić „Angry Birds” na iPhonie, na wzór Dmitrija Anatoliewicza.
Problemy, błędy, usterki i zadania zapewniali uczestnikom czterej mentorzy. Iwan Krugłow, główny programista w Booking.com (Holandia). Ben Tyler, główny programista w Booking.com (USA). Eduard Miedwiediew, CTO w Tungsten Labs (Niemcy). Jewgienij Warawwa, programista szerokiego profilu w Google (San Francisco).
A uczestnicy są podzieleni na drużyny — i rywalizują ze sobą. Interesujące?
Iwan, Ben, Eduard i Jewgienij z przyjaznym leninowskim uśmiechem patrzą na biednych uczestników Słorm SRE przed rozpoczęciem rywalizacji.
Oto zadanie:
My, my zbudujemy nowy świat...
Jest strona agregująca bilety do kina. Incydenty wymyślają mentorzy w wcześniej opracowanym scenariuszu (chociaż nikt nie wyklucza szczególnie wysublimowanej i podstępnej improwizacji), funkcjonowanie strony opisuje się różnymi metrykami. Problemy mogą być bardzo różne: bilety do teatru „Moulin Rouge” nie ładują się w bazie; plakaty filmów i spektakli ładują się w bazie ponad 10 sekund; opis konkretnego filmu się zawiesza; 0,1% zamówień trafia na już zarezerwowane miejsca; okresowo na słodkie odłącza się na minutę-dwie system obsługi płatności. I wiele, wiele innych nieprzyjemnych rzeczy, które mogą spadać na uczestnika Słorm SRE w jego rzeczywistej pracy.
Jesteśmy gotowi zmierzyć się ze wszystkim... i ze wszystkimi.
Nasza dużo cierpiąca strona składa się z kilku mikroserwisów. Jej zadaniem jest agregacja danych o seansach, cenach i wolnych miejscach we wszystkich kinach, pokazuje zapowiedzi filmów, pozwala wybrać kino, seans, salę i miejsce, zarezerwować i opłacić bilety. Ogólnie rzecz biorąc, wszystko, o czym widz może tylko marzyć. Tylko użytkownik nawet nie podejrzewa, jaka tytaniczna walka o stabilność i dostępność strony toczy się wewnątrz.
Dla strony na intensywie sformułowaliśmy wskaźniki SLO, SLI, SLA, opracowaliśmy architekturę i infrastrukturę, wdrożyliśmy stronę, skonfigurowaliśmy monitorowanie i alerty. I zaczęło się.
SLO, SLI, SLA
SLI — wskaźniki poziomu usług. SLO — cele poziomu usług. SLA — umowy o poziomie usług.
SLA — termin metodologii ITIL, oznaczający formalną umowę między klientem usługi a jej dostawcą, zawierającą opis usługi, prawa i obowiązki stron oraz, co najważniejsze, uzgodniony poziom jakości świadczonej usługi.
SLO — to cel poziomu usług: docelowa wartość lub zakres wartości dla poziomu usług, który jest mierzony przez SLI. Normalną wartością dla SLO jest „SLI ≤ wartość docelowa” lub „dolna granica ≤ SLI ≤ górna granica”.
SLI jest wskaźnikiem poziomu usług — starannie zdefiniowaną miarą ilościową jednego z aspektów świadczonego poziomu usług. Dla większości usług kluczowym SLI jest opóźnienie żądania — jak długo trwa zwrócenie odpowiedzi na żądanie. Inne powszechnie stosowane SLI obejmują częstość błędów, często wyrażaną jako udział wszystkich otrzymanych żądań oraz przepustowość systemu, zwykle mierzoną w żądaniach na sekundę.
Na początku zepsujemy samoloty, a dziewczyny, a dziewczyny później...
Wewnętrzne i zewnętrzne czynniki od pierwszych minut zaczęły „psuć” SLO. Na głowy administratorów spadły wszystkie - i błędy programistów, i awarie infrastruktury, i napływ odwiedzających, i ataki DDoS. Wszystko to, co pogarsza SLO.
„- Drodzy uczestnicy, spieszy mi się was ucieszyć, w pierwszej kolejności spada wam… wszystko!”
W międzyczasie prelegenci omawiali odporność, budżet błędów, praktykę testowania, zarządzanie przerwami i obciążeniem operacyjnym.
Nie jesteśmy palaczami, nie jesteśmy stolarzami...
Tut uczestnicy zaczęli naprawiać – najważniejsze to zrozumieć, od czego zacząć.
„- Boże, nigdy nie widziałem, żeby to się psuło w taki sposób i w takiej pozycji!”
Otóż, doszło do awarii. Usługa przetwarzania płatności wstrzymała działanie. Jak działać, aby jak najszybciej przywrócić sprawność?
Eksperci z uśmiechem spoglądając na uczestników, przygotowują kolejne wyzwanie.
Każdy zespół organizuje pracę grupy do usunięcia awarii - angażuje współpracowników, informuje interesariuszy. Jednocześnie ustalają priorytety. W ten sposób uczestnicy ćwiczyli pracę pod presją w warunkach skrajnie ograniczonego czasu.
„- Co to za okropieństwo?!"
Zarówno odetchnęli… jak i zakończyli ćwiczenie.
Razem z prelegentami po każdym rozwiązanym problemie i tymczasowo ustabilizowanej stronie, zespoły analizowały incydenty z perspektywy SRE. Szczegółowo analizowali problemy - przyczyny ich wystąpienia, proces usuwania. Następnie, zarówno w zespołach, jak i zbiorowo podjęli decyzję o dalszym zapobieganiu: jak poprawić monitoring, jak mądrze zmienić architekturę, jak dostosować podejście do rozwoju i eksploatacji oraz jak poprawić regulaminy. Prelegenci zaprezentowali praktykę przeprowadzania post-mortem.
„- Kto jeszcze chce męczarni! - Ja!”
Na elektronicznym tablicy wyraźnie i dokładnie rejestrowane były sukcesy zespołów.
Za pierwsze miejsca – nagroda od interesariuszy.
Źródło: habr.com
