{"id":22387,"date":"2021-11-16T17:13:23","date_gmt":"2021-11-16T17:13:23","guid":{"rendered":"https:\/\/www.dotcom-monitor.com\/blog\/2021\/11\/16\/sre-prinzipien-die-7-grundregeln\/"},"modified":"2026-08-27T21:26:41","modified_gmt":"2026-08-27T21:26:41","slug":"sre-prinzipien-die-7-grundregeln","status":"publish","type":"post","link":"https:\/\/www.dotcom-monitor.com\/blog\/de\/sre-prinzipien-die-7-grundregeln\/","title":{"rendered":"SRE Prinzipien: Die 7 Grundlegenden Regeln"},"content":{"rendered":"
\"Illustration
Das Google SRE Buch geht davon aus, dass Sie den gesamten Stack besitzen. Vieles von dem, was Ihre Nutzer erleben, l\u00e4uft auf Infrastruktur, die nicht Ihnen geh\u00f6rt.<\/figcaption><\/figure>\n

Die sieben SRE-Prinzipien stammen von einem Unternehmen, das seine Rechenzentren, sein Netzwerk, seine Load-Balancer und jede Codezeile dazwischen besitzt. Ihr Stack sieht wahrscheinlich anders aus. Ein gro\u00dfer Teil dessen, was Ihre Nutzer erleben, l\u00e4uft auf Infrastruktur, in die Sie nicht per SSH gelangen k\u00f6nnen: ein CDN, ein Authentifizierungsanbieter, ein Zahlungs-Gateway, DNS, ein Tag-Manager, eine Partner-API.<\/p>\n

Diese L\u00fccke ist entscheidend, denn die Prinzipien gelten auch au\u00dferhalb von Google. Aber einige \u00e4ndern ihre Form, wenn die fehlerhafte Komponente nicht in Ihrer Hand liegt. Ein Error Budget verh\u00e4lt sich anders, wenn ein Drittel davon durch einen Ausfall eines anderen verursacht wird. Die vier goldenen Signale sehen von au\u00dferhalb der Firewall anders aus als von innen. Und das Risiko, das Sie nicht wegintegrieren k\u00f6nnen, m\u00fcssen Sie messen.<\/p>\n

Dieser Artikel erkl\u00e4rt alle sieben Prinzipien so, wie das Google SRE Buch<\/a> sie definiert, und erg\u00e4nzt den Teil, den das Buch \u00fcberspringt: Wie jedes Prinzip aussieht, wenn Sie von Diensten abh\u00e4ngig sind, die Sie nicht kontrollieren. Wenn Sie neu in der Rolle sind, starten Sie mit was ein Site Reliability Engineer macht<\/a> und kommen Sie dann zur\u00fcck.<\/p>\n

Was sind die SRE-Prinzipien?<\/h2>\n

SRE-Prinzipien sind die Arbeitsregeln, die Google f\u00fcr den Betrieb zuverl\u00e4ssiger Systeme im gro\u00dfen Ma\u00dfstab formuliert hat: Risiko annehmen und managen, Service Level Objectives, Beseitigung von Toil, Monitoring, Automatisierung, Release Engineering und Einfachheit. Zusammen beantworten sie eine Frage: Wie zuverl\u00e4ssig muss dieser Dienst sein und was ist der g\u00fcnstigste nachhaltige Weg, ihn dort zu halten?<\/p>\n

Die Liste hat sich seit Ver\u00f6ffentlichung des SRE-Buchs 2016 nicht ge\u00e4ndert. Was sich ge\u00e4ndert hat, ist der durchschnittliche Stack. Microservices, SaaS-Abh\u00e4ngigkeiten und Drittanbieter-Skripte bedeuten, dass ein Teil Ihrer Zuverl\u00e4ssigkeit jetzt in den H\u00e4nden anderer Unternehmen liegt. Jeder der folgenden Abschnitte behandelt das Prinzip so, wie es geschrieben ist, und dann, was kaputtgeht, wenn die Abh\u00e4ngigkeit nicht Ihnen geh\u00f6rt. Am Ende gibt es eine kurze Liste von SRE Best Practices, die aus allen sieben Prinzipien abgeleitet sind.<\/p>\n

Prinzip 1 \u2013 Risiko annehmen und managen<\/h2>\n

Die Google-Formulierung: 100 % Zuverl\u00e4ssigkeit ist das falsche Ziel. Nutzer erreichen Sie \u00fcber Netzwerke und Ger\u00e4te, die von selbst ausfallen; jenseits eines bestimmten Punktes kosten zus\u00e4tzliche Neunen echtes Geld und niemand merkt den Unterschied. W\u00e4hlen Sie ein Zuverl\u00e4ssigkeitsziel, das das Unternehmen vertreten kann, und behandeln Sie die L\u00fccke zwischen diesem Ziel und Perfektion als Budget, das Sie f\u00fcr Features ausgeben d\u00fcrfen. Das Kapitel Risiko annehmen<\/a> erl\u00e4utert das im Detail.<\/p>\n

Innerhalb von Google funktioniert das, weil Risiko ein Regler ist, den sie drehen k\u00f6nnen. Mehr Replikation, mehr Redundanz, langsamere Rollouts: Geld ausgeben, mehr Neunen.<\/p>\n

Au\u00dferhalb von Google ist der Regler an manchen Stellen gar nicht angeschlossen. Sie k\u00f6nnen Ihrem Zahlungs-Gateway keine Replik hinzuf\u00fcgen. Sie k\u00f6nnen das Failover-Verhalten Ihres DNS-Anbieters nicht einstellen. Deren Zuverl\u00e4ssigkeit ist ein Vertragspunkt, kein technischer Parameter.<\/p>\n

Das Prinzip \u00e4ndert also seine Form: F\u00fcr Komponenten, die Sie besitzen, managen Sie Risiko durch Engineering. F\u00fcr die, die Sie nicht besitzen, managen Sie es durch Messung. Sie m\u00fcssen die reale Verf\u00fcgbarkeit Ihres Auth-Anbieters messen, gemessen von der Nutzerseite aus, nicht die Zahl auf dessen Statusseite. Statusseiten zeigen bei Teil-Ausf\u00e4llen oft gr\u00fcn an, und eine Abh\u00e4ngigkeit, die in ihrem eigenen Rechenzentrum l\u00e4uft, kann von Ihrem aus unerreichbar sein. Unabh\u00e4ngige Messung wandelt \u201eWir denken, das CDN ist unzuverl\u00e4ssig\u201c in ein verl\u00e4ngerbares Gespr\u00e4ch mit Datenunterlegung. Das ist der erste Job, den Dotcom-Monitor hier \u00fcbernimmt: eine externe Pr\u00fcfung jeder kritischen Abh\u00e4ngigkeit. Ein DNS-Check<\/a> auf die Nameserver des Anbieters, ein HTTP(S)-Check am CDN-Edge, ein API-Check<\/a> gegen das Zahlungs-Gateway. Jeder baut eine eigene Verf\u00fcgbarkeits- und Antwortzeit-Historie aus einem globalen Netzwerk auf. Und wo die Zahlen es rechtfertigen, umfahren Sie das Risiko: ein zweiter DNS-Anbieter, ein Backup-Zahlungsweg, eine zwischengespeicherte Kopie des Drittanbieter-Skripts.<\/p>\n

Wie man Risikomanagement umsetzt<\/h3>\n