Ist SRE (Site Reliability Engineering) die nächste Stufe von DevOps?
Die Antwort auf diese Frage lautet: SRE bildet eine Brücke zwischen DEV und OPs.
Eine logische nächste Frage wäre in diesem Fall: Ist eine Brücke notwendig?
Wir werden feststellen das es nicht ausreich, Entwickler und Betrieb in ein Team zu stecken. Es gibt einen natürlichen Interessenskonflikt. Ein Unternehmen muss also mehr tun, um die Vorteile der Arbeit im DevOps-Modus wirklich zu nutzen. Genau das tut SRE.
Die Schlüsselthemen von SRE sind Zuverlässigkeit, Skalierbarkeit, Verfügbarkeit, Leistung, Effizienz und Reaktion.
Diese sind in sieben architekturrelevant Grundsätze integriert , die dem SRE Workbook entnommen sind:
—————————————————————————————————————————
=> Der Betrieb ist ein Softwareproblem: Dies ist der Ausgagnspunkt von SRE.
Software wird sich ändern, aber der Betreib muss stabil bleiben, damit die Dienste nicht unterbrochen werden. Das bedeutet, dass die Software belastbar sein und intensiv getestet werden muss.
=> Arbeiten Sie nach Service-Level Objectives (SLOs): Setzen Sie klare Ziele für den Dienst. Wie hoch sollte die Verfügbarkeit einer Anwendung wirklich sein? Dies sind nicht nur IT-bezogene Ziele . In erster Linie geben die Geschäftsanforderungen die Parameter vor. Das bedeutet , dass die Projekte eng mit den Geschäftsinteressenten zusammenarbeiten müssen, um die Ziele zu definieren.
=> Arbeiten, um die Arbeitsbelastung zu minimieren: Wir werden noch weiter über Arbeit sprechen, aber im Prinzip bedeutet Arbeit nur Arbeit. Außerdem ist Arbeit manuelle Arbeit, die durch Automatisierung vermieden werden kann. Im Grunde besteht das Ziel von SRE darin, Computer die Arbeit so weit wie möglich für Sie erledigen zu lassen.
=> Automatisieren: Nach Grundsatz drei ist dieser logisch. Wenn Sie es automatisieren können , tun Sie es.
=> Schnell scheitern: Fehlschläge sind in Ordnung, solange sie in einem sehr frühen Stadium entdeckt werden. Die Behebung des Problems in diesem frühen Stadium entdeckt werden. Die Behebung des Problems in diesem frühen Stadium hat weitaus geringere Auswirkungen, als wenn es zu einem späteren Zeitpunkt im Entwicklungs- und Bereitstellungszyklus entdeckt und behoben wird. Außerdem führt das frühzeitige Erkennen und Beheben von Problemen zu geringeren Kosten.
=> Jedes Teammitglied ist ein Eigentümer: Dieser Punkt erfordert etwas mehr Erklärung, insbesondere in großen Unternehmen, in denen wir in der Regel eine Matrixorganisation haben. Denken Sie daran, dass viele Unternehmen mit Sourcing-Modellen arbeiten, bei denen bestimmte Lieferanten für die Infrastruktur (die Plattform) und andere Lieferanten und das Unternehmen selbst für die Anwendung (die Produkte) verantwortlich sind. Bei SRE gibt es diese Grenzen nicht. Sowohl die Produkt- als auch die Plattformteams teilen sich die Verantwortung für das Endprodukt. Daher müssen die Produkt- und Plattformteams die gleiche Sicht auf jede Komponente haben:
Anwendungsmöglichkeit, Frontend-Systeme, Backend-Infrastruktur und Sicherheitsregeln. Sie sind alle gleichberechtigte Eigentümer des Projekts.
=> Verwenden Sie einen Werkzeugsatz: Alle Teams verwenden die gleichen Tools. Sie können mehrere SRE-Teams haben, aber sie arbeiten alle mit denselben Tools. Der Grund dafür ist, dass ein Unternehmen zu viel Zeit mit der Verwaltung der verschiedenen Toolsets verbringen muss, anstatt sich auf die Projektergebnisse zu konzentrieren. Und bei SRE geht es vor allem um Konzentration.
—————————————————————————————————————————-
SRE-Architektur mit KPI‘s
Bevor wir uns mit der Definition von KPIs befassen, müssen wir auf die Grundprinzipien von SRE zurückkommen. SRE-Teams konzentrieren sich auf Zuverlässigkeit, Skalierbarkeit,Verfügbarkeit, Leistung, Effizienz und Reaktion. Dies alles sind messbare Größen, die wir in KPIs umwandeln können.
Die wichtigsten KPIs , die wir in SRE verwenden, sind die folgenden:
—————————————————————————————————————————
=> SLOs: In SRE wird damit definiert, wie gut ein System sein sollte. Ein SLO ist viel präziser als ein SLA, das eine Vielzahl verschiedener KPI umfasst. Man könnte auch sagen, dass das SLA eine Reihe von SLOs umfasst. Ein SLO ist jedoch eine Vereinbarung zwischen den Entwicklern im SRE-Team und dem Product Owner des Dienstes, während ein SLA eine Vereinbarung zwischen dem Dienstanbieter und dem Endbenutzer ist. Die SLO ist ein Zielwert. Zum Beispiel sollte das Eb-Frontend in der Lage sein, Hunderte von Anfragen pro Minute zu verarbeiten. Machen Sie es am Anfang nicht zu komplex. Durch die Festlegung dieses SLO hat das Team bereits eine Reihe von Herausforderungen, um dieses Ziel zu erreichen, da es nicht nur das Frontend betrifft , sondern auch den Durchsatz z.B. im Netzwerk und in den beteiligten Datenbanken. Mit anderen Worten: Durch die Festlegung dieses einen Ziels haben die Architekten und Entwickler eine Menge zu tun, um dieses Ziel zu erreichen.
=> SLIs: SLOs werden durch SLIs gemessen. Bei SRE gibt es einige Indikatoren, die wirklich wichtig sind: Anfragelatenz, Systemdurchsatz, Verfügbarkeit und die Fehlerquote. Dies sind die wichtigsten SLIs, die messen, wie gut ein System wirklich ist. Die Anfragelatenz misst die Zeit , bis ein System eine Antwort zurückgibt. Der Systemdurchsatz ist die Anzahl der Anfragen pro Sekunde oder MInute. Die Verfügbarkeit ist der Zeitraum, in dem ein System für den Endbenutzer nutzbar ist. Die Fehlerquote ist der prozentuale Anteil an der Gesamtzahl der Anfragen und der Anzahl der Anfragen, die erfolgreich zurückgegeben werden.
=> Fehlerbudget: Dies ist wahrscheinlich der wichtigste Begriff in SRE. Die SLO definiert auch das Fehlerbudget. Das Budget beginnt bei 100 und wird durch Abzug der SLO berechnet. Wenn wir zum Beispiel ein SLO haben, das besagt, dass die Verfügbarkeit eines Systems 99,9% beträgt, dann ist das Fehlerbudget 100-99,9 = -0,1. Dies ist der Spielraum, den die SRE-Teams haben, um Änderungen vorzunehmen, ohne die SLO zu beeinträchtigen. Dies zwingt die Entwickler im SRE-Team, entweder die Anzahl der Änderungen und Freigaben zu begrenzen oder so viel wie möglich zu testen und zu automatisieren, um eine Unterbrechung des Systems und eine Überschreitung des Fehlerbudgets zu vermeiden.
Um das Konzept des Fehlerbudgets in SRE zu verstehen, ist es wichtig zu wissen, wie SRE die Verfügbarkeit von Systemen behandelt . Es geht nicht einfach darum, die Ausfallzeit abzuziehen, um die Verfügbarkeit von Systemen zu erreichen. SRE berücksichtigt auch fehlgeschlagene Anfragen. Eine fehlgeschlagene Anfrage kann darauf zurückzuführen sein, dass ein System nicht oder nur langsam antwortet. Die Erkennung fehlgeschlagener Anfragen bestimmt die Verfügbarkeit und damit, ob das Fehlerbudget überschritten wird oder nicht. Wichtige Parameter sind folgende:
=> TTD: Die Zeit bis zur Erkennung eines Problems in einer Software oder einem System.
=> TTR: Die Zahl zur Lösung oder Reparatur des Problems
=> Häufigkeit/Jahr: Die Fehlerhäufigkeit pro Jahr.
=> Benutzer: Die Anzahl der Benutzer, die von dem Fehler betroffen sind.
=> Schlecht/Jahr: Die Anzahl der Munuten pro Jahr, in denen ein System nicht nutzbar ist, oder die schlechten Minuten pro Jahr.
Implementierung von SRE
Bislang haben wir und angesehen , was SRE ist und was die wichtigsten Elemente sind. Wie bei DevOps lautet der Rat, klein anzufangen. Es gibt zwei wichtige Schritte , die helfen SRE auf kontrollierte Weise zu implementieren
—————————————————————————————————————————-
=> Einigen Sie sich auf Standards und Praktiken: Dies kann nur für ein SRE-Team oder für das gesamte Unternehmen gelten, wenn der Ehrgeiz so groß ist.
Dies kann ein praktikabler Ansatz für Unternehmen mit einer begrenzten Anzahl von Anwendungen sein, aber für Unternehmen ist es vielleicht sinnvoller, mit einer SRE-Team-Charta zu arbeiten. Lassen Sie uns mit einem sehr gängigen Beipiel arbeiten. Unternehmen haben in der Regel Produktteams, die an Anwendungen arbeiten, und ein Plattformteams, das für die Infrastruktur zuständig ist. Es ist eine gute Praxis , ein SRE-Team zu haben, das eine Brücke zwischen einem Produktteam und dem Plattformteams schlägt und Standards und Praktiken für diesen speziellen Bereich festlegt.
Das Produktteam konzentriert sich auf die Bereitstellung der Anwendung und arbeitet natürlich eng mit dem Plattformteams zusammen. Das SRE-Team kann dies lenken und Standards für die Zuverlässigkeit des Endprodukts festlegen. Das bedeutet , dass SRE-Teams mehrere Bereiche abdecken müssen.
Google nennt drei Einstiegskriterien, um mit SRE zu beginnen:
=> Die SLOs wurden definiert und mit den Geschäftsinhabern vereinbart.
=> Es können tadellose Obduktionen durchgeführt werden.
=> Das Unternehmen verfügt über einen Prozess zur Verwaltung von Produktionsproblemen. Dabei kann es sich um den Standardprozess für das Incident Management handeln, wie er in IT Service Management Frameworks wie ITIL definiert ist.
Wo setzt SRE an und wie beginnen die Teams ihre Arbeit?
=> SRE-Spezialisten werden im UNternehmen eingestellt oder geschult.
=> Freigabeprozesse werden dokumentiert und von SRE-Spezialisten bewertet.
=> Betriebliche Prozesse werden dokumentiert, einschließlich Runbooks für Freigaben und Übergabe an den Betrieb. Diese Prozesse werden von SRE-Spezialisten evaluiert.
=> Es wurden SLOs definiert und vereinbart.
=> SRE-Teams sind beauftragt, Prozesse anzupassen und zu implementieren , die den Arbeitsaufwand verringern. Die Zusammenarbeit mit den Entwicklern und dem Betrieb , die zu einem Buy-in führt , ist eine Voraussetzung.
SRE-Teams können dies für alle neuen und bestehenden Prozesse tun:
=> SLO und Überprüfung des Fehlerhaushalts
=> Bewertungen von Vorfällen
=> Test- und R-unhook-Überprüfungen
=> Sicherheitsprüfungen
Bevor das Team jedoch wirklich loslegen kann, muss die Organisation klare Prioritäten setzen. Wie wir gelernt haben, wird SRE einen Kulturwandel auslösen, und die gesamte Organisation muss die Einführung von SRE unterstützen.
Die Idee der Pyramide ist, dass die Elemente am unteren Ende die Grunlagen sind, die zuerst implementiert werden müssen; sie bilden das Fundament. Von dort aus schreitet die Umwandlung zu fortgeschritteneren Elementen voran, wie z.B. Die Freigabekette bei der Entwicklung und Bereitstellung neuer Produkte an der Spitze der Pyramide.
Die Unternehmen von heute befinden sich in einem ständigen Wandel. Das setzt den Betrieb stark unter Druck, der einerseits mit den Entwicklungen Schritt halten muss und andererseits die Systeme stabil und zuverlässig halten muss. Ohne echte Zusammenarbeit zwischen Entwicklern und Betrieb ist das praktisch unmöglich. SRE geht die Herausforderung an. SRE hat erkannt, dass es das Problem nicht löst, wenn Entwickler und Betrieb in einem Raum zusammensitzen. SRE schafft eine Lösung, die betriebliche Probleme reduziert, indem sie Entwicklern hilft, zuverlässige Systeme zu erstellen.
Die wichtigsten Komponenten sind folgende:
=> Standardisierung: Standardisierung von Prozessen und Werkzeugen.
=> Automatisierung: Automatisierung führt zu Konsistenz, aber Automatisierung ermöglicht auch Skalierung. Dies erfordert eine sehr gut durchdachte Architektur. Bei der Automatisierung geht es darum, etwas einmal zu tun und dann den Rest der Automatisierung zu überlassen. Ohne Automatisierung würde der Betrieb einfach in manuellen Aufgaben ertrinken.
=> Beseitigen Sie mühsame Arbeit: Arbeit ist manuelle , sich wiederholende Arbeit, die automatisiert werden kann. Aber Arbeit ist auch Arbeit, die keinen Mehrwert für das Produkt schafft: Sie unterbricht und verlangsamt die Entwicklung von Dienstleistungen, die einen Mehrwert schaffen.
=> Einfachheit: Als Voraussetzung für ein stabiles , zuverlässiges System muss die Software einfach sein. Der Code muss einfach und sauber und die APIs so minimal wie möglich sein. SRE lebt nach der goldenen Regel „weniger ist mehr“.
Die hier in der Grafik aufgeführten Themen dienen zur Vertiefenden Beschäftigung mit SRE.
Post‘s werden folgen
Von unten nach oben dargestellt in der Grafik
Monitoring
Reaktion auf Vorfälle (Incident Response)
Postmortems
Testen und Freigeben
Kapazitätsplanung
Dev
UX
Zugehörige Post‘s:
Erster Teil:
https://einsiedlerkreps.blogspot.com/2023/05/devops-noops-devsecops-sre-aus-der.html
Zweiter Teil: DevOps:
https://einsiedlerkreps.blogspot.com/2023/05/devops-nahere-erlauterung-teil-ii.html
Keine Kommentare:
Kommentar veröffentlichen