SRE inginer - stagiar
În primul rând, permiteți-mi să mă prezint. eu - , inginer front-end în grup GitLab. Săptămâna trecută am avut onoarea de a face stagiu cu unul dintre inginerii noștri SRE de gardă. Scopul a fost de a observa modul în care ofițerul de serviciu a răspuns la incidente în fiecare zi și de a câștiga experiență reală la locul de muncă. Ne-am dori ca inginerii noștri să înțeleagă mai bine nevoile utilizatorilor Monitor::Sănătate.
A trebuit să urmăresc inginerul SRE peste tot timp de o săptămână. Adică am fost prezent la predare, am monitorizat aceleași canale de alertă și am răspuns la incidente dacă și când au avut loc.
Incidente
Au fost 2 incidente într-o săptămână.
1. Cryptominer
GitLab.com a înregistrat o creștere a utilizării miercuri „a, cauzat de încercările de a folosi minutele alergătorului pentru a extrage criptomonede. Incidentul a fost rezolvat folosind propriul instrument de neutralizare a încălcării, care oprește sarcinile alergătorului și șterge proiectul și contul asociat acestuia.
Dacă acest eveniment nu ar fi fost observat, un instrument automat l-ar fi prins, dar în acest caz, inginerul SRE a observat mai întâi încălcarea. A fost creată o sarcină de incident, dar informațiile despre aceasta sunt închise.
2. Degradarea performanței aplicațiilor Canary și principale
Incidentul a fost cauzat de încetiniri și o frecvență crescută a erorilor în aplicațiile web canary și principale de pe Gitlab.com. Au fost încălcate mai multe valori Apdex.
Deschideți sarcina incidentului:
Constatări cheie
Iată câteva lucruri pe care le-am învățat în timpul săptămânii mele de serviciu.
1. Alertele sunt cele mai utile atunci când se detectează abateri de la normă.
Alertele pot fi împărțite în mai multe tipuri:
- Alerte bazate pe o anumită valoare de prag, cum ar fi „10 erori 5xx au apărut pe secundă”.
- Alerte în care pragul este o valoare procentuală, cum ar fi „frecvența erorilor 5xx la 10% din volumul total de solicitări la un moment dat”.
- Alerte bazate pe media istorică, cum ar fi „5xx erori la percentila 90”.
În general, tipurile 2 și 3 sunt mai utile pentru SRE de serviciu, deoarece dezvăluie abateri de la normă în proces.
2. Multe alerte nu trec niciodată la incidente.
Inginerii SR se confruntă cu un flux constant de alerte, dintre care multe nu sunt de fapt critice.
Deci, de ce să nu vă limitați alertele doar la cele cu adevărat importante? Cu această abordare, totuși, este posibil să nu recunoașteți simptomele timpurii a ceea ce va transforma bulgărele de zăpadă într-o problemă reală care amenință pagube majore.
Sarcina SRE de gardă este de a determina care alerte indică de fapt ceva grav și dacă acestea trebuie să fie escalate și tratate. Bănuiesc că acest lucru se datorează și inflexibilității alertelor: ar fi mai bine dacă ar exista mai multe niveluri sau modalități „inteligente” de a configura alertele în conformitate cu situația descrisă mai sus.
Sugestie de caracteristici:
3. SRE-urile noastre de serviciu folosesc o mulțime de instrumente.
Intern:
- Proiect GitLab infra: runbook-uri live aici, sarcini de tură/săptămână, sarcini de răspuns la incident.
- Probleme GitLab: investigațiile, recenziile și întreținerea sunt, de asemenea, urmărite în probleme.
- Etichete GitLab: sarcinile de automatizare sunt lansate folosind etichete specifice, pe care roboții le folosesc pentru a urmări activitatea sarcinilor.
Extern:
- PagerDuty: Alerte
- Slack: fluxul de mesaje PagerDuty/AlertManager merge aici. Integrare cu comenzi slash pentru a efectua o varietate de sarcini, cum ar fi închiderea unei alerte sau escaladarea la un incident.
- Grafana: vizualizarea valorilor cu accent pe tendințele pe termen lung.
- Kibana: Oferă vizualizare/căutare în jurnal, capacitatea de a săpa mai adânc în evenimente specifice.
- Zoom: În Zoom există o „camera de lucru” care rulează constant. Acest lucru le permite inginerilor SRE să discute rapid despre evenimente fără a pierde timp prețios creând o sală și legați participanții.
Si multe altele.
4. Monitorizarea GitLab.com cu GitLab este un singur punct de eșec
Dacă GitLab.com se confruntă cu o întrerupere majoră a serviciului, nu dorim ca aceasta să afecteze capacitatea noastră de a rezolva problema. Poate fi oprit lansând o a doua instanță GitLab pentru a gestiona GitLab.com. De fapt, acest lucru funcționează deja pentru noi: .
5. Câteva caracteristici pe care trebuie să le luați în considerare adăugarea la GitLab
- , similar cu Google Docs. Acest lucru ar ajuta la sarcinile privind incidentele din timpul unui eveniment, precum și la sarcinile de debriefing. În ambele cazuri, mai mulți participanți ar putea avea nevoie să adauge ceva în timp real.
- Mai multe webhook-uri pentru sarcini. Capacitatea de a rula diferiți pași ai fluxului de lucru GitLab din interior vă va ajuta să vă reduceți dependența de integrările Slack. De exemplu, capacitatea de a permite o alertă în PagerDuty printr-o comandă oblică într-o problemă GitLab.
Concluzie
Inginerii SRE au dificultăți cu multe complexități. Ar fi grozav să vedem mai multe produse GitLab care abordează aceste probleme. Lucrăm deja la câteva completări la produs care vor ușura fluxurile de lucru menționate mai sus. Detalii disponibile la .
Vom extinde echipa în 2020 pentru a aduce împreună toate aceste funcții grozave. Dacă sunteți interesat, vă rugăm să verificați și nu ezitați să contactați oricine din echipa noastră pentru orice întrebări.
Sursa: www.habr.com