Service Management

Service Management richtet einen verlässlichen Tag-2-Betrieb ein und hält ihn laufend. Bewährte Service-Strukturen werden mit moderner Automatisierung verbunden, sodass Störungen proaktiv verhindert und im Fehlerfall schnell und koordiniert behandelt werden. Stabiler Betrieb ist kein Zufall, sondern das Ergebnis klarer Prozesse, messbarer Ziele und einer Organisation, die aus jedem Vorfall lernt. Genau diese Betriebsfähigkeit wird eingerichtet und laufend gehalten.

Typische Ausgangslagen

  • der Betrieb nach dem Go-live zu reaktiv ist und Incidents wiederkehren: Incident- und Problem-Management führen grössere Störungen durch Ablauf, Rollen und Post-Mortem
  • Supportwege unklar bleiben oder die Verfügbarkeit an geschäftskritischen Stichtagen abgesichert werden muss: Servicekatalog, Runbooks, Restore-Nachweis und Stichtag-Abläufe halten Eskalation und Wiederanlauf fest
  • Servicequalität messbar und Verantwortlichkeiten eindeutig werden müssen, etwa wenn ein Update den Folgebetrieb stören könnte oder ein Backup nie im Restore erprobt wurde: SLO-Dashboard, kontrollierte Update-QA und DR-Härtetest machen Betrieb und Verantwortlichkeiten belegbar

Ergebnisse

Der Betrieb wird belegbar: Reaktions- und Wiederherstellungszeiten sinken, kritische Störungen werden früh erkannt statt vom Nutzer gemeldet, und das Risiko eines Ausfalls am geschäftskritischen Stichtag ist nachweislich abgesichert. Als konkrete Artefakte entstehen:

  • ein Servicekatalog und operative Runbooks (inklusive DR- und Stichtag-Ablauf)
  • ein dokumentierter Restore-Nachweis aus dem DR-Härtetest
  • ein laufendes SLO-Dashboard
  • zu jedem grösseren Incident eine Post-Mortem-Analyse mit konkreten Massnahmen

So wird aus einem Vorfall ein dauerhafter Stabilitätsgewinn statt einer wiederkehrenden Belastung.

Der Leistungsumfang

Jede Störung durchläuft denselben Kreislauf, von der frühen Erkennung bis zur verankerten Massnahme, sodass aus einem Vorfall ein dauerhafter Stabilitätsgewinn wird.

stateDiagram-v2
    accTitle: Incident-Lebenszyklus im Service Management
    accDescr: Aus dem Normalbetrieb führt eine erkannte Störung über die Behebung zur moderierten Post-Mortem-Analyse, deren Massnahme wieder im Normalbetrieb verankert wird.
    [*] --> Normalbetrieb
    Normalbetrieb --> Incident: Störung erkannt (SLO/Observability)
    Incident --> Behebung: fester Ablauf, klare Rollen
    Behebung --> PostMortem: moderierte Analyse
    PostMortem --> Normalbetrieb: Massnahme verankert

Incident- und Problem-Management Strukturierte Prozesse für die Fehlerbehebung und die systematische Ursachensuche verankern dauerhafte Vermeidung. Jeder grössere Incident läuft durch einen festen Ablauf mit klaren Rollen und mündet in eine moderierte Post-Mortem-Analyse.

Service-Level-Management mit Observability und SLO Service Level Objectives werden definiert und über Observability überwacht, orientiert am realen Nutzererlebnis statt nur an technischer Server-Uptime. Kritische Störungen werden so frühzeitig erkannt, bevor sie der Nutzer meldet.

Backup- und Disaster-Recovery-Härtung Das Backup-Konzept wird nicht nur dokumentiert, sondern im Restore geprobt:

  • ein DR-Härtetest weist die Wiederherstellung im vereinbarten Zeitfenster nach
  • aus einem Backup, das versagen könnte, wird eine belegte Wiederanlauffähigkeit

Kontrollierte Update-QA und Stichtag-Stabilität Grössere Updates durchlaufen einen Test- und Freigabeprozess, bevor sie produktiv gehen:

  • Updates werden vor produktiver Nutzung gegen Kernabläufe wie den Belegscanner geprüft
  • termingebundene Lasten (Lohnlauf, Stichtagsabschluss) werden gezielt abgesichert und in Runbooks festgehalten

Self-Service-Support und Portale Wissensdatenbanken und Portale sorgen dafür, dass Anwender und Kunden schnelle Hilfe finden, ohne in Ticket-Warteschlangen zu hängen.

Abgrenzung

Der Service wird nach vereinbarten Service Level Objectives und einem definierten Eskalationspfad betrieben, gemessen am Nutzererlebnis statt an reiner Server-Verfügbarkeit. Reichweite, Erreichbarkeit und Reaktionsfenster werden vorab schriftlich festgelegt. Nicht enthalten sind die Erstentwicklung der Applikation und der laufende Plattform- und Cloud-Kostenbetrieb für Kubernetes und interne Entwicklerplattformen; diesen leistet der Platform- und FinOps-Betrieb. Die Stärkung der Liefer- und Release-Fähigkeit eines Entwicklungsteams übernimmt das Delivery Engineering.

Eckdaten

Der Umfang der Begleitung richtet sich nach Zahl und Kritikalität der Services:

  • wie viele Dienste unter Service-Level-Management stehen
  • wie streng die Verfügbarkeits- und Wiederanlaufziele sind
  • ob ein laufender Retainer oder ein abgegrenztes Optimierungsprojekt gefragt ist

Ein einzelner Dienst ist schlank zu betreuen, eine breite Service-Landschaft mit hohen SLOs verlangt mehr. Was die Begleitung im konkreten Fall kostet, hängt an genau diesen Faktoren. Der Preis-Richtwert nennt den Rahmen für die eigene Service-Landschaft.

Preise anfragen

Weiterführende Informationen