Site Reliability Engineering ist das, was entsteht, wenn du den Betrieb als Softwareproblem behandelst: ein Team von Engineers, das die Zuverlässigkeit eines Produktionsservice verantwortet, sie aus Sicht der Nutzer misst und mindestens die Hälfte seiner Zeit damit verbringt, Code zu schreiben, der Betriebsarbeit abschafft, statt diese Arbeit von Hand zu erledigen. Ein SRE ist kein umbenannter Sysadmin und kein DevOps Engineer mit Pager. Die Rolle hat einen definierten Zuständigkeitsbereich, einen definierten Satz an Dingen, die sie beobachtet, und eine definierte Beziehung zu den Entwicklern. Dieser Beitrag behandelt alle drei.

Dies ist Teil 1 von Budget for Failure, einer vierteiligen Serie darüber, was Site Reliability Engineering ist und wie man es betreibt. Teil 1 und 2 sind 101-Level: die Rolle, dann die Zahlen, mit denen sie arbeitet (SLI, SLO, SLA, Error Budgets). Teil 3 und 4 sind 201-Level: was ein SRE in der Codebase beherrschen muss und was auf der Provider-Seite zu prüfen ist, egal ob das eine Cloud oder dein eigenes Rechenzentrum ist. Die Beispiele laufen auf AWS; die Praxis ist nicht AWS-spezifisch.

Woher die Rolle kommt

Der Begriff stammt von Google, wo Ben Treynor Sloss 2003 das erste Team aufbaute und es später im SRE Book in einem Satz beschrieb: SRE ist das, was passiert, wenn man einen Software Engineer bittet, ein Operations-Team zu entwerfen. Die Antwort des Engineers auf einen wachsenden Service war nicht, Operatoren proportional zum Traffic einzustellen. Sie war, die Arbeit des Operators zu automatisieren und eine harte Obergrenze dafür zu setzen, wie viel manuelle Arbeit das Team annehmen darf.

Das Verhältnis zu DevOps wird, wieder von Google, meist so zusammengefasst: "class SRE implements interface DevOps". DevOps ist ein Satz von Prinzipien: geteilte Verantwortung, kleine Änderungen, Automatisierung, Messung. SRE ist eine konkrete Implementierung dieser Prinzipien mit angehängten Meinungen, etwa dazu, wie genau Zuverlässigkeit gemessen wird und was genau passiert, wenn die Messung sagt, dass ein Service nicht zuverlässig genug ist.

Wofür ein SRE verantwortlich ist

Das SRE Book fasst den Zuständigkeitsbereich in einem Satz: Ein SRE-Team ist verantwortlich für Verfügbarkeit, Latenz, Performance, Effizienz, Change Management, Monitoring, Notfallreaktion und Kapazitätsplanung seiner Services. Aufgeschlüsselt auf eine Arbeitswoche heißt das:

  • Verfügbarkeit und Latenz. Festlegen, was "funktioniert" für Nutzer als Zahl bedeutet, sie messen und sie verteidigen. Teil 2 handelt ausschließlich davon.
  • Change Management. Die meisten Ausfälle werden durch eine Änderung verursacht. Der SRE verantwortet die Maschinerie, die Änderungen sicher macht: progressive Rollouts, automatisiertes Rollback und den Nachweis, dass ein Release gesund ist.
  • Monitoring und Alerting. Entscheiden, welche Signale um 03:00 Uhr einen Menschen verdienen und welche auf ein Dashboard gehören. Ein Page, der keine Aktion erfordert, ist ein Defekt im Alerting, und der SRE behebt ihn wie jeden anderen Defekt.
  • Notfallreaktion. On-Call sein, Incidents mit klarer Kommandostruktur führen und erst den Service wiederherstellen, dann diagnostizieren.
  • Postmortems. Nach einem Incident eine schriftliche, blameless Analyse dessen, was passiert ist und welcher systemische Fix diese Klasse von Fehlern verhindert. Blameless ist eine technische Anforderung: Wer Bestrafung erwartet, hört auf zu berichten, was er gesehen hat.
  • Kapazitätsplanung. Wissen, wie viel Headroom vorhanden ist, wie die Nachfrage wächst und wie lange neue Kapazität braucht, in Minuten in der Cloud, in Monaten on-prem.
  • Effizienz und Performance. Zuverlässigkeit, erkauft mit unbegrenzter Reservekapazität, ist kein Engineering. Kosten pro Request sind auch eine SRE-Zahl.
  • Toil eliminieren. Weiter unten behandelt, denn es ist der Teil, der den Rest erst möglich macht.

