SRE Ingenieur - Intern
Zuerst möchte ich mich vorstellen. Ich bin @ tristan.read , ein Front-End- Ingenieur in der Monitor :: Health- Gruppe von GitLab. Letzte Woche war ich geehrt, ein Praktikant bei einem unserer diensthabenden SRE-Ingenieure zu sein. Ziel war es, täglich zu überwachen, wie der Mitarbeiter auf Vorfälle reagiert, und echte Arbeitserfahrung zu sammeln. Wir möchten, dass unsere Ingenieure die Bedürfnisse der Benutzer der Monitor :: Health- Funktionen besser verstehen.
Ich musste dem SRE-Ingenieur eine Woche lang überall folgen. Das heißt, ich habe an der Schicht teilgenommen, die gleichen Benachrichtigungskanäle gesehen und auf Vorfälle reagiert, wenn und wann sie stattfanden.
Vorfälle
In der Woche ereigneten sich 2 Vorfälle.
1. Cryptominer
Am Mittwoch hat GitLab.com einen Anstieg bei der Verwendung von GitLab Runner verzeichnet , der durch Versuche verursacht wurde, Runner-Minuten zur Ermittlung der Kryptowährung zu verwenden. Wir haben den Vorfall mit unserem eigenen Tool behoben, um Verstöße zu neutralisieren. Dadurch werden die Aufgaben des Läufers gestoppt und das damit verbundene Projekt und Konto gelöscht.
Wenn dieses Ereignis nicht bemerkt worden wäre, hätte es ein automatisiertes Tool abgefangen, aber in diesem Fall war der SRE-Ingenieur der erste, der den Verstoß bemerkte. Es wurde eine Vorfallaufgabe erstellt, die Informationen dazu wurden jedoch geschlossen.
2. Leistungseinbußen bei Kanarischen und Hauptanwendungen
Auslöser des Vorfalls waren Verlangsamungen und eine erhöhte Fehlerquote in Kanarischen und Hauptwebanwendungen auf Gitlab.com. Mehrere Apdex-Werte wurden verletzt.
Öffnen Sie die Vorfallaufgabe: https://gitlab.com/gitlab-com/gl-infra/production/issues/1442
Schlüsselergebnisse
Hier sind ein paar Punkte, die ich während der Dienstwoche gelernt habe.
1. Warnungen sind am nützlichsten, wenn Anomalien festgestellt werden.
Alerts können in verschiedene Typen unterteilt werden:
- Es sind Warnungen aufgetreten, die auf einem bestimmten Schwellenwert basieren, z. B. "10 5xx Fehler pro Sekunde".
- Warnungen, bei denen der Schwellenwert ein Prozentwert vom Typ "Häufigkeit von 5xx Fehlern pro 10% des Gesamtvolumens der Anforderungen zu einem bestimmten Zeitpunkt" ist.
- Warnungen basieren auf dem historischen Durchschnitt des Typs "5xx Fehler im 90. Perzentil".
Im Allgemeinen sind der 2. und der 3. Typ für SREs mit Dienstzeit nützlicher, da sie Abweichungen von der Norm im Prozess aufdecken.
2. Viele Warnungen eskalieren nie zu Vorfällen
Die Ingenieure von SR haben es mit einer ständigen Reihe von Warnungen zu tun, von denen viele nicht wirklich kritisch sind.
Warum also nicht die Warnungen auf wirklich wichtige beschränken? Mit einem solchen Ansatz kann man jedoch die frühen Symptome dessen nicht erkennen, was wie ein Schneeball zu einem echten Problem werden wird, das großen Schaden droht.
Die Pflicht des diensthabenden SRE besteht darin, festzustellen, welche Warnungen wirklich von etwas Ernsthaftem sprechen und ob sie eskaliert werden müssen und zu verstehen beginnen. Ich vermute, dies liegt auch an der Unflexibilität von Warnungen: Es wäre besser, wenn mehrere Ebenen oder „intelligente“ Methoden zum Setzen von Warnungen entsprechend der oben beschriebenen Situation eingeführt würden.
Funktionsvorschlag: https://gitlab.com/gitlab-org/gitlab/issues/42633
3. Unsere SRE-Mitarbeiter verwenden viele Tools.
Intern:
- GitLab Infra-Projekt: Runbooks leben hier, Schichtwechsel / Woche, Incident-Response-Aufgaben.
- GitLab-Probleme: Untersuchung, Analyse und Wartung werden auch in Tasks nachverfolgt.
- GitLab-Labels: Automatisierungsaufgaben werden anhand bestimmter Labels gestartet, anhand derer Bots die Aktivität von Aufgaben verfolgen.
Extern:
- PagerDuty: Warnungen
- Slack: PagerDuty / AlertManager-Nachrichtenfluss wird hier ausgeführt. Integration mit Slash-Befehlen, um eine Vielzahl von Aufgaben auszuführen, z. B. das Schließen einer Warnung oder das Eskalieren zu einem Vorfall.
- Grafana: Visualisierung von Metriken mit Fokus auf Langzeittrends.
- Kibana: gibt eine Visualisierung / Suche in der Zeitschrift, die Fähigkeit, bei bestimmten Ereignissen tiefer zu graben.
- Zoom: In Zoom gibt es einen ständig funktionierenden „Diskussionsraum“. Auf diese Weise können SRE-Ingenieure Ereignisse schnell diskutieren, ohne wertvolle Zeit damit zu verschwenden, Platz und Links für die Teilnehmer zu schaffen.
Und vieles mehr.
Wenn auf GitLab.com ein größerer Serviceausfall auftritt, soll dies nicht dazu führen, dass wir das Problem beheben können. Sie können den Vorgang beenden, indem Sie die zweite GitLab-Instanz ausführen, um GitLab.com zu installieren. Tatsächlich funktioniert das bei uns bereits: https://ops.gitlab.net/ .
5. Einige Funktionen, die beim Hinzufügen zu GitLab berücksichtigt werden müssen
- Bearbeitung von Aufgaben für mehrere Benutzer ähnlich wie in Google Text & Tabellen. Dies würde sowohl bei Incident-Aufgaben während des Ereignisses als auch beim Analysieren von Aufgaben helfen. In beiden Fällen müssen möglicherweise mehrere Teilnehmer etwas in Echtzeit hinzufügen.
- Weitere Webhooks für Aufgaben. Die Möglichkeit, verschiedene Schritte des GitLab-Workflows von innen auszuführen, verringert die Abhängigkeit von Slack-Integrationen. Zum Beispiel die Möglichkeit, die Benachrichtigung in PagerDuty über einen Schrägstrich-Befehl in der GitLab-Task zu aktivieren.
Fazit
SRE-Ingenieure haben es schwer mit vielen Schwierigkeiten. Es wäre großartig, mehr GitLab-Produkte bei der Lösung dieser Probleme zu sehen. Wir arbeiten bereits an einigen Produkterweiterungen, die die oben genannten Arbeitsabläufe erleichtern. Details finden Sie im Abschnitt zu Ops Product Vision .
2020 erweitern wir das Team, um all diese großartigen Funktionen zusammenzustellen. Bei Interesse lesen Sie bitte die Stellenangebote und zögern Sie nicht, sich bei Fragen an jemanden aus unserem Team zu wenden.