So werden Sie den Herausforderungen des Incident-Managements für MSPs gerecht
In diesem Kapitel gehen wir auf die wichtigsten Herausforderungen ein, mit denen MSPs in jeder Phase des Incident-Lebenszyklus konfrontiert sind, und stellen bewährte Lösungen vor, um sie zu bewältigen. Diese Empfehlungen basieren auf dem Feedback unserer MSP-Kunden aus ihrer täglichen Arbeit und beinhalten Best Practices, die wir in jahrelanger Zusammenarbeit mit führenden Dienstleistern optimiert haben.
Dieser Leitfaden soll nicht nur häufige Fallstricke aufzeigen, sondern auch praxisnahe Strategien liefern, mit denen MSPs ihre Incident-Management-Prozesse stärken und ihren Kunden einen erstklassigen Service bieten können.
Die größten Probleme, mit denen MSPs zu Beginn des Incident-Managements konfrontiert sind
Fehlen einer klaren Richtlinie für das Störungsmanagement
Viele MSPs arbeiten reaktiv, ohne einen standardisierten Plan für die Reaktion auf Störungen. Dies führt zu Ad-hoc-Entscheidungen, Verwirrung bei stressigen Incidents und uneinheitlichen Kundenerfahrungen.
Die Lösung:
Erstellen Sie ein standardisiertes, dokumentiertes Rahmenwerk für die Reaktion auf Störungen – ITIL ist ein guter Ausgangspunkt – und machen Sie daraus ein Regelwerk für den täglichen Gebrauch. ITIL bietet einen strukturierten Ansatz für das IT-Servicemanagement, einschließlich definierter Prozesse für die Erkennung, Eskalation, Kommunikation und Lösung von Störungen. Passen Sie die Richtlinie bei Bedarf an den jeweiligen Kunden an, aber stellen Sie sicher, dass Ihre Teams einer einheitlichen Struktur folgen. Ein gemeinsames Verständnis von Rollen, Verantwortlichkeiten, Eskalationspfaden und Kommunikationsverfahren bildet die Grundlage für schnellere, koordinierte Reaktionen.
Inkonsistente Risikobewertung
Ohne regelmäßige und systematische Risikobewertungen bleiben Schwachstellen verborgen, bis es zu spät ist. Auch dies führt dazu, dass MSPs eher reaktiv als proaktiv handeln, was zu einer Kaskade von Problemen führt, wenn es zu Zwischenfällen kommt.
Die Lösung:
Führen Sie regelmäßige Risikobewertungen sowohl für interne Systeme als auch für Kundenumgebungen ein. Tools wie Schwachstellen-Scanner und Konfigurations-Audits helfen bei der Ermittlung von Schwachstellen. Integrieren Sie die Ergebnisse in einen nach Prioritäten geordneten Lösungsplan. Richten Sie Ihre Bewertungen an den für die Branche des jeweiligen Kunden relevanten Compliance-Standards aus (zum Beispiel HIPAA, GDPR, ISO 27001).
Schwierigkeiten bei der SLA-Verwaltung
Jeder Kunde hat möglicherweise unterschiedliche Erwartungen in Bezug auf Antwort und Lösung, was zu Verwirrung bei der Priorisierung und zur Verletzung von vertraglichen Verpflichtungen führt.
Die Lösung:
Nutzen Sie Ihre Incident-Management-Plattform, um Incidents auf der Grundlage kundenspezifischer SLA-Einstellungen automatisch zu priorisieren und Alarmierungen oder Eskalationen auszulösen, wenn Fristen näher rücken.
Mit ilert zum Beispiel können Alarmierungen automatisch nach definierten Regeln eskaliert werden.
Raus aus dem Chaos: Herausforderungen beim Auftreten der ersten Störungen
Doppelte Alerts
Alarmierungen von verschiedenen, sich überschneidenden Überwachungstools können mehrere Benachrichtigungen über dasselbe zugrunde liegende Problem auslösen. Statt eines eindeutigen Signals sehen sich die Mitarbeiter mit einer Flut von redundanten Alarmierungen konfrontiert. Dies führt zu einer Alarmflut, die es den Teams erschwert, die Grundursache schnell zu identifizieren.
Die Lösung:
Nutzen Sie Ihre Incident-Management-Plattform als zentrale Schaltstelle. Stellen Sie sicher, dass alle Monitoring- und Beobachtungslösungen Alarmierungen direkt an Ihr Incident-Management-System weiterleiten, das Ähnlichkeiten erkennen und Alerts gruppieren kann.
Verschiedene Überwachungsmethoden über mehrere Kunden hinweg
MSPs verwalten oft eine Vielzahl von Kunden, die jeweils unterschiedliche Überwachungstools und Infrastrukturen nutzen. Einige Kunden verfügen möglicherweise über ein ausgefeiltes Cloud-natives Monitoring, während andere auf ein einfaches Server-Monitoring oder Legacy-Systeme zurückgreifen. Diese Vielfalt führt zu fragmentierten Alarmierungs-Workflows, inkonsistenter Erkennung von Störungen und Verzögerungen bei der Eskalation. Das macht es schwierig, konsistente Service-Levels aufrechtzuerhalten und SLA-Verpflichtungen für alle Kunden einzuhalten.
Die Lösung:
Durch die Zentralisierung von Alarmierungen aus allen Client-Monitoring-Systemen in einer einzigen Incident-Management-Plattform können MSPs verschiedene Umgebungen verwalten, ohne an Effizienz zu verlieren. Durch die Integration verschiedener Überwachungstools in ilert werden alle Alarmierungen konsistent an die richtigen Teams weitergeleitet, wobei kundenspezifischer Kontext und Runbooks für eine schnellere Lösung zur Verfügung stehen.
Manuelle Alarmierung funktioniert nicht
Kunden melden Probleme oft manuell durch Anrufe oder Tickets. Beides kann übersehen werden, wodurch sich die Zeit bis zur Bestätigung des Problems verlängert.
Die Lösung:
Schließen Sie die Lücke zwischen manueller und automatischer Alarmierung. Achten Sie bei den Tickets auf die Integration von ITSM- und PSA-Systemen in Ihre Incident-Management-Plattform. ilert arbeitet mit den gängigsten Anwendungen zusammen, wie zum Beispiel Autotask PSA, HaloPSA, ServiceNow und anderen. Tickets werden hierbei stets als Alarmierung behandelt. Bei Bedarf werden SMS oder Anrufe ausgelöst, sobald Ihr Kunde ein Problem meldet.
Das Thema “Hotlines” hatten wir schon angesprochen. So funktionieren sie im Detail: Sie stellen Ihren Kunden eine spezielle Telefonnummer zur Verfügung, die in der Regel an einen bestimmten Servicevertrag oder ein SLA gebunden ist. Wenn ein Nutzer diese Nummer anruft, leitet das System den Anruf entsprechend den Bereitschaftsplänen und Eskalationsrichtlinien weiter, um sicherzustellen, dass das richtige Team schnell erreicht wird – auch außerhalb der regulären Geschäftszeiten. Ein IVR-Menü (“Interactive Voice Response” / Sprachdialogsystem) hilft den Kunden, ihr Problem zu kategorisieren (zum Beispiel: Ausfall, technischer Support usw.), was eine schnellere Triage ohne manuellen Aufwand ermöglicht. PIN-Codes sichern die Hotline, sodass nur autorisierte Kontakte kritische Vorfälle auslösen können.
Ressourcenknappheit und Arbeitsüberlastung
MSPs arbeiten oft mit kleinen Teams, die ein hohes Aufkommen an Alarmierungen bewältigen müssen. Das führt zur Überlastung der Mitarbeiter, einer langsameren Bearbeitung von Störungen und einem erhöhten Fehlerrisiko.
Die Lösung:
Konzentrieren Sie die Energien Ihres Teams dort, wo sie am wichtigsten sind. Nutzen Sie ilert, um überflüssige Alarmierungen herauszufiltern, verwandte Alarmierungen zu gruppieren und nur kritische Probleme zu eskalieren. Automatisieren Sie wiederkehrende Aufgaben und verteilen Sie die Dienstbereitschaften gleichmäßig, um eine Überlastung der einzelnen Mitarbeiter zu vermeiden. Überprüfen Sie regelmäßig Ihre Alarmierungsrichtlinien und die Arbeitsbelastung, um die Leistungsfähigkeit und Ausgeglichenheit Ihres Teams zu erhalten und für echte Notfälle gerüstet zu sein.
Unzureichender Zugang zu Client-Umgebungen
Wenn die dienstbereiten Techniker während einer Störung nicht den richtigen Zugang zu den Client-Systemen haben, verzögert dies die Analyse, Fehlerbehebung und Wiederherstellung und macht aus einem kleinen Problem eine große Störung.
Die Lösung:
Bereiten Sie sich vor, bevor es zu Störungen kommt. Richten Sie einen sicheren, rollenbasierten Zugang zu kritischen Client-Umgebungen für Ihre Bereitschaftsteams ein. Verwenden Sie Tools wie VPNs, Bastion Hosts oder Remote-Management-Systeme, die regelmäßig getestet werden. Dokumentieren Sie die Zugriffsverfahren klar in Runbooks und halten Sie Notfallzugriffspfade (mit Genehmigung des Kunden) bereit. Schneller Zugriff bedeutet schnellere Lösungen – und weniger Ausfallzeiten für Ihre Kunden.
Kommunikationsprobleme
Verspätete oder inkonsistente Updates für Kunden
Bei Störungen, insbesondere bei größeren Ausfällen oder Service-Verschlechterungen, erwarten die Kunden klare, regelmäßige und proaktive Updates. Viele MSPs haben mit uneinheitlichen Zeitplänen, vagen Formulierungen oder manuellem Aufwand zu kämpfen, was zu Kommunikationslücken führt, das Vertrauen der Kunden beschädigt und möglicherweise gegen SLA-Verpflichtungen verstößt.
Die Lösung:
Definieren und standardisieren Sie zunächst, wie oft Kunden bei verschiedenen Störungen Updates erhalten sollten. Bei kritischen Störungen sollte die erste Kundenbenachrichtigung innerhalb von 15 Minuten nach der Entdeckung erfolgen, mit nachfolgenden Aktualisierungen alle 15 bis 30 Minuten bis zur Lösung. Bei schwerwiegenden Störungen sollte die erste Aktualisierung innerhalb von 30 Minuten erfolgen und mindestens jede Stunde aktualisiert werden. Bei geringfügigen Problemen sollten Sie innerhalb der ersten Stunde informieren und alle paar Stunden weitere Aktualisierungen bereitstellen. Bei informativen Störungen mit geringer Priorität reicht in der Regel eine Antwort innerhalb von 24 Stunden und eine Aktualisierung nach Lösung des Incidents aus. Selbst wenn es keine neuen Informationen gibt, können Sie Ihren Kunden mit einem „Keine Änderung“-Update versichern, dass aktiv an dem Problem gearbeitet wird.
Zweitens sollten MSPs bei jedem Kunden-Update eine strukturierte und proaktive Kommunikation nutzen. Jede Nachricht sollte den aktuellen Status der Störung, eine klare Beschreibung der Auswirkungen auf den Kunden, die bisher getroffenen Maßnahmen und eine Ankündigung des nächsten Updates enthalten (zum Beispiel: „Wir werden in 30 Minuten ein weiteres Update bereitstellen). Es ist wichtig, in prägnanter, klarer und nicht-technischer Sprache zu kommunizieren, es sei denn, der Kunde erwartet ausdrücklich technische Details. Vermeiden Sie vage Formulierungen wie „wir arbeiten daran“ – Ihr Kunde sollte immer das Gefühl haben, dass er mit aussagekräftigen Updates auf dem Laufenden gehalten wird.
Unklare Kundenerwartungen
Kunden überschätzen häufig die Zuständigkeiten des MSPs und erwarten sofortige Lösungen für komplexe Probleme.
Lösung:
Setzen Sie von Anfang an klare Erwartungen und wiederholen Sie diese regelmäßig. Führen Sie Ihre Kunden beim Onboarding und bei Vertragsverlängerungen durch den Leistungsumfang, die standardmäßigen Reaktionszeiten und die Inhalte (sowie Ausschlüsse) des SLAs. Bei größeren Incidents sollten Sie frühzeitig über die Komplexität, die geschätzte Bearbeitungszeit und die bereits eingeleiteten Maßnahmen informieren. Gehen Sie niemals davon aus, dass Ihre Kunden „wissen, wie es läuft“ – proaktives Erwartungsmanagement schafft Vertrauen und beugt Frustration in kritischen Situationen vor.
Interne Kommunikationssilos
Wenn Teams wie Support, Engineering und Security bei Incidents isoliert arbeiten, entstehen Informationssilos. Wichtige Details gelangen nicht schnell genug von einem Team zum anderen, was zu Verzögerungen bei der Diagnose, doppeltem Arbeitsaufwand und verpassten Chancen für eine schnelle Lösung führt. In Stresssituationen können solche Ineffizienzen die Lage verschärfen und den MSP gegenüber Kunden unorganisiert wirken lassen.
Lösung:
Überwinden Sie Silos durch gemeinsame Kommunikationskanäle und klare Kollaborationsprozesse. Nutzen Sie eine Incident-Management-Plattform wie ilert, um eine zentrale Informationsquelle für Incident-Updates zu schaffen. Üben Sie regelmäßig teamübergreifende Incident-Simulationen, um schnelle und offene Kommunikation im Ernstfall zu festigen. Ein gut vernetztes Team reagiert schneller, arbeitet effektiver und bietet ein besseres Kundenerlebnis.
Herausforderung Incident-Management in Multi-Tenant-Umgebungen
Das Incident-Management über verschiedene Kunden mit jeweils individuellen Umgebungen hinweg erhöht die Komplexität von Status-Updates und Reporting.
Lösung:
MSPs benötigen eine Incident-Management-Plattform, die speziell für Multi-Client-Umgebungen entwickelt wurde. Mit Lösungen wie ilert können Störungen automatisch nach Kunde, SLA-Stufe und Priorität gekennzeichnet werden, sodass kundenspezifische Workflows ohne zusätzlichen manuellen Aufwand möglich sind. Zielgruppenspezifische Statusseiten ermöglichen es, Echtzeit-Updates gezielt pro Kunde bereitzustellen – so sehen nur die jeweils relevanten Empfänger die Benachrichtigungen zu Incidents, die ihre Umgebung, Infrastruktur oder ihr Service-Level betreffen.
Die schwierige Phase nach einer IT-Störung
Unklare Ursachenanalyse
In vielen Post-Incident-Reviews brechen Teams die Analyse zu früh ab. Sie benennen zwar das unmittelbare technische Problem (zum Beispiel „Festplatte voll“ oder „Dienst abgestürzt“), identifizieren jedoch nicht die tieferliegenden Ursachen wie fehlendes Monitoring, mangelhafte Kapazitätsplanung oder versäumte Wartungsaufgaben. Ohne die tatsächlichen Ursachen zu erkennen, besteht ein hohes Risiko, dass ähnliche Störungen erneut auftreten.
Lösung:
1. Nutzen Sie strukturierte Methoden zur Root-Cause-Analyse (RCA), wie zum Beispiel die „5 Whys“ oder das Fischgräten-Diagramm, um der Ursache einer Störung systematisch auf den Grund zu gehen.
2. Beziehen Sie funktionsübergreifende Teams in die Analyse ein, um sowohl technische als auch prozessuale Schwachstellen sichtbar zu machen.
3. Dokumentieren Sie in jedem Postmortem sowohl die technischen Ursachen als auch Faktoren, die zu dem Problem beigetragen haben, wie menschliche Fehler, Prozessmängel oder Systemschwächen.
4. Verwenden Sie Incident-Management-Plattformen wie ilert, um einen vollständigen Audit-Trail zu erhalten – eine wichtige Grundlage für eine präzise Rekonstruktion des Incident-Verlaufs.
Blame Culture oder defensives Verhalten
Wenn Post-Incident-Reviews zu Schuldzuweisungen führen, vermeiden Teammitglieder es, Fehler offenzulegen oder ehrliches Feedback zu geben. Eine solche defensive Atmosphäre verhindert echtes Lernen und fördert langfristig eine toxische Kultur – das schwächt die gesamte Incident-Management-Praxis.
Lösung:
MSP-Führungskräfte sollten einen Postmortem-Prozess ohne Schuldzuweisungen etablieren, der sich auf Systemverbesserung statt auf persönliche Kritik fokussiert. Incident-Reviews sollten stets als Lernchance und Möglichkeit zur Stärkung der Betriebsabläufe verstanden werden – nicht als Mittel zur Sanktionierung. Es ist entscheidend, Verantwortliche in konstruktiver, nicht-wertender Gesprächsführung zu schulen und die Haltung zu verankern, dass Fehler meist auf systemische Schwächen hinweisen.
Fehlende Umsetzung der Erkenntnisse in den operativen Betrieb
Viele MSPs führen zwar Incident-Reviews durch, setzen die daraus gewonnenen Erkenntnisse jedoch nicht konsequent um. Die Learnings werden zwar besprochen, aber nicht systematisch in Monitoring-Setups, Runbooks, Eskalationsrichtlinien oder Kundenkonfigurationen überführt. Ohne diesen Feedback-Loop bleiben Schwachstellen bestehen – und die gleichen Fehler wiederholen sich.
Lösung:
Nach jedem größeren Incident müssen Korrekturmaßnahmen dokumentiert, klaren Verantwortlichen zugewiesen und bis zur Umsetzung nachverfolgt werden. Dazu gehören unter anderem die Aktualisierung von Runbooks, Anpassung von Monitoring-Schwellenwerten, Verfeinerung von Eskalationswegen oder Optimierung von Kundenkonfigurationen.
Mit einer Incident-Management-Plattform wie ilert lassen sich diese Aufgaben direkt dem jeweiligen Incident zuordnen, wodurch sie sichtbar und nachvollziehbar bleiben. In regelmäßigen operativen Meetings sollte der Status offener Maßnahmen überprüft werden, um die Umsetzung der Maßnahmen sicherzustellen.
