SLA-Engine

OpsWeaves SLA-Engine bindet Service-Levels nicht nur an den Kunden, sondern direkt an Assets und vererbt sie über die CMDB-Abhängigkeitskette. So ist „Datenbank Gold" nicht nur ein Label — alle Apps, die auf der Datenbank laufen, erben automatisch denselben Tier.

Kernkonzept: Asset-Kritikalität steuert SLA

Klassisches Ticketing (z.B. Jira Service Management) bindet SLAs an den Kunden („Klient A = Gold"). Das reicht nicht, wenn drei Kunden sich dieselbe Infrastruktur teilen — fällt das Cluster aus, hat plötzlich die Bronze-Kunden-App den gleichen Schmerz wie die Gold-Kunden-App.

OpsWeave bindet SLAs deshalb an Assets:

1. Direkt am Asset: Jedes Asset bekommt ein optionales sla_tier-Feld (Gold / Silver / Bronze / custom).
2. Vererbung: Hängt eine App von einem Gold-Server ab, erbt die App automatisch Gold — auch wenn sie für einen Silver-Kunden läuft.
3. Höchste Kritikalität gewinnt: Im DAG wird der höchste SLA-Tier traversiert.

Beispiel:

Geschäftskritischer Service (kein direkter SLA)
  ├─ depends_on → Load Balancer (Silver)
  └─ depends_on → PostgreSQL Cluster (Gold)

→ Service erbt Gold (höchster Tier in der Kette).
→ Incident auf diesem Service: 1 h Response, 4 h Resolution.

DAG-Vererbung

Die Vererbungslogik nutzt den Directed Acyclic Graph (DAG) der CMDB:

Pseudocode:

resolveSlaForAsset(assetId):
  if asset.sla_tier exists:
    return asset.sla_tier

  max_tier = null
  for each outgoing relation (depends_on, runs_on, part_of, ...):
    related = resolveSlaForAsset(related_asset_id)
    max_tier = max(max_tier, related)

  return max_tier

Implementiert über rekursive CTEs (PostgreSQL und SQLite), eine SQL-Abfrage pro Resolve — keine N+1-Queries.

API: SLA-Vererbungskette eines Assets abrufen

GET /api/v1/assets/:id/sla-chain

Antwort:

{
  "asset": "web-app-01",
  "resolved_sla_tier": "gold",
  "inheritance_path": [
    { "asset_id": "web-app-01", "sla_tier": null, "reason": "none" },
    { "asset_id": "db-postgres-prod", "sla_tier": "gold", "reason": "depends_on" }
  ]
}

SLA-Klassen

Eine SLA-Definition deckt nicht nur Incident-Reaktion ab, sondern mehrere Klassen:

Klasse	Bedeutung	Trigger
Verfügbarkeit	Uptime-Ziel pro Monat (z.B. 99,9 %)	Monatlicher Audit-Job
Incident-Reaktion	Erste Antwort auf einen Fehler	Ticket erstellt → Timer startet
Incident-Resolution	System läuft wieder	Timer endet bei Status „Resolved"
CVE-Patch	Security-Update auf betroffenen Assets	CVE published → Asset notifiziert
Patch-Compliance	Regelmäßige Patches (z.B. monatlich)	OS/App-Update released
Service-Request	Nicht-Incident (Passwort-Reset, Zugang)	SR-Ticket erstellt

Beispiel: Gold-Definition

gold_sla_definition:
  incident_response_minutes: 60
  incident_resolution_minutes: 240
  service_request_minutes: 480
  cve_critical_minutes: 1440      # 1 Tag
  cve_high_minutes: 10080         # 7 Tage
  patch_monthly_days: 30
  availability_slo: 99.9
  business_hours: business        # 08:00-17:00 Mo-Fr
  holiday_dates: ["2026-12-24", "2026-12-25"]

Konfiguration: drei Ebenen

1. SLA-Definitionen (global pro Mandant)

Settings → Service Levels → Definitions

Hier definierst du Tiers (Gold, Silver, Bronze) und ihre Fristen. Custom-Tiers wie „Platinum" für Enterprise-Kunden sind möglich.

2. SLA-Zuweisung pro Asset

CMDB → Asset Detail → Tab „SLA"

Du weist einem Asset einen Tier explizit zu. Über inherit_to_dependents: true wird der Tier an alle abhängigen Assets weitergegeben.

POST /api/v1/assets/:id/assign-sla
{
  "sla_definition_id": "sla_def_gold",
  "inherit_to_dependents": true
}

3. Kunden-Default (MSP-Szenario)

Settings → Customers → [Customer Name] → Default SLA

Fallback-Hierarchie für jedes Ticket:

1. Asset hat eigenen SLA-Tier → nimm den.
2. Asset erbt SLA aus DAG → nimm den.
3. Kunde hat Default → nimm den.
4. Kein Default → kein SLA-Timer.

Eskalation und Breach-Erkennung

Die Engine berechnet für jedes neue Ticket Fristen unter Berücksichtigung der konfigurierten Business Hours und Feiertage.

Beispiel (Gold, Business Hours 08–17):

Ticket erstellt: Donnerstag 16:30
Response-Deadline: Freitag 09:30 (+1 h Business-Time)
Resolution-Deadline: Freitag 13:30 (+4 h Business-Time)

Ticket erstellt: Freitag 16:30
Response-Deadline: Montag 09:30 (Wochenende übersprungen)

Ein Background-Worker prüft alle 60 Sekunden alle offenen Tickets:

für jedes offene Ticket:
  if now > 75 % der Frist und nicht breached:
    → Badge „SLA Warning" (gelb)
  if now > Frist und nicht breached:
    → SLA breached
    → Notification an Assignee + Group
    → History-Eintrag
    → Webhook-Event
    → Eskalations-Workflow (wenn konfiguriert)

Pause & Resume

Ticket-Status „Wartend" pausiert den SLA-Timer. Die verbleibende Frist wird gespeichert (sla_paused_minutes). Beim Statuswechsel zurück läuft der Timer mit angepasster Deadline weiter.

Response-Deadline: Freitag 12:00
Ticket → Waiting (Donnerstag 10:00) → 2 h Pause
Ticket → In Bearbeitung (Donnerstag 12:00)
Neue Response-Deadline: Freitag 14:00

MSP-Szenario: mehrere Kunden, geteilte Infrastruktur

Drei Kunden teilen sich ein Datenbank-Cluster:

Shared Database Cluster (Gold)
  ├── Acme Corp Web App     (kein direkter SLA)  → erbt Gold
  ├── TechStartup Web App   (Silver direkt)       → erbt Gold (höher gewinnt)
  └── SMB Web App           (Bronze direkt)       → erbt Gold

Outage 14:00 Freitag — was passiert:

1. Check_MK-Alert kommt rein → Ticket „Database Connection Failure".
2. Asset wird als Gold aufgelöst → Response-Deadline 15:00, Resolution-Deadline 18:00.
3. Optionaler Workflow erzeugt abhängige Tickets pro Kunde, alle mit geerbtem Gold.
4. 14:30 → SLA-Warning (75 % der 1 h verstrichen) → Assignee notified.
5. 15:00 → Response Breached → Eskalation an Incident-Manager.
6. 18:00 → Resolution Breached → Page an On-Call.

Vorteil: Du markierst die geteilte Infrastruktur einmal als Gold — alle abhängigen Kunden sind automatisch geschützt. Wer höhere Garantien braucht, bekommt einen separaten Tier auf seinem dedizierten Asset.

Visuelle Indikatoren

Im Ticket-Board zeigen farbige Punkte den SLA-Status:

• Grün: < 75 % der Frist verstrichen
• Gelb: > 75 % verstrichen
• Rot: Breached

Im Ticket-Detail (rechte Spalte):

SLA Status
├── Tier: Gold (inherited from Database)
├── Response: Due 15:00 (in 23 min) — Warning
├── Resolution: Due 18:00 (in 2 h 23 min) — OK
└── Paused: 30 min (waiting on customer)

Reports

Reports → SLA zeigt:

• Compliance-Rate pro Tier
• MTTR (Mean Time To Resolve) pro Tier
• Breach-Trends (letzte 30 Tage, getrennt nach Response- und Resolution-Breaches)
• Top-betroffene Assets

Wichtige API-Endpoints

GET    /api/v1/settings/sla-definitions
POST   /api/v1/settings/sla-definitions
GET    /api/v1/assets/:id/sla-chain
POST   /api/v1/assets/:id/assign-sla
GET    /api/v1/tickets?include=sla
GET    /api/v1/tickets/stats?filter=sla_breached:true&period=month

Was die Engine nicht macht

• Kein Monitoring: SLA-Engine prüft nur Tickets, nicht Live-Verfügbarkeit. Verfügbarkeits-SLOs werden nachträglich aus Monitoring-Quellen berechnet (siehe Monitoring-Integration).
• Keine Custom-Eskalations-Bäume out-of-the-box: Eskalation läuft über den Workflow-Engine — du baust die Stufen selbst.
• Keine SLA-Vererbung über Workflow-Schritte: Ein Workflow kann SLA-Felder lesen, aber das Ticket bleibt der Owner der SLA-Berechnung.