SLOs für interne Tools einfach erklärt: Setze messbare Ziele für Verfügbarkeit und Latenz und verknüpfe sie mit wenigen, handhabbaren Alerts, die ein kleines Team ohne Burnout pflegen kann.
Interne Tools wirken klein, weil die Zielgruppe klein ist. Der Einfluss ist es oft nicht: Fällt dein Ops-Dashboard aus, stehen Bestellungen; ist deine Support-Konsole langsam, warten Kunden; bricht dein Admin-Panel, stapeln sich Fixes.
Ohne klare Zuverlässigkeitsziele wird jeder Ausfall zur Debatte. Die eine Person zuckt bei einer zehnminütigen Störung mit den Schultern, eine andere behandelt es wie eine Krise. Du verlierst Zeit an laute Chats, unklare Prioritäten und Überraschungsarbeit im schlechtesten Moment.
SLOs lösen das, indem sie einfache Erwartungen setzen, die du messen kannst. Sie beantworten zwei praktische Fragen: Was muss funktionieren, und wie gut muss es funktionieren, damit Leute ihre Arbeit erledigen können.
Die versteckten Kosten von „wir halten es ziemlich stabil“ zeigen sich schnell. Die Arbeit stoppt, während Teams auf die Wiederherstellung warten. Support-Anfragen vervielfachen sich, weil niemand weiß, was normal ist. Entwickler werden in dringende Fixes gezogen statt an geplanten Verbesserungen zu arbeiten. Product Owner verlieren Vertrauen ins System und verlangen manuelle Backups. Kleine Probleme bleiben liegen, weil sie nie eine klare Grenze überschreiten.
Du brauchst kein komplettes Reliability-Programm. Ein kleines Team kann mit ein paar nutzerzentrierten Zielen anfangen wie „Login funktioniert“ oder „Suchergebnisse laden schnell“, plus einer kleinen Menge an Alerts, die zu echten Aktionen führen.
Das gilt unabhängig davon, wie das Tool gebaut ist. Wenn du AppMaster (appmaster.io) nutzt, um interne Apps zu erstellen, wähle die Aktionen, auf die Menschen angewiesen sind, miss Verfügbarkeit und Antwortzeit und alarmiere nur, wenn es die Arbeit beeinflusst.
Diese drei Begriffe klingen ähnlich, sind aber unterschiedliche Arten von Zuverlässigkeits-Sprache. Sie zu verwechseln ist eine häufige Quelle für Verwirrung.
Ein SLI (Service Level Indicator) ist eine Messung. Es ist etwas, das du zählen kannst, wie „Prozent der Anfragen, die erfolgreich waren“ oder „wie lange die Seite zum Laden brauchte“. Wenn du es nicht zuverlässig messen kannst, ist es kein gutes SLI.
Ein SLO (Service Level Objective) ist das Ziel für diese Messung. Es beantwortet: Welches Niveau ist für Nutzer die meiste Zeit gut genug? SLOs helfen dir zu entscheiden, was zuerst zu beheben ist und was warten kann.
Ein SLA (Service Level Agreement) ist ein Versprechen, meist schriftlich, oft mit Konsequenzen. Viele interne Tools brauchen überhaupt keine SLAs. Sie brauchen klare Ziele, keine juristisch anmutenden Zusagen.
Ein kurzes Beispiel:
Achte darauf, was fehlt: „nie down“ oder „immer schnell“. SLOs bedeuten nicht Perfektion. Sie machen Kompromisse sichtbar, damit ein kleines Team zwischen Features, Zuverlässigkeitsarbeit und dem Vermeiden unnötigen Aufwands wählen kann.
Eine praktische Regel: Wenn das Erreichen des Ziels Heldentaten erfordern würde, ist es kein SLO, sondern Wunschdenken. Fang mit etwas an, das dein Team ruhig aufrechterhalten kann, und verschärfe es später, wenn Nutzer weiterhin Schmerz melden.
Interne Tools versagen auf bestimmte Weisen: Das Admin-Panel lädt, aber Speichern dreht sich endlos; ein Ops-Dashboard öffnet, aber Diagramme aktualisieren nie; ein Mitarbeiterportal funktioniert, außer dass Login nach einem Update ausfällt. Am meisten Wert bekommst du, wenn du dich auf die Aktionen konzentrierst, auf die sich Nutzer jeden Tag verlassen, nicht auf jede Seite und jeden Button.
Beginne damit, den Tool-Typ zu benennen, weil er die kritischen Pfade andeutet. Admin-Panels drehen sich um „sicher etwas ändern“. Ops-Dashboards drehen sich um „sehen, was gerade los ist“. Portale drehen sich darum „reinkommen, Info finden und eine Anfrage abschicken“.
Schreibe dann die wichtigsten Nutzerreisen in einfacher Sprache auf. Ein guter Startkatalog:
Definiere für jede Reise, was als Fehler zählt. Sei streng und messbar: Ein 500-Fehler ist ein Fehler, aber genauso ein Timeout, eine Seite, die nie fertig lädt, oder ein Formular, das Erfolg meldet, während die Daten fehlen.
Halte den Umfang anfangs klein. Wähle 1 bis 3 Reisen, die echten Schmerz und echtes Risiko abbilden. Wenn die On-Call-Seiten meistens „niemand kann sich einloggen“ und „der Speichern-Button hängt“ sind, beginne mit Login und Formular abschicken. Füge Suche später hinzu, wenn du Messung und Alerts vertraust.
Gute SLIs sind langweilig. Sie stammen aus Daten, die du bereits hast, und entsprechen dem, was Nutzer fühlen, wenn das Tool funktioniert oder ausfällt. Wenn du eine ganze neue Monitoring-Infrastruktur brauchst, nur um sie zu messen, wähle einfachere SLIs.
Beginne mit Verfügbarkeit in Begriffen, die Leute verstehen: Kann ich das Tool öffnen und kann ich die Aufgabe beenden? Für viele interne Tools reichen zwei SLIs für den größten Teil des Schmerzes:
Füge dann Latenz hinzu, aber halte es eng. Wähle ein oder zwei Bildschirme oder Endpunkte, die die Wartezeiten repräsentieren, über die Nutzer sich beklagen, wie z. B. das Laden des Dashboards oder das Absenden eines Formulars. Alles zu messen schafft meist nur Rauschen und Streit.
Entscheide das Messfenster von vornherein. Ein rollierender 30-Tage-Zeitraum ist bei stabilen Tools üblich; wöchentlich kann funktionieren, wenn ihr oft releast und schnelles Feedback wollt. Was auch immer du wählst, bleibe dabei, damit Trends etwas bedeuten.
Wähle schließlich eine einzige Quelle der Wahrheit pro SLI und schreibe sie auf:
Beispiel: Wenn deine interne App auf AppMaster läuft, kannst du die Uptime mit einem synthetischen Ping an das Backend messen, die Erfolgsrate aus API-Antworten und die Latenz aus Backend-Request-Timings messen. Konsistenz ist wichtig, nicht Perfektion.
Fange damit an, eine Uptime-Nummer zu wählen, die du in einer schlechten Woche verteidigen kannst. Für viele interne Tools ist 99,5 % ein gutes erstes SLO. Es klingt hoch, aber es lässt Raum für normale Änderungen. Direkt auf 99,9 % zu springen bedeutet oft Nachtschichten und langsamere Releases.
Um Verfügbarkeit greifbar zu machen, übersetze sie in Zeit. Ein 30-Tage-Monat hat etwa 43.200 Minuten:
Diese erlaubte Downtime ist dein Error-Budget. Wenn du es früh verbrauchst, pausierst du riskante Änderungen und konzentrierst dich auf Zuverlässigkeit, bis du wieder im Plan bist.
Bei Latenz: Vermeide Durchschnitte. Sie verbergen die langsamen Momente, an die sich Nutzer erinnern. Verwende ein Perzentil (meist p95) und setze eine klare Schwelle, die an eine reale Aktion gebunden ist. Beispiele: „p95 Dashboard-Ladezeit unter 2 Sekunden“ oder „p95 Speichern unter 800 ms“.
Eine einfache Methode, die erste Zahl zu setzen: Beobachte eine Woche echten Traffics und wähle dann ein Ziel, das etwas besser ist als heute, aber nicht unrealistisch. Wenn p95 schon 1,9 s ist, ist ein 2,0-s-SLO sicher und nützlich. Ein 500-ms-SLO würde nur Rauschen erzeugen.
Passe SLOs an eure Support-Kapazität an. Ein kleines Team sollte wenige erreichbare Ziele einem Haufen strenger Ziele vorziehen. Wenn niemand innerhalb einer Stunde reagieren kann, setze keine Ziele, die eine schnellere Reaktion voraussetzen.
Ein strengeres SLO klingt beruhigend, hat aber seinen Preis. Wenn du ein Tool von 99,5 % auf 99,9 % verschärfst, sagst du damit auch: „Wir akzeptieren viel weniger schlechte Minuten“, was in der Regel mehr Paging und mehr Zeit für Zuverlässigkeit statt neue Features bedeutet.
Der einfachste Weg, das greifbar zu machen, ist, im Error-Budget zu sprechen. Bei 99,5 % monatlich kannst du in einem 30-Tage-Monat etwa 3,6 Stunden Ausfallzeit "ausgeben". Bei 99,9 % sind es nur etwa 43 Minuten. Dieser Unterschied entscheidet, wie oft du Feature-Arbeit stoppst, um Zuverlässigkeit zu reparieren.
Es hilft auch, Erwartungen an die Zeiten zu koppeln, in denen Leute das Tool wirklich nutzen. Ein 24/7-Ziel ist teuer, wenn das Tool nur von 9 bis 18 Uhr kritisch ist. Du kannst ein SLO für Geschäftszeiten (strenger) und ein lockereres für außerhalb der Geschäftszeiten (weniger Paging) setzen, damit das Team schlafen kann.
Geplante Wartung sollte nicht als Fehler zählen, solange sie kommuniziert und begrenzt ist. Behandle sie als explizite Ausnahme (ein Wartungsfenster), statt Alerts nachträglich zu ignorieren.
Schreibe die Grundlagen auf, damit alle die Kompromisse sehen:
Nach 4–6 Wochen echter Daten, überprüfe das Ziel. Wenn du nie Error-Budget verbrauchst, ist das SLO vielleicht zu locker. Wenn du es schnell verbrauchst und Features ins Stocken geraten, ist es wahrscheinlich zu eng.
Alerts sind nicht deine SLOs. Alerts sind das "jetzt läuft etwas schief"-Signal, das das SLO schützt. Eine einfache Regel: Erstelle für jedes SLO genau einen Alert, der zählt, und widerstehe der Versuchung, mehr hinzuzufügen, außer du kannst beweisen, dass sie die Downtime reduzieren.
Ein praktischer Ansatz ist, auf schnellen SLO-Verbrauch zu alarmieren (wie schnell du dein Error-Budget aufbrauchst) oder auf eine klare Schwelle, die Nutzer-Schmerz widerspiegelt. Wenn dein Latenz-SLO „p95 unter 800 ms“ ist, page nicht bei jedem kurzen Ausreißer. Page nur, wenn es anhaltend ist.
Eine einfache Trennung, die Lärm gering hält:
Konkrete Schwellen (an dein Traffic anpassen): Wenn dein Uptime-SLO 99,5 % monatlich ist, page, wenn die Verfügbarkeit unter 99 % für 10 Minuten fällt (klarer Ausfall). Erstelle ein Ticket, wenn sie unter 99,4 % über 6 Stunden fällt (langsamer Verbrauch). Bei Latenz: Page, wenn p95 über 1,5 s für 15 Minuten liegt; Ticket, wenn p95 über 1,0 s für 2 Stunden liegt.
Mach Ownership explizit. Entscheide, wer on-call ist (auch wenn es „eine Person diese Woche“ ist), was "acknowledge" bedeutet (zum Beispiel innerhalb von 10 Minuten) und was die erste Aktion ist. Für ein kleines Team, das eine interne App mit AppMaster betreibt, könnte die erste Aktion so aussehen: Letzte Deployments prüfen, API-Fehler ansehen, dann rollbacken oder neu deployen, falls nötig.
Nach jedem echten Alert mache eine kleine Nacharbeit: Ursache beheben oder den Alert justieren, sodass er seltener paged, aber echte Nutzerwirkung weiterhin einfängt.
Alert-Fatigue beginnt meist mit guten Absichten. Ein kleines Team fügt „nur ein paar“ Alerts hinzu und dann jede Woche einen weiteren. Bald trauen die Leute Benachrichtigungen nicht mehr, und echte Ausfälle werden übersehen.
Eine große Falle ist, bei jedem Spike zu alarmieren. Interne Tools haben oft bursty Traffic (Lohnläufe, Monatsenden). Wenn ein Alert bei einer zweiminütigen Spitze feuert, lernt das Team, ihn zu ignorieren. Koppel Alerts an Nutzerwirkungs-Signale, nicht an rohe Metrik-Noise.
Eine andere Falle ist zu denken „mehr Metriken = sicherer“. Häufig bedeutet es mehr Pages. Bleib bei einer kleinen Menge an Signalen, die Nutzer tatsächlich spüren: Login schlägt fehl, Seiten sind zu langsam, Schlüssel-Jobs werden nicht fertig.
Fehler, die am meisten Lärm erzeugen:
Dashboards sind weiterhin wichtig, aber sie sollten beim Diagnostizieren nach einem Alert helfen, nicht den Alert ersetzen.
Wenn du noch keine sauberen Messungen hast, tu nicht so, als hättest du sie. Füge zuerst Basis-Instrumentierung hinzu (Erfolgsrate, p95-Latenz und einen „kann ein Nutzer die Aufgabe abschließen“-Check), und setze dann Schwellen basierend auf ein bis zwei Wochen echter Daten.
Bevor du Alerts aktivierst, mache eine kurze Pre-Flight-Überprüfung. Die meisten Alert-Fatigue-Probleme kommen davon, dass eine dieser Basics übersprungen wurde und man später unter Druck versucht, es zu beheben.
Eine praktische Checkliste für ein kleines Team:
Stelle sicher, dass der Alert tatsächlich gehandhabt werden kann. Ein Alert, der feuert, wenn niemand verfügbar ist, trainiert Leute, ihn zu ignorieren.
Entscheide diese Betriebsdetails bevor der erste Page geht:
Wenn du das Tool baust oder änderst (auch in AppMaster), durchlaufe die Checkliste erneut. Regenerierter Code und neue Flows können Latenz und Fehlerbilder verschieben, und deine Alerts sollten mitziehen.
Ein Ops-Team von 18 Personen nutzt ein internes Dashboard den ganzen Tag, um Bestellstatus zu prüfen, fehlgeschlagene Benachrichtigungen neu zu senden und Rückerstattungen zu genehmigen. Wenn es down oder langsam ist, stoppt die Arbeit schnell.
Sie wählen zwei SLOs:
Dann fügen sie drei Alerts hinzu, die ein kleines Team handhaben kann:
Wichtig ist, was in der nächsten Woche passiert. Wenn der Error-Budget-Alert zweimal feuert, trifft das Team eine klare Entscheidung: Ein neues Feature verschieben und zwei Tage an der größten Latenzursache arbeiten (z. B. ein nicht indizierter Table-Scan). Wenn sie das Tool in AppMaster gebaut haben, können sie das Datenmodell anpassen, regenerieren und sauberen Code neu deployen, statt Quick-Fixes zu stapeln.
SLOs helfen nur, wenn sie mit echter Arbeit verbunden bleiben. Der Trick ist, sie wie eine kleine Gewohnheit zu behandeln, nicht wie ein neues Programm.
Nutze einen Rhythmus, der zu einem kleinen Team passt, und hänge ihn an ein bestehendes Meeting. Ein kurzer wöchentlicher Blick fängt Drift ein, und eine monatliche Anpassung reicht, sobald echte Daten vorhanden sind.
Ein leichtgewichtiger Prozess, der standhält:
Halte Verbesserungen klein und sichtbar. Wenn „langsames Laden jeden Montagmorgen" dreimal auftaucht, mache eine konkrete Änderung (einen Report cachen, einen Index hinzufügen, einen schweren Job später planen) und beobachte die SLI in der nächsten Woche.
Nutze SLOs auch als freundliches Nein. Kommt eine Anfrage für ein wenig wertvolles Feature, verweise auf das aktuelle Error-Budget und frage: „Wird diese Änderung unseren Save- oder Approval-Flow riskieren?“ Wenn ihr bereits Budget verbrennt, gewinnt Zuverlässigkeit. Das ist kein Blockieren, das ist Priorisieren.
Halte die Dokumentation minimal: Eine Seite pro Tool. Einschließlich der Schlüssel-Nutzeraktionen, der SLO-Zahlen, der wenigen Alerts und des Owners. Wenn das Tool in AppMaster gebaut wurde, füge hinzu, wo Logs/Metriken einzusehen sind und wer deployen kann — und dann Schluss.
Der einfachste Weg, Zuverlässigkeit real zu machen, ist, das erste Setup winzig zu halten. Wähle ein internes Tool, das echten Schmerz verursacht, wenn es ausfällt (On-Call-Übergaben, Bestellfreigaben, Rückerstattungen, Lagerbearbeitungen) und setze Ziele rund um die wenigen Aktionen, die Leute jeden Tag tun.
Ein kleinster brauchbarer Aufbau, den die meisten Teams kopieren können:
Wenn das stabil ist, erweitere langsam: eine Aktion mehr oder ein weiteres Tool pro Monat. Wenn du nicht benennen kannst, wer einen Alert besitzen wird, erstelle ihn noch nicht.
Wenn du interne Tools baust oder neu aufsetzt, kann AppMaster den Wartungsaufwand leichter handhabbar machen. Du kannst Datenmodelle und Geschäftslogik visuell anpassen und sauberen Code regenerieren, wenn Anforderungen sich ändern — das hilft, SLOs im Einklang mit dem aktuellen Tool zu halten.
Versuche, ein internes Tool zu bauen und von Tag eins an einfache SLOs hinzuzufügen. Du bekommst klarere Erwartungen, weniger Überraschungen und Alerts, mit denen dein kleines Team klarkommt.
Brauchen interne Tools wirklich SLOs, wenn nur ein kleines Team sie nutzt?SLOs beenden Diskussionen über Zuverlässigkeit, indem aus "ziemlich stabil" ein messbares Ziel wird. Schon bei 20 Nutzern kann ein Ausfall Bestellungen stoppen, Support verzögern oder Freigaben blockieren — kleine Tools können also große Auswirkungen haben.
Was sollten wir zuerst für ein Admin-Panel oder Ops-Dashboard messen?Miss ein paar Nutzeraktionen, die täglich durchgeführt werden und die Arbeit blockieren, wenn sie ausfallen. Übliche Starter sind Login, Laden des Haupt-Dashboards mit frischen Daten, Suchen/Filtern und das erfolgreiche Absenden eines Create/Update-Formulars.
Was ist der Unterschied zwischen SLI, SLO und SLA?Ein SLI ist die Metrik, die du misst (z. B. Erfolgsrate oder p95-Latenz). Ein SLO ist das Ziel für diese Metrik (z. B. 99,5 % Erfolg über 30 Tage). Ein SLA ist eine formale Vereinbarung mit Konsequenzen — die meisten internen Tools brauchen das nicht.
Was ist ein realistisches Uptime-SLO für ein kleines Team?Für viele interne Tools ist ein realistisches erstes Uptime-SLO 99,5 % monatlich, weil das ohne ständige Heldentaten erreichbar ist. Wenn das Tool während der Arbeitszeit wirklich kritisch ist, kannst du das Ziel später verschärfen, nachdem du Daten gesehen hast.
Wie übersetzen wir Uptime-Prozente in für Menschen verständliche Ausfallzeiten?Übersetze die Prozentzahl in Minuten, damit jeder die Kompromisse versteht. In einem 30-Tage-Monat erlauben 99,5 % etwa 216 Minuten Ausfallzeit, während 99,9 % nur etwa 43 Minuten erlauben — das bedeutet oft mehr Paging und mehr Aufwand für Zuverlässigkeit.
Wie setzen wir Latenz-SLOs, ohne Lärm zu erzeugen?Nutze ein Perzentil wie p95 statt eines Durchschnitts, weil Durchschnitte langsame Momente verschleiern. Setze das Ziel auf eine reale Aktion (z. B. „p95 Dashboard-Ladezeit unter 2 s während der Geschäftszeiten“) und wähle eine Schwelle, die du ruhig halten kannst.
Welche SLIs lassen sich ohne großes Monitoring am einfachsten messen?Starte mit Servermetriken und Logs, die du bereits hast: Verfügbarkeit (erreichbar und antwortend), Erfolgsrate für Schlüsselaktionen und p95-Latenz für ein oder zwei kritische Endpunkte oder Bildschirme. Ergänze synthetische Checks nur für die wichtigsten Flows, damit die Messung konsistent und einfach bleibt.
Wie viele Alerts sollten wir für ein internes Tool einrichten?Beschränke dich auf eine kleine Menge an Alerts, die Nutzerwirkung widerspiegeln, und page nur bei anhaltenden Problemen. Eine nützliche Teilung ist: ein dringendes Page für „Tool ist effektiv kaputt“ und ein nicht dringendes Ticket für „langsam merkliche Verschlechterung“.
Was verursacht Alert-Fatigue bei internen Tools und wie vermeiden wir sie?Alert-Fatigue entsteht meist durch Paging bei jedem Spike oder durch Alerts auf Symptome wie CPU statt auf Nutzerwirkung wie Fehler und Latenz. Halte die Alerts gering, gib jedem einen Owner und nach jedem echten Alarm: Ursache beheben oder den Alert so justieren, dass er seltener, aber relevanter feuert.
Wie wenden wir SLOs an, wenn wir unsere internen Tools in AppMaster bauen?Wähle die Schlüsselaktionen in deiner App und messe Verfügbarkeit, Erfolgsrate und p95-Latenz für diese Aktionen mit einer konsistenten "Quelle der Wahrheit". Wenn du intern mit AppMaster baust, fokussiere die Ziele auf das, was Nutzer tun (Login, Speichern, Suche) und passe Messungen und Alerts nach größeren Änderungen oder Regenerierungen an, damit sie zum aktuellen Verhalten passen.
21. Jan. 2026
8 Min
20. Jan. 20268 Min
20. Jan. 20268 MinExperimentieren Sie mit AppMaster mit kostenlosem Plan.
Wenn Sie fertig sind, können Sie das richtige Abonnement auswählen.
