Enginyer SRE - becari
Per començar, deixeu-me presentar-me. jo - , enginyer front-end del grup GitLab. La setmana passada vaig tenir el privilegi de ser becari amb un dels nostres enginyers SRE de guàrdia. L'objectiu era observar diàriament com l'oficial de servei respon als incidents i obtenir experiència laboral real. Ens agradaria que els nostres enginyers entenguessin millor les necessitats dels usuaris Monitor::Salut.
Vaig haver de seguir l'SRE durant una setmana. És a dir, vaig estar present en el trasllat de funcions, vaig observar els mateixos canals d'alerta i vaig donar resposta a les incidències, si i quan es produïen.
Incidències
Hi ha hagut 2 incidents en una setmana.
1. Cryptominer
GitLab.com va registrar un salt en l'ús dimecres 'a, causat per intents d'utilitzar els minuts del corredor per a la mineria de criptomoneda. L'incident es va resoldre mitjançant una eina de mitigació propietària que atura les tasques del corredor i elimina el projecte i el compte associat.
Si aquest esdeveniment no s'hagués notat, una eina automatitzada l'hauria detectat, però en aquest cas, l'enginyer SRE va notar primer la violació. S'ha creat una tasca d'incidència, però la informació està tancada.
2. Degradació del rendiment de les aplicacions Canàries i Principals
L'incident va ser alimentat per desacceleraments i augment de les taxes d'error a les aplicacions web canàries i principals a Gitlab.com. Es van violar diversos valors d'Apdex.
Tasca oberta per incident:
Principals conclusions
Aquí hi ha alguns punts que vaig aprendre durant la setmana de servei.
1. Les alertes són més útils quan es detecten desviacions de la norma.
Les notificacions es poden dividir en diversos tipus:
- Alertes basades en un llindar determinat, com ara "S'han produït 10 errors 5xx per segon".
- Alertes on el llindar és un valor percentual, com ara "índex d'error 5xx per 10% del total de sol·licituds en un moment determinat".
- Alertes basades en una mitjana històrica com ara "errors 5xx al percentil 90".
En termes generals, els tipus 2 i 3 són més útils per als SRE de servei, ja que revelen anomalies en el procés.
2. Moltes alertes mai es transformen en incidents
Els enginyers de SR tracten un flux constant d'alertes, moltes de les quals no són realment crítiques.
Llavors, per què no limitar les alertes només a les realment importants? Amb aquest enfocament, però, es poden passar per alt els primers símptomes del que convertirà una bola de neu en un problema real que amenaça un dany important.
La tasca de l'SRE de guàrdia és determinar quines alertes signifiquen realment alguna cosa greu i si cal augmentar-les i començar a resoldre's. Sospito que això també es deu a la inflexibilitat de les alertes: seria millor que introduïssin diversos nivells o maneres "intel·ligents" de personalitzar les alertes segons la situació descrita anteriorment.
Suggeriment de funcions:
3. Els nostres SRE utilitzen moltes eines
Intern:
- Projecte GitLab infra: Runbooks viuen aquí, trasllats de torns/setmanes, tasques de resposta a incidents.
- Problemes de GitLab: la investigació, la informació i el manteniment també es fan un seguiment dels problemes.
- Etiquetes de GitLab: les tasques d'automatització s'activen mitjançant etiquetes específiques que utilitzen els robots per fer un seguiment de l'activitat de les tasques.
Extern:
- Alertes de PagerDuty
- Slack: aquí és on va el flux de missatges PagerDuty/AlertManager. Integració amb ordres de barra inclinada per realitzar una varietat de tasques, com ara tancar una alerta o escalar un incident.
- Grafana: visualització de mètriques amb un focus en tendències a llarg termini.
- Kibana: ofereix visualització/cerca de registre, la capacitat d'aprofundir en determinats esdeveniments.
- Zoom: hi ha una "sala de descans" permanent a Zoom. Això permet als SRE discutir ràpidament els esdeveniments sense perdre un temps preciós creant una sala i enllaçant membres.
I molts molts altres.
4. La supervisió de GitLab.com amb GitLab és un únic punt d'error
Si GitLab.com experimenta una interrupció important del servei, no volem que afecti la nostra capacitat per resoldre el problema. Es pot aturar executant una segona instància de GitLab per gestionar GitLab.com. De fet, això ja ens funciona: .
5. Algunes funcions que cal afegir a GitLab
- , similar a Google Docs. Això ajudaria en les tasques d'incidència durant l'esdeveniment, així com en les tasques d'informació. En ambdós casos, és possible que diversos participants hagin d'afegir alguna cosa en temps real alhora.
- Més webhooks per a tasques. La possibilitat d'executar diversos passos del flux de treball de GitLab des de dins us ajudarà a reduir la vostra dependència de les integracions de Slack. Per exemple, la possibilitat d'habilitar una alerta a PagerDuty mitjançant una ordre de barra inclinada en un problema de GitLab.
Conclusió
Els enginyers d'SRE tenen moltes dificultats. Seria fantàstic veure que més productes GitLab abordessin aquests problemes. Ja estem treballant en algunes addicions al producte que facilitaran els fluxos de treball esmentats anteriorment. Les peces estan disponibles a .
El 2020, estem ampliant l'equip per reunir totes aquestes grans característiques. Si esteu interessats, feu una ullada , i no dubteu a contactar amb algú del nostre equip per a qualsevol pregunta.
Font: www.habr.com