SRE-ingenieur - stagiair
Laat ik mij eerst even voorstellen. I - , front-end engineer in de groep GitLab. Vorige week had ik de eer om stage te lopen bij een van onze oproepbare SRE-ingenieurs. Het doel was om te observeren hoe de dienstdoende officier dagelijks op incidenten reageerde en praktijkervaring op te doen tijdens het werk. We willen graag dat onze ingenieurs de gebruikersbehoeften beter begrijpen Monitor::Gezondheid.
Ik moest de SRE-ingenieur een week lang overal volgen. Dat wil zeggen dat ik bij de overdracht aanwezig was, dezelfde waarschuwingskanalen in de gaten hield en op incidenten reageerde als en wanneer deze zich voordeden.
Incidenten
Binnen een week waren er 2 incidenten.
1. Cryptominer
GitLab.com zag woensdag een sprong in het gebruik 'a, veroorzaakt door pogingen om de minuten van de hardloper te gebruiken om cryptocurrency te minen. Het incident werd afgehandeld met behulp van onze eigen tool voor het neutraliseren van overtredingen, die de taken van de hardloper stopzet en het bijbehorende project en account verwijdert.
Als deze gebeurtenis niet was opgemerkt, zou een geautomatiseerde tool deze hebben opgemerkt, maar in dit geval merkte de SRE-ingenieur de overtreding als eerste op. Er is een incidenttaak gemaakt, maar de informatie hierover is gesloten.
2. Prestatievermindering van Canary- en Main-applicaties
Het incident werd veroorzaakt door vertragingen en een verhoogde frequentie van fouten in de canary en de belangrijkste webapplicaties op Gitlab.com. Er werden verschillende Apdex-waarden geschonden.
Open incidenttaak:
Belangrijkste bevindingen
Hier zijn een paar dingen die ik heb geleerd tijdens mijn dienstweek.
1. Waarschuwingen zijn het nuttigst bij het detecteren van afwijkingen van de norm.
Waarschuwingen kunnen in verschillende typen worden onderverdeeld:
- Waarschuwingen op basis van een bepaalde drempelwaarde, zoals “10 5xx fouten per seconde.”
- Waarschuwingen waarbij de drempel een procentuele waarde is, zoals “frequentie van 5xx fouten per 10% van het totale aantal verzoeken op een bepaald moment.”
- Waarschuwingen gebaseerd op historisch gemiddelde, zoals '5xx-fouten op het 90e percentiel'.
Over het algemeen zijn typen 2 en 3 nuttiger voor dienstdoende SRE's, omdat ze tijdens het proces afwijkingen van de norm aan het licht brengen.
2. Veel waarschuwingen escaleren nooit tot incidenten.
SR-ingenieurs hebben te maken met een constante stroom waarschuwingen, waarvan er vele niet echt kritisch zijn.
Dus waarom zou u uw waarschuwingen niet beperken tot alleen de echt belangrijke waarschuwingen? Met deze aanpak herkent u echter mogelijk niet de eerste symptomen van wat zal uitgroeien tot een reëel probleem dat grote schade dreigt.
De taak van de SRE van wacht is om te bepalen welke waarschuwingen daadwerkelijk op iets ernstigs duiden en of deze moeten worden geëscaleerd en afgehandeld. Ik vermoed dat dit ook te wijten is aan de inflexibiliteit van waarschuwingen: het zou beter zijn als er meerdere niveaus of “slimme” manieren waren om waarschuwingen te configureren in overeenstemming met de hierboven beschreven situatie.
Functiesuggestie:
3. Onze dienstdoende SRE's gebruiken veel hulpmiddelen.
binnenlandse:
- GitLab infraproject: runbooks zijn hier live, ploegen-/weekopdrachten, incidentresponstaken.
- GitLab-problemen: onderzoeken, beoordelingen en onderhoud worden ook bijgehouden in problemen.
- GitLab-labels: Automatiseringstaken worden gestart met behulp van specifieke labels, die bots gebruiken om taakactiviteit bij te houden.
extern:
- PagerDuty: waarschuwingen
- Slack: de berichtenstroom van PagerDuty/AlertManager komt hierheen. Integratie met slash-opdrachten om verschillende taken uit te voeren, zoals het sluiten van een waarschuwing of het escaleren naar een incident.
- Grafana: visualisatie van statistieken met een focus op langetermijntrends.
- Kibana: Biedt visualisatie/zoekopdracht in logboeken, mogelijkheid om dieper in specifieke gebeurtenissen te graven.
- Zoom: Er is een constant actieve “breakout room” in Zoom. Hierdoor kunnen SRE-ingenieurs snel evenementen bespreken zonder kostbare tijd te verspillen aan het creëren van een ruimte en het koppelen van deelnemers.
En vele vele anderen.
4. Het monitoren van GitLab.com met GitLab is een enkel punt van falen
Als GitLab.com een grote servicestoring ervaart, willen we niet dat dit invloed heeft op ons vermogen om het probleem op te lossen. Het kan worden gestopt door een tweede GitLab-instantie te starten om GitLab.com te beheren. In feite werkt dit al voor ons: .
5. Een paar functies die je kunt overwegen om aan GitLab toe te voegen
- , vergelijkbaar met Google Documenten. Dit zou helpen bij taken over incidenten tijdens een evenement, maar ook bij taken over debriefing. In beide gevallen is het mogelijk dat meerdere deelnemers in realtime iets moeten toevoegen.
- Meer webhooks voor taken. De mogelijkheid om verschillende GitLab-workflowstappen van binnenuit uit te voeren, zal uw afhankelijkheid van Slack-integraties helpen verminderen. Bijvoorbeeld de mogelijkheid om een waarschuwing in PagerDuty toe te staan via een slash-opdracht in een GitLab-probleem.
Conclusie
SRE-ingenieurs hebben het moeilijk met veel complexiteit. Het zou geweldig zijn om te zien dat meer GitLab-producten deze problemen aanpakken. We werken al aan enkele toevoegingen aan het product die de hierboven genoemde workflows eenvoudiger zullen maken. Details beschikbaar op .
We breiden het team in 2020 uit om al deze geweldige functies samen te brengen. Bij interesse, kijk gerust eens en neem gerust contact op met iemand in ons team als u vragen heeft.
Bron: www.habr.com