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 Übernahme von Risiken ist das erste der SRE-Prinzipien, und das aus gutem Grund. Um die Zuverlässigkeit eines Systems zu verbessern, ist es wichtig, die Auswirkungen von “Was wäre wenn”-Ausfällen abzuschätzen. Es versteht sich, dass kein System zu 100 Prozent zuverlässig ist. Irgendwann wird etwas schief gehen. Leider weiß oder kümmert sich der alltägliche Benutzer oder Kunde nicht darum, so verständnisvoll zu sein. Und es gibt inhärente Kosten, die mit der Gewährleistung der Zuverlässigkeit verbunden sind. Ob das bedeutet, dass es sich um finanzielle Kosten, Zeitkosten oder einfach das Vertrauen eines Kunden in Ihre Dienstleistungen handelt.
Eine Verantwortung der SREs besteht darin, sich auf Fehler und Risiken zu stützen, um zu lernen, wie sie ihre Dienste und Systeme letztendlich widerstandsfähiger machen können. Es gibt jedoch Kompromisse, die berücksichtigt werden müssen. Beispielsweise kann die Gewährleistung maximaler Zuverlässigkeit auf Kosten einer schnelleren Bereitstellung zukünftiger Dienste gehen. Oder bedeuten weitere Verbesserungen nicht unbedingt einen deutlichen Umsatzzuwachs? Das Ziel ist es, ein zuverlässiges System zu schaffen, aber nicht mehr, als es sein muss, da die kosten und zeitlichen Kosten, die damit verbunden sind, die potenziellen Vorteile überwiegen.
Service-Level-Ziele
Das Prinzip der Risikobereitschaft ist eng mit Service-Level-Objekten oder SLOs verbunden. Um etwas tiefer zu gehen, sind SLOs die formalisierten Ziele innerhalb eines Service Level Agreements (SLA), die anhand von Service Level Indicators oder SLIs gemessen werden. SLIs sind die tatsächlichen Leistungsmetriken Ihrer Services. Wenn Ihr SLO beispielsweise angibt, dass Ihre Betriebszeit 99,9 % betragen muss, muss der tatsächliche SLI diese Leistungsmetrik erfüllen oder übertreffen, um diese spezifische SLO zu erfüllen. Die SLIs sind die Indikatoren, die ein SRE kontinuierlich überwachen würde, so dass, wenn es jemals diesen Schwellenwert überschreitet, teams alarmiert werden und das Problem schnell gelöst werden kann. SLIs sind wirklich an den Benutzer gebunden, um zu bestimmen, was für seine Erfahrung in Bezug auf den Dienst am wichtigsten ist.
SLAs vs. SLOs vs. SLIs
- SLAs. Vereinbarungen mit Ihren Kunden oder Kunden, die das Serviceniveau definieren, das geliefert werden soll.
- SLOs. Eine Vereinbarung innerhalb des SLA, die bestimmte Metriken wie Betriebszeit, Reaktionszeit, Sicherheit, Problemlösung usw. angibt.
- SLIs. Die tatsächliche Leistung oder Messungen Ihrer SLOs, die den Grad der Compliance bestimmen.
Die SLOs, die verwendet werden, um die tatsächliche Leistung anhand des SLA zu messen, bei dem es sich um die Vereinbarungen zwischen einem Dienstanbieter und dem Kunden handelt. Auch dies alles geht auf die Idee zurück, dass es eine Vereinbarung oder ein Verständnis darüber geben muss, wie viel Risiko oder Toleranz für eine bestimmte Dienstleistung zugelassen werden kann.
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 30-Tage-Testversion von Dotcom-Monitor oder vereinbaren Sie eine Demo mit einem unserer Performance-Ingenieure.
