Denken Sie an SRE: Betrachten Sie Projekte mit den Augen eines SRE-Ingenieurs

In den Kritiken von Slurm klang Kubernetes wie folgt: "Kubernetes erwies sich als einfacher als ich dachte." Jetzt klingt es nicht mehr, der Mythos von der Komplexität der K8s ist nicht mehr. Er wechselte in die Kategorie der Werkzeuge, die leicht zu erlernen und schwer zu beherrschen sind.

Wir wollen dasselbe mit SRE wiederholen. Zeigen Sie, dass SRE einfacher und verständlicher ist, als es sich anhört. Wechseln Sie das Paradigma: Lassen Sie die Leute das Projekt mit den Augen eines SRE-Ingenieurs sehen.

Wie immer am Anfang gibt es viele Unbekannte in der Gleichung. Und wie immer am Start geht das Interessanteste zuerst.

Vom 3. bis 5. Februar werden wir den Slurm SRE in Moskau ausrichten. Ein dreitägiges Intensivticket kostet 60.000. Was bekommt der Teilnehmer für sein Geld?

Wenn ich Freunden und Kollegen von SRE erzähle, stoße ich auf gesunde Skepsis:

• Zum ersten Mal höre ich von SRE, es ist eine Art Alchemie.
• Die Implementierung von SRE ist für Giganten wie Google schwierig.
• Es ist teuer und lang, sie werden keine Zeit geben, sie werden kein Budget zuweisen.
• Was Sie beschreiben, ist zu schön, um wahr zu sein.

Ich möchte diese Fragen ausmachen.

Es ist Zeit herauszufinden, was SRE ist.

Auf der Slogan-Ebene: SRE ist eine der Implementierungen von DevOps. Es erschien vor über 10 Jahren bei Google, hat sich aber erst vor kurzem auf dem „regulären“ Markt durchgesetzt, vor allem dank des Buches Site Reliability Engeneering, das 2016 von Google veröffentlicht wurde.

Die Verbindung zwischen SRE und DevOps ist in diesem Video gut beschrieben:

Das Schlimme ist, dass es in Slogans um nichts geht. Na ja, DevOps, na ja, Implementierung, die nächste "für alles Gute gegen alles Schlechte".

Sie können das Buch lesen (und es lohnt sich). Aber der Leser wird sich in der Position einer Person wiederfinden, die Karate anhand von Zeichnungen studiert. Das Buch beschreibt das Konzept ohne Anwendung auf die Realität. Der Lehrer führt die Hand auf einem bestimmten Weg und macht auf Fehler im Prozess aufmerksam.

Der Preis beinhaltet eine schnelle und gründliche Überprüfung des SRE-Ansatzes und der Werkzeuge.

Die Implementierung von SRE ist einfacher als es sich anhört

Auf Slurm werden wir SRE mit unseren Händen berühren: Wir werden Metriken auswählen, deren Messung konfigurieren, Warnungen ausgeben, Vorfälle erkennen, lösen und analysieren und das Projekt gemäß allen SRE-Kanonen neu erstellen.

Das heißt, wir geben schrittweise Anweisungen, die Sie nach der Rückkehr von Intensive selbst ausführen können.

Ich lüge In der Tat werden wir keine Anweisungen geben, sondern ein Beispiel, aus dem Sie eine Reihe von Ideen und Lösungen ziehen können.

Der Preis beinhaltet ein Muster für die Implementierung.

Das Hauptproblem ist, dass man diejenigen überzeugen muss, die nicht in Slurm waren. Daher lohnt es sich im Idealfall, sich als ganzes Team intensiv zu engagieren. Aus diesem Grund gewähren wir Gruppen große Rabatte.

Es wäre schön, von der Tankstelle geführt nach Slerm zu kommen. Und CEO ist auch nützlich, und über diesen Abschnitt ...

... wie Sie das Top-Management davon überzeugen können, dass SRE nützlich und notwendig ist.

In der Regel gibt es einen Aufgabenkonflikt zwischen CEO (Top-Management), STO (IT-Management), Entwicklern und Betrieb.

Ich sage absichtlich nicht "Interessenkonflikt", es ist genau ein Konflikt von Aufgaben.

CEO braucht finanzielle Leistung. STO - eine verständliche, überschaubare und möglichst komfortable Situation. Das heißt, verständliche Aufgaben mit verständlichem Geschäftswert, Einhaltung von Fristen, ein normaler Stapel, mehr Funktionen und weniger Fakaps. Entwickler müssen mehr Funktionen und Ausnutzung bereitstellen, um die Barrierefreiheit sicherzustellen (was eindeutig im Widerspruch zu "mehr Funktionen" steht).

