In einem unserer vorherigen Artikelhaben wir besprochen, was ein SRE ist, was er tut und einige der gemeinsamen Verantwortlichkeiten, die ein typischer SRE haben kann, wie z. B. die Unterstützung von Operationen, den Umgang mit Trouble Tickets und Incident Response sowie die allgemeine Systemüberwachung und -beobachtbarkeit. In diesem Artikel werden wir einen tieferen Einblick in die verschiedenen SRE-Prinzipien und -Richtlinien geben, die ein Site Reliability Engineer in seiner Rolle praktiziert. Wie DevOps dienen diese SRE-Prinzipien als Leitfaden, um die Ausrichtung in Bezug auf die Ausrichtung, Erfüllung und Unterstützung der Ziele der Organisation voranzutreiben.
Google war das erste Unternehmen, das die Rolle des Site Reliability Engineering geschaffen, angenommen und unterstützt hat. Seitdem hat sich die SRE-Rolle weiterentwickelt, da sich die Branche verändert und von den traditionellen monolithischen Strukturen zu großen, weit verteilten Netzwerken und Microservices verlagert hat. Eines ist jedoch weitgehend gleich geblieben – die Prinzipien, an die sich SREs halten. Diese SRE-Kernprinzipien konzentrieren sich auf eine Sache: Fahrsystem und Servicezuverlässigkeit. Lassen Sie uns tiefer in diese Kernprinzipien der SRE eintauchen.
SRE-Grundsätze
Risiken annehmen und managen
Die Akzeptanz von Risiken ist tatsächlich eines der Kernprinzipien von SRE, und es ist leicht zu verstehen, warum. Um ein System zuverlässiger zu machen, müssen Sie “Was-wäre-wenn”-Szenarien in Betracht ziehen und aus potenziellen Fehlern lernen. Kein System ist jemals zu 100 % zuverlässig und irgendwann muss etwas schief gehen. Leider wissen die meisten Nutzer nichts über diese Realität Bescheid (oder kümmern sich nicht besonders darum). Sie wollen nur, dass die Dinge funktionieren, und das Erreichen dieser Zuverlässigkeit hat immer ihren Preis, sei es in Bezug auf Geld, Zeit oder sogar die Aufrechterhaltung des Kundenvertrauens.
Für SREs ist es wichtig, sich auf Risiken zu konzentrieren und aus Fehlern zu lernen, um widerstandsfähige Systeme aufzubauen. Aber es gibt immer Kompromisse, die man abwägen muss. Die Maximierung der Zuverlässigkeit kann bedeuten, das Tempo neuer Funktionen zu verlangsamen, oder sie kann zu höheren Kosten führen, ohne dass der Umsatz stark gesteigert wird. Die Idee ist nicht, ein System zuverlässiger zu machen, als es eigentlich sein müsste. Denn wenn der zusätzliche Aufwand und die Ressourcen keinen sinnvollen Mehrwert bringen, sollten sie besser an anderer Stelle ausgegeben werden. Bei SRE geht es darum, das “genau richtige” Maß an Zuverlässigkeit zu finden, das Kosten, Geschwindigkeit und Wert in Einklang bringt.
Service-Level-Ziele
Das Prinzip der Risikobereitschaft ist eng mit den Service Level Objectives (SLOs) verbunden. Um es aufzuschlüsseln: SLOs sind spezifische Leistungsziele innerhalb eines Service Level Agreements (SLA), die an Service Level Indicators (SLIs) gemessen werden, den eigentlichen Metriken, die die Leistung Ihres Service verfolgen. Wenn Ihr SLO beispielsweise angibt, dass die Betriebszeit 99,9 % betragen sollte, misst das SLI, ob Sie diese Marke erreichen. Diese SLIs werden kontinuierlich von SREs überwacht, so dass das Team benachrichtigt wird und schnell reagieren kann, wenn die Leistung unter den vereinbarten Schwellenwert fällt. Bei SLIs geht es letztendlich darum, was für die Benutzer am wichtigsten ist, und Teams dabei zu helfen, Serviceaspekte zu priorisieren, die sich direkt auf die Benutzererfahrung auswirken.
Hier ist eine kurze Aufschlüsselung dieser Begriffe:
- SLAs: Die allgemeinen Vereinbarungen mit Kunden oder Kunden über das zu erbringende Serviceniveau.
- SLOs: Bestimmte Leistungsziele innerhalb der SLA, z. B. Betriebszeit, Reaktionszeit oder Sicherheitsstandards.
- SLIs: Die tatsächlichen Leistungsmessungen, mit denen die Einhaltung der SLOs verfolgt wird.
Im Wesentlichen ermöglichen SLOs den Teams, die reale Leistung anhand des SLA zu messen und klare Erwartungen an die Servicequalität zu setzen. Diese Struktur unterstreicht, dass es eine vereinbarte Risikotoleranz gibt, indem sie definiert, wie viel Variabilität oder Ausfallzeit ein Dienst aushalten kann, während er gleichzeitig die Benutzerbedürfnisse und Geschäftsziele erfüllt.
Lesen Sie:Erfahren Sie mehr über die Verwaltung der SLA-Compliance in Ihrem Unternehmen.
Beseitigen Sie die Arbeit
Arbeit, wie sie mit dem Umfang der SRE-Rolle definiert ist, ist der Umfang an manueller Arbeit, der erforderlich ist, um sicherzustellen, dass Dienste ausgeführt werden. Eines der Hauptziele eines SRE ist es, so viel Arbeit wie möglich zu automatisieren. Dadurch können SREs mehr Zeit für wichtigere Aufgaben eröffnen. Und wenn Sie darüber nachdenken, sollte die Verringerung der Arbeit wirklich ein Teil der Arbeit eines jeden sein. Je weniger Zeit für redundante Aufgaben benötigt wird, desto mehr Produktivität wird auf lange Sicht sichergestellt. Jedes Mal, wenn ein Zuverlässigkeitsingenieur am Standort sich wiederholende manuelle Aktivitäten ausführen muss, da er sich auf die Verwaltung des Produktionsdienstes bezieht, kann dies als Mühe bezeichnet werden.
In vielen Fällen kann es Vorkommen geben, in denen ein SRE manuelle, zeitaufwändige Aktivitäten ausführen muss, aber nicht alle sollten als Arbeit definiert werden. Es ist jedoch wichtig zu definieren, welche Aktivitäten innerhalb des SRE-Teams die meiste Zeit in Anspruch nimmt. Identifizieren Sie von dort aus, wo Verbesserungen vorgenommen werden können, um die Menge an Arbeit für eine bessere Arbeitsbalance zu reduzieren. Als Google zum ersten Mal die Rolle von SRE einführte, setzten sie sich das Ziel, dass sich die Hälfte der Zeit eines SREs darauf konzentrieren sollte, die zukünftige betriebliche Arbeit zu reduzieren oder Servicefunktionen hinzuzufügen. Die Entwicklung neuer Funktionen korreliert mit der Verbesserung von Metriken wie Zuverlässigkeit und Leistung, was letztendlich die potenzielle Arbeit auf der anderen Linie reduziert.
Überwachung
Bei Dotcom-Monitor dreht sich alles um Überwachungslösungen zur Verfolgung von Betriebszeit, Verfügbarkeit, Funktionalität und Rundum-Performance von Servern, Websites, Diensten und Anwendungen. Monitoring ist eines der wichtigsten SRE-Prinzipien innerhalb der Rolle. Die kontinuierliche Überwachung stellt sicher, dass die Dienste wie vorgesehen funktionieren und kann dazu beitragen, den Moment zu identifizieren, in dem Probleme auftreten, damit sie sofort behoben werden können. Wie bereits im vorherigen Abschnitt erwähnt, ist die Einhaltung dieser SLOs der Schlüssel zu den definierten Geschäfts-SLAs und letztendlich zu den Benutzern. Die Überwachung kann SREs und Teams einen historischen Leistungstrend liefern und Einen Einblick in ein einmaliges Problem im Vergleich zu einem umfassenderen, systemischen Problem geben. Wie von der Google SRE-Initiative definiert, umfassen die vier goldenen Signale der Überwachung die folgenden Metriken:
- Latenz. Latenz ist die Zeit oder Verzögerung, die ein Dienst benötigt, um auf eine Anforderung zu antworten. Es ist klar, dass langsame Reaktionszeiten die wahrgenommene Benutzererfahrung beeinflussen. Überwachung kann eine Möglichkeit bieten, zwischen
- Verkehr. Datenverkehr bezieht sich auf die Menge der Benutzernachfrage oder -last auf dem System. Dies kann durch HTTP-Anfragen pro Sekunde oder abhängig vom tatsächlichen Dienst gemessen werden.
- Fehler. Fehler beziehen sich auf die Rate, mit der Anforderungen an den Dienst fehlschlagen. Für SRE-Teams ist es jedoch wichtig, zwischen harten Ausfällen wie 500 Serverfehlern und weichen Fehlern wie einer Antwort von 200 OK zu unterscheiden, bei der eine Zeit überschritten wurde, weil ein bestimmter Leistungsschwellenwert festgelegt wurde. Es ist wichtig zu überlegen, wie diese verschiedenen Szenarien wie diese angemessen überwacht werden können.
- Sättigung. Bei der Sättigung geht es darum, zu messen, wie viele Systemressourcen ein bestimmter Dienst hat. Bis zu einem bestimmten Punkt wird es bei den meisten Diensten zu Leistungseinbußen kommen. Zu verstehen, wo dies geschieht, kann helfen, Überwachungsziele und -ziele richtig zu definieren, so dass Korrekturmaßnahmen durchgeführt werden können.
Automatisierung
Automatisieren, automatisieren, automatisieren. Wir haben dieses Prinzip vorhin angesprochen, als wir über die Verringerung der Arbeit diskutiert haben, aber es kann nicht unterschätzt werden. Die Art der SRE-Rolle ist so vielfältig, wie eine Rolle sein kann. Um das Potenzial für manuelle Eingriffe in alle Facetten ihrer Verantwortlichkeiten zu reduzieren, ist die Automatisierung von Aufgaben der Schlüssel zu einem erfolgreichen Unternehmen. Da Services skaliert und immer weiter verteilt werden, wird es viel schwieriger zu verwalten. Durch die Automatisierung sich wiederholender Aufgaben auf breiter Front, sei es beim Testen, bei der Softwarebereitstellung, bei Vorfällen oder einfach bei der Kommunikation zwischen Teams, bietet die Automatisierung unmittelbare Vorteile, Effizienz und vor allem Konsistenz. Seit der Konzeption der SRE-Rolle hat sich die Art und Weise, wie Entwicklungs-, QA- und Operationsteams zusammenarbeiten, verändert. Um diese neue DevOps-Umgebung und -Praktiken zu unterstützen, wurden verschiedene Plattformen und Tools entwickelt.
LesenSie: Top 13 Site Reliability (SRE) Tools.
Release-Engineering
Release-Engineering. Klingt nach einem komplexen Thema, aber in Wirklichkeit ist es nur eine einfache Möglichkeit, zu definieren, wie Software erstellt und bereitgestellt wird. Während Release Engineering an sich sein eigener Titel und seine eigene Rolle ist, bedeutet dies innerhalb des Konzepts von SRE, Dienste bereitzustellen, die stabil, konsistent und natürlich wiederholbar sind. Dies geht auf den vorherigen Abschnitt über Automatisierung zurück. Wenn Sie etwas tun, tun Sie es richtig UND können Sie das bei Bedarf konsequent wiederholen. Der Aufbau einer Reihe von einmaligen Diensten ist zeitaufwendig und verursacht unnötige Mühen.
Wenn wir auf die Geschichte der SRE-Position bei Google zurückgehen, hatten sie engagierte Release-Ingenieure, die direkt mit SREs arbeiteten. Release-Ingenieure haben in der Regel die Aufgabe, Best Practices für die Entwicklung von Softwarediensten, die Bereitstellung von Updates, kontinuierliche Tests und die Behebung von Softwareproblemen sowie viele andere Verantwortlichkeiten zu definieren. Diese Rolle wird immer wichtiger, wenn Sie darüber nachdenken, wie Sie Dienste skalieren und schnell bereitstellen können. Eine Reihe von Best Practices und Tools (und deren Durchsetzung) ist unerlässlich, um diese Anforderungen erfüllen zu können, und gibt den SRE-Teams Sicherheit, sobald dieser Build in Produktion geht.
Einfachheit
Mit einer Position, die scheinbar kein Ende der Anzahl der Verantwortlichkeiten und Erwartungen hat, wie die SRE-Rolle, ist das letzte Prinzip ironischerweise Einfachheit. Vielleicht leichter gesagt als getan in der Praxis, konzentriert sich dieses Prinzip auf die Idee, ein System oder eine Dienstleistung zu entwickeln, die nur so komplex wie nötig ist. Während das auf den ersten Blick kontraintuitiv erscheinen mag, läuft es wirklich darauf hinaus, ein System zu wollen, das zuverlässig, konsistent und vorhersehbar ist. Das mag langweilig klingen, aber für einen SRE ist das eines der ultimativen Endziele.
SREs streben nach einem System oder Service, der nicht komplex oder schwer zu verwalten ist. SREs wollen eine, die einfach die Arbeit erledigt, für die sie entwickelt wurde. Aus der Sicht eines Benutzers kann ein Dienst, der viele Funktionen bietet, jedoch auch viele Vorteile bieten, aber für einen SRE bedeutet das nur mehr potenzielle Kopfschmerzen. Änderungen sind jedoch immer unvermeidlich, wenn Sie einem Webdienst neue Funktionen hinzufügen möchten, tun Sie dies mit Bedacht. Kleinere, inkrementelle Änderungen sind einfacher (und einfacher) zu verwalten, als viele Funktionen gleichzeitig aufzubauen und zu versenden. SREs müssen auch die Bedürfnisse und Ziele des Unternehmens berücksichtigen.
SRE-Prinzipien: Die 7 Grundregeln – Abschließende Gedanken
Die SRE-Rolle konzentriert sich auf den Aufbau, die Bereitstellung und die Wartung zuverlässiger Systeme und Dienste in großem Maßstab. Diese sieben Kernprinzipien helfen bei der Definition der Praktiken für SREs, die dazu beitragen, die Ausrichtung innerhalb der DevOps-Praktiken zu fördern und die Ziele des Unternehmens zu unterstützen. Es ist eine komplexe Rolle, die versucht, Zuverlässigkeit mit Feature-Releases in Einklang zu bringen und gleichzeitig ein außergewöhnliches Qualitätsniveau beizubehalten.
Die Dotcom-Monitor-Plattform bietet SREs alle Überwachungsfunktionen, die sie benötigen, um die Kontinuität ihrer Dienste zu gewährleisten. Von konfigurierbaren Warnungen und Berichten bis hin zu Echtzeit-Dashboards und -Berichten bietet die Plattform die wesentlichen Tools, die erforderlich sind, um die Leistung aller ihrer Dienste langfristig zu verwalten. Erstellen Sie beispielsweise Webanwendungsskripts basierend auf Benutzerverhalten, Aktionen und Pfaden und richten Sie synthetische Überwachungsaufgaben ein, um eine konsistente Erfahrung im Laufe der Zeit sicherzustellen. Unabhängig davon, wie wichtig die Überwachung Ihres Teams ist, gibt es eine Lösung, die Ihren Anforderungen entspricht.
Starten Sie kostenlos mit der kostenlosen Testversion von Dotcom-Monitor oder vereinbaren Sie einen Termin für eine Demo mit einem unserer Performance-Ingenieure.
