SRE-ingenieur - stagiair
Laat ik mezelf eerst even voorstellen. Ik ben , frontend engineer in de groep GitLab. Vorige week had ik het voorrecht om stage te lopen bij een van onze SRE-engineers die op afroep beschikbaar zijn. Het doel was om te observeren hoe de engineer die op afroep beschikbaar is dagelijks op incidenten reageert en praktijkervaring op te doen. We willen dat onze engineers de behoeften van gebruikers beter begrijpen. Monitor::Gezondheid.
Ik zou een week lang meelopen met de SRE-engineer. Dat hield in dat ik aanwezig zou zijn bij overdrachten, dezelfde waarschuwingskanalen zou bewaken en zou reageren op incidenten als die zich voordeden.
Incidenten
Er waren 2 incidenten gedurende de week.
1. Cryptominer
GitLab.com zag woensdag een piek in gebruik 'a, veroorzaakt door pogingen om runner-minuten te gebruiken om cryptocurrency te minen. Het incident werd opgelost met een gepatenteerde mitigatietool die runner-taken stopt en het bijbehorende project en account verwijdert.
Als deze gebeurtenis niet was opgemerkt, zou deze door een geautomatiseerde tool zijn opgemerkt, maar in dit geval merkte de SRE-engineer de overtreding als eerste op. Er is een taak voor het incident aangemaakt, maar de informatie erover is gesloten.
2. Prestatievermindering van Canary- en Main-toepassingen
Het incident werd veroorzaakt door vertragingen en een verhoogd foutpercentage in de Canary- en hoofdwebapplicaties op Gitlab.com. Verschillende Apdex-waarden werden geschonden.
Open taak voor incident:
Belangrijkste bevindingen
Dit zijn een paar dingen die ik heb geleerd tijdens mijn dienstweek.
1. Waarschuwingen zijn vooral nuttig wanneer ze afwijkingen van de norm detecteren.
Meldingen kunnen worden onderverdeeld in verschillende typen:
- Waarschuwingen op basis van een bepaalde drempelwaarde, bijvoorbeeld 'er zijn 10 5xx-fouten per seconde opgetreden'.
- Waarschuwingen waarbij de drempelwaarde een percentage is, zoals 'percentage van 5xx-fouten per 10% van het totale aanvraagvolume op een bepaald moment'.
- Waarschuwingen gebaseerd op historische gemiddelden, zoals '5xx-fouten in het 90e percentiel'.
Over het algemeen zijn type 2 en 3 beter geschikt voor oproep-SRE's, omdat ze afwijkingen van de norm tijdens het proces aan het licht brengen.
2. Veel meldingen leiden nooit tot incidenten
SR-engineers krijgen voortdurend te maken met meldingen, waarvan er veel niet eens kritisch zijn.
Waarom zouden we de waarschuwingen dan niet beperken tot de echt belangrijke? Deze aanpak kan echter de vroege waarschuwingssignalen missen die kunnen uitgroeien tot een reëel probleem dat grote schade kan aanrichten.
De taak van de dienstdoende SRE is om te bepalen welke meldingen echt ernstig zijn en of ze moeten worden geëscaleerd en onderzocht. Ik vermoed dat dit ook te wijten is aan de inflexibiliteit van meldingen: het zou beter zijn als er meerdere niveaus of "slimme" manieren waren om meldingen te configureren op basis van de hierboven beschreven situatie.
Suggestie voor een functie:
3. Onze oproepbare SRE's gebruiken veel hulpmiddelen
Intern:
- GitLab-infrastructuurproject: thuisbasis van Runbooks, overdrachten van diensten/weken en taken voor respons op incidenten.
- Problemen met GitLab: onderzoeken, beoordelingen en onderhoud worden ook bijgehouden in taken.
- GitLab-labels: automatiseringstaken worden geactiveerd door specifieke labels, die bots gebruiken om taakactiviteit te volgen.
Extern:
- PagerDuty: Waarschuwingen
- Slack: Dit is waar de berichtenstroom van PagerDuty/AlertManager naartoe gaat. Integreert met slash-opdrachten om verschillende taken uit te voeren, zoals het sluiten van een melding of het escaleren naar een incident.
- Grafana: Visualiseer statistieken met de focus op langetermijntrends.
- Kibana: Biedt visualisatie/zoekmogelijkheden voor logs en de mogelijkheid om dieper in te gaan op specifieke gebeurtenissen.
- Zoom: Zoom heeft een permanente 'breakout room'. Hierdoor kunnen SRE's snel evenementen bespreken zonder kostbare tijd te hoeven besteden aan het creëren van een ruimte en het delen van de link met deelnemers.
En nog veel, veel meer.
4. Het monitoren van GitLab.com met GitLab is een enkel punt van falen
Als GitLab.com een grote storing ervaart, willen we niet dat dit onze mogelijkheden om het probleem op te lossen beïnvloedt. We kunnen dit oplossen door een tweede GitLab-instantie te gebruiken om GitLab.com te beheren. Dit hebben we al werkend: .
5. Een paar functies die u kunt overwegen toe te voegen aan GitLab
- , vergelijkbaar met Google Docs. Dit zou helpen bij incidenttaken tijdens een evenement, evenals bij debriefingtaken. In beide gevallen kunnen meerdere deelnemers in realtime iets moeten toevoegen.
- Meer webhooks voor taken. De mogelijkheid om verschillende stappen van een GitLab-workflow van binnenuit te triggeren, zal de afhankelijkheid van Slack-integraties verminderen. Bijvoorbeeld de mogelijkheid om meldingen aan PagerDuty toe te staan via een slash-opdracht in een GitLab-taak.
Conclusie
SRE-engineers hebben het moeilijk met veel complexiteit. Het zou geweldig zijn als er meer GitLab-producten zouden komen die deze problemen aanpakken. We werken al aan een aantal productuitbreidingen die de bovengenoemde workflows zullen vereenvoudigen. Meer informatie is beschikbaar op .
We breiden ons team in 2020 uit om al deze geweldige functies te bundelen. Als je geïnteresseerd bent, bekijk dan , en neem gerust contact op met een van onze teamleden als u vragen heeft.
Bron: www.habr.com
