Inginer SRE - intern
Pentru început, permiteți-mi să mă prezint. Eu sunt , inginer frontend în grupul GitLab. Săptămâna trecută am avut onoarea să fiu intern la unul dintre inginerii SRE de serviciu. Scopul a fost să observ zilnic cum reacționează inginerul de serviciu la incidente și să obțin experiență practică. Ne-ar plăcea ca inginerii noștri să înțeleagă mai bine nevoile utilizatorilor Monitor::Health.
Trebuia să urmăresc inginerul SRE timp de o săptămână. Asta înseamnă că am fost prezent la schimbul de tură, am observat aceleași canale de alertare și am reacționat la incidente, dacă au avut loc.
Incidente
În săptămâna respectivă au avut loc 2 incidente.
1. Miner de criptomonede
Miercuri, pe GitLab.com, s-a observat o creștere a utilizării ‘ului, cauzată de încercările de a folosi minutele runner-ului pentru mining de criptomonede. Incidentul a fost rezolvat cu ajutorul propriului instrument de neutralizare a abaterilor, care oprește sarcinile runner-ului și elimină proiectul și contul asociat.
Dacă acest eveniment nu ar fi fost observat, un instrument automatizat l-ar fi prins, dar în acest caz inginerul SRE a depistat aberația primul. A fost creat un ticket pentru incident, însă informațiile despre acesta sunt închise.
2. Degradarea performanței aplicațiilor Canary și Main
Incidentul a fost provocat de încetiniri și o frecvență mai mare a erorilor în aplicațiile web canary și main pe Gitlab.com. Au fost afectate mai multe valori de Apdex.
Ticket deschis pentru incident:
Concluzii principale
Iată câteva aspecte pe care le-am învățat în timpul săptămânii de tură.
1. Alerta este cea mai utilă atunci când detectează abateri de la normalitate.
Altele tipuri de alerte pot fi împărțite în mai multe tipuri:
- Alertele bazate pe un prag specific, de tipul „au fost 10 erori 5xx pe secundă”.
- Alertele în care pragul este o valoare procentuală, de tipul „frecvența erorilor 5xx la 10% din volumul total de solicitări într-un interval de timp dat”.
- Alertele bazate pe valoarea medie istorică, de tipul „erori 5xx în percentila a 90-a”.
În general, tipurile 2 și 3 sunt mai utile pentru inginerii SRE de serviciu, deoarece scot la iveală abaterile de la normalitate în proces.
2. Multe alerte nu sunt escaladate la incidente.
Inginerii SRE se confruntă cu un flux constant de alerte, dintre care multe nu sunt de fapt critice.
Așadar, de ce să nu limităm alertele doar la cele cu adevărat importante? Cu un astfel de abordare, totuși, am putea să nu recunoaștem semnele timpurii ale unei probleme care ar putea escalada într-o situație serioasă cu potențiale daune mari.
Sarcina de gardă SRE consiste în a determina care alerte indică cu adevărat ceva serios și dacă acestea ar trebui să fie escalate și să fie investigate. Suspectez că acest lucru este cauzat și de inflexibilitatea alertelor: ar fi mai bine dacă s-ar implementa mai multe niveluri sau metode „inteligente” de configurare a alertelor în conformitate cu situația descrisă mai sus.
Propunere de funcție:
3. SRE-urile noastre de gardă folosesc numeroase instrumente
Interne:
- Proiectul infra GitLab: aici se află Runbook-urile, predările de gardă pe schimburi/săptămâni, sarcinile de răspuns la incidente.
- Problemele GitLab: investigațiile, analizele și întreținerea sunt de asemenea urmăriți în sarcini.
- Etichete GitLab: sarcinile de automatizare sunt declanșate de anumite etichete, urmărind activitatea sarcinilor.
Externe:
- PagerDuty: alerte
- Slack: aici se direcționează fluxul de mesaje din PagerDuty/AlertManager. Integrarea cu comenzi slash pentru a îndeplini diverse sarcini, cum ar fi: închiderea unei alerte sau escaladarea acesteia la incident.
- Grafana: vizualizarea metricalor cu accent pe trenduri pe termen lung.
- Kibana: oferă vizualizare/căutare în jurnal, cu posibilitatea de a aprofunda în anumite evenimente.
- Zoom: există o „sala de discuții” permanent activă în Zoom. Acest lucru permite inginerilor SRE să discute rapid despre evenimente, fără a pierde timp prețios pentru a crea o cameră și a trimite link-uri participanților.
Și multe, multe altele.
4. Monitorizarea GitLab.com prin GitLab — aceasta este un punct unic de eșec
Dacă ar avea loc o defecțiune majoră a serviciilor pe GitLab.com, nu ne-am dori ca aceasta să ne afecteze capacitatea de a rezolva problema. Poate fi gestionată prin pornirea unei instanțe secundare GitLab pentru gestionarea GitLab.com. De fapt, aceasta funcționează deja pentru noi: .
5. Câteva caracteristici ce ar trebui luate în considerare pentru a fi adăugate în GitLab
- , similar to Google Docs. This would assist in incident tasks during events and in analysis tasks as well. In both cases, several participants might need to add something in real time.
- More webhooks for tasks. The ability to trigger various steps of the GitLab workflow internally will help reduce dependence on Slack integrations. For example, the option to allow PagerDuty notifications via a slash command in a GitLab task.
Concluzie
SRE engineers face many challenges. It would be great to see more GitLab products addressing these issues. We are already working on some additions to the product that will ease the workflows mentioned above. Details are available in .
In 2020, we are expanding the team to gather all these amazing features. If you're interested, please check out the , and feel free to reach out to anyone on our team with any questions.
Sursa: habr.com
