SRE-engineer ā stagiair
Laat me eerst voorstellen. Ik ben , frontend engineer in de groep van GitLab. Afgelopen week had ik de eer om stagiaire te zijn bij een van onze SRE-engineers in dienst. Het doel was om dagelijks te observeren hoe de wachtende engineer reageert op incidenten en om echte werkervaring op te doen. We willen dat onze engineers de behoeften van de gebruikers beter begrijpen. Monitor::Health.
Tijdens de week volgde ik de SRE-engineer overal. Dat betekende dat ik aanwezig was tijdens de overdracht van de dienst, de waarschuwingskanalen volgde en reageerde op incidenten, als en wanneer deze zich voordeden.
Incidenten
In de loop van de week vond er 2 incidenten plaats.
1. Cryptominer
Woensdag werd er een piek in het gebruik van GitLab.com geregistreerd, veroorzaakt door pogingen om runner-minuten te gebruiken voor het minen van cryptocurrencies. Het incident werd aangepakt met behulp van onze eigen tool voor het neutraliseren van schendingen, die taken van de runner stopt en het gerelateerde project en account verwijdert. Als dit evenement niet was opgemerkt, zou een geautomatiseerde tool het hebben opgevangen, maar in dit geval merkte de SRE-engineer de overtreding als eerste op. Er werd een incidenttaak aangemaakt, maar de informatie hierover is gesloten.
2. Prestatieafname van de Canary- en Main-applicaties
Het incident werd veroorzaakt door vertragingen en een verhoogde foutfrequentie in de canary- en main-webapplicaties op GitLab.com. Verscheidene Apdex-waarden werden overschreden.
Open incidenttaak:
Belangrijkste conclusies
Hier zijn een paar punten die ik heb begrepen tijdens mijn week in de wacht.
1. Alerts zijn het meest nuttig wanneer ze afwijkingen van de norm detecteren.
Alerts kunnen in verschillende typen worden verdeeld:
Alerts gebaseerd op een bepaalde drempelwaarde, zoals 'er zijn 10 5xx-fouten per seconde voorgevallen'.
- Alerts waarbij de drempel een percentage is, zoals 'frequentie van 5xx-fouten is 10% van het totale aantal verzoeken in een bepaalde periode'.
- Alerts gebaseerd op historische gemiddelde waarden zoals '5xx-fouten in de 90e percentiel'.
- Over het algemeen zijn de 2de en 3de types nuttiger voor SRE-wachters, omdat ze afwijkingen van de norm in het proces onthullen.
2. Veel alerts escaleren nooit naar incidenten
SRE-engineers hebben te maken met een constante stroom van alerts, waarvan veel eigenlijk niet kritisch zijn.
SR-engineers hebben te maken met een constante stroom van meldingen, waarvan vele in feite niet kritisch zijn.
Waarom de meldingen niet beperken tot alleen de echt belangrijke? Met deze aanpak kunnen echter vroege symptomen die zich kunnen ontwikkelen tot een echt probleem, dat aanzienlijke schade kan veroorzaken, niet worden herkend.
De taak van de SRE-dienstdoende is om te bepalen welke meldingen werkelijk iets serieus aangeven en of ze geĆ«scaleerd moeten worden en een nadere beoordeling vereisen. Ik vermoed dat dit ook te maken heeft met de inflexibiliteit van meldingen: het zou beter zijn als er verschillende niveaus of 'slimme' manieren zouden worden geĆÆntroduceerd om meldingen in overeenstemming met de eerder beschreven situatie aan te passen.
Functiesuggestie:
3. Onze SRE-dienstdoenden gebruiken veel tools
Intern:
- GitLab-infra-project: hier bevinden zich Runbooks, overdrachten van dienstdoende naar schift/week, taken voor het reageren op incidenten.
- GitLab-issues: onderzoeken, reviews en onderhoud worden ook gevolgd in taken.
- GitLab-labels: automatiseringstaken worden gestart op basis van specifieke labels, waarop bots de activiteit van taken volgen.
Extern:
- PagerDuty: meldingen
- Slack: hier komt de stroom van berichten van PagerDuty/AlertManager binnen. Integratie met slash-commando's om verschillende taken uit te voeren, zoals: melding sluiten of escaleren naar een incident.
- Grafana: visualisatie van statistieken met een focus op langdurige trends.
- Kibana: biedt visualisatie/zoekfunctie in logboeken, met de mogelijkheid om dieper in specifieke evenementen te graven.
- Zoom: er is een continu werkende 'discussiekamer' in Zoom. Dit stelt SRE-engineers in staat om snel gebeurtenissen te bespreken zonder kostbare tijd te verspillen aan het creƫren van een kamer en het delen van links met deelnemers.
En nog veel meer.
4. Monitoring van GitLab.com met GitLab is een single point of failure.
Als er een grote storing van diensten op GitLab.com optreedt, willen we niet dat dit onze mogelijkheid om het probleem op te lossen beĆÆnvloedt. Het kan worden aangepakt door een tweede instantie van GitLab te starten voor het beheer van GitLab.com. Dit werkt al voor ons: .
5. Enkele functies om te overwegen voor toevoeging aan GitLab
- , vergelijkbaar met Google Docs. Dit zou helpen bij taken rond incidenten tijdens een gebeurtenis, evenals bij beoordelingen. In beide gevallen kunnen meerdere deelnemers tegelijkertijd iets in real-time willen toevoegen.
- Meer webhooks voor taken. De mogelijkheid om verschillende stappen van de GitLab-werkstroom van binnenuit te starten, helpt de afhankelijkheid van Slack-integraties te verminderen. Bijvoorbeeld de mogelijkheid om een melding in PagerDuty te aktiveren via een slash-commando in een GitLab-taak.
Conclusie
SRE-engineers hebben het moeilijk met veel complicaties. Het zou geweldig zijn om meer GitLab-producten te zien die deze problemen aanpakken. We werken al aan enkele toevoegingen aan het product die de eerder genoemde werkprocessen vergemakkelijken. Details zijn beschikbaar in .
In 2020 breiden we het team uit om al deze geweldige functies te verzamelen. Als je geĆÆnteresseerd bent, kijk dan alsjeblieft naar , en aarzel niet om contact op te nemen met iemand van ons team voor vragen.
Bron: habr.com
