Inżynieria niezawodności witryny - kurs 65 000 rub. ze Slurm, szkolenie, data 1 stycznia 2024 r.
Miscellanea / / November 29, 2023
DO LUDZI
Inżynier SRE może być inżynierem operacyjnym lub programistą. Podczas intensywnego kursu będziesz dużo ćwiczyć, a zdobyte umiejętności i wiedzę będziesz mógł zaadaptować i wdrożyć w dowolnej dziedzinie.
BIZNES
SRE rozwiązuje te same problemy co DevOps: zwiększa szybkość wydawania nowych funkcji i usprawnia procesy w zespole. Jednak głównym zadaniem SRE jest zapewnienie stabilności i niezawodności usług, z wyłączeniem sytuacji, w których użytkownicy narzekają na awarie, a inżynierowie mają zielone harmonogramy.
Budujemy:
Nasza strona szkoleniowa składa się z kilku mikroserwisów. Agreguje dane o seansach, cenach i dostępnych miejscach ze wszystkich kin, wyświetla zapowiedzi filmów, pozwala na wybór kina, spektaklu, sali i miejsca, rezerwację i opłacenie biletów.
Sformułujemy wskaźniki SLO, SLI, SLA dla tej witryny, opracujemy architekturę i infrastrukturę, która będzie je wspierać, ustawimy monitoring i alarmowanie.
Błędy programistów, awarie infrastruktury, napływ odwiedzających i ataki DoS prowadzą do pogorszenia SLO.
Analizujemy stabilność, budżet błędów, praktykę testowania, zarządzanie przerwami i obciążeniem operacyjnym.
Był wypadek. Usługa przetwarzania płatności nie działa. Jak działać, aby przywrócić funkcjonalność w jak najkrótszym czasie?
Organizujemy pracę zespołu reagowania kryzysowego: angażujemy współpracowników, powiadamiamy interesariuszy, ustalamy priorytety. Szkolimy do pracy pod presją w niezwykle ograniczonych warunkach czasowych.
Spójrzmy na podejście do serwisu z punktu widzenia SRE. Analizujemy incydenty (przyczyny wystąpienia, postęp eliminacji). Podejmujemy decyzje, aby dalej im zapobiegać: usprawniamy monitoring, zmieniamy architekturę, podejście do rozwoju i eksploatacji, regulacje. Automatyzujemy procesy.
— Mamy dziesiątki wybudowanych infrastruktur i setki napisanych rurociągów CI/CD,
— Certyfikowany Administrator Kubernetes,
— Autor kilku kursów z zakresu Kubernetes i DevOps,
— Regularny prelegent na rosyjskich i międzynarodowych konferencjach informatycznych.
DZIEŃ 1: Sesja inauguracyjna AMA
Omówimy cele i zadania kursu, a także opowiemy, czym jest SRE i podzielimy go na zespoły.
Otwarcie 2 tematów teoretycznych:
Temat 1: Monitorowanie
- Dlaczego monitorowanie jest potrzebne?
- Percentyle
- Alarmowanie
- Obserwowalność
Temat 2: Teoria SRE
- SLO, SLI, SLA
- Trwałość
- Budżet błędu
DZIEŃ 2: analiza praktyk i przypadków
Ćwiczyć: Wykonanie podstawowego dashboardu i ustawienie niezbędnych alertów
Ćwiczyć: Dodanie alertów SLO/SLI + do dashboardu
Ćwiczyć: Pierwsze ładowanie systemu
Rozwiązanie przypadku 1: zależność od źródła.
W dużym systemie istnieje wiele współzależnych usług i nie zawsze działają one równie dobrze. Jest to szczególnie denerwujące, gdy Twoja usługa jest w porządku, ale sąsiednia, na której polegasz, okresowo ulega awarii.
Projekt edukacyjny znajdzie się właśnie w takich warunkach, a Ty zadbasz o to, aby nadal generował jakość na najwyższym możliwym poziomie.
DZIEŃ 3: Sesja AMA, odpowiedzi na pytania
Dostęp do drugiego modułu teoretycznego otwiera się:
Rozwiązywanie problemów związanych ze środowiskiem i architekturą
Drugi moduł opiera się na rozwiązaniu dwóch przypadków: zależności od źródła i problemów architektonicznych. Prelegenci opowiedzą o zarządzaniu incydentami, zasadach obowiązujących w straży pożarnej i pracy z sekcjami zwłok oraz udostępnią szablony, które możesz wykorzystać w swoim zespole.
Temat 3: Zarządzanie incydentami
- Inżynieria odporności
- Jak powstaje straż pożarna
- Jak skuteczny jest Twój zespół w przypadku incydentu?
- 7 zasad lidera incydentu
- 5 zasad strażaka
- HiPPO - opinia najlepiej zarabiającej osoby. Lider ds. komunikacji
TTemat 4: Narzędzia Varrum i zarządzanie alertami.
Najlepsze praktyki innych firm w zakresie organizacji zarządzania incydentami.
DZIEŃ 4: analiza praktyk i przypadków
Rozwiązanie przypadku 2: zależność od źródła.
Jeśli zależysz od usługi o niskim poziomie SLO, to jedno. Inną sprawą jest, gdy usługa jest taka sama dla innych części systemu. Dzieje się tak, jeśli kryteria oceny nie są spójne: na przykład odpowiadasz na żądanie w ciągu sekundy i uznajesz je za sukces, ale zależna usługa czeka tylko 500 czasu moskiewskiego i wychodzi z błędem.
W tym przypadku omówimy znaczenie harmonizacji metryk i nauczymy się patrzeć na jakość oczami klienta.
Rozwiązanie przypadku 3: problemy z bazą danych.
Baza danych może być również źródłem problemów. Przykładowo, jeśli nie będziesz monitorować przekaźnika replikacji, replika stanie się nieaktualna, a aplikacja zwróci stare dane. Co więcej, debugowanie takich przypadków jest szczególnie trudne: teraz dane są niespójne, ale po kilku sekundach nie są już spójne i nie jest jasne, jaka jest przyczyna problemu.
Dzięki tej obudowie poczujesz cały ból związany z debugowaniem i dowiesz się, jak zapobiegać takim problemom.
Ćwiczyć: Piszemy sekcję zwłok poprzedniej sprawy i omawiamy ją z prelegentami.
DZIEŃ 5: Sesja AMA, odpowiedzi na pytania
Sesja AMA i odpowiedzi na pytania z poprzednich tematów.
Dostęp do trzeciego modułu teoretycznego otwiera się:
Blokowanie ruchu i wypuszczanie kanarków
W trzecim module przeanalizujemy przypadek poświęcony problemowi z otoczeniem (będzie szczegółowa analiza Zdrowie Sprawdzanie), a także krok po kroku przeanalizujemy, jak wdrożyć SRE w firmach i poznamy doświadczenia firm, w których pracują prelegenci intensywny
Temat 5: Sprawdzanie stanu zdrowia
- Kontrola stanu w Kubernetes
- Czy nasz serwis jeszcze żyje?
- Sondy wykonawcze
- Początkowe opóźnienie sekundy
- Dodatkowy port zdrowia
- Serwer zdrowia Sidecar
- Bezgłowa sonda
- Sonda sprzętowa
Temat 6: Metody wdrażania
Temat 7: Wdrożenie projektu SRE
Duże firmy często tworzą oddzielny zespół SRE, który przejmuje usługi innych działów w celu wsparcia. Jednak nie każda usługa jest gotowa do przyjęcia do wsparcia. Podpowiemy, jakie wymagania musi spełniać. Prelegenci podzielą się także swoimi doświadczeniami, jak wdrożyli SRE i jakie błędy popełnili.
DZIEŃ 6: analiza praktyk i przypadków
Rozwiązanie przypadku 4: jest problem ze środowiskiem, nie można kupić biletów.
Zadaniem Healthcheck jest wykrycie uszkodzonej usługi i zablokowanie ruchu do niej. A jeśli uważasz, że w tym celu wystarczy wysłać żądanie do usługi z rootem i otrzymać odpowiedź, to ty mylisz się: nawet jeśli usługa odpowie, nie gwarantuje to jej działania - mogą pojawić się problemy okolica.
W tym przypadku dowiesz się, jak skonfigurować poprawną kontrolę stanu i nie zezwalać na ruch tam, gdzie nie może zostać przetworzony.
Zreasumowanie