Nasz zespół uwielbia eksperymenty. Każdy Slurm nie jest statycznym powtórzeniem poprzednich, ale refleksją nad doświadczeniem i przejściem od dobrego do lepszego. Ale z postanowiliśmy zastosować zupełnie nowy format – aby zapewnić uczestnikom warunki jak najbardziej zbliżone do „walki”.
Jeśli krótko przedstawimy, co robiliśmy podczas intensywnego kursu: „Budujemy, niszczymy, naprawiamy,
Uczymy się." SRE niewiele jest warte w samej teorii – tylko praktyka, realne rozwiązania, realne problemy.
Uczestnicy zostali podzieleni na zespoły, aby energiczny duch rywalizacji nie pozwolił nikomu zasnąć ani uruchomić „Angry Birds” na iPhonie, wzorując się na przykładzie Dmitrija Anatolijewicza.
Problemy, usterki, błędy i zadania dostarczało uczestnikom czterech mentorów. Ivan Kruglov, główny programista w Booking.com (Holandia). Ben Tyler, główny programista w Booking.com (USA). Eduard Miedwiediew, dyrektor ds. technicznych w Tungsten Labs (Niemcy). Evgeniy Varavva, generalny programista w Google (San Francisco).
Ponadto uczestnicy dzielą się na zespoły i rywalizują ze sobą. Ciekawy?
Ivan, Ben, Eduard i Evgeniy przed rozpoczęciem zawodów patrzą na biednych uczestników Slurm SRE z życzliwym leninowskim mrużeniem oczu.
Zatem zadanie:
Jesteśmy nasi, zbudujemy nowy świat...
Istnieje witryna internetowa skupiająca bilety do kina. Incydenty wymyślane są przez mentorów według wcześniej opracowanego scenariusza (choć nikt nie wyklucza szczególnie wyrafinowanej i podstępnej improwizacji), działanie serwisu opisywane jest różnymi metrykami. Problemy mogą być bardzo różne: bilety do teatru Moulin Rouge nie są ładowane do bazy danych; plakaty filmów i spektakli ładują się do bazy w czasie dłuższym niż 10 sekund; opis pojedynczego filmu zawiesza się; 0,1% zamówień jest już zarezerwowanych; Od czasu do czasu system przetwarzania płatności ulega awarii na minutę lub dwie. I wiele, wiele, wiele nieprzyjemnych rzeczy, które mogą spotkać uczestnika Slum SRE w jego prawdziwej pracy.
Jesteśmy gotowi poradzić sobie ze wszystkim... i każdym.
Nasza cierpliwa strona internetowa składa się z kilku mikroserwisów. Jego zadaniem jest agregacja danych o seansach, cenach i dostępnych miejscach ze wszystkich kin, wyświetla zapowiedzi filmowe, pozwala na wybór kina, spektaklu, sali i miejsca, rezerwację i opłacenie biletów. Generalnie wszystko o czym widz może tylko pomarzyć. Ale użytkownik nawet nie podejrzewa, jak gigantyczna walka o stabilność i dostępność witryny toczy się wewnątrz.
Dla obiektu intensywnego wygenerowaliśmy wskaźniki SLO, SLI, SLA, opracowaliśmy architekturę i infrastrukturę, wdrożyliśmy witrynę, skonfigurowaliśmy monitoring i alarmowanie. I odchodzimy.
SLO, SLI, SLA
SLI - wskaźniki poziomu usług. SLO to cele poziomu usług. SLA - umowy dotyczące poziomu usług.
SLA to termin metodologiczny ITIL oznaczający formalną umowę pomię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 świadczenia tej usługi praca.
SLO to cel poziomu usług: wartość docelowa lub zakres wartości poziomu usługi mierzony przez SLI. Normalną wartością SLO jest „SLI ≤ Target” lub „Dolny limit ≤ SLI ≤ Górny limit”.
SLI to wskaźnik poziomu usług — dokładnie określona ilościowa miara jednego aspektu poziomu świadczonych usług. W przypadku większości usług za kluczowy poziom SLI uważa się opóźnienie żądania – czas potrzebny na zwrócenie odpowiedzi na żądanie. Inne popularne SLI obejmują poziom błędów, często wyrażany jako ułamek wszystkich otrzymanych żądań, oraz przepustowość systemu, zwykle mierzoną w żądaniach na sekundę.
Najpierw rozbijemy samoloty, potem dziewczyny, a potem dziewczyny...
Czynniki wewnętrzne i zewnętrzne zaczęły „psuć” SLO już od pierwszych minut. Wszystko spadło na głowy administratorów – błędy programistów, awarie infrastruktury, napływ odwiedzających i ataki DDoS. Wszystko co pogarsza SLO.
„- Drodzy uczestnicy, spieszę, aby was zadowolić, pierwszą rzeczą, która wam się nie uda, jest… wszystko!”
Po drodze prelegenci omówili stabilność, budżet błędów, praktykę testowania, zarządzanie przerwami i obciążeniem operacyjnym.
Nie jesteśmy palaczami, nie stolarzami...
Następnie uczestnicy zaczęli wszystko naprawiać - najważniejsze jest zrozumienie, za co najpierw chwycić.
„-Panie, nigdy nie widziałem, żeby się tak złamał, w tej formie i w takim położeniu!”
A więc zdarzył się wypadek. Usługa przetwarzania płatności nie działa. Jak działać, aby przywrócić funkcjonalność w jak najkrótszym czasie?
Eksperci, patrząc z czułością na uczestników, przygotowują kolejną sztuczkę.
Każdy zespół organizuje pracę grupy w celu wyeliminowania wypadku – angażuje współpracowników, powiadamia zainteresowane strony (interesariuszy). Jednocześnie ustalane są priorytety. W ten sposób uczestnicy zostali przeszkoleni do pracy pod presją w niezwykle ograniczonych warunkach czasowych.
„Jaki horror się pojawił?!”
Zrób wydech... i zakończ ćwiczenie
Wraz z prelegentami, po rozwiązaniu każdego problemu i tymczasowej stabilizacji miejsca zdarzenia, zespół badał zdarzenia z punktu widzenia SRE. Szczegółowo przeanalizowaliśmy problemy – przyczyny ich występowania, przebieg eliminacji. Następnie, zarówno zespołowo, jak i zbiorowo, podejmowaliśmy decyzje, jak dalej im zapobiegać: jak usprawnić monitoring, jak mądrze zmieniać architekturę, jak dostosować podejście do rozwoju i działania, jak poprawić regulacje. Prelegenci zaprezentowali praktykę przeprowadzania sekcji zwłok.
„Kto jeszcze pragnie męki! - I!"
Sukcesy drużyn były ściśle i przejrzyście rejestrowane na elektronicznej tablicy wyników.
Za pierwsze miejsca – premia od interesariuszy.
Źródło: www.habr.com