Cloud oder On-Prem: Was ein SRE unter dem Service prüft

Der Infrastruktur-Provider ist die größte einzelne Abhängigkeit, die ein Service hat, und ein SRE behandelt ihn wie jede andere Abhängigkeit: liest, was er tatsächlich zusagt, kartiert, wo er gemeinsam ausfällt, und prüft, was passiert, wenn er nicht antwortet. Das gilt, egal ob der Provider AWS ist oder ein Plattform-Team, das zwei Stockwerke tiefer Racks betreibt. Die Fragen sind auf beiden Seiten identisch; was sich ändert, ist, wer sie beantwortet. In der Cloud antwortet der Provider, und du verifizierst. On-prem antwortest du, und niemand verifiziert dich. Dieser Beitrag ist die Checkliste, in sechs Bereichen: die Zusage, Failure Domains, Control Planes, Limits, Kapazität und Wartung.

Dies ist Teil 4 von Budget for Failure, der zweite Teil auf 201-Level und der letzte der Serie. Teil 1 hat die Rolle definiert, Teil 2 hat ihr Zahlen gegeben, und Teil 3 hat sie in den Anwendungscode getragen. Dieser Teil geht unter den Code.

1. Die Zusage: Deine Abhängigkeiten deckeln dein SLO

Teil 2 hat aufgelistet, was vier AWS-SLAs zusagen. Jetzt die Rechnung, die die meisten Architecture Reviews auslassen. Ein Request, der durch einen Load Balancer, eine Compute-Schicht, eine Datenbank und Object Storage laufen muss, ist nur erfolgreich, wenn alle vier es sind. Sind die Ausfälle unabhängig, multiplizieren sich die Verfügbarkeiten:

ALB (multi-AZ)      0.9999
EC2 (multi-AZ)      0.9999
RDS (Multi-AZ)      0.9995
S3 Standard         0.9990
------------------------------
product             0.9983   =  99.83%
allowed downtime    about 73 minutes in 30 days

Bevor dein eigener Code eine einzige Exception geworfen hat, liegt der vertragliche Boden unter diesem Stack bei 99,83 Prozent. AWS läuft normalerweise deutlich über seinen SLA-Böden, die praktische Zahl ist also besser, aber der Schluss bleibt: Du kannst keine 99,99 Prozent auf einer harten Abhängigkeit versprechen, die 99,9 zusagt. Entweder senkst du das Versprechen, oder du machst die Abhängigkeit weich, mit einem Cache, einer Queue oder einem Fallback, wie in Teil 3.

On-prem gibt es kein SLA-Dokument zum Multiplizieren, also baust du dieselbe Tabelle aus deiner eigenen Historie: gemessene Verfügbarkeit des Storage-Arrays, des Hypervisor-Clusters, des Core-Netzwerks, der Stromversorgung. Wenn niemand diese Zahlen hat, ist das der erste Befund des Reviews.

2. Failure Domains: was gemeinsam stirbt

Die Multiplikation setzt Unabhängigkeit voraus. Eine Failure Domain ist eine Menge von Dingen, die sich eine Ausfallursache teilen, und der Job des SRE ist, sie zu kennen und Replikas über sie zu verteilen.

Drei Checks gelten auf beiden Seiten. Liegen die Replikas jedes zustandsbehafteten Systems wirklich in verschiedenen Domains, oder sitzen drei Nodes eines Quorums in einer Zone oder einem Rack? Sitzt etwas Single-homed im Pfad von etwas Multi-homed, etwa ein NAT Gateway, das drei Zonen bedient, oder zwei "redundante" Switches an derselben Stromzuführung? Und reicht die verbleibende Kapazität, nachdem die größte Domain, die du überleben willst, weg ist, für die volle Last? Einen Zonenverlust mit drei Zonen zu überleben heißt, jede mit höchstens zwei Dritteln zu fahren.

Die Serie Nothing Fails Alone besteht aus vier durchgearbeiteten Incidents genau dazu, inklusive eines read-only Skripts, das Single-Zone-Konzentrationen in einem AWS-Account findet.

3. Control Plane und Data Plane

Jede Plattform hat zwei Hälften. Die Data Plane macht die Arbeit: Instances laufen, Load Balancer leiten weiter, DNS antwortet. Die Control Plane ändert Dinge: eine Instance starten, eine Route ändern, eine Gruppe skalieren. Control Planes sind komplexer und fallen häufiger aus, und sie neigen dazu, während großer Incidents auszufallen, also genau dann, wenn ein Recovery-Plan sie nutzen will.