SRE sagt, dass alle Teilnehmer an dem Prozess eine einzige Aufgabe haben: das Glück des Benutzers. Der Benutzer ist zufrieden mit einem ausgewogenen Verhältnis zwischen neuen Funktionen und der Zuverlässigkeit des Dienstes. Zufriedene User zahlen mehr Geld. Um das Benutzerglück zu verwalten, benötigen Sie spezielle Tools.

Darüber hinaus können Sie mit SRE, das auf Metriken basiert, Finanzindikatoren in Zielindikatoren verschiedener Metriken und diese wiederum in Aufgaben von DevOps-Teams übersetzen.

Ermöglicht Ihnen das Übersetzen - ich habe übertrieben. Durch das Vorhandensein dieser Metriken können Sie die Beziehung zwischen dem Status der Metriken und den Finanzindikatoren ermitteln. Dies ist eine separate große, aber verständliche Aufgabe.

Es gibt ein Projekt DORA, DevOps Research & Assessments , das jährliche Studien zum Unternehmenswert und zum ROI von DevOps und seiner Unterklasse SRE veröffentlicht. Wir übersetzen jetzt den aktuellen Bericht ins Russische. Es gibt Bewertungsformeln, die mit einer gewissen Genauigkeit auf Ihr Unternehmen angewendet werden können.

Zusammenfassung: SRE gibt Unternehmen die Möglichkeit, die finanzielle Leistung durch die Festlegung von Metrikzielen zu verwalten. Das DevOps-Team erkennt anhand der aktuellen Metriken eindeutig, was getan werden muss, um den maximalen Nutzen für die finanzielle Leistung zu erzielen. Welcher CEO wird ein solches Tool ablehnen?

Es ist durchaus möglich, Ressourcen für die Implementierung von SRE zu erhalten.

Der Kurspreis enthält eine Reihe von Argumenten für die Umstellung auf SRE und DevOps.

Und auch in kleinen Unternehmen gibt es einen Platz für SRE.

SRE ist in Tools, Kultur und Organisationsstruktur unterteilt.

Einige Tools, z. B. Service Mesh, werden für große und komplexe Projekte benötigt. Die gleichen Wiederholungsversuche, Backoffs, Fehlerinjektionen und ordnungsgemäßen Verschlechterungen können jedoch auch in kleinen Projekten durchgeführt werden und bieten eine enorme Rendite.

Kultur ist auch in jedem Unternehmen nützlich. Der klassische Administrator, der Prometheus einrichtet, handelt nach dem Standard: Er überwacht den Speicher- und Plattenverbrauch sowie andere bekannte Überwachungsfunktionen. Der SRE-Ingenieur wird zunächst mit dem Unternehmen wichtige Indikatoren für Geschäftsprozesse erörtern und dann deren Überwachung einrichten. Es ist sofort klar, dass die SRE-Engineering-Kultur auch in Kleinstunternehmen von Nutzen ist.

Aber die Organisationsstruktur in kleinen Unternehmen ist wahrscheinlich nicht erforderlich und sogar schädlich. Wenn alle Mitarbeiter Generalisten sind, muss die Zuweisung von SRE-Befehlen nicht erzwungen werden.

Alles, was wir beschreiben, funktioniert bereits

Der Kurs wurde von denen entwickelt, die SRE schon lange in ihren Teams implementiert haben und schon lange in diesem Paradigma gelebt haben. Ivan Kruglov und Ben Tyler, beide Hauptentwickler bei Booking.com. Eugene Varavva, ein bekannter Entwickler bei Google. Eduard Medvedev, CTO bei Tungsten Labs, aufgewachsen als SRE-Ingenieur.

Edward hält am 12. Dezember um 11:00 Uhr ein Webinar "SRE - HYIP oder die Zukunft?"

Über das Programm

Wie für das Programm. Ich erhalte bereits Expertenfeedback, dass das Programm nicht kämpft: Es ist zu umfangreich und manchmal unlogisch. Das ist tatsächlich so.

Tatsächlich haben wir einen Rahmen für das Programm, eine Reihe von Ideen, die wir enthüllen möchten. Wir haben zwei Monate harte Arbeit vor uns, während wir uns vorbereiten, wird das Programm geklärt: Wir entfernen das Unnötige und spezifizieren die verbleibenden.

Das Programm zeigt aber bereits in seiner jetzigen Form deutlich, in welche Richtung wir arbeiten.

Ist alles das Geld wert?

PS. Was hat der Kubernetes Hub damit zu tun?

Alle Übungen werden bei Kubernetes durchgeführt. Wer Kubernetes besitzt, hat eine direkte Verbindung zu den SRE-Ingenieuren. Für diejenigen, die keine besitzen, besuchen Sie unsere Kubernetes-Kurse .

Anmeldung für Slurm SRE