{"id":65291,"date":"2020-05-11T13:51:00","date_gmt":"2020-05-11T13:51:00","guid":{"rendered":"https:\/\/kepner-tregoe.com\/blogs\/the-essential-guide-to-incident-response\/"},"modified":"2026-06-29T19:54:35","modified_gmt":"2026-06-29T19:54:35","slug":"the-essential-guide-to-incident-response","status":"publish","type":"post","link":"https:\/\/kepner-tregoe.com\/de\/blogs\/the-essential-guide-to-incident-response\/","title":{"rendered":"Der ultimative Leitfaden f\u00fcr Incident Response"},"content":{"rendered":"

Manchmal lohnt es sich, zu den Grundlagen zur\u00fcckzukehren. Zum Beispiel, indem wir uns den eigentlichen Zweck von Incident Response (IR) vor Augen f\u00fchren. Die Antwort ist einfach: den Gesch\u00e4ftsbetrieb aufrechtzuerhalten. Doch diese scheinbare Einfachheit t\u00e4uscht. Die Verantwortung ist enorm – insbesondere dann, wenn bei der Bew\u00e4ltigung eines Major Incidents<\/a> etwas schiefl\u00e4uft. Laut Gartner<\/a> kostet jede Minute eines Systemausfalls durchschnittlich 5.600 $. Das summiert sich auf mehr als 300.000 US-Dollar pro Stunde. Entsprechend hoch sind die finanziellen Auswirkungen und der Druck auf die Verantwortlichen.<\/p>\n

Bei Kepner-Tregoe haben wir sieben Best Practices zusammengestellt, die den Erfolg Ihres Incident-Response-Programms nachhaltig unterst\u00fctzen. Sie umfassen operative, technische und organisatorische Ma\u00dfnahmen, die gemeinsam den Aufbau eines leistungsstarken IR-Teams erm\u00f6glichen.<\/p>\n

Warum Incident Response wichtig ist<\/h3>\n

ITIL definiert einen Incident als jede Unterbrechung oder Beeintr\u00e4chtigung des normalen IT-Betriebs. Bezogen auf Ihr Unternehmen bedeutet das: Ein Incident liegt immer dann vor, wenn ein Systemverhalten Ihre Kunden oder Gesch\u00e4ftsprozesse negativ beeinflusst. Dabei muss es sich nicht zwangsl\u00e4ufig um einen vollst\u00e4ndigen Systemausfall handeln. Nehmen wir beispielsweise ein langsames E-Mail-System. Handelt es sich dabei um einen Incident? Nach unserer Definition eindeutig ja. Verz\u00f6gerte E-Mails f\u00fchren zu l\u00e4ngeren Reaktionszeiten im Kundenservice, verz\u00f6gern die Bearbeitung von Ausschreibungen (RFPs), bremsen die Produktentwicklung und beeintr\u00e4chtigen letztlich nahezu jede wertsch\u00f6pfende Aktivit\u00e4t im Unternehmen.<\/p>\n

Incident Response beschreibt den Prozess, mit dem auf solche Vorf\u00e4lle reagiert wird. Dabei unterscheiden sich Incidents von Problemen (\u201eProblems\u201c) \u2013 auf diesen Unterschied gehen wir sp\u00e4ter noch ein. Eine erfolgreiche Incident Response, die sowohl schnell als auch wirksam ist, steigert die Effizienz von Mitarbeitern und Prozessen, erh\u00f6ht die Produktivit\u00e4t und tr\u00e4gt letztlich zu h\u00f6heren Ums\u00e4tzen bei. Incident Response ist damit eine gesch\u00e4ftskritische Disziplin.<\/p>\n

7 Best Practices f\u00fcr eine erfolgreiche Incident Response<\/h3>\n

Hier sind sieben Best Practices, mit denen Sie Ihr IR-Team auf H\u00f6chstleistung trimmen k\u00f6nnen.<\/p>\n

1. Kommunizieren, kommunizieren, kommunizieren<\/h4>\n

Zwischen der IT und dem Rest der Organisation \u2013 insbesondere den Endanwendern \u2013 besteht h\u00e4ufig eine Kommunikationsl\u00fccke. Das erschwert eine effektive Incident Response erheblich, denn viele Incidents werden zun\u00e4chst von den Nutzern bemerkt und gemeldet.<\/p>\n

Deshalb m\u00fcssen Anwender Vorf\u00e4lle m\u00f6glichst einfach melden k\u00f6nnen. Je fr\u00fcher Ihr Team von einem Incident erf\u00e4hrt, desto schneller kann es reagieren. Gleichzeitig sollten die Betroffenen w\u00e4hrend der gesamten Bearbeitung regelm\u00e4\u00dfig \u00fcber den aktuellen Stand informiert werden. Nur so entsteht das notwendige Vertrauen f\u00fcr eine enge Zusammenarbeit bei zuk\u00fcnftigen Vorf\u00e4llen.<\/p>\n

Bieten Sie daher mehrere Meldewege an, beispielsweise per E-Mail, Chat, Serviceportal oder \u00fcber interne Kollaborationsplattformen. Erg\u00e4nzend dazu sollten Self-Service-Angebote eingerichtet werden, mit denen Anwender einfache Probleme selbst l\u00f6sen k\u00f6nnen. Sorgen Sie daf\u00fcr, dass diese Angebote leicht zug\u00e4nglich sind, und vermitteln Sie den Nutzen von Wissensdatenbanken und Selbsthilfeoptionen.<\/p>\n

W\u00e4hrend der Bearbeitung eines Incidents ist eine transparente Kommunikation entscheidend. Zwei Informationen sollten jederzeit leicht verf\u00fcgbar sein: der aktuelle Bearbeitungsstatus einschlie\u00dflich einer gesch\u00e4tzten L\u00f6sungszeit, und die Priorit\u00e4t des Incidents im Verh\u00e4ltnis zu anderen Vorf\u00e4llen.<\/p>\n

Automatisierte Benachrichtigungen k\u00f6nnen dabei unterst\u00fctzen, alle Beteiligten \u00fcber den gesamten Lebenszyklus eines Major Incidents hinweg auf dem Laufenden zu halten. Klare Statusmeldungen reduzieren zudem die Zahl doppelter Ticketmeldungen und entlasten den Service Desk.<\/p>\n

Selbst wenn es keine neuen Erkenntnisse gibt, sollten Stakeholder regelm\u00e4\u00dfig informiert werden \u2013 beispielsweise st\u00fcndlich oder alle 30 Minuten. F\u00fcr Major Incidents empfiehlt sich au\u00dferdem eine dedizierte Kommunikationslinie, \u00fcber die Betroffene schnell Unterst\u00fctzung erhalten.<\/p>\n

2. DevOps-Prinzipien etablieren<\/h4>\n

Bevor DevOps zum Standard wurde, arbeiteten Incident-Response-Teams h\u00e4ufig isoliert. Sie waren f\u00fcr die Behebung von St\u00f6rungen verantwortlich, w\u00e4hrend die Entwickler, die die Systeme erstellt hatten, nur begrenzt eingebunden waren.<\/p>\n

R\u00fcckmeldungen \u00fcber wiederkehrende Probleme gelangten oft nicht zu den Entwicklungsteams. Zwischen denjenigen, die Systeme entwickelten, und denjenigen, die sie im Fehlerfall betreuten, bestand nur wenig Austausch. Genau diese Silos sollte DevOps aufbrechen.<\/p>\n

Angesichts der zunehmenden Komplexit\u00e4t moderner IT-Landschaften ist das heute wichtiger denn je. Systeme sind eng miteinander vernetzt, und \u00c4nderungen oder St\u00f6rungen in einem Bereich wirken sich h\u00e4ufig auf andere Bereiche aus.<\/p>\n

Eine funktionierende DevOps-Kultur f\u00fchrt dazu, dass Entwickler ihre Systeme nachhaltiger und wartungsfreundlicher gestalten, weil sie auch Verantwortung f\u00fcr den laufenden Betrieb \u00fcbernehmen. Probleme werden nicht einfach an andere Teams weitergereicht. Gleichzeitig profitieren Incident-Response-Teams von einer besseren Zusammenarbeit, klareren Dokumentation und direkter Unterst\u00fctzung durch die Systemexperten.<\/p>\n

3. Wissen, wann \u201eSwarming\u201c sinnvoll ist<\/h4>\n

Viele Unternehmen arbeiten bei der Incident-Bearbeitung mit einem mehrstufigen Supportmodell: Tier 1 \u00fcbernimmt der Service Desk, Tier 2 die Anwendungsspezialisten und Tier 3 die Systemexperten oder Entwickler.<\/p>\n

F\u00fcr Major Incidents sollte dieses Modell jedoch nicht starr angewendet werden. Geben Sie Ihren Teams die M\u00f6glichkeit, bei Bedarf auf \u201eSwarming\u201c umzuschalten.<\/p>\n

Swarming eignet sich insbesondere dann, wenn ein Vorfall erhebliche Auswirkungen auf das Gesch\u00e4ft hat. In solchen F\u00e4llen sollten Sie von den normalen gestuften IR-Prozessen abweichen. Swarming ersetzt diese Struktur durch ein Modell der vernetzten Zusammenarbeit. Das Konzept wurde urspr\u00fcnglich von Cisco entwickelt, das 2008 im Whitepaper \u201eDigital Swarming<\/a>\u201c dar\u00fcber schrieb. Das Konzept wurde sp\u00e4ter vom Consortium for Service Innovation \u00fcbernommen und als \u201eIntelligent Swarming<\/a>\u201c weitergef\u00fchrt.<\/p>\n

Die Grundidee besteht darin, die kollektive Expertise aller Beteiligten gleichzeitig zu nutzen. Durch gemeinsames Brainstorming, schnellen Wissensaustausch und direkte Zusammenarbeit lassen sich komplexe Probleme oft deutlich schneller l\u00f6sen.<\/p>\n

Zu den zentralen Prinzipien des Swarming geh\u00f6ren:<\/p>\n