Worauf ein SRE schaut

Ein DevOps Engineer, der von der Infrastruktur kommt, beobachtet meist Ressourcen: CPU, Memory, Disk, Node-Anzahl. Ein SRE beginnt eine Ebene höher, bei dem, was der Nutzer erlebt hat, und nutzt Ressourcenmetriken nur, um es zu erklären. Der Standard-Einstieg sind die vier Golden Signals aus dem Monitoring-Kapitel des SRE Book:

SignalWelche Frage es beantwortetWo es auf AWS liegt
LatenzWie lange dauern Requests, getrennt nach Erfolg und Fehler?ALB TargetResponseTime Perzentile, API Gateway Latency, Application Traces
TrafficWie viel Last liegt auf dem System?ALB RequestCount, gesendete SQS-Nachrichten, Lambda Invocations
ErrorsWelcher Anteil der Requests schlägt fehl?ALB HTTPCode_Target_5XX_Count und HTTPCode_ELB_5XX_Count, Lambda Errors
SaturationWie voll ist die knappste Ressource?RDS-Verbindungen gegen max_connections, Queue-Alter, ECS CPU Reservation, Service-Quota-Auslastung

Zwei Details trennen die SRE-Lesart dieser Signale von einer beiläufigen. Latenz wird als Verteilung gelesen, nie als Durchschnitt: Das 99. Perzentil ist dort, wo die unzufriedenen Nutzer sitzen. Und Saturation wird gegen das Limit gelesen, das tatsächlich zuerst erreicht wird, und das ist selten die CPU. Es ist der Datenbank-Connection-Pool, die Port-Zuteilung des NAT Gateway, die Lambda-Concurrency auf Account-Ebene oder das IOPS-Budget des EBS-Volumes.

Über die vier Signale hinaus beobachtet ein SRE die Dinge, die den Incident des nächsten Monats vorhersagen: Rate und Fehlerrate von Änderungen, das Alter der ältesten ungepatchten Abhängigkeit, wie viel der letzten Woche für manuelle Arbeit draufging und wie viele Pages der On-Call Engineer bekommen hat.

Die 50-Prozent-Regel und Toil

Das Merkmal, das SRE von einem Operations-Team mit besserem Titel unterscheidet, ist eine Obergrenze. In Googles Modell verbringt ein SRE mindestens 50 Prozent seiner Zeit mit Engineering-Arbeit, gemittelt über einige Quartale. Der Rest darf in Betriebsarbeit gehen: Tickets, On-Call, manuelle Aufgaben.

Der manuelle Teil hat einen Namen, Toil, und eine präzise Definition: Arbeit, die mit dem Betrieb eines Produktionsservice verbunden ist und dazu neigt, manuell, repetitiv, automatisierbar, taktisch und ohne bleibenden Wert zu sein, und die linear mit dem Service wächst. Einen hängenden Worker neu starten, ein Zertifikat von Hand rotieren, einen Quota-Antrag genehmigen, eine Datenbank für einen Entwickler kopieren. Jedes für sich ist klein. Zusammen sind sie der Grund, warum ein Team von fünf Leuten kein Engineering mehr schafft.

Die Obergrenze ist das, was dem SRE die Position verschafft, Nein zu sagen. Wenn Toil über die Hälfte der Teamzeit steigt, ist die Antwort kein Heldentum. Sie lautet, die größte Quelle zu automatisieren oder die Betriebslast an das Team zurückzugeben, das sie erzeugt, bis sie schrumpft. On-Call folgt derselben Logik: Das SRE Book setzt eine tragbare Last bei etwa zwei Incidents pro On-Call-Schicht an, denn jeder Incident braucht Nachbereitung und ein Postmortem, und wer fünf Pages pro Nacht bekommt, macht keines von beidem.

Wie ein SRE Entwicklern hilft

Die schlechteste Version dieser Rolle ist ein Gate: Entwickler werfen ein Release über die Mauer, und ein Reliability-Team entscheidet, ob es passieren darf. Die nützliche Version behandelt Entwickler als Kunden und Zuverlässigkeit als Produkt, das der SRE für sie baut. Vier konkrete Formen:

Die Paved Road. Ein Service-Template, das mit strukturiertem Logging, Metriken, Tracing, Health Checks, einer Deployment-Pipeline mit Canary und Rollback und bereits verdrahteten, vernünftigen Alarmen ankommt. Ein Entwickler, der den Default nimmt, bekommt einen zuverlässigen Service, ohne ein Runbook zu lesen. Das ist das Wertvollste, was ein SRE-Team ausliefert.

