Der Ton des Webinars ist schlecht, daher haben wir ihn transkribiert.
Mein Name ist Medwedew Eduard. Heute werde ich darüber sprechen, was SRE ist, wie SRE entstanden ist, welche Arbeitskriterien für SRE-Ingenieure gelten, ein wenig über Zuverlässigkeitskriterien und ein wenig über seine Überwachung. Wir werden auf den Gipfeln laufen, da man in einer Stunde nicht viel sagen kann, aber ich werde Materialien für zusätzliche Überprüfungen zur Verfügung stellen, und wir alle warten auf Sie . in Moskau Ende Januar.
Lassen Sie uns zunächst darüber sprechen, was SRE ist – Site Reliability Engineering. Und wie es als eigenständige Position, als eigenständige Richtung erschien. Alles begann damit, dass in traditionellen Entwicklungskreisen Dev und Ops zwei völlig unterschiedliche Teams sind, meist mit zwei völlig unterschiedlichen Zielen. Das Ziel des Entwicklungsteams besteht darin, neue Funktionen einzuführen und die Anforderungen des Unternehmens zu erfüllen. Das Ziel des Ops-Teams besteht darin, sicherzustellen, dass alles funktioniert und nichts kaputt geht. Offensichtlich widersprechen sich diese Ziele direkt: Damit alles funktioniert und nichts kaputt geht, sollten Sie so wenig wie möglich neue Funktionen einführen. Aus diesem Grund gibt es viele interne Konflikte, die die heute DevOps genannte Methodik zu lösen versucht.
Das Problem ist, dass wir keine klare Definition von DevOps und keine klare Implementierung von DevOps haben. Ich habe vor zwei Jahren auf einer Konferenz in Jekaterinburg gesprochen und bisher begann der DevOps-Bereich mit dem Bericht „Was ist DevOps“. Im Jahr 2 ist Devops fast 2017 Jahre alt, aber wir streiten immer noch darüber, was es ist. Und das ist eine sehr seltsame Situation, die Google vor einigen Jahren zu lösen versuchte.
Im Jahr 2016 veröffentlichte Google ein Buch mit dem Titel „Site Reliability Engineering“. Und tatsächlich begann mit diesem Buch die SRE-Bewegung. SRE ist eine spezifische Implementierung des DevOps-Paradigmas in einem bestimmten Unternehmen. SRE-Ingenieure setzen sich dafür ein, dass die Systeme zuverlässig funktionieren. Sie stammen meist von Entwicklern, manchmal auch von Administratoren mit ausgeprägtem Entwicklungshintergrund. Und sie tun das, was Systemadministratoren früher taten, aber ein starker Hintergrund in der Entwicklung und Kenntnisse des Systems in Bezug auf Code führen dazu, dass diese Leute nicht zu routinemäßigen Verwaltungsarbeiten neigen, sondern zur Automatisierung neigen.
Es stellt sich heraus, dass das DevOps-Paradigma in SRE-Teams dadurch umgesetzt wird, dass es SRE-Ingenieure gibt, die strukturelle Probleme lösen. Hier ist es die gleiche Verbindung zwischen Dev und Ops, über die seit 8 Jahren gesprochen wird. Die Rolle eines SRE ähnelt insofern der eines Architekten, als Neulinge nicht zu SREs werden. Menschen, die am Anfang ihrer Karriere stehen, haben noch keine Erfahrung, verfügen nicht über die nötige Breite an Wissen. Denn SRE erfordert ein sehr subtiles Wissen darüber, was genau wann genau schief gehen kann. Daher ist hier in der Regel eine gewisse Erfahrung sowohl innerhalb als auch außerhalb des Unternehmens erforderlich.
Sie fragen, ob der Unterschied zwischen SRE und Devops beschrieben wird. Sie wurde gerade beschrieben. Wir können über den Platz des SRE in der Organisation sprechen. Im Gegensatz zu diesem klassischen DevOps-Ansatz, bei dem Ops noch eine separate Abteilung ist, ist SRE Teil des Entwicklungsteams. Sie sind an der Produktentwicklung beteiligt. Es gibt sogar einen Ansatz, bei dem SRE eine Rolle ist, die von einem Entwickler an einen anderen weitergegeben wird. Sie beteiligen sich an Codeüberprüfungen auf die gleiche Weise wie beispielsweise UX-Designer, Entwickler selbst und manchmal auch Produktmanager. SREs arbeiten auf dem gleichen Niveau. Wir müssen sie genehmigen, wir müssen sie überprüfen, damit SRE bei jedem Einsatz sagt: „Okay, dieser Einsatz, dieses Produkt wird die Zuverlässigkeit nicht negativ beeinflussen.“ Und wenn ja, dann innerhalb akzeptabler Grenzen. Wir werden auch darüber sprechen.
Dementsprechend hat die SRE ein Vetorecht, den Kodex zu ändern. Und im Allgemeinen führt dies auch zu kleinen Konflikten, wenn die SRE falsch implementiert wird. Im selben Buch über Site Reliability Engineering wird in vielen Teilen, nicht einmal in einem, beschrieben, wie diese Konflikte vermieden werden können.
Sie fragen, wie SRE mit Informationssicherheit zusammenhängt. SRE ist nicht direkt an der Informationssicherheit beteiligt. In großen Unternehmen wird dies im Wesentlichen von Einzelpersonen, Testern und Analysten durchgeführt. Aber SRE interagiert auch mit ihnen in dem Sinne, dass einige Vorgänge, einige Commits und einige Bereitstellungen, die sich auf die Sicherheit auswirken, auch die Verfügbarkeit des Produkts beeinträchtigen können. Daher interagiert SRE als Ganzes mit allen Teams, einschließlich Sicherheitsteams und Analysten. Daher werden SREs hauptsächlich dann benötigt, wenn sie versuchen, DevOps zu implementieren, aber gleichzeitig wird die Belastung für Entwickler zu groß. Das heißt, das Entwicklungsteam selbst kann es nicht mehr ertragen, dass es nun auch für Ops verantwortlich sein muss. Und es gibt eine separate Rolle. Diese Rolle ist im Budget vorgesehen. Manchmal ist diese Rolle in der Größe des Teams festgelegt, eine separate Person erscheint, manchmal wird sie von einem der Entwickler übernommen. So erscheint der erste SRE im Team.
Die Komplexität des Systems, das von SRE betroffen ist, die Komplexität, die sich auf die Zuverlässigkeit des Betriebs auswirkt, ist notwendig und zufällig. Von notwendiger Komplexität spricht man, wenn die Komplexität eines Produkts in dem Maße zunimmt, wie es neue Produktfunktionen erfordern. Zufällige Komplexität liegt vor, wenn die Komplexität des Systems zunimmt, die Produktfunktion und die Geschäftsanforderungen jedoch keinen direkten Einfluss darauf haben. Es stellt sich heraus, dass entweder der Entwickler irgendwo einen Fehler gemacht hat, der Algorithmus nicht optimal ist oder einige zusätzliche Interessen eingeführt wurden, die die Komplexität des Produkts ohne besondere Notwendigkeit erhöhen. Ein guter SRE sollte dieser Situation immer ein Ende bereiten. Das heißt, jedes Commit, jede Bereitstellung, jede Pull-Anfrage, bei der die Schwierigkeit durch zufälliges Hinzufügen erhöht wird, sollte blockiert werden.
Die Frage ist, warum man nicht einfach einen Ingenieur, einen Systemadministrator mit viel Wissen ins Team holt. Ein Entwickler in der Rolle eines Ingenieurs, so wird uns gesagt, sei nicht die beste Personallösung. Ein Entwickler in der Rolle eines Ingenieurs ist nicht immer die beste Personallösung, aber der Punkt hier ist, dass ein Entwickler, der sich mit Ops beschäftigt, etwas mehr Lust auf Automatisierung hat, etwas mehr Wissen und Fähigkeiten zur Umsetzung hat diese Automatisierung. Und dementsprechend reduzieren wir nicht nur die Zeit für bestimmte Vorgänge, nicht nur die Routine, sondern auch so wichtige Geschäftsparameter wie MTTR (Mean Time To Recovery, Wiederherstellungszeit). Dadurch, und darüber sprechen wir später noch, sparen wir Geld für die Organisation.
Lassen Sie uns nun über die Kriterien für den Betrieb von SRE sprechen. Und vor allem über Zuverlässigkeit. In kleinen Unternehmen und Startups kommt es oft vor, dass die Leute davon ausgehen, dass die Dienstleistung, wenn sie gut geschrieben ist, wenn das Produkt gut und korrekt geschrieben ist, funktioniert und nicht kaputt geht. Das ist alles, wir schreiben guten Code, sodass nichts kaputt gehen kann. Der Code ist sehr einfach, es gibt nichts zu brechen. Dabei handelt es sich um dieselben Leute, die sagen, dass wir keine Tests brauchen, denn sehen Sie, das sind die drei VPI-Methoden, warum hier eine Pause machen?
Das ist natürlich alles falsch. Und diese Leute werden in der Praxis sehr oft von solchem Code gebissen, weil Dinge kaputt gehen. Manchmal gehen Dinge auf unvorhersehbare Weise kaputt. Manchmal sagen die Leute nein, es wird nie passieren. Und es passiert ständig. Es passiert oft genug. Und deshalb strebt niemand eine 100-prozentige Verfügbarkeit an, denn eine 100-prozentige Verfügbarkeit gibt es nie. Das ist die Norm. Und wenn wir über die Verfügbarkeit eines Dienstes sprechen, sprechen wir daher immer von Neunen. 2 Neunen, 3 Neunen, 4 Neunen, 5 Neunen. Wenn wir das in Ausfallzeit umrechnen, dann zum Beispiel 5 Neunen, dann sind das etwas mehr als 5 Minuten Ausfallzeit pro Jahr, 2 Neunen sind 3,5 Tage Ausfallzeit.
Aber es ist offensichtlich, dass es irgendwann zu einem Rückgang des POI und der Kapitalrendite kommt. Die Umstellung von zwei Neunen auf drei Neunen bedeutet eine um mehr als drei Tage geringere Ausfallzeit. Die Umstellung von vier Neunen auf fünf verringert die Ausfallzeit um 3 Minuten pro Jahr. Und es stellt sich heraus, dass dies für das Geschäft möglicherweise nicht kritisch ist. Und im Allgemeinen ist die erforderliche Zuverlässigkeit kein technisches Problem, sondern in erster Linie ein Geschäftsproblem, es ist ein Produktproblem. Welche Ausfallzeit ist für Benutzer des Produkts akzeptabel, was erwarten sie, wie viel zahlen sie beispielsweise, wie viel Geld verlieren sie, wie viel Geld verliert das System.
Eine wichtige Frage hierbei ist die Zuverlässigkeit der übrigen Komponenten. Denn der Unterschied zwischen 4 und 5 Neunen wird auf einem Smartphone mit 2 Neunen Zuverlässigkeit nicht sichtbar sein. Grob gesagt: Wenn auf einem Smartphone in Ihrem Dienst zehnmal im Jahr etwas kaputt geht, ist der Ausfall höchstwahrscheinlich achtmal auf der Betriebssystemseite aufgetreten. Der Benutzer ist daran gewöhnt und wird nicht noch einmal im Jahr darauf achten. Es ist notwendig, den Preis einer zunehmenden Zuverlässigkeit und steigenden Gewinnen in Beziehung zu setzen.
Gerade im Buch über SRE gibt es ein gutes Beispiel für die Steigerung von 4 Neunen auf 3 Neunen. Es stellt sich heraus, dass die Erhöhung der Verfügbarkeit etwas weniger als 0,1 % beträgt. Und wenn der Umsatz des Dienstes 1 Million US-Dollar pro Jahr beträgt, beträgt die Umsatzsteigerung 900 US-Dollar. Wenn es uns weniger als 900 US-Dollar pro Jahr kostet, die Erschwinglichkeit um neun zu erhöhen, ist die Erhöhung finanziell sinnvoll. Wenn es mehr als 900 Dollar im Jahr kostet, macht es keinen Sinn mehr, weil die Umsatzsteigerung einfach nicht die Arbeitskosten, Ressourcenkosten, ausgleicht. Und 3 Neunen werden uns reichen.
Dies ist natürlich ein vereinfachtes Beispiel, bei dem alle Anfragen gleich sind. Und der Wechsel von 3 Neunen auf 4 Neunen ist ganz einfach, aber gleichzeitig bedeutet der Wechsel von 2 Neunen auf 3 bereits eine Ersparnis von 9 Dollar und kann finanziell sinnvoll sein. In der Realität ist das Scheitern der Registrierungsanfrage natürlich schlimmer als das Scheitern der Anzeige der Seite. Anfragen haben ein unterschiedliches Gewicht. Aus geschäftlicher Sicht mögen sie ein völlig anderes Kriterium haben, aber in der Regel ist dies eine ziemlich zuverlässige Annäherung, wenn es sich nicht um bestimmte Dienstleistungen handelt.
Wir haben eine Frage erhalten, ob SRE einer der Koordinatoren bei der Auswahl einer architektonischen Lösung für den Dienst ist. Sagen wir im Hinblick auf die Integration in die bestehende Infrastruktur, damit es zu keinen Einbußen bei der Stabilität kommt. Ja, SREs, genauso wie Pull Requests, Commits und Releases die Architektur, die Einführung neuer Dienste, Microservices und die Implementierung neuer Lösungen beeinflussen. Warum habe ich vorher gesagt, dass Erfahrung erforderlich ist, Qualifikationen erforderlich sind? Tatsächlich ist SRE eine der blockierenden Stimmen in jeder Architektur- und Softwarelösung. Dementsprechend muss ein SRE als Ingenieur zunächst nicht nur verstehen, sondern auch verstehen, wie sich bestimmte Entscheidungen auf Zuverlässigkeit und Stabilität auswirken, und verstehen, wie sich dies auf die Geschäftsanforderungen auswirkt und aus welcher Sicht dies akzeptabel sein kann was nicht.
Daher können wir jetzt nur über Zuverlässigkeitskriterien sprechen, die in SRE traditionell als SLA (Service Level Agreement) definiert werden. Höchstwahrscheinlich ein bekannter Begriff. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement ist möglicherweise ein symbolischer Begriff, insbesondere wenn Sie mit Netzwerken, Anbietern und Hosting zusammengearbeitet haben. Hierbei handelt es sich um eine allgemeine Vereinbarung, die die Leistung Ihres gesamten Dienstes, Strafen, einige Strafen für Fehler, Metriken und Kriterien beschreibt. Und SLI ist die Verfügbarkeitsmetrik selbst. Das heißt, was SLI sein kann: Antwortzeit des Dienstes, Anzahl der Fehler in Prozent. Es könnte an der Bandbreite liegen, wenn es sich um eine Art Datei-Hosting handelt. Bei Erkennungsalgorithmen kann der Indikator beispielsweise auch die Richtigkeit der Antwort sein. SLO (Service Level Objective) ist jeweils eine Kombination aus dem SLI-Indikator, seinem Wert und seiner Periode.
Nehmen wir an, das SLA könnte so aussehen. Der Dienst ist das ganze Jahr über zu 99,95 % verfügbar. Oder 99 kritische Support-Tickets werden innerhalb von 3 Stunden pro Quartal geschlossen. Oder 85 % der Anfragen werden jeden Monat innerhalb von 1,5 Sekunden beantwortet. Das heißt, wir verstehen nach und nach, dass Fehler und Ausfälle ganz normal sind. Das ist eine akzeptable Situation, wir planen sie, wir rechnen teilweise sogar damit. Das heißt, SRE baut Systeme auf, die Fehler machen können, die normal auf Fehler reagieren müssen und diese berücksichtigen müssen. Und wenn möglich, sollten sie mit Fehlern so umgehen, dass der Benutzer sie entweder nicht bemerkt oder bemerkt, aber es gibt eine Art Problemumgehung, dank derer nicht alles vollständig zusammenbricht.
Wenn Sie beispielsweise ein Video auf YouTube hochladen und YouTube es nicht sofort konvertieren kann, das Video zu groß ist oder das Format nicht optimal ist, schlägt die Anfrage natürlich nicht mit einer Zeitüberschreitung fehl und YouTube gibt keinen 502-Fehler aus , wird YouTube sagen: „Wir haben alles erstellt, Ihr Video wird bearbeitet.“ Es wird in etwa 10 Minuten fertig sein. Dabei handelt es sich um das Prinzip des Graceful Degradation, das man zum Beispiel aus der Frontend-Entwicklung kennt, sofern man das schon einmal gemacht hat.
Die nächsten Begriffe, über die wir sprechen werden und die für die Arbeit mit Zuverlässigkeit, Fehlern und Erwartungen sehr wichtig sind, sind MTBF und MTTR. MTBF ist die mittlere Zeit zwischen Ausfällen. MTTR Mean Time To Recovery, durchschnittliche Zeit bis zur Wiederherstellung. Das heißt, wie viel Zeit seit der Entdeckung des Fehlers, vom Auftreten des Fehlers bis zur Wiederherstellung des vollständigen Normalbetriebs des Dienstes vergangen ist. MTBF wird hauptsächlich durch Arbeiten an der Codequalität behoben. Das heißt, die Tatsache, dass SREs „Nein“ sagen können. Und Sie müssen im gesamten Team verstehen, dass SRE, wenn er „Nein“ sagt, dies nicht tut, weil er schädlich ist, nicht weil er schlecht ist, sondern weil sonst alle leiden werden.
Auch hier gibt es viele Artikel, viele Methoden, viele Möglichkeiten, selbst in dem Buch, auf das ich mich so oft beziehe, wie man sicherstellen kann, dass andere Entwickler nicht anfangen, SRE zu hassen. Bei MTTR hingegen geht es um die Arbeit an Ihren SLOs (Service Level Objective). Und es ist größtenteils Automatisierung. Denn unser SLO ist beispielsweise eine Betriebszeit von 4 Neunen pro Quartal. Das bedeutet, dass wir in 3 Monaten 13 Minuten Ausfallzeit einkalkulieren können. Und es stellt sich heraus, dass die MTTR nicht mehr als 13 Minuten betragen darf. Wenn wir innerhalb von 13 Minuten auf mindestens eine Ausfallzeit reagieren, bedeutet dies, dass wir bereits das gesamte Budget für das Quartal ausgeschöpft haben. Wir brechen das SLO. 1 Minuten, um auf einen Absturz zu reagieren und ihn zu beheben, sind viel für eine Maschine, aber sehr kurz für einen Menschen. Denn bis ein Mensch eine Warnung erhält, bis er reagiert, bis er den Fehler versteht, vergehen bereits mehrere Minuten. Bis jemand versteht, wie er das Problem beheben kann, was genau zu beheben ist und was zu tun ist, dauert es noch ein paar Minuten. Und selbst wenn Sie, wie sich herausstellt, nur den Server neu starten oder einen neuen Knoten erstellen müssen, beträgt die manuelle MTTR bereits etwa 13 bis 7 Minuten. Bei der Automatisierung des Prozesses erreicht die MTTR sehr oft eine Sekunde, manchmal sogar Millisekunden. Google spricht normalerweise von Millisekunden, aber in Wirklichkeit ist natürlich nicht alles so gut.
Im Idealfall sollte der SRE seine Arbeit nahezu vollständig automatisieren, da sich dies direkt auf die MTTR, ihre Metriken, den SLO des gesamten Dienstes und damit auf den Geschäftsgewinn auswirkt. Bei Zeitüberschreitungen werden wir gefragt, ob ein Verschulden von SRE vorliegt. Zum Glück trägt niemand die Schuld. Und dies ist eine separate Kultur namens balmeless postmortem, über die wir heute nicht sprechen, sondern auf Slurm analysieren werden. Das ist ein sehr interessantes Thema, über das man viel reden kann. Grob gesagt, wenn die vorgesehene Zeit pro Quartal überschritten wird, ist ein bisschen von jedem die Schuld, was bedeutet, dass es nicht produktiv ist, allen die Schuld zu geben. Stattdessen sollten wir vielleicht niemandem die Schuld geben, sondern die Situation korrigieren und mit dem arbeiten, was wir haben. Meiner Erfahrung nach ist dieser Ansatz den meisten Teams, insbesondere in Russland, etwas fremd, aber er macht Sinn und funktioniert sehr gut. Daher werde ich am Ende des Artikels Literatur empfehlen, die Sie zu diesem Thema lesen können. Oder kommen Sie zu Slurm SRE.
Lassen Sie mich erklären. Wenn die SLO-Zeit pro Quartal überschritten wird, wenn die Ausfallzeit nicht 13, sondern 15 Minuten betrug, wer kann daran schuld sein? Natürlich könnte SRE schuld sein, denn er hat eindeutig einen fehlerhaften Commit oder Deployment durchgeführt. Schuld daran könnte der Administrator des Rechenzentrums sein, der möglicherweise außerplanmäßige Wartungsarbeiten durchgeführt hat. Wenn der Administrator des Rechenzentrums daran schuld ist, dann ist es die Person von Ops, die bei der Koordination des SLO die Wartung nicht berechnet hat. Schuld daran ist der Manager, technische Leiter oder jemand, der den Rechenzentrumsvertrag unterzeichnet hat und nicht darauf geachtet hat, dass das SLA des Rechenzentrums nicht auf die erforderliche Ausfallzeit ausgelegt ist. Dementsprechend tragen nach und nach alle in dieser Situation die Schuld. Und es bedeutet, dass es keinen Sinn hat, in dieser Situation irgendjemandem die Schuld zuzuschieben. Aber natürlich muss es korrigiert werden. Deshalb gibt es Obduktionen. Und wenn Sie zum Beispiel GitHub-Postmortems lesen und dies in jedem einzelnen Fall immer eine sehr interessante, kleine und unerwartete Geschichte ist, können Sie ersetzen, dass niemand jemals sagt, dass diese bestimmte Person schuld war. Die Schuld wird immer auf bestimmte unvollkommene Prozesse gelegt.
Kommen wir zur nächsten Frage. Automatisierung. Wenn ich in anderen Zusammenhängen über Automatisierung spreche, beziehe ich mich oft auf eine Tabelle, die Ihnen sagt, wie lange Sie an der Automatisierung einer Aufgabe arbeiten können, ohne mehr Zeit für die Automatisierung zu benötigen, als Sie tatsächlich einsparen. Es gibt einen Haken. Der Haken daran ist, dass SREs durch die Automatisierung einer Aufgabe nicht nur Zeit, sondern auch Geld sparen, da sich die Automatisierung direkt auf die MTTR auswirkt. Sie retten sozusagen die Moral von Mitarbeitern und Entwicklern, die ebenfalls eine erschöpfbare Ressource darstellt. Sie reduzieren die Routine. Und das alles wirkt sich positiv auf die Arbeit und damit auf das Geschäft aus, auch wenn es den Anschein hat, dass Automatisierung aus Zeitgründen keinen Sinn ergibt.
Tatsächlich ist dies fast immer der Fall, und es gibt nur sehr wenige Fälle, in denen in der Rolle des SRE nicht etwas automatisiert werden sollte. Als nächstes sprechen wir über das sogenannte Fehlerbudget, das Budget für Fehler. Tatsächlich stellt sich heraus, dass, wenn für Sie alles viel besser ist als der SLO, den Sie sich selbst gesetzt haben, dies auch nicht sehr gut ist. Das ist eher schlecht, da SLO nicht nur als Untergrenze, sondern auch als ungefähre Obergrenze fungiert. Wenn Sie sich ein SLO mit einer Verfügbarkeit von 99 % setzen und tatsächlich 99,99 % haben, stellt sich heraus, dass Sie Raum für Experimente haben, die dem Unternehmen überhaupt nicht schaden, weil Sie dies alles selbst festgelegt haben, und das tun Sie auch Dieser Platz wird nicht genutzt. Sie haben ein Budget für Fehler, das in Ihrem Fall nicht ausgeschöpft wird.
Was machen wir damit? Wir verwenden es für buchstäblich alles. Zum Testen unter Produktionsbedingungen, zum Ausrollen neuer Funktionen, die sich auf die Leistung auswirken können, für Releases, zur Wartung, für geplante Ausfallzeiten. Es gilt auch die umgekehrte Regel: Wenn das Budget erschöpft ist, können wir nichts Neues veröffentlichen, weil wir sonst das SLO überschreiten. Das Budget ist bereits erschöpft, wir haben etwas freigegeben, wenn es sich negativ auf die Leistung auswirkt, das heißt, wenn es sich nicht um eine Art Fix handelt, der an sich den SLO direkt erhöht, dann überschreiten wir das Budget, und das ist eine schlechte Situation Es muss postmortal analysiert und möglicherweise einige Prozesskorrekturen vorgenommen werden.
Das heißt, es stellt sich heraus, dass, wenn der Dienst selbst nicht gut funktioniert und SLO ausgegeben wird und das Budget nicht für Experimente, nicht für einige Releases, sondern für sich selbst ausgegeben wird, statt einiger interessanter Korrekturen, statt interessanter Funktionen, statt interessanter Veröffentlichungen. Statt kreativer Arbeit müssen Sie sich mit dummen Korrekturen herumschlagen, um das Budget wieder in Ordnung zu bringen, oder das SLO bearbeiten, und das ist auch ein Prozess, der nicht allzu oft passieren sollte.
Daher stellt sich heraus, dass in einer Situation, in der wir mehr Budget für Fehler haben, alle interessiert sind: sowohl SRE als auch Entwickler. Für Entwickler bedeutet ein großes Budget für Fehler, dass sie sich mit Veröffentlichungen, Tests und Experimenten befassen können. Für SREs bedeutet ein Budget für Fehler und die Eingabe dieses Budgets, dass sie ihre Arbeit direkt gut machen. Und das wirkt sich auf die Motivation einer gemeinsamen Arbeit aus. Wenn Sie als Entwickler auf Ihre SREs hören, haben Sie mehr Raum für gute Arbeit und viel weniger Routine.
Es zeigt sich, dass Experimente in der Produktion ein durchaus wichtiger und nahezu integraler Bestandteil von SRE in großen Teams sind. Und es wird normalerweise Chaos Engineering genannt, was auf das Team von Netflix zurückgeht, das ein Dienstprogramm namens Chaos Monkey herausgebracht hat.
Chaos Monkey stellt eine Verbindung zur CI/CD-Pipeline her und stürzt den Server in der Produktion zufällig ab. Auch hier geht es in der SRE-Struktur um die Tatsache, dass ein ausgefallener Server an sich nicht schlecht ist, das wird erwartet. Und wenn es innerhalb des Budgets liegt, ist es akzeptabel und schadet dem Unternehmen nicht. Natürlich verfügt Netflix über genügend redundante Server, genügend Replikation, sodass das alles behoben werden kann und der Benutzer als Ganzes es nicht einmal merkt, und noch mehr, dass niemand aus irgendeinem Budget einen Server verlässt.
Netflix verfügte eine Zeit lang über eine ganze Reihe solcher Dienstprogramme, von denen eines, Chaos Gorilla, eine der Availability Zones von Amazon vollständig lahmlegte. Und solche Dinge helfen erstens, versteckte Abhängigkeiten aufzudecken, wenn nicht ganz klar ist, was was beeinflusst, was von was abhängt. Und wenn Sie mit einem Microservice arbeiten und die Dokumentation nicht ganz perfekt ist, kommt Ihnen das vielleicht bekannt vor. Und wiederum hilft dies sehr dabei, Fehler im Code zu erkennen, die Sie beim Staging nicht erkennen können, da jedes Staging aufgrund der Tatsache, dass die Lastskala unterschiedlich ist, das Lastmuster unterschiedlich ist und die Ausrüstung unterschiedlich ist, nicht gerade eine exakte Simulation ist höchstwahrscheinlich auch andere. Spitzenlasten können auch unerwartet und unvorhersehbar sein. Und solche Tests, die wiederum nicht über das Budget hinausgehen, helfen sehr gut, Fehler in der Infrastruktur zu erkennen, die durch Staging, Autotests und CI/CD-Pipeline niemals erkannt werden. Und solange alles in Ihrem Budget enthalten ist, spielt es keine Rolle, dass Ihr Dienst dort ausgefallen ist, auch wenn es sehr beängstigend erscheinen würde, der Server ist ausgefallen, was für ein Albtraum. Nein, das ist normal, das ist gut, das hilft, Insekten zu erkennen. Wenn Sie ein Budget haben, können Sie es ausgeben.
F: Welche Literatur kann ich empfehlen? Liste am Ende. Es gibt viel Literatur, ich werde ein paar Berichte empfehlen. Wie funktioniert es und funktioniert SRE in Unternehmen ohne eigenes Softwareprodukt oder mit minimaler Entwicklung? Zum Beispiel in einem Unternehmen, dessen Haupttätigkeit nicht Software ist. In einem Unternehmen, in dem die Hauptaktivität nicht Software ist, funktioniert SRE genauso wie überall sonst, denn in einem Unternehmen müssen Sie auch Softwareprodukte verwenden, auch wenn diese noch nicht entwickelt sind, Sie müssen Updates einführen, Sie müssen Änderungen vornehmen Die Infrastruktur muss wachsen und skaliert werden. Und SREs helfen dabei, mögliche Probleme in diesen Prozessen zu erkennen und vorherzusagen und sie zu kontrollieren, nachdem ein gewisses Wachstum einsetzt und sich die Geschäftsanforderungen ändern. Denn es ist absolut nicht notwendig, in die Softwareentwicklung involviert zu sein, um über ein SRE zu verfügen, wenn Sie über mindestens ein paar Server verfügen und von Ihnen zumindest ein gewisses Wachstum erwartet wird.
Das Gleiche gilt für kleine Projekte, kleine Organisationen, denn große Unternehmen haben das Budget und den Raum zum Experimentieren. Aber gleichzeitig können all diese Früchte der Experimente überall genutzt werden, das heißt, SRE erschien natürlich in Google, in Netflix, in Dropbox. Aber gleichzeitig können kleine Unternehmen und Startups bereits komprimiertes Material lesen, Bücher lesen und Berichte ansehen. Sie hören immer öfter davon, sie schauen sich konkrete Beispiele an, ich finde es in Ordnung, es kann wirklich nützlich sein, wir brauchen das auch, es ist großartig.
Das heißt, alle wesentlichen Arbeiten zur Standardisierung dieser Prozesse sind bereits für Sie erledigt. Es bleibt Ihnen überlassen, die Rolle von SRE speziell in Ihrem Unternehmen zu bestimmen und mit der tatsächlichen Umsetzung all dieser Praktiken zu beginnen, die wiederum bereits beschrieben wurden. Das heißt, aus nützlichen Prinzipien für kleine Unternehmen ist dies immer die Definition von SLA, SLI, SLO. Wenn Sie sich nicht mit Software befassen, handelt es sich hierbei um interne SLAs und interne SLOs, ein internes Fehlerbudget. Dies führt fast immer zu interessanten Diskussionen innerhalb des Teams und innerhalb des Unternehmens, da sich herausstellen kann, dass Sie viel mehr für die Infrastruktur, für eine Art Organisation idealer Prozesse und die ideale Pipeline ausgeben als nötig. Und diese 4 Neunen, die Sie in der IT-Abteilung haben, brauchen Sie jetzt nicht wirklich. Aber gleichzeitig könnte man Zeit und das Budget für Fehler für etwas anderes verwenden.
Dementsprechend ist die Überwachung und Organisation der Überwachung für ein Unternehmen jeder Größe sinnvoll. Und im Allgemeinen ist diese Denkweise, bei der Fehler etwas Akzeptables sind, wo es ein Budget gibt, wo es Ziele gibt, wiederum für ein Unternehmen jeder Größe nützlich, angefangen bei Startups für 3 Personen.
Die letzte technische Nuance, über die es zu sprechen gilt, ist die Überwachung. Denn wenn wir über SLA, SLI, SLO sprechen, können wir ohne Überwachung nicht verstehen, ob wir in das Budget passen, ob wir unsere Ziele einhalten und wie wir das endgültige SLA beeinflussen. Ich habe so oft gesehen, dass die Überwachung so abläuft: Es gibt einen Wert, zum Beispiel die Zeit einer Anfrage an den Server, die durchschnittliche Zeit oder die Anzahl der Anfragen an die Datenbank. Er hat einen von einem Ingenieur festgelegten Standard. Weicht die Metrik von der Norm ab, kommt eine E-Mail. Das alles ist in der Regel absolut nutzlos, weil es zu einer solchen Flut von Warnungen, einer Flut von Meldungen aus der Überwachung führt, wenn eine Person sie jedes Mal zuerst interpretieren muss, d. h. feststellen muss, ob der Wert der Metrik bedeutet der Handlungsbedarf. Und zweitens nimmt er all diese Warnungen einfach nicht mehr wahr, wenn im Grunde keine Aktion von ihm erforderlich ist. Das ist eine gute Überwachungsregel und die allererste Regel bei der Implementierung von SRE ist, dass eine Benachrichtigung nur erfolgen sollte, wenn Maßnahmen erforderlich sind.
Im Standardfall gibt es 3 Ereignisebenen. Es gibt Warnungen, es gibt Tickets, es gibt Protokolle. Warnungen sind alles, was ein sofortiges Handeln erfordert. Das heißt, alles ist kaputt, Sie müssen es sofort reparieren. Tickets erfordern verzögertes Handeln. Ja, Sie müssen etwas tun, Sie müssen etwas manuell tun, die Automatisierung ist fehlgeschlagen, aber Sie müssen es in den nächsten Minuten nicht tun. Protokolle sind alles, was keine Aktion erfordert, und wenn alles gut läuft, wird sie im Allgemeinen niemand lesen. Sie müssen die Protokolle nur dann lesen, wenn sich im Nachhinein herausstellt, dass etwas kaputt gegangen ist, von dem wir seit einiger Zeit nichts wussten. Oder müssen Sie etwas recherchieren? Aber im Allgemeinen wird alles, was keine Aktion erfordert, in die Protokolle verschoben.
Wenn wir definiert haben, welche Ereignisse Aktionen erfordern, und gut beschrieben haben, wie diese Aktionen aussehen sollten, bedeutet dies als Nebeneffekt, dass die Aktion automatisiert werden kann. Das heißt, was passiert. Wir gehen von Alarmbereitschaft aus. Lasst uns in die Tat umsetzen. Wir gehen zur Beschreibung dieser Aktion über. Und dann gehen wir zur Automatisierung über. Das heißt, jede Automatisierung beginnt mit einer Reaktion auf ein Ereignis.
Von der Überwachung kommen wir zu einem Begriff namens Observability. Auch um dieses Wort gab es in den letzten Jahren einen gewissen Hype. Und nur wenige Menschen verstehen, was es außerhalb des Kontexts bedeutet. Der wichtigste Punkt ist jedoch, dass die Beobachtbarkeit ein Maß für die Systemtransparenz ist. Wenn etwas schief gelaufen ist, wie schnell können Sie dann feststellen, was genau schief gelaufen ist und wie der Zustand des Systems zu diesem Zeitpunkt war? In Bezug auf den Code: Welche Funktion ist fehlgeschlagen, welcher Dienst ist fehlgeschlagen. Wie war der Status beispielsweise der internen Variablen oder der Konfiguration? In Bezug auf die Infrastruktur ist dies die Verfügbarkeitszone, in der der Fehler aufgetreten ist, und wenn Sie Kubernetes installiert haben, in welchem Pod der Fehler aufgetreten ist und wie der Status des Pods war. Und dementsprechend steht Observability in direktem Zusammenhang mit MTTR. Je höher die Beobachtbarkeit des Dienstes, desto einfacher ist es, den Fehler zu identifizieren, desto einfacher ist es, den Fehler zu beheben, desto einfacher ist es, den Fehler zu automatisieren, desto niedriger ist die MTTR.
Wenn wir wieder auf kleine Unternehmen zurückkommen, stellt sich auch heute noch häufig die Frage, wie man mit der Teamgröße umgeht und ob ein kleines Team einen separaten SRE einstellen muss. Habe bereits vorhin darüber gesprochen. In den ersten Entwicklungsphasen eines Startups oder beispielsweise eines Teams ist dies überhaupt nicht notwendig, da SRE zu einer Übergangsrolle gemacht werden kann. Und das wird das Team ein wenig beleben, denn es gibt zumindest eine gewisse Vielfalt. Und außerdem wird es die Menschen darauf vorbereiten, dass sich mit dem Wachstum im Allgemeinen die Verantwortlichkeiten von SRE sehr stark ändern werden. Wenn Sie jemanden einstellen, hat er natürlich einige Erwartungen. Und diese Erwartungen werden sich im Laufe der Zeit nicht ändern, aber die Anforderungen werden sich sehr ändern. Daher ist die Einstellung eines SRE in der Anfangsphase recht schwierig. Der eigene Anbau ist viel einfacher. Aber es lohnt sich, darüber nachzudenken.
Die einzige Ausnahme besteht möglicherweise dann, wenn sehr strenge und genau definierte Wachstumsanforderungen gelten. Das heißt, im Fall eines Startups kann dies eine Art Druck von Investoren sein, eine Art Wachstumsprognose mehrmals gleichzeitig. Dann ist die Beauftragung eines SRE grundsätzlich gerechtfertigt, weil sie vertretbar ist. Wir haben Wachstumsanforderungen, wir brauchen eine Person, die dafür verantwortlich ist, dass bei einem solchen Wachstum nichts kaputt geht.
Noch eine Frage. Was ist zu tun, wenn die Entwickler mehrmals ein Feature ausschneiden, das die Tests besteht, aber die Produktion unterbricht, die Basis lädt, andere Features unterbricht, welcher Prozess soll implementiert werden? Dementsprechend wird in diesem Fall das Fehlerbudget eingeführt. Und einige der Dienste, einige der Funktionen werden bereits in der Produktion getestet. Es kann kanarisch sein, wenn nur eine kleine Anzahl von Benutzern, aber bereits in der Produktion, ein Feature bereitgestellt wird, aber bereits mit der Erwartung, dass, wenn etwas beispielsweise bei einem halben Prozent aller Benutzer kaputt geht, es trotzdem erfüllt wird Budget für Fehler. Dementsprechend wird es ja einen Fehler geben, bei manchen Benutzern geht alles kaputt, aber wir haben bereits gesagt, dass das normal ist.
Es gab eine Frage zu SRE-Tools. Das heißt, gibt es etwas Bestimmtes, das SREs verwenden würden, was alle anderen nicht tun würden? Tatsächlich gibt es einige hochspezialisierte Dienstprogramme, es gibt eine Art Software, die beispielsweise Lasten simuliert oder Canary-A/B-Tests durchführt. Aber im Grunde ist das SRE-Toolkit das, was Ihre Entwickler bereits verwenden. Weil SRE direkt mit dem Entwicklungsteam interagiert. Und wenn Sie unterschiedliche Tools haben, wird sich herausstellen, dass die Synchronisierung einige Zeit in Anspruch nimmt. Besonders wenn SREs in großen Teams arbeiten, in großen Unternehmen, in denen es mehrere Teams geben kann, ist es eine unternehmensweite Standardisierung, die hier sehr hilfreich ist, denn wenn in 50 Teams 50 verschiedene Utilities verwendet werden, bedeutet dies, dass der SRE diese kennen muss alle. Und das wird natürlich nie passieren. Und die Qualität der Arbeit, die Qualität der Kontrolle zumindest einiger Teams wird deutlich abnehmen.
Unser Webinar neigt sich dem Ende zu. Es ist mir gelungen, einige grundlegende Dinge zu erzählen. Natürlich kann man über SRE nichts in einer Stunde erzählen und verstehen. Aber ich hoffe, dass es mir gelungen ist, diese Denkweise und die wichtigsten Kernpunkte zu vermitteln. Und dann wird es möglich sein, sich bei Interesse mit dem Thema auseinanderzusetzen, selbst zu lernen und zu schauen, wie es von anderen Menschen, in anderen Unternehmen umgesetzt wird. Und dementsprechend kommen Sie Anfang Februar zu uns bei Slurm SRE.
Der Slurm SRE ist ein dreitägiger Intensivkurs, der über das spricht, worüber ich jetzt spreche, aber mit viel mehr Tiefe, mit realen Fällen, mit Übung, der gesamte Intensivkurs ist auf die praktische Arbeit ausgerichtet. Die Leute werden in Teams eingeteilt. Sie alle werden an realen Fällen arbeiten. Dementsprechend haben wir die Booking.com-Ausbilder Ivan Kruglov und Ben Tyler. Wir haben einen wunderbaren Eugene Barabbas von Google aus San Francisco. Und ich werde dir auch etwas sagen. Besuchen Sie uns also unbedingt.
Also die Bibliographie. Es gibt Referenzen zu SRE. auf demselben Buch, oder besser gesagt auf 2 Büchern über SRE, geschrieben von Google. Noch eine , wo die Bedingungen und ihre Anwendung etwas detaillierter sind. Die nächsten 3 sind Berichte über SRE in verschiedenen Unternehmen. Erste - , das ist eine Keynote von Ben Trainer von Google. Zweite - . Der dritte ist wieder . Vierter Bericht von , das nur 5 wichtige SRE-Mitarbeiter in 190 Ländern beschäftigt. Es ist sehr interessant, sich das alles anzusehen, denn so wie DevOps für verschiedene Unternehmen und sogar verschiedene Teams sehr unterschiedliche Bedeutungen hat, hat SRE selbst in Unternehmen ähnlicher Größe sehr unterschiedliche Verantwortlichkeiten.
2 weitere Links zu den Prinzipien des Chaos Engineering: , . Und am Ende gibt es noch 3 Listen aus der Serie Awesome Lists zum Thema , pro und über . Die Liste zu SRE ist unglaublich umfangreich, man muss nicht alles durchgehen, es gibt etwa 200 Artikel. Ich kann die dortigen Artikel zum Thema Kapazitätsplanung und zur tadellosen Obduktion nur wärmstens empfehlen.
Interessanter Artikel:
Vielen Dank, dass Sie mir die ganze Zeit zugehört haben. Ich hoffe, Sie haben etwas gelernt. Ich hoffe, Sie haben genug Material, um noch mehr zu lernen. Und sehe dich. Hoffentlich im Februar.
Das Webinar wurde von Eduard Medvedev moderiert.
PS: Für diejenigen, die gerne lesen, hat Eduard eine Referenzliste gegeben. Wer es lieber in der Praxis verstehen möchte, ist herzlich willkommen .
Source: habr.com