SRE-Ingenieur - Auszubildender
Lassen Sie mich mich zunächst vorstellen. ICH - , Front-End-Ingenieur in der Gruppe GitLab. Letzte Woche hatte ich das Privileg, ein Praktikum bei einem unserer diensthabenden SRE-Ingenieure zu absolvieren. Ziel war es, täglich zu beobachten, wie der diensthabende Beamte auf Vorfälle reagiert, und echte Berufserfahrung zu sammeln. Wir möchten, dass unsere Ingenieure die Bedürfnisse der Benutzer besser verstehen Überwachen::Gesundheit.
Ich musste dem SRE eine Woche lang folgen. Das heißt, ich war bei der Dienstübergabe anwesend, habe die gleichen Alarmierungskanäle beobachtet und auf Vorfälle reagiert, sofern und wann sie auftraten.
Vorfälle
Es gab 2 Vorfälle in einer Woche.
1. Kryptominer
GitLab.com verzeichnete am Mittwoch einen Anstieg der Nutzung 'a, verursacht durch Versuche, Läuferminuten für das Kryptowährungs-Mining zu nutzen. Der Vorfall wurde mithilfe eines benutzerdefinierten Schadensbegrenzungstools behoben, das die Aufgaben des Läufers stoppt und das damit verbundene Projekt und Konto löscht.
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. Es wurde eine Vorfallaufgabe erstellt, die Informationen dazu sind jedoch geschlossen.
2. Leistungseinbußen bei Canary- und Main-Anwendungen
Der Vorfall wurde durch Verlangsamungen und erhöhte Fehlerraten in den Canary- und Hauptwebanwendungen auf Gitlab.com angeheizt. Mehrere Apdex-Werte wurden verletzt.
Offene Aufgabe nach Vorfall:
Wichtigste Erkenntnisse
Hier sind ein paar Punkte, die ich während der Dienstwoche gelernt habe.
1. Warnungen sind am nützlichsten, wenn Abweichungen von der Norm erkannt werden.
Benachrichtigungen können in verschiedene Typen unterteilt werden:
- Warnungen basierend auf einem bestimmten Schwellenwert, z. B. „Pro Sekunde sind 10 5xx-Fehler aufgetreten.“
- Warnungen, bei denen der Schwellenwert ein prozentualer Wert ist, z. B. „5xx Fehlerrate pro 10 % aller Anfragen zu einem bestimmten Zeitpunkt“.
- Warnungen basierend auf einem historischen Durchschnitt wie „5xx Fehler im 90. Perzentil“.
Im Allgemeinen sind die Typen 2 und 3 für SREs im Dienst nützlicher, da sie Auffälligkeiten im Prozess aufdecken.
2. Viele Warnungen eskalieren nie zu Vorfällen
SR-Ingenieure haben es mit einem ständigen Strom von Alarmen zu tun, von denen viele nicht wirklich kritisch sind.
Warum also nicht die Warnungen auf die wirklich wichtigen beschränken? Mit diesem Ansatz können jedoch frühe Symptome dessen, was sich zu einem echten Problem entwickeln wird, das mit großen Schäden droht, übersehen werden.
Die Aufgabe des diensthabenden SRE besteht darin, festzustellen, welche Alarmmeldungen wirklich eine ernste Bedeutung haben und ob sie eskaliert und mit der Behebung begonnen werden müssen. Ich vermute, dass dies auch an der Inflexibilität der Warnungen liegt: Es wäre besser, wenn sie mehrere Ebenen oder „intelligente“ Möglichkeiten einführen würden, um Warnungen entsprechend der oben beschriebenen Situation anzupassen.
Funktionsvorschlag:
3. Unsere SREs verwenden viele Tools
Intern:
- GitLab-Infraprojekt: Runbooks live hier, Schicht-/Wochenübergaben, Aufgaben zur Reaktion auf Vorfälle.
- GitLab-Probleme: Untersuchung, Nachbesprechung und Wartung werden ebenfalls in Problemen verfolgt.
- GitLab-Labels: Automatisierungsaufgaben werden durch bestimmte Labels ausgelöst, die Bots verwenden, um die Aufgabenaktivität zu verfolgen.
Extern:
- PagerDuty-Benachrichtigungen
- Slack: Hier geht der PagerDuty/AlertManager-Nachrichtenfluss hin. Integration mit Slash-Befehlen zur Ausführung verschiedener Aufgaben, z. B. Schließen einer Warnung oder Eskalieren zu einem Vorfall.
- Grafana: Visualisierung von Kennzahlen mit Fokus auf langfristige Trends.
- Kibana: Bietet Visualisierung/Protokollsuche und die Möglichkeit, tiefer in bestimmte Ereignisse einzutauchen.
- Zoom: In Zoom gibt es einen permanenten „Breakout-Raum“. Dies ermöglicht es SREs, Ereignisse schnell zu besprechen, ohne wertvolle Zeit mit der Einrichtung eines Raums und der Verknüpfung von Mitgliedern zu verschwenden.
Und vieles mehr.
4. Die Überwachung von GitLab.com mit GitLab ist ein Single Point of Failure
Wenn bei GitLab.com ein größerer Dienstausfall auftritt, möchten wir nicht, dass dies unsere Fähigkeit zur Behebung des Problems beeinträchtigt. Es kann gestoppt werden, indem eine zweite GitLab-Instanz ausgeführt wird, um GitLab.com zu verwalten. Tatsächlich funktioniert das bei uns bereits: .
5. Einige Funktionen, die Sie als Ergänzung zu GitLab in Betracht ziehen sollten
- , ähnlich wie Google Docs. Dies würde bei Vorfallaufgaben während der Veranstaltung sowie bei Nachbesprechungsaufgaben hilfreich sein. In beiden Fällen müssen möglicherweise mehrere Teilnehmer gleichzeitig etwas in Echtzeit hinzufügen.
- Weitere Webhooks für Aufgaben. Die Möglichkeit, verschiedene GitLab-Workflow-Schritte von innen auszuführen, trägt dazu bei, Ihre Abhängigkeit von Slack-Integrationen zu verringern. Zum Beispiel die Möglichkeit, eine Warnung in PagerDuty über einen Slash-Befehl in einem GitLab-Problem zu aktivieren.
Abschluss
SRE-Ingenieure haben es mit vielen Komplexitäten schwer. Es wäre großartig, wenn mehr GitLab-Produkte diese Probleme lösen würden. Wir arbeiten bereits an einigen Ergänzungen des Produkts, die die oben genannten Arbeitsabläufe erleichtern. Teile sind erhältlich in .
Im Jahr 2020 erweitern wir das Team, um all diese großartigen Funktionen zu vereinen. Bei Interesse schauen Sie bitte vorbei , und bei Fragen können Sie sich jederzeit an jemanden aus unserem Team wenden.
Source: habr.com