Wie man eine Web-App baut, die SLA-Konformität genau verfolgt

Definiere SLA-Konformität und was du baust

SLA-Konformität bedeutet, die messbaren Zusagen in einem Service Level Agreement (SLA) — einem Vertrag zwischen Anbieter und Kunde — einzuhalten. Die Aufgabe deiner App ist es, eine einfache Frage mit Belegen zu beantworten: Haben wir gehalten, was wir versprochen haben, für diesen Kunden, in diesem Zeitraum?

Es hilft, drei verwandte Begriffe zu trennen:

• SLI (Service Level Indicator): die rohe Messung (zum Beispiel „Prozentsatz erfolgreicher Checks“, „Zeit bis zur ersten Antwort“ oder „Zeit bis Wiederherstellung“).
• SLO (Service Level Objective): ein internes Ziel für ein SLI (oft strenger als das SLA). Beispiel: „99,95% Uptime-Ziel.“
• SLA: die extern vereinbarte Zusage, oft mit Gutschriften oder Strafen verknüpft. Beispiel: „99,9% monatliche Verfügbarkeit.“

Häufige SLA-Kennzahlen, die du verfolgen wirst

Die meisten SLA-Tracking-Web-Apps starten mit einer kleinen Menge an Kennzahlen, die sich auf reale operative Daten abbilden lassen:

• Uptime / Verfügbarkeit: Prozentsatz der Zeit, in der der Service während des Berichtszeitraums „up“ ist.
• Antwortzeit (Support): Zeit von der Erstellung eines Kundentickets bis zur ersten menschlichen Antwort.
• Lösungszeit: Zeit von Incident-/Ticket-Erstellung bis Schließung oder Wiederherstellung.
• Verfügbarkeitsfenster: Regeln wie „nur Geschäftszeiten zählen“, „geplante Wartung ausschließen“ oder „nur von 08:00–18:00 in der Zeitzone des Kunden messen“.

Wer nutzt die App — und warum

Verschiedene Nutzer brauchen dieselbe Wahrheit, präsentiert aber anders:

• Ops/SRE: sollen Verstöße früh erkennen und Incident-Timelines validieren.
• Support-Teams: verfolgen Antwort- und Lösungszusagen pro Kunde.
• Manager: sehen Trends, Risiken und ob Teams konstant Ziele erreichen.
• Kunden: sehen transparente Berichte (und manchmal eine Statusseite), die zeigen, was passiert ist.

Was du baust (und was nicht)

Dieses Produkt geht um Tracking, Nachweis und Reporting: Signale sammeln, vereinbarte Regeln anwenden und revisionsfähige Ergebnisse erzeugen. Es garantiert nicht Performance; es misst sie — präzise, konsistent und so, dass du das Ergebnis später verteidigen kannst.

Anforderungen: Kennzahlen, Regeln und wer was braucht

Bevor du Tabellen entwirfst oder Code schreibst, sei schmerzhaft klar darüber, was „Konformität“ für dein Geschäft bedeutet. Die meisten SLA-Tracking-Probleme sind keine technischen, sondern Anforderungsprobleme.

Sammle die Inputs (verlass dich nicht auf Erinnerung)

Fange an, die Wahrheitsquellen zu sammeln:

• Kundenverträge und MSAs (inklusive Anhängen und Ticketing-Addenda)
• Service-Tiers (z. B. Basic vs. Premium) und welche Kunden zu welchem Tier gehören
• Geschäftszeiten und Zeitzonen pro Kunde (oder pro Service)
• Ausschlüsse und Sonderregeln: geplante Wartungsfenster, höhere Gewalt, vom Kunden verursachte Verzögerungen, Drittanbieterabhängigkeiten, Kulanzfristen

Schreibe diese als explizite Regeln auf. Wenn sich eine Regel nicht klar formulieren lässt, kann sie nicht zuverlässig berechnet werden.

Entscheide, was verfolgt werden muss

Liste die realen „Dinge“, die eine SLA-Zahl beeinflussen können:

