Site Reliability Engineering - curs 65.000 rub. din Slurm, antrenament, Data 1 ianuarie 2024.
Miscelaneu / / November 29, 2023
OAMENILOR
Un inginer SRE poate fi fie un inginer operațional, fie un dezvoltator. Pe parcursul cursului intensiv vei exersa mult, iar abilitățile și cunoștințele pe care le dobândești pot fi adaptate și implementate în orice domeniu.
AFACERI
SRE rezolvă aceleași probleme ca și DevOps: crește viteza lansării de noi funcții și îmbunătățește procesele din cadrul echipei. Dar sarcina principală a SRE este de a asigura stabilitatea și fiabilitatea serviciilor, excluzând situațiile în care utilizatorii se plâng de defecțiuni, iar inginerii au programe verzi.
Construim:
Site-ul nostru de instruire constă din mai multe microservicii. Agregează date despre spectacole, prețuri și locuri disponibile din toate cinematografele, arată anunțuri de film, vă permite să selectați un cinema, spectacol, sală și loc, rezervați și plătiți biletele.
Vom formula indicatori SLO, SLI, SLA pentru acest site, vom dezvolta o arhitectură și o infrastructură care îi va susține, vom configura monitorizarea și alertarea.
Erorile dezvoltatorilor, defecțiunile infrastructurii, un aflux de vizitatori și atacurile DoS duc la înrăutățirea SLO-urilor.
Analizăm stabilitatea, bugetul de erori, practica de testare, gestionarea întreruperilor și încărcarea operațională.
A existat un accident. Serviciul de procesare a plăților este oprit. Cum să acționezi pentru a restabili funcționalitatea în cel mai scurt timp posibil?
Organizăm munca echipei de intervenție în situații de urgență: implicarea colegilor, sesizarea părților interesate, stabilirea priorităților. Ne antrenăm să lucrăm sub presiune în condiții de timp extrem de limitate.
Să ne uităm la abordarea site-ului din punct de vedere SRE. Analizăm incidentele (cauze de apariție, progresul eliminării). Luăm decizii pentru a le preveni în continuare: îmbunătățim monitorizarea, schimbăm arhitectura, abordarea dezvoltării și exploatării și reglementările. Automatizăm procesele.
— Avem zeci de infrastructuri construite și sute de conducte CI/CD scrise,
— Administrator certificat Kubernetes,
— Autor al mai multor cursuri despre Kubernetes și DevOps,
— Vorbitor regulat la conferințe IT ruse și internaționale.
ZIUA 1: Sesiune de lansare AMA
Vom discuta despre scopurile și obiectivele cursului și, de asemenea, vă vom spune ce este SRE și îl vom împărți în echipe.
Deschiderea a 2 teme teoretice:
Tema 1: Monitorizare
- De ce este nevoie de monitorizare?
- Percentile
- Alertarea
- Observabilitate
Tema 2: Teoria SRE
- SLO, SLI, SLA
- Durabilitate
- Eroare buget
ZIUA 2: analiza practicilor și a cazurilor
Practică: Realizarea unui tablou de bord de bază și configurarea alertelor necesare
Practică: Adăugarea de alerte SLO/SLI + la tabloul de bord
Practică: Prima încărcare a sistemului
Soluția cazului 1: dependența în aval.
Într-un sistem mare, există multe servicii interdependente și nu funcționează întotdeauna la fel de bine. Este deosebit de enervant când serviciul tău este în regulă, dar cel vecin, de care depinzi, scade periodic.
Proiectul educațional se va regăsi exact în aceste condiții, iar tu te vei asigura că produce în continuare calitate la cel mai înalt nivel posibil.
ZIUA 3: Sesiune AMA, răspuns la întrebări
Accesul la modulul 2 teoretic se deschide:
Rezolvarea problemelor cu mediul și arhitectura
Al doilea modul este construit în jurul rezolvării a două cazuri: dependența din amonte și problemele de arhitectură. Vorbitorii vor vorbi despre gestionarea incidentelor, regulile pentru pompieri și lucrul cu autopsie și vor oferi șabloane pe care le puteți folosi în echipa dumneavoastră.
Tema 3: Managementul incidentelor
- Ingineria Rezilienței
- Cum se formează o brigadă de pompieri
- Cât de eficientă este echipa ta în incident?
- 7 reguli pentru un lider de incident
- 5 reguli pentru un pompier
- HiPPO - opinia celui mai bine plătit. Lider de comunicare
TTema 4: Instrumente Varrum și managementul alertelor.
Cele mai bune practici ale altor companii în organizarea managementului incidentelor.
ZIUA 4: analiza practicilor și a cazurilor
Soluția cazului 2: dependență în amonte.
Un lucru este atunci când depinzi de un serviciu cu un SLO scăzut. Este o altă problemă când serviciul dvs. este același pentru alte părți ale sistemului. Acest lucru se întâmplă dacă criteriile de evaluare nu sunt consecvente: de exemplu, răspundeți la o solicitare într-o secundă și o considerați un succes, dar serviciul dependent așteaptă doar 500 de timp de la Moscova și pleacă cu o eroare.
În acest caz, vom discuta despre importanța armonizării valorilor și vom învăța să privim calitatea prin ochii clientului.
Soluția cazului 3: probleme cu baza de date.
Baza de date poate fi, de asemenea, o sursă de probleme. De exemplu, dacă nu monitorizați releul de replicare, replica va deveni depășită și aplicația va returna date vechi. Mai mult, depanarea unor astfel de cazuri este deosebit de dificilă: acum datele sunt inconsistente, dar după câteva secunde nu mai sunt consistente și nu este clar care este cauza problemei.
Prin carcasă, veți simți toată durerea depanării și veți învăța cum să preveniți astfel de probleme.
Practică: Scriem un post-mortem asupra cazului anterior și îl discutăm cu vorbitorii.
ZIUA 5: Sesiune AMA, răspunsuri la întrebări
Sesiune AMA și răspunsuri la întrebări pe subiecte anterioare.
Accesul la cel de-al 3-lea modul teoretic se deschide:
Ecranarea traficului și eliberarea canarelor
În cel de-al treilea modul vom analiza un caz dedicat unei probleme cu mediul (va fi o analiză detaliată a Sănătății Verificare), și, de asemenea, vom analiza pas cu pas modul de implementare a SRE în companii și vom afla experiența companiilor în care lucrează vorbitorii intens
Subiectul 5: Verificarea sănătății
- Verificarea sănătății în Kubernetes
- Mai este serviciul nostru?
- Sonde executive
- InitialDelaySeconds
- Portul secundar de sănătate
- Server de sănătate Sidecar
- Sondă fără cap
- Sondă hardware
Subiectul 6: Metode de implementare
Subiectul 7: Integrarea proiectului SRE
Companiile mari formează adesea o echipă SRE separată, care preia serviciile altor departamente pentru sprijin. Dar nu orice serviciu este gata să fie acceptat pentru asistență. Vă vom spune ce cerințe trebuie să îndeplinească. Vorbitorii vor împărtăși și experiența lor, cum au implementat SRE și ce greșeli au făcut.
ZIUA 6: analiza practicilor și a cazurilor
Soluția cazului 4: există o problemă cu mediul, este imposibil să cumpărați bilete.
Sarcina Healthcheck este să detecteze un serviciu întrerupt și să blocheze traficul către acesta. Și dacă credeți că pentru aceasta este suficient să faceți o cerere către serviciul cu root și să primiți un răspuns, atunci dvs vă înșelați: chiar dacă serviciul răspunde, acest lucru nu garantează funcționarea acestuia - pot apărea probleme în împrejurimi.
Prin acest caz, veți învăța cum să configurați Healthcheck-ul corect și să nu permiteți traficului să meargă acolo unde nu poate fi procesat.
Rezumând