Inžinierstvo spoľahlivosti stránok - kurz 65 000 rub. zo Slurmu, školenie, Dátum 1.1.2024.
Rôzne / / November 29, 2023
ĽUĎOM
Inžinier SRE môže byť buď prevádzkový inžinier alebo vývojár. Počas intenzívneho kurzu si veľa precvičíte a zručnosti a vedomosti, ktoré získate, môžete prispôsobiť a uplatniť v akejkoľvek oblasti.
BUSINESS
SRE rieši rovnaké problémy ako DevOps: zvyšuje rýchlosť uvoľňovania nových funkcií a zlepšuje procesy v tíme. Hlavnou úlohou SRE je však zabezpečiť stabilitu a spoľahlivosť služieb, s výnimkou situácií, keď sa používatelia sťažujú na poruchy a inžinieri majú zelené plány.
Staviame:
Naša školiaca stránka pozostáva z niekoľkých mikroslužieb. Agreguje údaje o predstaveniach, cenách a voľných miestach zo všetkých kín, premieta filmové oznámenia, umožňuje vybrať kino, predstavenie, sálu a miesto, rezervovať a zaplatiť vstupenky.
Sformulujeme indikátory SLO, SLI, SLA pre túto stránku, vyvinieme architektúru a infraštruktúru, ktorá ich bude podporovať, nastavíme monitoring a upozorňovanie.
Chyby vývojárov, zlyhania infraštruktúry, prílev návštevníkov a DoS útoky vedú k zhoršeniu SLO.
Analyzujeme stabilitu, chybovosť, testovaciu prax, riadenie prerušení a prevádzkovej záťaže.
Stala sa nehoda. Služba spracovania platieb nefunguje. Ako postupovať, aby sa funkčnosť obnovila v čo najkratšom čase?
Organizujeme prácu tímu núdzovej reakcie: zapojenie kolegov, informovanie zainteresovaných strán, stanovenie priorít. Trénujeme prácu pod tlakom v extrémne obmedzených časových podmienkach.
Pozrime sa na prístup k stránke z pohľadu SRE. Analyzujeme incidenty (príčiny vzniku, priebeh odstraňovania). Robíme rozhodnutia, aby sme im ďalej predchádzali: zlepšujeme monitorovanie, meníme architektúru, prístup k vývoju a prevádzke a predpisy. Automatizujeme procesy.
— Máme desiatky vybudovaných infraštruktúr a stovky napísaných kanálov CI/CD,
— Certifikovaný správca Kubernetes,
— Autor niekoľkých kurzov o Kubernetes a DevOps,
— Pravidelný rečník na ruských a medzinárodných IT konferenciách.
1. DEŇ: Úvodná časť AMA
Budeme diskutovať o cieľoch a zámeroch kurzu a tiež vám povieme, čo je SRE a rozdelíme ho do tímov.
Otvorenie 2 teoretických tém:
Téma 1: Monitorovanie
- Prečo je potrebné monitorovanie?
- Percentily
- Upozornenie
- Pozorovateľnosť
Téma 2: Teória SRE
- SLO, SLI, SLA
- Trvanlivosť
- Chyba rozpočtu
2. DEŇ: analýza praktík a prípadov
Cvičenie: Vytvorenie základného dashboardu a nastavenie potrebných upozornení
Cvičenie: Pridanie SLO/SLI + upozornení na palubnú dosku
Cvičenie: Prvé zaťaženie systému
Riešenie prípadu 1: downstream závislosť.
Vo veľkom systéme existuje veľa vzájomne závislých služieb a nie vždy fungujú rovnako dobre. Je to obzvlášť nepríjemné, keď je vaša služba v poriadku, ale susedná služba, na ktorej ste závislí, pravidelne klesá.
Vzdelávací projekt sa ocitne presne v týchto podmienkach a vy zabezpečíte, aby stále produkoval kvalitu na najvyššej možnej úrovni.
3. DEŇ: relácia AMA, zodpovedané otázky
Otvorí sa prístup k 2. teoretickému modulu:
Riešenie problémov životného prostredia a architektúry
Druhý modul je postavený na riešení dvoch prípadov: upstream závislosť a architektonické problémy. Rečníci budú hovoriť o riadení incidentov, pravidlách pre hasičský zbor a práci s pitvou a poskytnú šablóny, ktoré môžete použiť vo svojom tíme.
Téma 3: Manažment incidentov
- Inžinierstvo odolnosti
- Ako vzniká hasičský zbor
- Aký efektívny je váš tím pri incidente?
- 7 pravidiel pre vedúceho incidentu
- 5 pravidiel pre hasiča
- HiPPO - názor najlepšie platenej osoby. Vedúci komunikácie
TTéma 4: Nástroje Varrum a správa upozornení.
Osvedčené postupy iných spoločností pri organizovaní správy incidentov.
4. DEŇ: analýza praktík a prípadov
Riešenie prípadu 2: závislosť proti prúdu.
Jedna vec je, keď ste závislí na službe s nízkym SLO. Iná vec je, keď je vaša služba rovnaká pre ostatné časti systému. Stáva sa to, ak hodnotiace kritériá nie sú konzistentné: napríklad odpoviete na požiadavku do sekundy a považujete ju za úspešnú, ale závislá služba čaká iba 500 moskovského času a odíde s chybou.
V prípade si rozoberieme dôležitosť harmonizácie metrík a naučíme sa pozerať na kvalitu očami klienta.
Riešenie prípadu 3: problémy s databázou.
Zdrojom problémov môže byť aj databáza. Ak napríklad nemonitorujete relé replikácie, replika bude zastaraná a aplikácia vráti staré údaje. Okrem toho je ladenie takýchto prípadov obzvlášť ťažké: teraz sú údaje nekonzistentné, ale po niekoľkých sekundách už nie sú konzistentné a nie je jasné, čo je príčinou problému.
Prostredníctvom puzdra pocítite všetku bolesť ladenia a dozviete sa, ako takýmto problémom predchádzať.
Cvičenie: Napíšeme pitvu na predchádzajúci prípad a prediskutujeme ho s rečníkmi.
5. DEŇ: relácia AMA, zodpovedané otázky
Relácia AMA a odpovede na otázky k predchádzajúcim témam.
Otvorí sa prístup k 3. teoretickému modulu:
Dopravné tienenie a kanáriky
V treťom module rozoberieme prípad venovaný problémom so životným prostredím (bude podrobný rozbor Zdravia Kontrola) a tiež krok za krokom analyzujeme, ako implementovať SRE vo firmách a dozvieme sa skúsenosti spoločností, v ktorých rečníci pracujú intenzívne
Téma 5: Kontrola zdravotného stavu
- Kontrola stavu v Kubernetes
- Je naša služba ešte živá?
- Exec sondy
- InitialDelaySeconds
- Port sekundárneho zdravia
- Sidecar Health Server
- Bezhlavá sonda
- Hardvérová sonda
Téma 6: Metódy nasadenia
Téma 7: Začlenenie projektu SRE
Veľké spoločnosti často tvoria samostatný tím SRE, ktorý preberá na podporu služby iných oddelení. Nie každá služba je však pripravená na prijatie na podporu. Prezradíme vám, aké požiadavky musí spĺňať. Rečníci sa tiež podelia o svoje skúsenosti, ako implementovali SRE a aké chyby urobili.
6. DEŇ: analýza praktík a prípadov
Riešenie prípadu 4: je problém so životným prostredím, nie je možné kúpiť lístky.
Úlohou Healthchecku je odhaliť nefunkčnú službu a zablokovať jej prevádzku. A ak si myslíte, že na to stačí požiadať službu root a dostať odpoveď, potom vy mýlite sa: aj keď služba odpovie, nezaručuje to jej fungovanie - môžu nastať problémy okolí.
Prostredníctvom tohto prípadu sa naučíte, ako nakonfigurovať správny Healthcheck a nedovoliť, aby prenos smeroval tam, kde ho nemožno spracovať.
Zhrnutie