• Incidents/Outages (Start, Ende, Schweregrad, betroffene Services)
• Requests/Tickets (Erstellt, erste Antwort, Lösung, in „Warten auf Kunde")
• Wartungen (geplant vs. Notfall; ob sie gegen Verfügbarkeit zählen)
• Teilweise Ausfälle (degradierte Leistung) und ob sie überhaupt zählen

Identifiziere außerdem, wer was braucht: Support will Echtzeit-Risiken sehen, Manager wöchentliche Rollups, Kunden einfache Zusammenfassungen (oft für eine Statusseite).

Wähle 1–3 Metriken für die erste Veröffentlichung

Halte den Umfang klein. Wähle das Minimum, das das System Ende-zu-Ende beweist, zum Beispiel:

• Verfügbarkeit % pro Service pro Monat
• Incident-Antwortzeit (erste menschliche Antwort) innerhalb der Geschäftszeiten
• Zeit bis zur Lösung für Severity-1-Incidents

Anforderungsliste und Erfolgskriterien

Erstelle eine einseitige Checkliste, die du später testen kannst:

• Klare Metrikdefinitionen (Start/Stop Zeitstempel, Zeitzone, Rundung)
• Inklusions-/Ausschlussregeln (Wartung, Wartezeit auf Kunde)
• Zielwerte pro Tier (z. B. 99,9%, 1 Stunde Antwort)
• Ausgabeanforderungen (Kundenbericht, internes Dashboard, Export)

Erfolg sieht so aus: Zwei Personen berechnen denselben Beispielmonat manuell und deine App liefert exakt dasselbe Ergebnis.

Datenmodell für SLAs, Services, Incidents und Events

Ein korrekter SLA-Tracker beginnt mit einem Datenmodell, das erklären kann, warum eine Zahl so ist, wie sie ist. Wenn du eine monatliche Verfügbarkeitszahl nicht bis zu den exakten Events und Regeln zurückverfolgen kannst, wirst du Kundenstreitigkeiten und interne Unsicherheit haben.

Kern-Entitäten (mach sie langweilig und explizit)

Mindestens solltest du modellieren:

• Kunde (Tenant/Account): besitzt Services, Kalender, Kontakte und Reporting-Einstellungen.
• Service: das Gemessene (API, Web-App, regionsspezifische Komponente). Füge optional Parent/Child-Beziehung hinzu, falls du mehrere Komponenten rollupen willst.
• Plan: ein kommerzielles Wrapper (z. B. „Gold“), hauptsächlich verwendet, um ein Default-SLA-Policy-Set zuzuordnen.
• SLA-Policy: die messbaren Regeln: Verfügbarkeitsziel, Antwortzeit-Ziel, Messfenster und was als „ausgeschlossen“ zählt.
• Incident: eine menschenfreundliche Gruppierung (Titel, Schweregrad, Timeline), die auf die zugrunde liegenden Events verweist.
• Event: die unveränderlichen Fakten (Statuswechsel, Monitoring-Signale, Bestätigungen), die die Berechnungen antreiben.

Eine nützliche Beziehung ist: customer → service → SLA policy (möglicherweise über einen Plan). Incidents und Events referenzieren dann Service und Kunde.

Minimales Schema für zeitbasierte Verfolgung

Zeitfehler sind die Hauptursache falscher SLA-Mathematik. Speichere:

• occurred_at als UTC (Timestamp mit Zeitzonensemantik)
• received_at (wann dein System es gesehen hat)
• source (Monitor-Name, Integration, manuell)
• external_id (zum Deduplizieren von Retries)
• payload (rohes JSON für zukünftiges Debugging)

Speichere außerdem customer.timezone (IANA-String wie America/New_York) für Anzeige und Geschäftszeiten-Logik, aber nutze sie nicht, um Event-Zeiten umzuschreiben.

Arbeitszeiten und Feiertage

Wenn Antwortzeit-SLAs außerhalb der Geschäftszeiten pausieren, modellier Kalender explizit:

• working_hours pro Kunde (oder pro Region/Service): Wochentag + Start/End-Zeiten
• holiday_calendar verknüpft mit einer Region oder einem Kunden, mit Datumsbereichen und Bezeichnungen

Halte Regeln datengetrieben, damit Ops einen Feiertag aktualisieren kann, ohne zu deployen.

Auditierbarkeit: Rohdaten vs. berechnete Werte

Speichere rohe Events in einer append-only-Tabelle und die berechneten Ergebnisse separat (z. B. sla_period_result). Jede Ergebniszeile sollte Periode-Grenzen, Input-Version (Policy-Version + Engine-Version) und Referenzen zu den verwendeten Event-IDs enthalten. Das macht Neuberechnungen sicher und liefert eine Prüfbahn, wenn Kunden fragen: „Welche Ausfall-Minuten habt ihr gezählt?"

Event-Ingestion: Wie Daten in deine App gelangen

Deine SLA-Zahlen sind nur so vertrauenswürdig wie die Events, die du ingestierst. Ziel ist einfach: jede relevante Änderung erfassen (Ausfall gestartet, Incident bestätigt, Service wiederhergestellt) mit konsistenten Zeitstempeln und genügend Kontext, um später Compliance zu berechnen.

Übliche Event-Quellen

Die meisten Teams holen Daten aus einer Mischung von Systemen:

• Ticketing / Incident-Tools (Jira Service Management, ServiceNow, Zendesk): erstellt/acknowledged/resolved Zeitstempel, Prioritätswechsel, Zuweisungsänderungen.
• Monitoring-Tools (Pingdom, Datadog, CloudWatch, Prometheus Alertmanager): up/down-Signale, Alarm ausgelöst/gelöscht, synthetische Check-Ergebnisse.
• Infrastruktur- und Anwendungs-Logs: Deploy-Events, Fehler-Spikes, Health-Check-Fehler (nützlich, wenn Monitoring laut oder lückenhaft ist).
• Manuelle Einträge: kleines UI für „geschäftlich bestätigter Outage-Start/Ende“ oder „Wartungsfenster gestartet“, wenn Automation die Wahrheit nicht erkennen kann.

Ingestionsoptionen (und wann sie passen)

Webhooks sind meist die beste Wahl für Echtzeit-Genauigkeit und geringere Last: das Quellsystem schickt Events an deinen Endpunkt.

Polling ist ein guter Fallback, wenn Webhooks fehlen: deine App fragt periodisch Änderungen seit dem letzten Cursor ab. Du brauchst Rate-Limit-Handling und sorgfältige „since“-Logik.

CSV-Import hilft bei Backfills und Migrationen. Behandle es als erstklassigen Ingestionspfad, damit du historische Perioden ohne Hacks neu verarbeiten kannst.

Empfohlenes Event-Format (mit Idempotenz)

Normalisiere alles in eine einzige interne „Event“-Form, auch wenn die Upstream-Payloads unterschiedlich sind:

• event_id (erforderlich): eindeutig und stabil bei Retries. Bevorzuge die Event-GUID der Quelle; sonst generiere einen deterministischen Hash.
• source (erforderlich): z. B. datadog, servicenow, manual.
• event_type (erforderlich): z. B. incident_opened, incident_acknowledged, service_down, service_up.
• occurred_at (erforderlich): Zeitpunkt, wann das Event passiert ist (nicht wann du es erhalten hast), mit Zeitzone.
• received_at (system): wann deine App es ingestiert hat.
• service_id (erforderlich): der SLA-relevante Service, den das Event betrifft.
• incident_id (optional, aber empfohlen): verknüpft mehrere Events zu einem Incident.
• attributes (optional): Priorität, Region, Kundensegment usw.

Speichere event_id mit einer Unique-Constraint, um Ingestion idempotent zu machen: Retries erzeugen keine Duplikate.

Validierungsregeln, die schlechte Daten verhindern

Verwerfe oder quarantäniere Events, die:

• fehlende/ungültige Zeitstempel haben oder occurred_at weit in der Zukunft liegt.
• nicht auf eine bekannte service_id abbildbar sind (oder erzeuge einen expliziten „unmapped“-Workflow).
• eine vorhandene event_id duplizieren.
• in einer Reihenfolge ankommen, die deine Regeln bricht (markiere sie als „benötigt Überprüfung“ statt stillschweigend zu überschreiben).

Diese Disziplin erspart spätere Diskussionen über SLA-Berichte — weil du saubere, nachvollziehbare Eingaben vorweisen kannst.

SLA-Berechnungs-Engine: Roh-Events in Konformität umwandeln

Deine Berechnungs-Engine ist der Ort, an dem „rohe Events“ zu SLA-Ergebnissen werden, die du verteidigen kannst. Wichtig ist, sie wie Buchhaltung zu behandeln: deterministische Regeln, klare Inputs und eine wiederabspielbare Spur.

Beginne mit einer normalisierten Timeline

Konvertiere alles in einen einzigen geordneten Stream pro Incident (oder pro Service-Impact):

• Zeitstempel (UTC) für: Incident gestartet, bestätigt/erste Antwort, gemildert, gelöst, wieder geöffnet
• Zustandswechsel: pausiert/fortgesetzt, warten-auf-Kunde, Wartungsfenster aktiv
• Scope: welche Service(s) und Kunde(s) betroffen sind und mit welcher Schwere

Berechne Dauern, indem du Intervalle aufsummierst, nicht indem du blind zwei Zeitstempel subtrahierst.

Time-to-first-response (TTFR) und Time-to-resolution (TTR)

Definiere TTFR als die verstrichene „chargeable“-Zeit zwischen incident_start und first_agent_response (oder acknowledged, je nach SLA-Formulierung). Definiere TTR als die verstrichene „chargeable“-Zeit zwischen incident_start und resolved.

„Chargeable“ bedeutet, dass du Intervalle entfernst, die nicht zählen:

• außerhalb der Geschäftszeiten (bei Geschäftszeiten-SLAs)
• explizite Pausen (z. B. „Warten auf Kunde")
• Ausschlüsse wie geplante Wartung oder vom Kunden verursachte Verzögerungen

Implementationstipp: speichere eine Kalenderfunktion (Geschäftszeiten, Feiertage) und eine Regel-Funktion, die eine Timeline nimmt und die belastbaren Intervalle zurückgibt.

Teilweise Ausfälle und Multi-Service-Incidents

Entscheide vorab, ob du berechnest:

• pro-Service-SLAs (empfohlen): ein Incident kann mehrere Service-Impact-Records erzeugen, jede mit eigenem TTFR/TTR
• pro-Kunde-SLAs: derselbe Ausfall kann nur eine Teilmenge von Tenants betreffen

Bei teilweisen Ausfällen: gewichte nach Auswirkung nur, falls dein Vertrag das verlangt; andernfalls behandle „degradiert“ als eigene Verstoßkategorie.

Nachvollziehbarkeit: Inputs, Outputs und Replays speichern

Jede Berechnung sollte reproduzierbar sein. Persistiere:

• die exakten verwendeten Events (mit IDs, Zeitstempeln und Quelle)
• die abgeleiteten Intervalle (was ausgeschlossen wurde und warum)
• die finalen Ergebnisse (TTFR, TTR, Verstoß-Flags und Regel-Version)

Wenn Regeln sich ändern, kannst du Neuberechnungen nach Version durchführen, ohne Historie umzuschreiben — entscheidend für Audits und Kundenstreitigkeiten.

Reporting-Logik: Perioden, Verfügbarkeit und Edge-Cases

Reporting ist der Punkt, an dem SLA-Tracking Vertrauen gewinnt — oder Fragen aufwirft. Deine App sollte klar machen, welcher Zeitraum gemessen wird, welche Minuten zählen und wie die finalen Zahlen abgeleitet wurden.

Perioden: Kalender, Abrechnung und Rolling-Windows

Unterstütze die üblichen Reporting-Perioden, die Kunden tatsächlich nutzen:

• Kalendermonat/Quartal (z. B. 1.–31. März)
• Abrechnungszyklen (z. B. 15.–14., an Rechnungen ausgerichtet)
• Rolling-Windows (z. B. „letzte 30 Tage“, täglich aktualisiert)

Speichere Perioden als explizite Start/End-Timestamps (nicht "Monat = 3"), damit du Berechnungen später abspielen und erklären kannst.

Verfügbarkeit: Gesamtminuten vs. berechtigte Minuten

Eine häufige Verwirrungsquelle ist, ob der Nenner der gesamte Zeitraum oder nur die „berechtigte“ Zeit ist.

Definiere zwei Werte pro Periode:

• Eligible minutes: Minuten, die zur SLA zählen (oft exklusive geplanter Wartung, vom Kunden verursachter Ausfälle oder Zeiten außerhalb der Supportstunden)
• Downtime minutes: eligible Minuten, in denen der Service als down gilt

Dann berechne:

availability_percent = 100 * (eligible_minutes - downtime_minutes) / eligible_minutes

Wenn eligible minutes null sein können (z. B. ein Service wird nur während Geschäftszeiten überwacht und die Periode enthält keine), definiere die Regel vorab: entweder „N/A“ oder als 100% behandeln — aber sei konsistent und dokumentiere es.

Zahlen in ein klares Bestehen/Nichtbestehen verwandeln

Die meisten SLAs brauchen sowohl eine Prozentzahl als auch ein binäres Ergebnis.

• Prozent: z. B. 99,95% für die Periode
• Pass/Fail: vergleiche mit dem SLA-Ziel (z. B. bestanden, wenn ≥ 99,9%)

Behalte auch die „distance to breach“ (verbleibendes Downtime-Budget), damit Dashboards vor dem Überschreiten der Schwelle warnen können.

Edge-Cases, die du bewusst behandeln musst

• Zeitzonen: wähle eine Reporting-Zeitzone pro Kunde/Vertrag (oft die des Kunden) und konvertiere Events konsistent.
• Daylight Saving Time: gehe nie davon aus, dass ein Tag 1440 Minuten hat. Nutze zeitzonenbewusste Zeitstempel, damit die Periodenlänge bei DST-Übergängen korrekt ist.
• Fehlende Endzeiten: Incidents haben manchmal keinen resolved-Timestamp. Behandle sie als „offen“ und begrenze sie auf das Periodenende, während du den Datensatz zur Nachbearbeitung markierst.

Behalte immer die rohen Eingaben (inkludierte/ausgeschlossene Events und Anpassungen), damit jeder Bericht die Frage beantworten kann: „Warum ist diese Zahl so?“ ohne vage Erklärungen.

UI und Dashboards, die SLA-Status offensichtlich machen

Deine Berechnungs-Engine kann perfekt sein und trotzdem Nutzer verlieren, wenn die UI nicht sofort die Basisfrage beantwortet: „Erfüllen wir das SLA gerade, und warum?“ Gestalte die App so, dass jeder Bildschirm mit einem klaren Status beginnt und es den Leuten ermöglicht, in die Zahlen und die rohen Events hineinzuzoomen, die sie erzeugt haben.

Wichtige Ansichten, die du bauen solltest

Übersichts-Dashboard (für Operatoren und Manager). Führe mit einigen Kacheln an: Compliance des aktuellen Zeitraums, Verfügbarkeit, Antwortzeit-Compliance und „verbleibende Zeit bis zum Verstoß“, wo anwendbar. Verwende explizite Labels (z. B. „Verfügbarkeit (aktueller Monat)“ statt nur „Uptime“). Wenn du mehrere SLAs pro Kunde unterstützt, zeige zuerst den schlechtesten Status und erlaube Ausklappen.

Kundendetail (für Account-Teams und kundenorientiertes Reporting). Eine Kunden-Seite sollte alle Services und SLA-Tiers dieses Kunden zusammenfassen, mit einfachem Pass/Warn/Fail-Status und einer kurzen Erklärung (z. B. „2 gezählte Incidents; 18m Downtime gezählt"). Füge Links zu /status (falls du eine kundenfreundliche Statusseite anbietest) und zu einem Report-Export hinzu.

Service-Detail (für tiefe Untersuchungen). Zeige hier die exakten SLA-Regeln, das Berechnungsfenster und eine Aufschlüsselung, wie die Konformitätszahl gebildet wurde. Enthält ein Diagramm der Verfügbarkeit über die Zeit und eine Liste der Incidents, die zur SLA gezählt wurden.

Incident-Timeline (für Audits). Eine einzelne Incident-Ansicht sollte eine Timeline der Events zeigen (erkannt, bestätigt, mitigiert, gelöst) und welche Zeitstempel für „Antwort“ und „Lösung“ verwendet wurden.

Filter, die reale Fragen abdecken

Mache Filter konsistent über alle Bildschirme: Datumsspanne, Kunde, Service, Tier und Schweregrad. Verwende überall dieselben Einheiten (Minuten vs. Sekunden; Prozentsätze mit denselben Nachkommastellen). Wenn Nutzer die Datumsspanne ändern, aktualisiere jeden Wert auf der Seite, damit es keine Inkonsistenzen gibt.

Drilldown ohne Vertrauensverlust

Jede Zusammenfassungsmetrik sollte einen „Warum?“-Pfad haben:

• Von einer Compliance-Prozentzahl → Liste der in dieser Periode gezählten Incidents.
• Von einem Incident → rohe Events und die abgeleiteten Zeitstempel, die in Berechnungen genutzt wurden.
• Von Verfügbarkeit → Downtime-Intervalle mit Quelle (Monitoring-Event vs. manuelle Anpassung).

Zeige Tooltipps sparsam, um Begriffe wie „Ausgeschlossene Downtime“ oder „Geschäftszeiten“ zu definieren, und zeige den genauen Regeltext auf der Service-Seite, damit niemand raten muss.

Einfach, aber unmissverständlich

Bevorzuge klare Sprache statt Abkürzungen („Antwortzeit“ statt „MTTA“, es sei denn, deine Nutzer erwarten Abkürzungen). Kombiniere Farbe mit Textlabels („At risk: 92% des Error-Budgets verwendet“), um Mehrdeutigkeiten zu vermeiden. Falls deine App Audit-Logs unterstützt, füge eine kleine Box „Zuletzt geändert“ an den SLA-Regeln hinzu, die zu /audit verlinkt, damit Nutzer verifizieren können, wann Definitionen geändert wurden.

Alerting und Benachrichtigungen bei Verstößen

Alerting ist der Punkt, an dem deine SLA-Tracking-Web-App aufhört, passiv zu berichten, und Teams hilft, Strafen zu vermeiden. Die besten Alerts sind zeitnah, spezifisch und handlungsorientiert — sie sagen jemandem was als Nächstes zu tun ist, nicht nur, dass etwas „schlecht“ ist.

Definiere Alert-Trigger, die echte Entscheidungen auslösen

Beginne mit drei Trigger-Typen:

• Approaching breach: z. B. „Du hast 30 Minuten übrig, um die Antwortzeit-SLA zu erfüllen“ oder „Verfügbarkeit diesen Monat ist auf 99,92% gefallen und das SLA ist 99,9%“. Dieser Alert hat hohen Wert, weil er Wiederherstellung ermöglicht.
• Breach occurred: ausgelöst, wenn die Berechnungs-Engine bestätigt, dass das SLA für das relevante Fenster verfehlt wurde.
• Wiederholte Verstöße: erkenne Muster wie „3 Verstöße in 30 Tagen“ oder „derselbe Service zweimal diese Woche verfehlt“, was oft auf ein systemisches Problem hinweist.

Mache Trigger pro Kunde/Service/SLA konfigurierbar, da verschiedene Verträge unterschiedliche Toleranzen haben.

Wähle Kanäle und halte Botschaften handlungsfähig

Sende Alerts dorthin, wo Leute tatsächlich reagieren:

• E-Mail für revisionsfähige Benachrichtigungen und externe Stakeholder.
• Slack für schnelle interne Koordination.
• SMS (optional) für Eskalationen hoher Schwere.

Jeder Alert sollte Deep-Links enthalten wie /alerts, /customers/{id}, /services/{id} und die Incident- oder Event-Detailseite, damit Reagierende die Zahlen schnell verifizieren können.

Rauschen reduzieren: Deduplizierung, Ruhezeiten, Eskalation

Implementiere Deduplizierung, indem du Alerts mit demselben Key (Kunde + Service + SLA + Periode) gruppierst und Wiederholungen für ein Cooldown-Fenster unterdrückst.

Füge Ruhezeiten (pro Team-Zeitzone) hinzu, damit nicht-kritische „approaching breach“-Alerts bis zu Geschäftszeiten warten, während „breach occurred“ Ruhezeiten bei hoher Schwere überschreiben kann.

Unterstütze schließlich Eskalationsregeln (z. B. On-Call nach 10 Minuten benachrichtigen, Manager nach 30 Minuten eskalieren), damit Alerts nicht in einem Postfach hängen bleiben.

Zugriffskontrolle, Authentifizierung und Audit-Logs

SLA-Daten sind sensibel, weil sie interne Performance und kundenspezifische Berechtigungen offenlegen können. Behandle Zugriffskontrolle als Teil der SLA-Mathematik: derselbe Incident kann unterschiedliche Konformitätsergebnisse erzeugen, je nachdem, welche SLA auf einen Kunden angewendet wird.

Rollen, die du von Anfang an unterstützen solltest

Halte Rollen einfach und erweitere sie später granularer:

• Admin: konfiguriert globale Einstellungen, verwaltet Services, SLAs, Nutzer, Integrationen und Abrechnungsitems.
• Agent: erstellt/aktualisiert Incidents und Wartungsfenster, fügt Events hinzu und ergänzt Postmortem-Notizen.
• Manager: liest alles in ihrem Scope, genehmigt SLA-Definitionen und exportiert Reports.
• Customer viewer: sieht nur ihre eigenen Services, SLA-Ziele, Incident-Historie und kundenfreundliche Berichte.

Ein praktikabler Default ist RBAC + Tenant-Scoping:

• Jeder Datensatz (Service, SLA-Policy, Report) hat einen Owner Tenant/Kunden.
• Interne Nutzer können für mehrere Tenants scoped sein; Customer Viewer auf genau einen.
• Schreibrechte sind enger als Leserechte: z. B. können Agents Incidents bearbeiten, aber keine SLA-Regeln ändern.

Was jede Rolle sehen/bearbeiten darf

Sei explizit bezüglich kundenspezifischer Daten:

• Customer Viewer dürfen niemals interne Felder sehen (Root-Cause-Hypothesen, interne Schwere, On-Call-Notizen, private Tags).
• SLA-Policies sollten versioniert werden, sodass ein Kunde die SLA-Bedingungen sehen kann, die zur Zeit des Incidents galten.

Authentifizierungsoptionen, die dich nicht in die Enge treiben

Starte mit E-Mail/Passwort und erfordere MFA für interne Rollen. Plane SSO später (SAML/OIDC) ein, indem du Identität (wer sie sind) von Autorisierung (was sie sehen/dürfen) trennst. Für Integrationen gib API-Keys an Service-Accounts mit engen Scopes und Rotationsunterstützung aus.

Audit-Logs, für die du dankbar sein wirst

Füge unveränderliche Audit-Einträge hinzu für:

• SLA-Regeländerungen (Schwellen, Kalender, Ausschlüsse, Zuordnung zu Services/Kunden)
• Incident-Edits (Zeitstempel, Statuswechsel, manuelle Downtime-Overrides)
• Berechtigungs- und API-Key-Änderungen

Speichere wer, was sich geändert hat (vorher/nachher), wann, wo (IP/User-Agent) und eine Korrelations-ID. Mache Audit-Logs durchsuchbar und exportierbar (z. B. /settings/audit-log).

API-Design für Integrationen und Automatisierung

Eine SLA-Tracking-App ist selten eine Insel. Du willst eine API, die Monitoring-Tools, Ticketing-Systeme und interne Workflows Incidents, Events erstellen und Reports ziehen lässt, ohne manuelle Arbeit.

Beginne mit einer kleinen, vorhersehbaren Oberfläche

Nutze einen versionierten Basis-Pfad (z. B. /api/v1/...), damit du Payloads weiterentwickeln kannst, ohne bestehende Integrationen zu brechen.

Essentielle Endpunkte, die die meisten Anwendungsfälle abdecken:

• Events: POST /api/v1/events zum Ingest von Statusänderungen (up/down, Latenzproben, Wartungsfenster). GET /api/v1/events für Audits und Debugging.
• Incidents: POST /api/v1/incidents, PATCH /api/v1/incidents/{id} (acknowledge, resolve, assign), GET /api/v1/incidents.
• SLAs: GET /api/v1/slas, POST /api/v1/slas, PUT /api/v1/slas/{id} zum Verwalten von Verträgen und Schwellen.
• Reports: GET /api/v1/reports/sla?service_id=...&from=...&to=... für Compliance-Zusammenfassungen.
• Alerts: POST /api/v1/alerts/subscriptions zum Verwalten von Webhooks/E-Mail-Zielen; GET /api/v1/alerts für Alert-Historie.

Mache Paginierung und Filterung konsistent

Wähle eine Konvention und nutze sie überall. Zum Beispiel: limit, cursor-Paginierung plus Standardfilter wie service_id, sla_id, status, from und to. Halte die Sortierung vorhersehbar (z. B. sort=-created_at).

Definiere Fehlerantworten, auf die Integratoren sich verlassen können

Gib strukturierte Fehler mit stabilen Feldern zurück:

{ "error": { "code": "VALIDATION_ERROR", "message": "service_id is required", "fields": { "service_id": "missing" } } }

Nutze klare HTTP-Statuscodes (400 Validierung, 401/403 Auth, 404 nicht gefunden, 409 Konflikt, 429 Rate Limit). Für Event-Ingestion erwäge Idempotenz (Idempotency-Key), damit Retries keine Incidents duplizieren.

Rate Limits und grundlegende Sicherheit

Setze angemessene Rate Limits pro Token (striktere Limits für Ingest-Endpunkte), sanitisiere Eingaben und validiere Zeitstempel/Zeitzonen. Bevorzuge scope-basierte API-Tokens (read-only Reporting vs. write-Zugriff auf Incidents) und logge immer, wer welchen Endpunkt aufgerufen hat (Details in deinem Audit-Log-Abschnitt unter /blog/audit-logs).

Teststrategie: Beweise, dass die Zahlen korrekt sind

SLA-Zahlen sind nur nützlich, wenn Leute ihnen vertrauen. Tests für eine SLA-Tracking-Web-App sollten weniger auf „lädt die Seite“ fokussieren und mehr auf „verhält sich Zeitmathematik exakt wie der Vertrag sagt“. Behandle deine Berechnungsregeln wie ein Produkt-Feature mit einer eigenen Test-Suite.

Unit-Tests für Regeln mit festen Timelines

Beginne damit, deine Berechnungs-Engine unitzgetestet mit deterministischen Inputs zu testen: eine Timeline von Events (Incident geöffnet, bestätigt, mitigiert, gelöst) und ein klar definiertes SLA-Regelset.

Nutze feste Zeitstempel und „freeze time“, damit Tests nicht von der aktuellen Uhrzeit abhängen. Decke Edge-Cases ab, die oft SLA-Berichte brechen:

• Incident startet vor dem Berichtzeitraum und endet darin
• Überlappende Incidents (sollen Downtimes zusammengeführt oder gestapelt werden?)
• Mehrere Pausen (Wartung, vom Kunden verursachte Verzögerungen)
• Grenzminuten/-sekunden (genau um 00:00, Monatsende, Schalttag)

End-to-End-Tests für die gesamte Pipeline

Füge einige E2E-Tests hinzu, die den kompletten Flow durchlaufen: Events ingestieren → Konformität berechnen → Report generieren → UI rendern. Diese fangen Diskrepanzen zwischen „was die Engine berechnet hat“ und „was das Dashboard zeigt“. Halte die Szenarien wenige, aber mit hohem Wert und assertiere auf finale Zahlen (Verfügbarkeit %, Verstoß ja/nein, Zeit bis Ack).

Wiederverwendbare Fixtures für Kalender und Zeitzonen

Erzeuge Test-Fixtures für Geschäftszeiten, Feiertage und Zeitzonen. Du willst reproduzierbare Fälle wie „Incident tritt Freitag 17:55 Ortszeit auf“ und „Feiertag verschiebt Antwortzeit-Zählung".

Überwache die SLA-App selbst

Tests enden nicht mit dem Deploy. Füge Monitoring für Job-Fehler, Queue-/Backlog-Größe, Neuberechnungsdauer und Fehlerquoten hinzu. Wenn Ingestion hinterherhinkt oder ein Nachtjob fehlschlägt, kann dein SLA-Report falsch sein, selbst wenn der Code korrekt ist.

Deployment, Betrieb und ein praktischer MVP-Fahrplan

Eine SLA-Tracking-App zu liefern geht weniger um ausgefallene Infrastruktur als um vorhersehbaren Betrieb: deine Berechnungen müssen pünktlich laufen, Daten müssen sicher sein und Berichte reproduzierbar.

Ein einfacher, zuverlässiger Deployment-Pfad

Starte mit Managed-Services, damit du dich auf Korrektheit konzentrieren kannst.

• Managed-DB (PostgreSQL): automatisierte Backups, Point-in-Time Recovery, Verschlüsselung.
• Container-Hosting für Web/API (z. B. managed container platform): einfache Rollbacks und konsistente Umgebungen.
• Object Storage für Exporte (CSV/PDF) und große Artefakte, mit Lifecycle-Regeln.

Halte Umgebungen minimal: dev → staging → prod, jeweils mit eigener DB und Secrets.

Hintergrund-Jobs, die du von Anfang an brauchst

SLA-Tracking ist nicht rein Request/Response; es hängt von geplanten Aufgaben ab.

• Berechnungsjobs: SLA-Fenster neu berechnen bei neuen Events und nach spät eintreffenden Daten neu ausführen.
• Report-Generierung: tägliche/monatliche Zusammenfassungen, kundenfertige Exporte.
• Datenhygiene: alte rohe Events archivieren, abgeleitete Tabellen komprimieren, referentielle Integrität prüfen.

Führe Jobs über einen Worker-Prozess + Queue oder einen managed Scheduler aus, der interne Endpunkte aufruft. Mache Jobs idempotent (retry-safe) und logge jeden Lauf für Auditzwecke.

Aufbewahrung und Exporte (ohne zu viel zu versprechen)

Definiere Retention nach Datentyp: behalte abgeleitete Compliance-Ergebnisse länger als rohe Events. Biete Exporte zuerst als CSV an (schnell, transparent), später PDF-Templates. Sei klar: Exporte sind „Best-Effort-Formatierung“, die DB bleibt die Quelle der Wahrheit.

Phasierter Fahrplan, der Umfang kontrolliert

1. MVP: ein Service, ein SLA, eine Zeitzone, einfaches Dashboard + Monatsbericht.
2. Mehr Metriken: Antwortzeit-SLAs, Wartungsfenster, Ausschlüsse, mehrere Kalender.
3. Kundenportal: per-Kunde-Ansichten, Zugriffskontrolle, herunterladbare Berichte.
4. Statusseite: öffentliche/ private Seiten, gestützt auf berechnete Verfügbarkeit (siehe /blog/status-pages).

Prototyping schneller mit Koder.ai (optional)

Wenn du dein Datenmodell, den Ingest-Flow und die Reporting-UI schnell validieren willst, kann eine Vibe-Coding-Plattform wie Koder.ai helfen, ein End-to-End-Prototyp ohne vollständigen Engineering-Aufwand zu erstellen. Da Koder.ai komplette Anwendungen per Chat generiert (Web-UI plus Backend), ist es praktisch, um schnell zu realisieren:

• ein React-Dashboard für Compliance, Error-Budgets und Drilldown-Timelines,
• ein Go + PostgreSQL-Backend zum Speichern roher Events und Periodenergebnisse,
• Export-/Report-Endpunkte und einfache Kundenportal-Views.

Sobald Anforderungen und Berechnungen bewiesen sind (der schwierige Teil), kannst du iterieren, den Quellcode exportieren und in einen traditionelleren Build-&-Operate-Workflow überführen — wobei Features wie Snapshots und Rollback während schneller Iteration erhalten bleiben.