Das Production Readiness Review. Bevor ein neuer Service echten Traffic bekommt, geht der SRE ihn mit den Entwicklern durch: Wovon hängt er ab, was passiert, wenn jede einzelne Abhängigkeit langsam ist, wie sind die Timeouts, wie wird zurückgerollt, wer wird gepaged. Es ist ein Review des Designs, früh genug gemacht, um das Design noch zu ändern. Teil 3 geht durch, worauf zu achten ist.

Das Error Budget. Eine gemeinsame, vorab vereinbarte Zahl, die beiden Seiten sagt, wann es sicher ist, schnell auszuliefern, und wann es Zeit ist, langsamer zu werden. Sie ersetzt die Diskussion darüber, ob ein Release "zu riskant" ist, durch einen Messwert. Teil 2 baut sie auf.

Geteilter On-Call. Entwickler, die den Pager für ihren eigenen Service tragen, schreiben anderen Code. Viele Organisationen starten einen Service in der Rotation der Entwickler und übergeben ihn erst dann an SRE, wenn er eine Zuverlässigkeitsschwelle erreicht, und geben ihn zurück, wenn er darunter fällt. Der Job des SRE ist es, diese Rotation menschlich zu machen, mit guten Alerts und guten Runbooks, nicht den Schmerz zu absorbieren, damit ihn upstream niemand spürt.

SRE und DevOps: Wo sich die Arbeit unterscheidet

Wenn du beruflich Pipelines, Terraform und Kubernetes betreibst, nimmst du den Großteil des Toolings mit. Was sich ändert, ist die Frage, die jedes Tool beantwortet.

Als DevOps EngineerAls SRE zusätzlich
Die CI/CD-Pipeline bauenEntscheiden, welcher Nachweis einen Rollout automatisch stoppt, und messen, wie viel Zuverlässigkeit jedes Release kostet
Alarme auf CPU, Memory und Disk setzenNur bei nutzerseitig sichtbaren Symptomen pagen und Ressourcenmetriken für die Diagnose behalten
Infrastruktur als Code provisionierenIhre Failure Domains und Quotas kennen und wissen, was passiert, wenn die Control Plane des Providers ausfällt
Den Incident behebenDen Incident führen, das Postmortem schreiben und den Fix ausliefern, der die Fehlerklasse beseitigt
Eine Aufgabe auf Anfrage automatisierenToil als Zahl verfolgen und nicht zulassen, dass es die Hälfte der Teamzeit übersteigt
Anwendungscode als Sache der Entwickler betrachtenIhn lesen, seine Timeouts und Retries reviewen und Pull Requests dagegen schicken

Die letzte Zeile ist die, die die meisten Infrastruktur-Engineers unterschätzen. Ein SRE, der den Code des Service nicht lesen kann, kann Ausfälle nur von außen beobachten. Zuverlässigkeit wird darin entschieden, wie eine Funktion mit einer langsamen Abhängigkeit umgeht, und das steht im Repository, nicht im Cluster.

Failure Modes und worauf zu achten ist

Die Umbenennung. Ein Operations-Team, das den SRE-Titel und dieselbe Ticket-Queue bekommt, hat nichts geändert. Ohne die Toil-Obergrenze und die Autorität, die damit einhergeht, bleibt keine Zeit für Engineering, und der Titel beschreibt ein Ziel.

Der Gatekeeper. Ein Reliability-Team, das Releases genehmigt, wird zum Flaschenhals, um den die Organisation herumroutet. Einfluss kommt von der Paved Road und von Daten, nicht von einem Veto.

Der Held. Ein Engineer, der jedes System kennt und jeden Ausfall behebt, ist ein Single Point of Failure mit Gehalt. Incidents, die mit "Sam hat zwanzig Minuten gebraucht" enden, brauchen ein Runbook, keinen Applaus.

Zuverlässigkeit ohne Zahl. "So zuverlässig wie möglich" lässt sich weder planen noch besetzen noch gegen Features abwägen. Alles in diesem Beitrag hängt davon ab, sagen zu können, wie zuverlässig ein Service sein soll und ob er es gerade ist. Das ist das Vokabular von SLIs, SLOs und Error Budgets, und das ist Teil 2.

Lies das als Nächstes

Für Consulting zu AWS, Cloud-Architektur, SRE-Praxis, CI/CD-Pipelines, Linux und mehr, starte auf ercanermis.com.

Referenzen