SRE-Ingenieur â Praktikant
ZunĂ€chst erlauben Sie mir, mich vorzustellen. 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, die tĂ€gliche Ăberwachung zu beobachten, wie der Diensthabende auf VorfĂ€lle reagiert, und praktische Erfahrungen zu sammeln. Wir möchten, dass unsere Ingenieure die BedĂŒrfnisse der Nutzer besser verstehen Monitor::Health.
Ich sollte eine Woche lang dem SRE-Ingenieur ĂŒberallhin folgen. Das bedeutet, ich war bei der Ăbergabe des Dienstes anwesend, habe die gleichen AlarmkanĂ€le beobachtet und auf VorfĂ€lle reagiert, falls und wann sie auftraten.
VorfÀlle
In der Woche gab es 2 VorfÀlle.
1. Krypto-Mining
Am Mittwoch wurde auf GitLab.com ein Anstieg im Verbrauch festgestellt, der durch Versuche verursacht wurde, die Minuten des Runners zum Mining von KryptowĂ€hrungen zu nutzen. Der Vorfall wurde mit einem eigenen Tool zur Neutralisierung von VerstöĂen bearbeitet, das die Aufgaben des Runners stoppt und das zugehörige Projekt und Konto entfernt.
Wenn dieses Ereignis nicht bemerkt worden wÀre, hÀtte es ein automatisiertes Tool erkannt, aber in diesem Fall bemerkte der SRE-Ingenieur den Verstoà zuerst. Ein Vorfallticket wurde erstellt, jedoch sind die Informationen dazu vertraulich.
2. Leistungsverschlechterungen der Anwendungen Canary und Main
Der Vorfall wurde durch Verzögerungen und eine erhöhte Fehlerquote in den Canary- und Haupt-Webanwendungen auf Gitlab.com ausgelöst. Mehrere Apdex-Werte wurden ĂŒberschritten.
Offene Ticketnummer fĂŒr den Vorfall:
Wesentliche Erkenntnisse
Hier sind einige Punkte, die ich in meiner Woche im Dienst gelernt habe.
1. Alarme sind am hilfreichsten, wenn sie Abweichungen von der Norm erkennen.
Alarme lassen sich in mehrere Typen unterteilen:
- Alarme, die auf einem bestimmten Schwellenwert basieren, wie âes gab 10 5xx Fehler pro Sekundeâ.
- Alarme, bei denen der Schwellenwert ein Prozentsatz ist, wie âdie HĂ€ufigkeit der 5xx-Fehler liegt bei 10 % des gesamten Anfragevolumens in einem bestimmten Zeitraumâ.
- Alarme, die auf einem historischen Durchschnittswert basieren, wie â5xx Fehler im 90. Perzentilâ.
Im Allgemeinen sind der 2. und der 3. Typ hilfreicher fĂŒr anwesende SREs, da sie Abweichungen von der Norm wĂ€hrend des Prozesses aufdecken.
2. Viele Alarme eskalieren nicht zu VorfÀllen
SRE-Ingenieure haben es mit einem stÀndigen Fluss von Alarmen zu tun, von denen viele tatsÀchlich nicht kritisch sind.
Warum also nicht die Benachrichtigungen auf wirklich wichtige beschrĂ€nken? Mit einem solchen Ansatz könnten jedoch frĂŒhe Symptome nicht erkannt werden, die sich zu einem ernsthaften Problem entwickeln, das groĂen Schaden anrichten könnte.
Die Aufgabe des diensthabenden SRE besteht darin, zu ermitteln, welche Benachrichtigungen tatsĂ€chlich auf etwas Ernstes hinweisen und ob sie eskaliert und ĂŒberprĂŒft werden mĂŒssen. Ich vermute, das liegt auch an der UnflexibilitĂ€t der Benachrichtigungen: Es wĂ€re besser, wenn mehrere Ebenen oder "intelligente" Möglichkeiten zur Konfiguration von Benachrichtigungen entsprechend der beschriebenen Situation eingefĂŒhrt wĂŒrden.
Funktionsvorschlag:
3. Unsere diensthabenden SRE nutzen viele Werkzeuge
Intern:
- GitLab Infra-Projekt: Hier leben die Runbooks, die Ăbergaben der Schichten/Woche, Aufgaben zur Bearbeitung von VorfĂ€llen.
- GitLab-Issues: Ermittlungen, Analysen und Wartungsarbeiten werden ebenfalls in Aufgaben nachverfolgt.
- GitLab-Labels: Automatisierungsaufgaben werden anhand bestimmter Labels ausgelöst, die von Bots zur Ăberwachung der AktivitĂ€t der Aufgaben verfolgt werden.
Extern:
- PagerDuty: Benachrichtigungen
- Slack: Hier flieĂt der Nachrichtenstrom von PagerDuty/AlertManager. Integration mit Slash-Befehlen zur DurchfĂŒhrung verschiedener Aufgaben, wie z.B.: eine Benachrichtigung schlieĂen oder auf einen Vorfall eskalieren.
- Grafana: Visualisierung von Metriken mit Fokus auf langfristige Trends.
- Kibana: Bietet Visualisierung/Suche im Logbuch, Möglichkeit, bei bestimmten Ereignissen tiefer zu graben.
- Zoom: Es gibt einen stÀndig aktiven "Besprechungsraum" in Zoom. Dadurch können SRE-Ingenieure Ereignisse schnell besprechen, ohne wertvolle Zeit mit dem Erstellen eines Raumes und dem Versenden von Links an Teilnehmer zu verlieren.
Und vieles, vieles mehr.
4. Ăberwachung von GitLab.com mit GitLab â ein einzelner Ausfallpunkt
Wenn es bei GitLab.com zu einem umfassenden Ausfall von Diensten kommt, möchten wir nicht, dass dies unsere FÀhigkeit beeintrÀchtigt, das Problem zu lösen. Es könnte unterbunden werden, indem eine zweite Instanz von GitLab zur Steuerung von GitLab.com gestartet wird. TatsÀchlich funktioniert das bei uns bereits: .
5. Mehrere Funktionen, die in GitLab hinzugefĂŒgt werden sollten
- , Ă€hnlich wie bei Google Docs. Dies wĂŒrde bei Vorfallaufgaben wĂ€hrend eines Ereignisses sowie bei Analyseaufgaben helfen. In beiden FĂ€llen könnten mehrere Teilnehmer gleichzeitig in Echtzeit etwas hinzufĂŒgen mĂŒssen.
- Mehr Webhooks fĂŒr Aufgaben. Die Möglichkeit, verschiedene Schritte im GitLab-Arbeitsablauf intern auszufĂŒhren, wird die AbhĂ€ngigkeit von Slack-Integrationen verringern. Zum Beispiel die Möglichkeit, Benachrichtigungen in PagerDuty ĂŒber Slash-Befehle in einer GitLab-Aufgabe zu ermöglichen.
Fazit
SRE-Ingenieure haben es mit vielen Schwierigkeiten schwer. Es wĂ€re groĂartig, mehr GitLab-Produkte zur Lösung dieser Probleme zu sehen. Wir arbeiten bereits an einigen ErgĂ€nzungen, die die oben genannten ArbeitsablĂ€ufe erleichtern werden. Details sind verfĂŒgbar in .
Im Jahr 2020 erweitern wir das Team, um all diese groĂartigen Funktionen zu sammeln. Wenn Sie interessiert sind, werfen Sie bitte einen Blick auf , und zögern Sie nicht, sich mit jemandem aus unserem Team bei Fragen in Verbindung zu setzen.
Quelle: habr.com
