Das Webinar hat einen schlechten Klang, daher haben wir es entschlüsselt.
Ich heiße Edward Medvedev. Heute werde ich darüber sprechen, was SRE ist, wie SRE erschienen ist, wozu SRE-Ingenieure Arbeitskriterien haben, ein wenig über Zuverlässigkeitskriterien, ein wenig über die Überwachung. Wir werden nach oben gehen, weil Sie in einer Stunde nicht viel erzählen werden, aber ich werde Materialien für zusätzliche Einarbeitung geben, und wir warten alle auf Sie bei Slerm SRE . in Moskau Ende Januar.
Lassen Sie uns zunächst darüber sprechen, worum es bei SRE - Site Reliability Engineering geht. Und wie es als separate Position, als separate Richtung erschien. Alles begann mit der Tatsache, dass Dev und Ops in den traditionellen Entwicklungskreisen zwei völlig unterschiedliche Teams sind, normalerweise mit zwei völlig unterschiedlichen Zielen. Ziel des Entwicklungsteams ist es, neue Funktionen bereitzustellen und die Anforderungen des Unternehmens zu erfüllen. Das Ziel des Ops-Teams ist es, dass alles funktioniert und nichts kaputt geht. Offensichtlich widersprechen sich diese Ziele direkt: Damit alles funktioniert und nichts kaputt geht, ist es am besten, neue Funktionen so wenig wie möglich einzuführen. Aus diesem Grund gibt es viele interne Konflikte, die die Methode, die jetzt als DevOps bezeichnet wird, zu lösen versucht.
Das Problem ist, dass wir keine klare Definition von DevOps und keine klare Implementierung von DevOps haben. Ich habe vor 2 Jahren auf einer Konferenz in Jekaterinburg gesprochen, und bis jetzt hat die DevOps-Sektion mit einer Präsentation von „What is DevOps“ begonnen. 2017 ist der devo fast 10 Jahre alt, aber wir streiten uns immer noch darüber, was es ist. Und das ist eine sehr seltsame Situation, die Google vor einigen Jahren zu lösen versucht hat.
2016 veröffentlichte Google ein Buch mit dem Titel Site Reliability Engineering. Und tatsächlich begann die SRE-Bewegung mit diesem Buch. SRE ist eine spezielle Option zur Implementierung des DevOps-Paradigmas in einem bestimmten Unternehmen. Die SRE-Ingenieure haben sich zum Ziel gesetzt, eine zuverlässige Systemleistung sicherzustellen. Sie stammen hauptsächlich von Entwicklern, manchmal auch von Administratoren mit einem starken Entwicklungshintergrund. Und sie tun, was Systemadministratoren zuvor getan haben, aber ein starker Hintergrund in der Entwicklung und Kenntnis des Systems in Bezug auf Code führt dazu, dass diese Personen nicht für routinemäßige Verwaltungsarbeiten anfällig sind, sondern für Automatisierung.
Es stellt sich heraus, dass das DevOps-Paradigma in SRE-Teams durch die Tatsache umgesetzt wird, dass es SRE-Ingenieure gibt, die strukturelle Probleme lösen. Hier ist es genau die Verbindung zwischen Dev und Ops, über die die Leute seit 8 Jahren gesprochen haben. Die Rolle von SRE ähnelt der eines Architekten in dem Sinne, dass dies bei SRE-Neulingen nicht der Fall ist. Menschen zu Beginn einer Karriere haben noch keine Erfahrung, verfügen nicht über die notwendige Wissensbreite. Denn SRE erfordert ein sehr genaues Wissen darüber, was genau und wann genau schief gehen kann. Daher ist hier in der Regel innerbetriebliche und außerbetriebliche Erfahrung gefragt.
Sie fragen, ob der Unterschied zwischen SRE und Devops beschrieben wird. Sie wurde gerade beschrieben. Wir können über den Platz von 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 zum anderen wechselt. Sie nehmen an Codeüberprüfungen auf die gleiche Weise teil wie beispielsweise UX-Designer, Entwickler selbst und manchmal auch Produktmanager. SRE arbeitet auf der gleichen Ebene. Wir brauchen ihr Update, wir brauchen ihre Überprüfung, damit für jede SRE-Bereitstellung steht: „Nun, diese Bereitstellung wird die Zuverlässigkeit dieses Produkts nicht beeinträchtigen. Und wenn doch, bis zu einem gewissen Grad. “ Wir werden auch darüber reden.
Dementsprechend hat der SRE ein Veto gegen die Änderung des Codes. Und im Allgemeinen führt dies auch zu einer Art kleinem Konflikt, wenn die SRE falsch implementiert wird. In demselben 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. Grundsätzlich tun dies in großen Unternehmen Einzelpersonen, Tester und Analysten. SRE interagiert jedoch auch in dem Sinne, dass einige Operationen, einige Commits, einige Bereitstellungen, die sich auf die Sicherheit auswirken, sich auch auf die Verfügbarkeit des Produkts auswirken können. Daher hat der SRE als Ganzes eine Interaktion mit allen Teams, einschließlich Sicherheitsteams, einschließlich Analysten. Daher werden meistens SREs benötigt, wenn sie versuchen, DevOps zu implementieren, aber gleichzeitig wird die Belastung der Entwickler zu groß. Das heißt, das Entwicklerteam selbst kann nicht mehr mit der Tatsache fertig werden, dass es jetzt auch für Ops verantwortlich sein muss. Und eine separate Rolle erscheint. Diese Rolle ist im Budget vorgesehen. Manchmal ist diese Rolle in der Größe des Teams festgelegt, eine separate Person erscheint, manchmal wird es einer der Entwickler. So erscheint der erste SRE im Team.
Die Komplexität des Systems, die von SRE betroffen ist, die Komplexität, die die Zuverlässigkeit der Arbeit beeinflusst, ist notwendig und zufällig. Die notwendige Komplexität liegt vor, wenn die Komplexität eines Produkts in dem Maße zunimmt, wie es neue Produkteigenschaften erfordern. Zufällige Komplexität tritt auf, wenn die Komplexität des Systems zunimmt, die Produktmerkmale und Geschäftsanforderungen dies jedoch nicht direkt beeinflussen. Es stellt sich heraus, dass entweder der Entwickler irgendwo einen Fehler gemacht hat oder der Algorithmus nicht optimal ist, oder es werden einige zusätzliche Interessen eingeführt, die die Komplexität des Produkts ohne besondere Notwendigkeit erhöhen. Ein guter SRE sollte diese Situation immer abschneiden. Das heißt, Commits, Bereitstellungen und Pull-Anforderungen, bei denen die Komplexität durch zufällige Hinzufügungen zunimmt, sollten blockiert werden.
Die Frage ist, warum man nicht einfach einen Ingenieur einstellt, einen Systemadministrator mit viel Wissen im Team. Ein Entwickler in der Rolle eines Ingenieurs, so wird uns gesagt, ist nicht die beste Personallösung. Ein Entwickler in der Rolle eines Ingenieurs ist nicht immer die beste Personallösung, aber der Entwickler, der sich mit Ops befasst, hat ein wenig mehr Verlangen nach Automatisierung und verfügt über ein wenig mehr Wissen und Fähigkeiten, um diese Automatisierung zu implementieren. Dementsprechend reduzieren wir nicht nur die Zeit für bestimmte Vorgänge, sondern auch die Routine, sondern auch so wichtige Geschäftsparameter wie MTTR (Mean Time To Recovery, Wiederherstellungszeit). Daher, und dies wird auch ein wenig später sein, sparen wir Geld für die Organisation.
Kommen wir nun zu den Kriterien für die Arbeit von SRE. Und vor allem um Zuverlässigkeit. In kleinen Unternehmen, Startups, kommt es sehr oft vor, dass die Leute annehmen, dass ein gut geschriebener Service, ein gut geschriebenes Produkt, das funktioniert und nicht kaputt geht. Das ist alles, wir schreiben guten Code, also gibt es nichts zu brechen. Der Code ist sehr einfach, es gibt nichts zu brechen. Dies sind ungefähr die gleichen Leute, die sagen, dass wir keine Tests benötigen, denn es handelt sich um drei VPI-Methoden, warum sollte man sie brechen?
Das ist natürlich alles falsch. Und diese Leute beissen sehr oft einen solchen Code in der Praxis, weil die Dinge kaputt gehen. Dinge brechen manchmal auf unvorhersehbare Weise. Manchmal sagen die Leute nein, das wird nie passieren. Und alles passiert genau. Das kommt ziemlich oft vor. Und deshalb strebt niemand nach 100% Verfügbarkeit, weil 100% Verfügbarkeit niemals vorkommt. Das ist die Norm. Wenn wir also von der Verfügbarkeit eines Dienstes sprechen, sprechen wir immer von neun. 2 Neunen, 3 Neunen, 4 Neunen, 5 Neunen. Wenn Sie dies in Ausfallzeiten umsetzen, zum Beispiel 5 Neunen, dann sind dies etwas mehr als 5 Minuten Ausfallzeit pro Jahr, 2 Neunen sind 3,5 Tage Ausfallzeit.
Es ist jedoch offensichtlich, dass der POI und die Kapitalrendite irgendwann sinken. Das bedeutet, dass die Ausfallzeit um mehr als drei Tage reduziert werden muss. Durch den Wechsel von vier auf fünf Minuten werden die Ausfallzeiten um 47 Minuten pro Jahr reduziert. Und es stellt sich heraus, dass dies für ein Unternehmen möglicherweise nicht kritisch ist. Und im Allgemeinen ist die erforderliche Zuverlässigkeit kein technisches Problem, sondern in erster Linie ein geschäftliches Problem, sondern ein Produktproblem. Welches Ausfallzeitniveau ist für Benutzer des Produkts akzeptabel, was erwarten sie, wie viel zahlen sie, zum Beispiel, wie viel Geld sie verlieren, wie viel Geld das System verliert.
Eine wichtige Frage in diesem Fall ist, wie zuverlässig die übrigen Komponenten sind. Weil der Unterschied zwischen 4 und 5 Neunen auf einem Smartphone mit 2 Neunen Zuverlässigkeit nicht sichtbar ist. Grob gesagt, wenn auf einem Smartphone in Ihrem Dienst zehnmal im Jahr etwas ausfällt, tritt der Fehler höchstwahrscheinlich achtmal genau auf der Seite des Betriebssystems auf. Der Benutzer ist daran gewöhnt und wird nicht einmal im Jahr darauf achten. Es ist notwendig, den Preis für steigende Zuverlässigkeit und steigenden Gewinn in Beziehung zu setzen.
Nur in dem Buch über SRE gibt es ein gutes Beispiel für die Erhöhung von 3 auf 4 Neunen. Es stellt sich heraus, dass die Erhöhung der Verfügbarkeit etwas weniger als 0,1% beträgt. Und wenn der Service-Umsatz 1 Million US-Dollar pro Jahr beträgt, steigt der Umsatz um 900 US-Dollar. Wenn die Erhöhung der Zugänglichkeit um neun weniger als 900 US-Dollar pro Jahr kostet, ist diese Erhöhung finanziell sinnvoll. Wenn es mehr als 900 US-Dollar pro Jahr kostet, ist es nicht mehr sinnvoll, da das Umsatzwachstum die Arbeitskosten und die Ressourcenkosten einfach nicht kompensiert. Und 3 Neunen werden für uns ausreichen.
Dies ist natürlich ein vereinfachtes Beispiel, bei dem alle Abfragen gleich sind. Und von 3 auf 4 Neunen zu wechseln ist ganz einfach, aber gleichzeitig bedeutet das Wechseln von 2 auf 3 bereits eine Einsparung von 9.000 US-Dollar. Dies kann finanziell sinnvoll sein. In Wirklichkeit ist ein Fehler bei einer Registrierungsanforderung natürlich schlimmer als ein Fehler beim Anzeigen einer Seite, da Anforderungen ein anderes Gewicht haben. Sie mögen aus geschäftlicher Sicht sehr unterschiedliche Kriterien haben, aber wenn es sich in der Regel nicht um spezifische Dienstleistungen handelt, ist dies eine ziemlich zuverlässige Annäherung.
Wir haben die Frage, ob SRE einer der Koordinatoren bei der Auswahl einer architektonischen Lösung für einen Dienst ist. Nehmen wir in Bezug auf die Integration in die bestehende Infrastruktur an, dass die Stabilität nicht beeinträchtigt wird. Ja, SREs haben die gleichen Auswirkungen auf Pull-Anforderungen, Commits und Releases. Sie wirken sich auf die Architektur, die Einführung neuer Services, Microservices und die Einführung neuer Lösungen aus. Warum habe ich vorher gesagt, dass ich Erfahrung brauche, ich brauche Qualifikationen. Tatsächlich ist SRE eine der blockierenden Stimmen in jeder Architektur- und Softwarelösung. Dementsprechend sollte der SRE als Ingenieur zuallererst nicht nur verstehen, sondern auch verstehen, wie sich bestimmte Lösungen auf die Zuverlässigkeit und Stabilität auswirken und wie sich dies auf die Geschäftsanforderungen auswirkt und von welchem Standpunkt aus dies sein kann es ist zulässig und womit nicht.
Daher können wir jetzt nur über Zuverlässigkeitskriterien sprechen, die in SRE traditionell als SLA (Service Level Agreement) definiert sind. Höchstwahrscheinlich ein vertrauter Begriff. SLI (Service Level Indicator). SLO (Service Level Objective). Service Level Agreement ist möglicherweise ein wegweisender Begriff, insbesondere wenn Sie mit Netzwerken, Anbietern und Hosting gearbeitet haben. Dies ist 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 kann SLI sein: Antwortzeit vom Service, die Anzahl der Fehler in Prozent ausgedrückt. Dies kann Bandbreite sein, wenn es um eine Art von Datei-Hosting geht. Wenn es sich um Erkennungsalgorithmen handelt, kann ein Indikator beispielsweise sogar die Richtigkeit der Antwort sein. SLO (Service Level Objective) ist eine Kombination aus SLI-Indikator, Wert und Zeitraum.
Angenommen, SLA kann so sein. Der Service 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 allmählich, dass Fehler und Ausfälle völlig normal sind. Dies ist eine akzeptable Situation, wir planen sie, wir rechnen sogar bis zu einem gewissen Grad damit. Das heißt, SRE erstellt Systeme, die Fehler machen können und die normalerweise auf Fehler reagieren, die diese berücksichtigen sollten. Und wenn möglich, sollten sie Fehler so behandeln, dass der Benutzer sie entweder nicht bemerkt oder bemerkt, aber es gibt eine Problemumgehung, aufgrund derer nicht alles vollständig herunterfällt.
Wenn Sie beispielsweise ein Video auf YouTube hochladen und YouTube es nicht sofort konvertieren kann, wenn das Video zu groß ist, wenn das Format nicht optimal ist, die Anfrage natürlich nicht aus der Zeit fällt, YouTube keinen 502-Fehler ausgibt, sagt YouTube: "Wir haben alle erstellt, Dein Video wird verarbeitet. Es wird in ungefähr 10 Minuten fertig sein. “ Dies ist das Prinzip der anmutigen Degradierung, das zum Beispiel bei der Entwicklung des Frontends bekannt ist, falls Sie dies jemals getan haben.
Die folgenden Begriffe, über die wir sprechen werden, sind sehr wichtig für das Arbeiten mit Zuverlässigkeit, Fehlern und Erwartungen: 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 dem Zeitpunkt, zu dem der Fehler erkannt wurde, vergangen ist, von dem Zeitpunkt an, zu dem der Fehler aufgetreten ist, bis zu dem Zeitpunkt, zu dem der Dienst vollständig wiederhergestellt ist. MTBF wird hauptsächlich durch Arbeiten an der Codequalität behoben. Das heißt, dass die SRE nein sagen kann. Und Sie brauchen das Verständnis des gesamten Teams, dass wenn der SRE „Nein“ sagt, er dies nicht sagt, weil er schädlich ist, nicht weil er schlecht ist, sondern weil sonst jeder leiden wird.
Auch hier gibt es viele Artikel, viele Methoden und viele Möglichkeiten, selbst in dem Buch, auf das ich so oft verweise, wie man verhindern kann, dass andere Entwickler anfangen, SRE zu hassen. Andererseits arbeitet MTTR an Ihrem SLO (Service Level Objective). Und das ist meistens Automatisierung. Weil unser SLO zum Beispiel eine Betriebszeit von 4 Neunen pro Quartal hat. Dies bedeutet, dass wir in 3 Monaten 13 Minuten Ausfallzeit einplanen können. Und es stellt sich heraus, dass wir nicht länger als 13 Minuten MTTR haben können. Wenn wir 13 Minuten auf mindestens eine Ausfallzeit reagieren, haben wir das gesamte Budget für das Quartal bereits ausgeschöpft. Wir brechen SLO. 13 Minuten für eine Reaktion und die Behebung eines Fehlers sind viel für das Auto, aber sehr wenig für eine Person. Denn solange eine Warnung an eine Person geht, während diese reagiert, bis sie den Fehler versteht, sind es schon einige Minuten. Bis eine Person versteht, wie man es repariert, was genau zu reparieren ist, was zu tun ist, sind es noch ein paar Minuten. Und in der Tat, selbst wenn Sie den Server nur neu starten müssen, wie sich herausstellt, oder einen neuen Knoten anheben, dauert die manuelle MTTR bereits etwa 7-8 Minuten. Bei der Automatisierung eines Prozesses erreicht die MTTR sehr oft eine Sekunde, manchmal eine Millisekunde. Google spricht normalerweise von Millisekunden, aber in Wirklichkeit sieht es natürlich nicht so gut aus.
Im Idealfall sollte SRE seine Arbeit fast vollständig automatisieren, da es sich direkt auf MTTR, seine Metriken, den SLO des gesamten Service und damit auf den Profit des Geschäfts auswirkt. Wenn die Zeit abgelaufen ist, fragen Sie uns, ob die Schuld bei SRE liegt. Niemand ist schuld. Und dies ist eine eigenständige Kultur, die als balsamloses Postmortem bezeichnet wird und über die wir heute nicht sprechen werden, sondern die wir anhand von Slurme analysieren werden. Dies ist ein sehr interessantes Thema, über das viel gesprochen werden kann. Grob gesagt, wenn die zugewiesene Zeit für ein Viertel überschritten wird, dann ist jeder für ein bisschen schuld, was bedeutet, dass es nicht produktiv ist, alle zu beschuldigen. Lassen Sie uns stattdessen vielleicht niemanden beschuldigen, sondern korrigieren Sie die Situation und arbeiten Sie mit dem, was wir haben. Meiner Erfahrung nach ist diese Herangehensweise an die meisten Teams, insbesondere in Russland, etwas fremd, macht aber Sinn und funktioniert sehr gut. Daher werde ich am Ende des Artikels auch die Literatur empfehlen, die zu diesem Thema gelesen werden kann. Oder kommen Sie zu Slurm SRE.
Ich werde es erklären. Wenn die SLO-Zeit pro Quartal überschritten wird, wenn die Ausfallzeit nicht 13 Minuten, sondern 15 Minuten beträgt, wer könnte daran schuld sein? Natürlich könnte SRE daran schuld sein, dass er offensichtlich eine Art schlechtes Commit oder einen schlechten Einsatz gemacht hat. Der Administrator des Rechenzentrums könnte daran schuld sein, weil er möglicherweise eine außerplanmäßige Wartung durchgeführt hat. Wenn der Administrator des Rechenzentrums die Schuld trägt, ist die Person verantwortlich, die bei der Koordination des SLO nicht mit der Wartung gerechnet hat. Der Manager, der technische Direktor oder jemand, der den Rechenzentrumsvertrag unterzeichnet und nicht darauf geachtet hat, dass das SLA-Rechenzentrum nicht für die erforderlichen Ausfallzeiten ausgelegt ist, ist schuld. Dementsprechend ist nach und nach jeder für diese Situation verantwortlich. Und das bedeutet, dass es keinen Sinn macht, jemandem in dieser Situation die Schuld zu geben. Aber natürlich müssen Sie es beheben. Daher gibt es post mortem. Und wenn Sie zum Beispiel Githubs Post-Mortem lesen, was immer eine sehr interessante, kleine und unerwartete Geschichte ist, können Sie ersetzen, dass niemand jemals behauptet hat, dass diese bestimmte Person schuld war. Schuld ist immer bestimmten unvollkommenen Prozessen zugeordnet.
Fahren wir mit der nächsten Frage fort. Automatisierung Wenn ich in anderen Kontexten über Automatisierung spreche, beziehe ich mich normalerweise auf eine Tabelle, in der angegeben ist, wie lange Sie an der Automatisierung einer Aufgabe arbeiten können, damit die Automatisierung nicht länger dauert, als Sie normalerweise sparen. Da ist ein Haken. Der Haken ist, dass SRE bei der Automatisierung einer Aufgabe nicht nur Zeit, sondern auch Geld spart, da die Automatisierung die MTTR direkt beeinflusst. Sie sparen sozusagen die Moral der Mitarbeiter und Entwickler, die auch eine erschöpfende Ressource ist. Sie reduzieren die Routine. Und das alles wirkt sich positiv auf die Arbeit und in der Folge auch auf das Geschäft aus, auch wenn Automatisierung zeitlich nicht sinnvoll erscheint.
In der Tat hat es fast immer, und es gibt sehr wenige Fälle, in denen es sich nicht lohnt, etwas in der Rolle von SRE zu automatisieren. Weiter werden wir über das sogenannte Fehlerbudget sprechen, das Budget für Fehler. In der Tat stellt sich heraus, dass, wenn alles für Sie viel besser ist als der SLO, den Sie für sich selbst festgelegt haben, dies auch nicht sehr gut ist. Dies ist ziemlich schlecht, da SLO nicht nur als Untergrenze, sondern auch als ungefähre Obergrenze funktioniert. Wenn Sie sich SLO in 99% iger Zugänglichkeit setzen und tatsächlich 99,99% haben, stellt sich heraus, dass Sie über einen Experimentierbereich verfügen, der dem Geschäft überhaupt nicht schadet, da Sie dies gemeinsam festgelegt haben und Sie der Bereich sind nicht benutzen. Sie haben ein Budget für Fehler, die in Ihrem Fall nicht aufgewendet werden.
Was machen wir mit ihm? Wir verwenden es buchstäblich für alles. Zum Testen unter Produktionsbedingungen und zur Einführung neuer Funktionen, die sich auf Leistung, Releases, Wartung und geplante Ausfallzeiten auswirken können. Die gegenteilige Regel gilt auch: Wenn das Budget erschöpft ist, können wir nichts Neues entladen, da sonst die SLO überschritten wird. Das Budget ist bereits erschöpft. Wir haben noch nichts veröffentlicht. Wenn es die Produktivität negativ beeinflusst, das heißt, wenn es sich nicht um eine Korrektur handelt, die den SLO direkt erhöht, gehen wir über das Budget hinaus. Dies ist eine schlechte Situation. Es muss analysiert werden , post mortem, und möglicherweise eine Art von Prozess zu beheben.
Das heißt, es stellt sich heraus, dass, wenn der Service selbst schlecht 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 für interessante Fixes für Entwickler interessante Features statt interessante Features Veröffentlichungen. Anstelle irgendeiner kreativen Arbeit müssen Sie dumme Korrekturen vornehmen, um das Budget wieder in Ordnung zu bringen oder SLO zu bearbeiten, und dies ist auch ein Vorgang, der nicht zu oft vorkommen 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 die Entwickler. Für Entwickler bedeutet ein großes Budget für Fehler, dass Sie sich mit Releases, Tests und Experimenten befassen können. Für SRE bedeutet das Budget für Fehler und die Eingabe in dieses Budget, dass sie ihre Arbeit direkt gut machen. Und das wirkt sich auf die Motivation für eine Art Zusammenarbeit aus. Wenn Sie als Entwickler auf Ihre SREs hören, haben Sie mehr Platz für gute Arbeit und viel weniger Routine.
Es stellt sich heraus, dass das Experimentieren in der Produktion in großen Teams ein ziemlich wichtiger und fast integraler Bestandteil von SRE ist. Und es wird normalerweise als Chaos Ingeneering bezeichnet, das vom Netflix-Team stammt, das ein Hilfsprogramm namens Chaos Monkey herausgebracht hat.
Chaos Monkey stellt eine Verbindung zur CI / CD-Pipeline her und lässt den Server in der Produktion zufällig fallen. Auch in der SRE-Struktur sprechen wir von der Tatsache, dass ein abgestürzter Server an sich nicht schlecht ist, sondern erwartet wird. Und wenn es im Budget enthalten ist, ist es akzeptabel und schadet dem Geschäft nicht. , , , , , .
- , , Chaos Gorilla, . , -, , , , . , , , . , , , - , , , , , . . , , , , , CI/CD . , , , , , , , . , , , . , .
: ? . , . , SRE . , , . , , SRE , , , , , , , . SRE , - . , SRE, - .
, , . , SRE , , . , , . , , , , , , .
, . SRE , . , , SLA, SLI, SLO. , SLA SLO, . - , , , - , , . 4 , IT , . , - .
. , - , , Objectives, , 3 .
, , . SLA, SLI, SLO, , , Objectives, SLA. , : - , , . . , -. , , , , , -, , : - . -, , . , SRE , , .
3 . , , . – , . , , , . – , . , - , - , , . – , , , . , - - , . - . , , .
, , , , , . , . . . . . , .
, Observability. . , . , Observability . - , , , . : , . , , , . , - Kubernetes, , . Observability MTTR. Observability , , , , MTTR.
, , , , SRE. . , , , SRE . , - . , , -, SRE . , , , - . , . SRE . . .
, , , . - , - . SRE, -, , . , , , .
. , , , , , , . . , . canary, , , , - , , , . , , , , .
SRE. , - , SRE, . - , - , , , canary A/B . SRE , . SRE . , , . SRE , , , , 50 50 , , SRE . . , .
. - . , SRE . , , . , , , , , , . SRE.
SRE — , , , , , , . . . Booking.com . , . - . .
, . SRE. , 2 SRE, . SLA, SLI, SLO , . 3 SRE . – Keys to SRE , . — SRE . SRE . SRE , 5 SRE 190 . , DevOps , SRE , .
2 chaos ingeneering: (1) , (2) . 3 Awesome Lists chaos ingeneering , SRE SRE . SRE , , 200 . capacity planning blameless postmortem.
: SRE as a life choice
, . , - . , , . . .
.
PS: , , . , , SRE .