Die Frage für jede Recovery-Prozedur ist also, ob sie einen Control-Plane-Aufruf braucht, um zu gelingen. Ein Design, das einen Zonenverlust überlebt, weil die Kapazität bereits anderswo läuft, ist statisch stabil. Eines, das ihn überlebt, weil Autoscaling Ersatz starten wird, hängt von der EC2 Control Plane ab, in dem Moment, in dem jeder andere Kunde sie ebenfalls aufruft. Der Artikel der Amazon Builders' Library zu Static Stability ist die Referenz.

On-prem existiert dieselbe Trennung unter anderen Namen: der Kubernetes API Server, vCenter, die IPAM- und DNS-Automatisierung, der Identity Provider, von dem jeder Login und jedes Service-Token abhängt. Frag, was noch funktioniert, wenn jedes davon down ist, und ob das Tooling zum Beheben eines Ausfalls (das VPN, die Bastion, die Deploy-Pipeline, das Chat-System) auf der Infrastruktur läuft, die es reparieren soll.

4. Limits: der Ausfall, der wie eine Quota aussieht

Saturation, aus den Golden Signals in Teil 1, hat eine providerseitige Form, die Host-Metriken nie zeigen. Auf AWS sind die Limits, die in Postmortems landen, selten die CPU:

• Service Quotas. Laufende On-Demand-vCPUs pro Instance-Familie, Lambda Concurrent Executions pro Account, Elastic IPs, Regeln pro Security Group. Ein Scale-out, das auf eine Quota trifft, schlägt im schlechtesten Moment fehl.
• API-Rate-Limits. Control-Plane-APIs throtteln pro Account und Region. Ein Deploy-Tool, ein Autoscaler und ein Monitoring-Agent, die alle Describe* aufrufen, können sich gegenseitig throtteln.
• Adressraum. Ein Subnetz, dem die freien IPs ausgegangen sind, stoppt neue Pods, neue Lambda-Netzwerkschnittstellen und neue Instances, mit einer Fehlermeldung, die nichts davon erwähnt.
• Obergrenzen pro Ressource. IOPS und Durchsatz auf einem EBS-Volume, Verbindungen auf einer RDS-Instance-Klasse, Ports auf einem NAT Gateway.

Behandle jedes davon als Saturation-SLI mit einem Alarm deutlich vor 100 Prozent. Für viele Quotas veröffentlicht CloudWatch die Nutzung im Namespace AWS/Usage, und die Metric-Math-Funktion SERVICE_QUOTA() liefert das aktuelle Limit, sodass ein Ausdruck den Prozentsatz der genutzten Quota ergibt. Für den Rest reicht ein Inventarskript nach Zeitplan.

On-prem sind die Limits physisch und langsamer zu erhöhen: Höheneinheiten im Rack, Strom und Kühlung pro Rack, Switch-Ports, lizenzierte Cores, Durchsatz des Storage-Controllers, die Größe des Adressplans, der vor fünf Jahren gemacht wurde.

5. Kapazität: elastisch heißt nicht unendlich

Das Versprechen der Cloud ist, dass Kapazität in Minuten ankommt. Das tut sie meistens, und ein SRE plant für die Male, in denen sie es nicht tut. Ein bestimmter Instance-Typ in einer bestimmten Zone kann InsufficientInstanceCapacity zurückgeben, am häufigsten während eines Zonen-Ereignisses, wenn alle in dieselben überlebenden Zonen failovern. Die Verteidigung ist Diversität (mehrere Instance-Typen und alle Zonen in der Auto Scaling Group), Vorab-Provisionierung für den Failover-Fall und On-Demand Capacity Reservations für die Workloads, die nicht warten können.

On-prem beträgt die Vorlaufzeit Wochen bis Monate, Kapazitätsplanung ist also eine Prognosedisziplin: gemessenes Wachstum, ein Beschaffungskalender und Headroom, dimensioniert als N+1 oder N+2 gegen die Failure Domains oben. Die Entscheidung, die die Zuverlässigkeit am stärksten beeinflusst, fällt beim Kauf, lange vor dem Incident, der sie testet.

In beiden Welten gilt: Lasttest, um das erste Limit zu finden, statt es zu schätzen. Die Zahl, die zählt, ist das Traffic-Niveau, bei dem der SLI aus Teil 2 zu degradieren beginnt, und welche Ressource das verursacht hat.

6. Wartung: die Incidents mit Datum

