SRE-Ingenieur — Praktikant
Zunächst lassen Sie mich vorstellen. Ich bin , Frontend-Ingenieur in der Gruppe von GitLab. In der vergangenen Woche hatte ich die Ehre, Praktikant bei einem unserer diensthabenden SRE-Ingenieure zu sein. Ziel war es, täglich zu beobachten, wie der Diensthabende auf Vorfälle reagiert, und praktische Erfahrungen zu sammeln. Wir möchten, dass unsere Ingenieure die Bedürfnisse der Benutzer besser verstehen Monitor::Health.
Ich sollte eine Woche lang dem SRE-Ingenieur überall hin folgen. Das heißt, ich war bei der Übergabe des Schichtdienstes anwesend, beobachtete die gleichen Alarmkanäle und reagierte auf Vorfälle, wenn und wann sie auftraten.
Vorfälle
In der Woche gab es 2 Vorfälle.
1. Krypto-Miner
Am Mittwoch wurde auf GitLab.com ein Anstieg der Nutzung festgestellt des ‘a, verursacht durch Versuche, die Runner-Minuten für das Mining von Kryptowährungen zu verwenden. Der Vorfall wurde mit unserem eigenen Tool zur Neutralisierung von Störungen bearbeitet, das die Runner-Aufgaben stoppt und das zugehörige Projekt sowie das Konto entfernt.
Wenn dieses Ereignis nicht bemerkt worden wäre, hätte es ein automatisiertes Tool aufgefangen, aber in diesem Fall hat der SRE-Ingenieur die Anomalie zuerst festgestellt. Eine Incident-Aufgabe wurde erstellt, jedoch sind die Informationen dazu vertraulich.
2. Leistungseinbußen der Canary- und Main-Anwendungen
Der Vorfall wurde durch Verzögerungen und eine erhöhte Fehlerhäufigkeit in den Canary- und Main-Webanwendungen auf Gitlab.com ausgelöst. Es wurden mehrere Apdex-Werte überschritten.
Offene Incident-Aufgabe:
Wichtige Erkenntnisse
Hier sind einige Punkte, die ich während meiner einwöchigen Schicht festgestellt habe.
1. Benachrichtigungen sind am nützlichsten, wenn sie Abweichungen von der Norm erfassen.
Benachrichtigungen können in mehrere Typen unterteilt werden:
- Schwellenwertbasierte Benachrichtigungen, wie «10 5xx-Fehler pro Sekunde aufgetreten».
- Prozentsatzbasierte Benachrichtigungen, wie «Die Häufigkeit von 5xx-Fehlern liegt bei 10 % des Gesamtvolumens an Anfragen in einem festgelegten Zeitraum».
- Historisch durchschnittliche basierte Benachrichtigungen, wie «5xx-Fehler im 90. Perzentil».
Im Allgemeinen sind die 2. und 3. Typen hilfreicher für die diensthabenden SRE, da sie Abweichungen von der Norm im Prozess aufdecken.
2. Viele Benachrichtigungen eskalieren nicht zu Vorfällen.
SR-Ingenieure haben es mit einem ständigen Strom von Benachrichtigungen zu tun, von denen viele eigentlich nicht kritisch sind.
Warum nicht die Benachrichtigungen auf wirklich wichtige beschränken? Mit solch einem Ansatz könnte man jedoch frühe Anzeichen übersehen, die sich zu einem ernsthaften Problem auswachsen könnten, das großen Schaden anrichten könnte.
Die Aufgabe des diensthabenden SRE besteht darin zu bestimmen, welche Benachrichtigungen tatsächlich auf etwas Ernsthaftes hinweisen und ob sie eskaliert und weiterverfolgt werden sollten. Ich vermute, das liegt auch an der Unflexibilität der Benachrichtigungen: Es wäre besser, wenn mehrere Stufen oder "intelligente" Möglichkeiten zur Anpassung der Benachrichtigungen entsprechend der oben beschriebenen Situation eingeführt werden würden.
Funktionsvorschlag:
3. Unsere diensthabenden SREs nutzen viele Werkzeuge.
Intern:
- GitLab Infra-Projekt: Hier leben Runbooks, Übergaben für Schichten/Wochen, Aufgaben zur Reaktion auf Vorfälle.
- GitLab-Issues: Untersuchungen, Auswertungen und Wartungen werden ebenfalls in Aufgaben verfolgt.
- GitLab-Labels: Automatisierungsaufgaben werden durch bestimmte Tags ausgelöst, die von Bots überwacht werden, um die Aktivität der Aufgaben nachzuvollziehen.
Extern:
- PagerDuty: Benachrichtigungen
- Slack: Hier fließt der Nachrichtenton von PagerDuty/AlertManager. Integration mit Slash-Befehlen zur Ausführung verschiedener Aufgaben wie: Benachrichtigung schließen oder an einen Vorfall eskalieren.
- Grafana: Visualisierung von Metriken mit Fokus auf langfristige Trends.
- Kibana: bietet Visualisierung / Suche in Protokollen, mit der Möglichkeit, bestimmte Ereignisse tiefergehender zu untersuchen.
- Zoom: Es gibt einen ständig laufenden 'Besprechungsraum' in Zoom. Dies ermöglicht es SRE-Ingenieuren, Ereignisse schnell zu besprechen, ohne wertvolle Zeit mit der Einrichtung eines Raums und dem Versenden von Links an Teilnehmer zu verlieren.
Und vieles, vieles mehr.
4. Überwachung von GitLab.com mit GitLab — das ist der einzige Ausfallpunkt.
Wenn es auf GitLab.com zu einem größeren Dienstausfall kommt, möchten wir nicht, dass dies unsere Fähigkeit zur Problemlösung beeinträchtigt. Das Problem kann eingedämmt werden, indem eine zweite Instanz von GitLab gestartet wird, um GitLab.com zu verwalten. Tatsächlich läuft dies bereits bei uns: .
5. Einige Funktionen, die in GitLab hinzugefügt werden sollten
- , ähnlich wie Google Docs. Dies würde bei Incident-Management-Aufgaben während eines Events und bei Nachbesprechungen helfen. In beiden Fällen könnten mehrere Teilnehmer in Echtzeit etwas hinzufügen müssen.
- Mehr Webhooks für Aufgaben. Die Möglichkeit, verschiedene Schritte von GitLab-Workflows intern auszuführen, würde die Abhängigkeit von Slack-Integrationen verringern. Beispielsweise die Möglichkeit, Benachrichtigungen in PagerDuty über einen Slash-Befehl in einer GitLab-Aufgabe zu aktivieren.
Fazit
SRE-Ingenieure haben es mit zahlreichen Herausforderungen zu tun. Es wäre großartig, mehr GitLab-Produkte zur Lösung dieser Probleme zu sehen. Wir arbeiten bereits an einigen Ergänzungen zum Produkt, die die oben genannten Arbeitsabläufe erleichtern werden. Details sind im .
Im Jahr 2020 erweitern wir das Team, um all diese großartigen Funktionen zu entwickeln. Wenn Sie interessiert sind, schauen Sie sich bitte die , und zögern Sie nicht, sich mit jemandem aus unserem Team bei Fragen in Verbindung zu setzen.
Quelle: habr.com
