Am 21. Mai beginnt in Slurme ein SRE-Intensivkurs. Drei volle Tage lang werden die Teilnehmer in die Theorie und Praxis der Unterstützung von Hochlastdiensten eintauchen. Keine Arbeitsaufgaben, keine Familienangelegenheiten - nur studieren. Unter dem Schnitt sagen wir Ihnen, was Sie erwartet, wenn Sie sich für einen Beitritt entscheiden.
SRE-Hilfe
Site Reliability Engineering (SRE) - Gewährleistung der Zuverlässigkeit von Informationssystemen. Dies ist ein neuer Ansatz zur Unterstützung von Websites, Diensten und Anwendungen mit Tausenden und Millionen von Benutzern. Der Ansatz stammt von Google und verbreitet sich mittlerweile auf der ganzen Welt. In Russland wurde SRE in Yandex, Mail.ru, Sberbank, Tinkoff, MTS, Megafon und anderen Unternehmen implementiert.
Erfahrene Entwickler und Systemadministratoren werden zu SRE-Ingenieuren: Vertiefte Kenntnisse der Server-Betriebssysteme, des Netzwerkbetriebs, der Überwachungstools sowie der Programmierkenntnisse sind wichtig. All diese harten Fähigkeiten werden der SRE-Methodik überlagert - spezifischen Praktiken, die dazu beitragen, eine hohe Zuverlässigkeit sicherzustellen.
„Bei SRE geht es nicht so sehr um Warnungen und Postmortems. Hier geht es um die Tatsache, dass der Code, der nachts untergräbt, die Produktion nicht erreicht. "
Aus der Kommunikation mit Ingenieuren, die SRE implementiert haben
Die Hauptquelle des Wissens über SRE war lange Zeit das gleichnamige Buch von Google. Jetzt gibt es mehrere Englisch- und Russisch-Sprachprogramme. Eines davon ist das SRE-Intensiv in Slurme.
Intensives Format
Der Intensivkurs findet online statt und besteht aus Vorlesungen und praktischen Übungen. Es wird eine Sendung im Zoom- und Telegramm-Chat mit Sprechern geben.
Zwei Arten von Übungen. Es gibt zwei Arten von praktischen Übungen: Anpassung anhand von Beispielen und Arbeiten an Aufgaben, deren Lösung nicht vorbestimmt ist. Auf dem Intensivkurs werden sie Fälle genannt .
Teamwork für einen echten Service. Um an den Fällen zu arbeiten, werden die Teilnehmer des Intensivkurses in Teams von 5-8 Personen zusammengefasst. Jedes Team erhält einen Stand mit einer Bewerbung - mehrere VDS, auf denen eine Website zur Bestellung von Tickets eingerichtet ist .
Ein Service zur Bestellung von Tickets, dessen stabiler Betrieb von den Teilnehmern der Intensive Failure Simulation sichergestellt wird
.Während des Intensivkurses treten bei der Arbeit des Standorts mehrere schwerwiegende Fehler auf. Die Aufgabe des Teams besteht darin, die Ursache zu finden, deren Wiederholung zu beseitigen und zu verhindern. Die Fälle basieren auf realen Erfahrungen: Die Referenten sammelten die Probleme, mit denen sie während ihrer SRE-Praxis konfrontiert waren, und schufen eine Umgebung, um diese Probleme zu simulieren.
Erfahrene Referenten. Das Intensivprogramm wurde entwickelt und wird durchgeführt von:
- Ivan Kruglov, Staff Software Engineer bei Databricks.
- Artyom Artemiev, Lead SRE bei TangoMe.
- Pavel Selivanov, Senior DevOps Engineer bei Mail.ru Cloud Solutions.
Unterstützung. Kuratoren werden helfen, sich in Teams zusammenzuschließen und gemeinsame Arbeit zu organisieren. Referenten und Ingenieure des technischen Supports von Slurm unterstützen Sie bei der Lösung komplexer Probleme.
Remote-Format. Die Vorträge werden in Zoom ausgestrahlt, die Diskussion der Aufgaben findet in Slack statt. Alle Notizen der Vorlesungen bleiben erhalten und stehen nach dem Intensivkurs zur Verfügung. Es ist nützlich, nach einer Weile bereits in einer ruhigeren Atmosphäre zu ihnen zurückzukehren.
Drei Tage volles Eintauchen. Das Intensivprogramm ist für drei volle Tage von 10:00 bis 18:00 Uhr Moskauer Zeit ausgelegt. Zwischen den Vorträgen und dem Mittagessen gibt es kurze Pausen.
Beginnen Sie am 21. Mai. Es ist noch Platz.
Erfahren Sie mehr und registrieren Sie sich
Nachfolgend finden Sie das vollständige Intensivprogramm.
Tag 1: Kennenlernen der SRE-Theorie, Einrichten von Überwachung und Alarmierung
Am ersten Tag lernen Sie die Theorie von SRE kennen, lernen, wie Sie Überwachung und Alarmierung einrichten, und arbeiten mit anderen Teilnehmern des Intensivkurses zusammen.
Lassen Sie uns über die Metriken SLO, SLI, SLA und deren Beziehung zu den Geschäftsanforderungen sprechen. Wir werden die Best Practices für die Einrichtung von Überwachungs- und Regeln für die Feuerwehr teilen. Wir werden die ersten praktischen Fälle geben.
Thema 1: Überwachung
- Warum brauchen Sie eine Überwachung?
- Symptome vs Ursachen,
- Black-Box vs. White-Box-Überwachung,
- Goldene Signale,
- Perzentile,
- Alarmierend,
- Beobachtbarkeit.
Übung: Erstellen eines einfachen Dashboards und Einrichten der erforderlichen Warnungen.
Thema 2: SRE-Theorie
- SLO, SLI, SLA,
- Haltbarkeit,
- Fehlerbudget.
Übung: Hinzufügen von SLO / SLI + -Warnungen zum Dashboard.
Übung: Erste Belastung des Systems.
Fall 1: Downstream-Sucht. In einem großen System gibt es viele voneinander abhängige Dienste, und sie funktionieren nicht immer gleich gut. Es ist besonders anstößig, wenn Ihr Dienst in Ordnung ist und der benachbarte, von dem Sie abhängig sind, regelmäßig ausfällt. Das Schulungsprojekt wird sich unter solchen Bedingungen befinden, und Sie werden es so gestalten, dass es immer noch die Qualität auf höchstem Niveau liefert.
Thema 3: Incident Management
- Resilience Engineering,
- Wie sich die Feuerwehr aufstellt
- Wie effektiv ist Ihr Team bei dem Vorfall?
- 7 Regeln für einen Vorfallführer,
- 5 Regeln für einen Feuerwehrmann,
- HiPPO - Meinung der bestbezahlten Person. Kommunikationsleiter.
Fall 2: Upstream-Sucht. Es ist eine Sache, wenn Sie auf einen Service mit einem niedrigen SLO angewiesen sind. Es ist eine andere Sache, wenn Ihr Service für andere Teile des Systems so ist. Dies geschieht, wenn die Bewertungskriterien nicht vereinbart sind: Sie antworten beispielsweise innerhalb einer Sekunde auf eine Anfrage und betrachten sie als erfolgreich, aber der abhängige Dienst wartet nur 500 Moskau-Zeiten und geht mit einem Fehler. In diesem Fall werden wir die Bedeutung der Metrikabstimmung diskutieren und lernen, die Qualität mit den Augen des Kunden zu betrachten.
Thema 4: SRE-Onboarding eines Projekts
In großen Unternehmen ist es nicht ungewöhnlich, ein separates SRE-Team zu bilden, das die Unterstützung von Diensten anderer Abteilungen übernimmt. Aber nicht jeder Dienst ist bereit, unterstützt zu werden. Wir werden Ihnen sagen, welche Anforderungen es erfüllen muss.
Tag 2: Probleme mit der Umwelt und der Architektur lösen
Der zweite Tag dreht sich fast ausschließlich um die Lösung von zwei Fällen: Probleme mit der Umwelt (es wird eine detaillierte Analyse der Gesundheitsprüfung geben) und Probleme mit der Architektur. Die Referenten werden über die Arbeit mit Obduktionen sprechen und Vorlagen bereitstellen, die Sie in Ihrem Team verwenden können.
Thema 5: Gesundheitsprüfung
- Gesundheitscheck in Kubernetes,
- Lebt unser Service?
- Exec Sonden,
- initialDelaySeconds,
- Sekundärer Gesundheitshafen,
- Sidecar Health Server,
- Kopflose Sonde,
- Hardware-Sonde.
Fall 3: Umweltprobleme und der richtige Gesundheitscheck. Die Aufgabe von Healthcheck besteht darin, einen Ausfallzeitdienst zu erkennen und den Datenverkehr zu blockieren, damit Benutzer kein Problem haben. Und wenn Sie der Meinung sind, dass es ausreicht, eine Anfrage an den Dienst zu senden und eine Antwort zu erhalten, irren Sie sich: Selbst wenn der Dienst antwortet, garantiert dies nicht seine Leistung - es kann Probleme in der Umgebung geben. In diesem Fall lernen Sie, wie Sie den richtigen Healthcheck konfigurieren und den Datenverkehr nicht dort ablegen, wo er nicht verarbeitet werden kann.
Thema 6: Praxis der Arbeit mit Postmortems - Wir schreiben ein Postmortem basierend auf dem vorherigen Fall und analysieren es mit den Sprechern.
Thema 7: Lösen von Infrastrukturproblemen
- Überwachung von MySQL,
- SLO / SLI für MySQL,
- Anomalieerkennung.
Fall 4: Probleme mit der Datenbank. Die Datenbank kann auch zu Problemen führen. Wenn Sie beispielsweise das Replikationsrelais nicht überwachen, ist das Replikat veraltet und die Anwendung gibt alte Daten zurück. Darüber hinaus ist es besonders schwierig, solche Fälle zu debuggen: Jetzt sind die Daten inkonsistent, aber nach einigen Sekunden sind sie verschwunden, und die Ursache des Problems ist nicht klar. In diesem Fall werden Sie den Schmerz des Debuggens spüren und lernen, wie Sie solche Probleme verhindern können.
Tag 3: Verkehrsabschirmung und kanarische Freisetzung
Es gibt zwei Fälle über die hohe Verfügbarkeit der Produktion: Verkehrsabschirmung und kanarische Bereitstellung. Sie lernen diese Ansätze kennen und lernen, wie man sie anwendet. Wir planen kein Hardcore-Tuning von Hand, obwohl wer weiß.
Thema 8: Verkehrsabschirmung
- Verhalten von Wachstumsgraphen in Bezug auf die Anzahl der Anfragen und Geschäftsvorgänge
- Sättigungs- und Kapazitätsplanung
- traffic shielding rate limiting
- sidecar rate-limiting 100
5: traffic shielding. ? , 100 , 1000. , , , . , .
9: Canary Deployment
- k8s (Rolling Update vs Recreate),
- canary blue-green ,
- blue-gree/canary release k8s,
- canary release GitLab CI/CD,
- canary release,
- .gitlab-ci.yml.
6: . ,
, - . , . Canary Deployment, .