Wenn Stabilität aufhört, Verhandlungssache zu sein
Ein Zuverlässigkeitsziel mit Zahl beendet den Streit zwischen Entwicklung und Betrieb, weil beide Seiten danach dieselbe Rechnung vor sich haben statt zweier Meinungen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Ohne Zielwert gewinnt im Zweifel immer die dringendere Seite
Die Entwicklung will ausliefern, der Betrieb will Ruhe, und beide haben recht. Ohne vereinbarte Größe entscheidet die Lautstärke oder die Hierarchie, und nach jedem größeren Ausfall kippt die Stimmung für ein paar Wochen zur Vorsicht, bis der Druck wieder steigt. Das wiederholt sich, weil nichts davon aufgeschrieben ist.
Der zweite wiederkehrende Fehler ist die Alarmierung. Ein System meldet, was messbar ist, statt was zählt, und irgendwann kommen nachts Meldungen über eine erhöhte Prozessorlast, die niemand bearbeiten kann. Nach zwei Monaten ignorieren die Leute die Meldungen, und die eine wichtige geht darin unter.
Teuer ist beides auf dieselbe Weise: über die Menschen. Bereitschaft, die regelmäßig für nicht handhabbare Meldungen weckt, kostet in kurzer Zeit die erfahrenen Leute, und mit ihnen geht das Wissen, das die Störungen überhaupt beherrschbar gemacht hat.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Wer entscheidet was rund um Zuverlässigkeit
Ein Fehlerbudget wirkt nur, wenn vorher geklärt ist, wer die Zahl festlegt und wer die Folgen trägt. Die Übersicht zeigt die Themen, an denen sich das im Alltag entscheidet.
| Thema | Wer entscheidet | Wer setzt um | Stolperfalle |
|---|---|---|---|
| Höhe des Zuverlässigkeitsziels | Die Stelle mit der Ergebnisverantwortung für den Dienst, gemeinsam mit der Fachseite | Site Reliability und Betrieb, die Messung, Auswertung und Meldewege einrichten | Das Ziel wird technisch gesetzt statt am Bedarf des Geschäfts, und niemand hat ausgerechnet, was die nächsthöhere Stufe an Aufwand bedeutet. |
| Folge eines aufgebrauchten Budgets | Entwicklung und Betrieb gemeinsam, vorher und schriftlich | Das Entwicklungsteam, das seine Reihenfolge auf Stabilitätsarbeit umstellt | Die Folge wird erst im Konflikt ausgehandelt, und dann setzt sich durch, wer den wichtigeren Termin hat. |
| Was nachts jemanden weckt | Das Team, das die Bereitschaft trägt, nach dem Grundsatz der Handhabbarkeit | Site Reliability, die Meldungen ohne Handlungsbedarf abschaltet oder umleitet | Neue Meldungen werden ergänzt und alte nie entfernt, bis die Bereitschaft zur Dauerbelastung wird. |
| Übernahme eines neuen Dienstes in die Bereitschaft | Das Bereitschaftsteam, auf Basis vereinbarter Mindestanforderungen | Das Entwicklungsteam, das Protokolle, Messgrößen und Handlungsanweisungen liefert | Der Dienst geht in Betrieb, bevor jemand beschrieben hat, was bei welcher Meldung zu tun ist. |
| Nachbereitung einer Störung | Das Team, das die Maßnahmen anschließend auch umsetzt | Die benannten Personen mit Termin, wie bei jeder anderen Arbeit auch | Der Bericht wird geschrieben, die Maßnahmen bekommen keinen Platz in der Planung, und derselbe Ausfall wiederholt sich. |
Höhe des Zuverlässigkeitsziels
- Wer entscheidet
- Die Stelle mit der Ergebnisverantwortung für den Dienst, gemeinsam mit der Fachseite
- Wer setzt um
- Site Reliability und Betrieb, die Messung, Auswertung und Meldewege einrichten
- Stolperfalle
- Das Ziel wird technisch gesetzt statt am Bedarf des Geschäfts, und niemand hat ausgerechnet, was die nächsthöhere Stufe an Aufwand bedeutet.
Folge eines aufgebrauchten Budgets
- Wer entscheidet
- Entwicklung und Betrieb gemeinsam, vorher und schriftlich
- Wer setzt um
- Das Entwicklungsteam, das seine Reihenfolge auf Stabilitätsarbeit umstellt
- Stolperfalle
- Die Folge wird erst im Konflikt ausgehandelt, und dann setzt sich durch, wer den wichtigeren Termin hat.
Was nachts jemanden weckt
- Wer entscheidet
- Das Team, das die Bereitschaft trägt, nach dem Grundsatz der Handhabbarkeit
- Wer setzt um
- Site Reliability, die Meldungen ohne Handlungsbedarf abschaltet oder umleitet
- Stolperfalle
- Neue Meldungen werden ergänzt und alte nie entfernt, bis die Bereitschaft zur Dauerbelastung wird.
Übernahme eines neuen Dienstes in die Bereitschaft
- Wer entscheidet
- Das Bereitschaftsteam, auf Basis vereinbarter Mindestanforderungen
- Wer setzt um
- Das Entwicklungsteam, das Protokolle, Messgrößen und Handlungsanweisungen liefert
- Stolperfalle
- Der Dienst geht in Betrieb, bevor jemand beschrieben hat, was bei welcher Meldung zu tun ist.
Nachbereitung einer Störung
- Wer entscheidet
- Das Team, das die Maßnahmen anschließend auch umsetzt
- Wer setzt um
- Die benannten Personen mit Termin, wie bei jeder anderen Arbeit auch
- Stolperfalle
- Der Bericht wird geschrieben, die Maßnahmen bekommen keinen Platz in der Planung, und derselbe Ausfall wiederholt sich.
Fünf Schritte von der Messgröße zum Fehlerbudget
- 01 Du bestimmst, was für die Nutzer ein erfolgreicher Aufruf ist.
- 02 Du misst diesen Anteil über einen festen Zeitraum.
- 03 Du vereinbarst ein Ziel und rechnest es in erlaubte Ausfallzeit um.
- 04 Der Rest bis hundert Prozent ist das Budget für Störungen.
- 05 Ist das Budget aufgebraucht, greift die vorher vereinbarte Folge.
Was du mitnimmst
Du bekommst das Handwerkszeug, mit dem Zuverlässigkeit messbar und damit verhandelbar wird, und die Kriterien, an denen du eine brauchbare Alarmierung von einer schädlichen unterscheidest.
Aus Nutzersicht messen
Du wählst Messgrößen, die abbilden, was jemand tatsächlich erlebt, also erfolgreiche Anfragen und Antwortzeiten, nicht die Auslastung einzelner Maschinen.
Ein Ziel festlegen und begründen
Du vereinbarst einen Zielwert, der zum Geschäftsbedarf passt, und rechnest ihn in erlaubte Ausfallzeit um, damit alle wissen, worüber sie reden.
Das Fehlerbudget als Regel nutzen
Du vereinbarst vorher, was passiert, wenn das Budget aufgebraucht ist, sonst ist es eine Zahl ohne Wirkung.
Nur auf Handlungsbedarf alarmieren
Du löst Meldungen an Menschen nur aus, wenn es etwas zu tun gibt, und schickst alles andere in die Auswertung.
Wiederkehrende Handarbeit begrenzen
Du erfasst, wie viel Zeit für wiederholte Betriebsaufgaben draufgeht, und automatisierst das Wiederkehrende, bevor es das Team auffrisst.
Störungen ohne Schuldzuweisung nachbereiten
Du beschreibst nach einem Vorfall die Kette der Ursachen und leitest Änderungen am System ab statt Ermahnungen an Personen.
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Was die Rolle von DevOps und Plattformarbeit unterscheidet
Alle drei Rollen arbeiten am selben Unterbau, verfolgen aber verschiedene Zwecke. Ein DevOps Engineer automatisiert den Weg von der Änderung bis zum Betrieb. Ein Platform Engineer baut daraus ein Angebot für andere Teams. Site Reliability setzt an der Frage an, wie verlässlich das Ergebnis im Betrieb sein muss und woran man das erkennt. Das ist weniger ein anderer Werkzeugkasten als eine andere Messlatte.
Der Ursprung erklärt die Denkweise. Google beschreibt in seinem frei verfügbaren Buch zu Site Reliability Engineering die beiden Kernideen: ein Zuverlässigkeitsziel mit dem daraus abgeleiteten Fehlerbudget und die Begrenzung wiederkehrender Handarbeit, für die dort ein Anteil von höchstens der Hälfte der Arbeitszeit genannt wird. Wer diese beiden Punkte streicht, hat keine Site Reliability, sondern einen Betrieb mit englischem Titel.
Genau das ist im deutschen Stellenmarkt der häufige Fall: Die Ausschreibung nennt Site Reliability und beschreibt anschließend klassische Systemadministration. Die brauchbare Rückfrage im Gespräch lautet deshalb, ob es Zielwerte gibt, wer sie festgelegt hat und was zuletzt passiert ist, als das Budget aufgebraucht war.
Zielwerte, Fehlerbudget und die Rechnung dahinter
Ein Zielwert wird aus Nutzersicht gemessen, also am Anteil erfolgreicher Aufrufe oder an einer Antwortzeit, die eingehalten wird. Der Rest bis zu hundert Prozent ist das Fehlerbudget für den Zeitraum. Bei einem Monat mit dreißig Tagen entspricht ein Zielwert von 99,9 Prozent gut 43 Minuten, in denen der Dienst die Zusage verfehlen darf, ohne dass jemand eingreifen muss.
Der Nutzen liegt in der Konsequenz. Solange Budget übrig ist, kann die Entwicklung zügig ausliefern, denn Ausfälle sind eingepreist. Ist es aufgebraucht, gilt die vorher vereinbarte Regel, meistens ein Vorrang für Stabilitätsarbeit bis zum Ende des Zeitraums. Ohne diese Vereinbarung bleibt das Budget eine Kennzahl in einer Übersicht, und der Streit läuft weiter wie vorher.
Der zweite Anwendungsfall ist die Auswahl der Alarme. Wenn das Budget in wenigen Stunden verbrannt wird, ist das eine Meldung wert, die jemanden weckt. Ein langsam schleichender Verbrauch gehört in die Auswertung am Vormittag. Diese Unterscheidung entlastet die Bereitschaft mehr als jedes neue Werkzeug.
Woher die amtliche Zahl auf dieser Seite kommt
Für Site Reliability gibt es keine eigene Berufsgattung, die Rolle ist zu jung für eine Systematik aus dem Jahr 2010. Die Zelle unten stammt aus der IT-Systemadministration auf dem Anforderungsniveau Spezialist, weil dort die nächstliegende Tätigkeit einsortiert ist. Sie beschreibt eine Nachbarschaft, nicht diese Rolle.
Wichtig ist, was das Anforderungsniveau bedeutet: den Zuschnitt der Stelle und nicht die Erfahrung der Person. Auf den Nachbarseiten zu Plattformarbeit und Auslieferung stehen andere Zellen, weil dort andere Berufsgruppen am nächsten liegen. Ein Vergleich dieser drei Zahlen vergliche also Berufsgruppen der Statistik und nicht den Wert der drei Rollen.
Wie überall in dieser Erhebung handelt es sich um Bruttomonatsverdienste von Vollzeitbeschäftigten ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld fehlen, der Jahresverdienst liegt also über dem Zwölffachen, und der Median ist aussagekräftiger als der Durchschnitt, weil einzelne Spitzenverdienste den Durchschnitt anheben. Die Vergütung der Rufbereitschaft steckt in diesen Zahlen ebenfalls nicht, obwohl sie in dieser Rolle ein realer Einkommensbestandteil ist.
Der Weg hinein und was dabei zählt
Der häufigste Einstieg führt aus der Systemadministration, der zweithäufigste aus der Entwicklung. Aus dem Betrieb bringst du das Gespür für Fehlerbilder mit und musst dir aneignen, wie man Software baut und testet. Aus der Entwicklung ist es umgekehrt: Du kannst automatisieren und musst lernen, wie sich ein System unter Last, bei Netzstörungen und im Wiederanlauf verhält.
Dazu kommt eine Fähigkeit, die in beiden Herkünften selten geübt wird: mit Zahlen zu argumentieren. Ein Zielwert vorzuschlagen, ihn in Ausfallminuten zu übersetzen und den Aufwand für die nächsthöhere Stufe zu beziffern, ist der Kern der Rolle. Wer das kann, wird in Gesprächen mit der Fachseite ernst genommen, auch ohne Zertifikat.
Verbreitete Nachweise betreffen den Unterbau: Linux, Containerplattformen und Überwachung. Für die eigentliche Denkweise ist das frei verfügbare Buch von Google die günstigste Quelle, und ein eigenes Beispiel, in dem du Messgrößen und einen Zielwert festgelegt und danach die Alarme aufgeräumt hast, wirkt im Gespräch stärker als jede Prüfung.
Woran du wächst und wohin die Rolle führt
Zwei Leute mit gleicher Berufsdauer unterscheiden sich daran, ob sie Alarme abschalten können. Meldungen hinzuzufügen ist einfach und fühlt sich verantwortungsvoll an. Eine Meldung zu entfernen, die seit einem halben Jahr nur bestätigt wird, verlangt ein Urteil und die Bereitschaft, dafür geradezustehen.
Der zweite Unterschied ist die Ehrlichkeit der Zielwerte. Ein Ziel, das dauerhaft übererfüllt wird, ist zu niedrig angesetzt und verschenkt Handlungsspielraum. Eines, das jeden Monat gerissen wird, verliert seine Wirkung, weil niemand mehr Konsequenzen zieht. Beides zu erkennen und nachzujustieren ist erfahrungsabhängig.
Weiter geht es in die Plattformarbeit, in die Architektur oder in die Verantwortung für die Zuverlässigkeit mehrerer Dienste, in größeren Häusern mit eigener Leitungsfunktion. Wer den Betrieb im engeren Sinn behalten will, geht Richtung Service-Management, wo dieselben Fragen vertraglich statt technisch verhandelt werden.
Dazu passende Kurse
Wie aus Rohdaten eine Meldung wird, die jemand nachts bearbeiten kann, zeigen Kurse, in denen du Messwerte sammelst und daraus brauchbare Alarme machst .
Wenn Zuverlässigkeit auch vertraglich zugesagt wird, gehören Trainings, in denen Störungen und ihre Nachbereitung geregelt ablaufen dazu.
Die amtlichen Zahlen zu dieser Rolle
Die Zahl stammt aus der Berufsgattung IT-Systemadministration auf dem Anforderungsniveau Spezialist, weil für diese jüngere Rolle keine eigene Zelle existiert und dort die nächstliegende Tätigkeit einsortiert ist. Sie beschreibt also eine Nachbarschaft und nicht diese Rolle. Anforderungsniveau meint den Zuschnitt der Stelle und nicht die Berufserfahrung der Person. Es sind Vollzeitwerte ohne Sonderzahlungen, der Median ist dabei die belastbarere Größe, und die Vergütung der Rufbereitschaft ist in beiden Werten nicht enthalten.
Amtliche Medianverdienste, April 2025
Brutto im MonatStatistisches Bundesamt, Verdiensterhebung. Vollzeit, ohne Sonderzahlungen. Die Hälfte der Beschäftigten verdient weniger als der Median, die andere Hälfte mehr.
KldB 43343, Durchschnitt 5.495 €, gerundet rund 62.000 € im Jahr ohne Sonderzahlungen
- Vollzeitbeschäftigte, Bruttomonatsverdienst ohne Sonderzahlungen. Weihnachts- und Urlaubsgeld, Prämien und Boni sind nicht enthalten, der Jahresverdienst liegt also über dem Zwölffachen.
- Das Anforderungsniveau beschreibt den Zuschnitt der Stelle, nicht die Berufserfahrung. Fachkraft, Spezialist und Experte sagen etwas über die Komplexität der Tätigkeit aus, nicht über Dienstjahre.
- Die Erhebung geht regional nur bis auf die Bundeslandebene. Für einzelne Städte gibt es keine amtlichen Zahlen, weil der Zufallsfehler zu groß wäre.
Quelle: Statistischer Bericht Verdienste , Statistisches Bundesamt (Destatis). Den eigenen Fall prüfst du im Entgeltatlas der Bundesagentur für Arbeit . Beachte dort: Entgelte oberhalb der Beitragsbemessungsgrenze sind der Statistik nicht bekannt, bei gut bezahlten IT-Rollen steht deshalb nur eine Untergrenze.
Ein sehr gutes, praxisorientiertes und nachhaltiges Seminar. So sollte es immer sein. Vielen Dank.
Ein sehr guter und verständlicher Überblick über die Grundlagen im Umgang mit BricsCAD.
Alle meine Erwartungen wurden erfüllt und ich habe mich sehr gut aufgenommen gefühlt, jede Frage wurden Probleme direkt beseitigt.
Häufige Fragen
Ist Site Reliability Engineering nur ein neuer Name für Systemadministration?
Welchen Zielwert sollte ich vereinbaren?
Gehört Rufbereitschaft zwingend dazu?
Brauche ich Programmierkenntnisse?
Passt thematisch dazu
Bevor du Messgrößen festlegst, hilft die Frage, welches Überwachungswerkzeug zu welcher Umgebung passt .
Für verteilte Dienste reicht eine Messreihe allein nicht, deshalb lohnt sich anzusehen, wie Messwerte, Protokolle und Aufrufketten zusammenfinden .
Deine Ansprechpartner
Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.
Yves Hoppe
Weiterbildung & Beratung
Hilft dir, aus dem IT-Berufe-Programm den passenden Kurs für deinen Stand zu finden.
Norbert Jansen
Beratung & Inhouse
Plant mit dir Inhouse-Trainings, die auf eure Abläufe und euren Datenbestand zugeschnitten sind.
Zuverlässigkeit beginnt bei der Messung
Wie aus Messwerten brauchbare Alarme werden und wie eine Umgebung dauerhaft im Blick bleibt, lässt sich an den gängigen Werkzeugen von Grund auf lernen.