Ein großer Teil der Incidents wird von jemandem im Voraus terminiert und dann vergessen. In der Cloud: Instance-Retirement-Hinweise, Datenbank-Wartungsfenster, Engine- und Kubernetes-Versionen, die das Ende des Standard-Supports erreichen, Zertifikatsablauf, veraltete Runtimes. AWS veröffentlicht die meisten davon pro Account über AWS Health, das sich über EventBridge in dieselbe Queue wie deine übrige Betriebsarbeit routen lässt. Ungelesen werden sie zu überraschenden Reboots.

On-prem ist die Liste länger und gehört ganz dir: Firmware, Hypervisor- und Betriebssystem-Patching, Austausch von Disks und Batterien, Hardware-Refresh-Zyklen, Vendor-Supportverträge, Ersatzteile vor Ort. Jedes braucht einen Owner und einen Kalender. Eine Plattform, die drei Major-Versionen hinterherhinkt, gibt Error Budget im Voraus aus.

Der letzte Check in diesem Bereich ist, wie du erfährst, dass der Provider einen schlechten Tag hat. Eine Statusseite wird von Menschen während eines Incidents geschrieben und hinkt ihm hinterher. Miss den Provider selbst, von außen: Ein synthetischer Canary, der den echten Nutzerpfad aus einem anderen Netz heraus durchläuft, sagt dir von einem regionalen Problem, bevor das Dashboard es tut, und er hält den Nenner des SLI am Leben, wenn echter Traffic dich nicht erreichen kann.

Wem was gehört

Keine der beiden Spalten ist kürzer, weil die Arbeit verschwunden wäre. Eine Cloud verschiebt die unteren Zeilen zu einem Provider, der darin mehr Übung hat als fast jedes einzelne Unternehmen, und im Gegenzug nimmst du eine Abhängigkeit in Kauf, die du nicht inspizieren kannst. Dieser Tausch ist meistens richtig. Er bleibt ein Tausch, und der SRE ist die Person, die beide Seiten davon benennen kann.

Failure Modes und worauf zu achten ist

Das SLA als Prognose behandeln. Es ist eine Preisbedingung mit angehängter Gutschrift. Designe nach gemessenem Verhalten und Failure Domains, nicht nach der Prozentzahl auf der Seite.

Multi-Zone nur auf dem Diagramm. Drei Zonen in der Subnetzliste und eine im laufenden Zustand, oder ein Failover, der nie geübt wurde. Teste ihn bewusst, innerhalb des Error Budgets.

Recovery, die braucht, was kaputt ist. Runbooks, deren erster Schritt ein Console-Login oder ein Pipeline-Lauf in der betroffenen Region ist.

Limits, die in Produktion entdeckt werden. Jede Quota und jede Obergrenze aus Abschnitt 4 ist in einem Lasttest billig zu finden und während eines Launches teuer.

Wo dich das hinbringt

Der Weg der Serie in einem Durchgang. Du verantwortest Zuverlässigkeit als Engineering-Problem und deckelst die manuelle Arbeit, damit Zeit bleibt, es zu lösen (Teil 1). Du formulierst als SLO, wie zuverlässig der Service sein soll, und gibst die Lücke bewusst als Error Budget mit unterschriebener Policy aus (Teil 2). Du gehst ins Repository und behebst die Timeouts, Retries und Rollouts, die die Zahl entscheiden, und du pagest auf Burn Rate statt auf CPU (Teil 3). Und du weißt, was die Plattform unter dir verspricht, wo sie gemeinsam ausfällt und was du tun wirst, wenn sie es tut (Teil 4). Die Werkzeuge für alle vier nutzen die meisten Engineers bereits. Was die Arbeit zu SRE macht, ist, dass jedes davon jetzt eine einzige Frage beantwortet: Bekommen die Nutzer die Zuverlässigkeit, auf die wir uns geeinigt haben, und was ist der günstigste Weg, das so zu halten?

Lies das als Nächstes

• Teil 3 dieser Serie: SRE in der Codebase: Timeouts, Retries und Alerts as Code.
• Der Fix teilt das Schicksal des Ausfalls: drei Incidents, in denen der Recovery-Pfad von der Control Plane abhing, die gerade down war.
• Your LLM Bill Is an Observability Problem auf ercan.ai: dasselbe Denken in Provider-Abhängigkeiten, angewandt auf Modell-APIs, wo Quotas und Kosten die Saturation-Signale sind.

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

Referenzen

• Amazon Builders' Library: Static stability using Availability Zones
• AWS whitepaper: AWS Fault Isolation Boundaries
• Amazon CloudWatch: Visualizing your service quotas and setting alarms
• Amazon EC2: On-Demand Capacity Reservations
• AWS Health: Monitoring events with Amazon EventBridge
• Amazon Compute Service Level Agreement
• Google SRE Book, Chapter 18: Software Engineering in SRE (capacity planning)