{"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":"2020-05-11T13:51:00","modified_gmt":"2020-05-11T13:51:00","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 hilft es, sich auf die Grundlagen zu besinnen. Zum Beispiel, indem wir uns den Zweck von Incident Response (IR) vor Augen f\u00fchren. Die Antwort ist einfach: den Gesch\u00e4ftsbetrieb aufrechtzuerhalten. Doch diese Einfachheit ist tr\u00fcgerisch. Es handelt sich um eine ungeheure Verantwortung, wie Sie wissen, falls jemals etwas bei Ihrer F\u00e4higkeit, auf einen Major Incident zu reagieren, schiefgelaufen ist. Laut Gartner<\/a> kostet jede Minute, in der Ihre Systeme ausfallen, im Durchschnitt 5.600 $, was sich auf mehr als 300.000 $ pro Stunde summiert. Das ist viel Geld und bedeutet einen enormen Druck. <\/p>\n

Bei KT haben wir unsere K\u00f6pfe zusammengesteckt und sieben Best Practices entwickelt, um den Erfolg Ihres IR-Programms sicherzustellen. Diese umfassen operative, technische und organisatorische Vorschl\u00e4ge, die alle dazu beitragen, ein erstklassiges IR-Team aufzubauen. <\/p>\n

Warum Incident Response?<\/h3>\n

ITIL beschreibt einen Incident als jede Unterbrechung oder St\u00f6rung des normalen IT-Betriebs. Wir k\u00f6nnen dies spezifischer auf Ihr Unternehmen beziehen und sagen, dass ein Incident jeder Umstand ist, in dem ein System so agiert, dass es Ihre Kunden negativ beeinflusst. Es muss sich dabei nicht um einen kompletten Systemabsturz handeln. Nehmen wir ein langsames E-Mail-System. Stellt das einen Incident dar? Nach unserer Definition auf jeden Fall, denn langsame E-Mails bedeuten langsamere Reaktionen auf Kundenservice-Anfragen, verz\u00f6gerte Reaktionen auf Ausschreibungen (RFPs), eine verlangsamte Produktentwicklung und beeintr\u00e4chtigen so gut wie jede gewinnorientierte Aktivit\u00e4t Ihres Unternehmens. <\/p>\n

IR ist Ihr Prozess zur Reaktion auf diese Incidents (wobei sich Incidents von Problemen unterscheiden, was wir sp\u00e4ter besprechen werden). Eine erfolgreiche IR \u2013 was bedeutet, dass sie sowohl schnell als auch effektiv ist \u2013 f\u00fchrt zu einer verbesserten Effizienz von Mitarbeitern und Prozessen, h\u00f6herer Produktivit\u00e4t und letztlich zu h\u00f6heren Ums\u00e4tzen f\u00fcr das Unternehmen. Es handelt sich dabei wirklich um eine gesch\u00e4ftskritische Operation. <\/p>\n

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

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

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

Historisch gesehen gab es oft eine Kommunikationskluft zwischen der IT und dem Rest der Organisation \u2013 insbesondere zwischen der IT und den Nutzern. Dies f\u00fchrt zu Problemen beim Versuch, eine exzellente IR zu liefern, da viele, wenn nicht sogar die meisten Ihrer Incidents von Ihren Nutzern gemeldet werden. Diese m\u00fcssen eine einfache M\u00f6glichkeit f\u00fcr diese Meldungen haben, damit Sie so fr\u00fch wie m\u00f6glich von Incidents erfahren. Anschlie\u00dfend m\u00fcssen Sie sie in Echtzeit \u00fcber die Behebung des Incidents auf dem Laufenden halten. All dies ist notwendig, um ihr Vertrauen zu gewinnen, damit sie bei k\u00fcnftigen Vorf\u00e4llen enger mit Ihnen zusammenarbeiten \u2013 eine Kooperation, die unerl\u00e4sslich ist. Er\u00f6ffnen Sie zu Beginn mehrere Kan\u00e4le, \u00fcber die Nutzer problemlos Tickets erstellen k\u00f6nnen. Sie sollten beispielsweise in der Lage sein, das IR-Team per E-Mail, Chat, \u00fcber ein Portal oder ein soziales Unternehmensnetzwerk wie Yammer zu benachrichtigen. Sie sollten zudem Self-Service-Mechanismen einrichten, damit Nutzer einfache Incidents selbst l\u00f6sen k\u00f6nnen. Machen Sie den Self-Service leicht zug\u00e4nglich und kl\u00e4ren Sie die Nutzer \u00fcber die Vorteile der Selbsthilfe und der Nutzung der Wissensdatenbank zur eigenst\u00e4ndigen Probleml\u00f6sung auf. <\/p>\n

W\u00e4hrend das IR-Team an der Behebung des Incidents arbeitet, ist es essenziell, alle Beteiligten in Echtzeit \u00fcber den Fortschritt zu informieren. Zwei Informationen sollten dabei jederzeit prominent angezeigt werden: der Incident-Status (aktueller Stand der Behebung, einschlie\u00dflich der gesch\u00e4tzten Zeit bis zum Abschluss) und die Priorit\u00e4t des Incidents (wie wichtig die Behebung im Vergleich zu anderen Incidents ist). <\/p>\n

Automatisierung kann helfen, indem sie w\u00e4hrend des gesamten Lebenszyklus von Major Incidents automatische Updates versendet. Klare und sichtbare Benachrichtigungen verhindern zudem, dass Nutzer Duplikate von Tickets erstellen und den Helpdesk \u00fcberlasten. Selbst wenn es nichts Neues zu berichten gibt, teilen Sie dies Ihren Stakeholdern st\u00fcndlich oder halbst\u00fcndlich mit. Richten Sie zudem eine dedizierte Leitung ein, um sofort auf Major Incidents zu reagieren und allen Betroffenen Unterst\u00fctzung anzubieten. <\/p>\n

2. DevOps-Prozesse einf\u00fchren<\/h4>\n

Bevor DevOps zum Mainstream wurde, war das IR-Team im Grunde auf sich allein gestellt. Sie waren f\u00fcr alle Incidents verantwortlich und nicht die Personen, die die Systeme tats\u00e4chlich gebaut hatten. Es gab beispielsweise keine R\u00fcckkopplungsschleife an die Entwickler, wie repetitive St\u00f6rungen bei einer bestimmten Anwendung behoben werden k\u00f6nnten. Es fand kaum Kommunikation zwischen den Erstellern der Systeme und denjenigen statt, die f\u00fcr deren Reparatur bei Fehlern zust\u00e4ndig waren. Tats\u00e4chlich war ein Grund f\u00fcr die Entstehung von DevOps die Beseitigung dieser organisatorischen Silos. Dies ist aufgrund der Komplexit\u00e4t heutiger Systeme unerl\u00e4sslich \u2013 sie sind alle miteinander vernetzt, und was das eine beeinflusst, wirkt sich wahrscheinlich auch auf andere aus. <\/p>\n

Mit einer etablierten DevOps-Struktur leisten Entwickler bessere Arbeit beim Aufbau ihrer Systeme, da sie nun wissen, dass sie diese auch unterst\u00fctzen m\u00fcssen \u2013 Probleme werden nicht mehr einfach \u00fcber den Zaun geworfen, damit sich eine andere Gruppe darum k\u00fcmmert. IR-Teams erhalten Unterst\u00fctzung und verf\u00fcgen \u2013 wenn DevOps richtig umgesetzt wird \u2013 in der Regel \u00fcber eine klare Dokumentation, wie komplexe Systeme am Laufen gehalten werden. <\/p>\n

3. Erkennen, wann \u201eSwarming\u201c erforderlich ist<\/h4>\n

Obwohl die meisten Unternehmen eine gestufte Struktur f\u00fcr den Umgang mit Incidents haben \u2013 Tier 1 ist der Helpdesk, Tier 2 umfasst Anwendungsspezialisten und Tier 3 sind im Allgemeinen die System-Experten und Entwickler \u2013, sollten Sie diese Struktur bei der L\u00f6sung von Major Incidents nicht universell erzwingen. Geben Sie Ihrem Team die Freiheit zum \u201eSwarming\u201c (Ausschw\u00e4rmen), wenn es n\u00f6tig ist. <\/p>\n

Dies ist meist dann erforderlich, wenn ein Problem massive 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 stammt von Cisco, das 2008 im Whitepaper \u201eDigital Swarming<\/a>\u201c dar\u00fcber schrieb. Das Konzept wurde sp\u00e4ter vom Consortium for Service Innovation \u00fcbernommen und zu einer Vision namens \u201eIntelligent Swarming<\/a>\u201c weiterentwickelt. <\/p>\n

Die Grundidee hinter Swarming ist, dass man anstelle einer Eskalation alle Personen, die zur L\u00f6sung eines Incidents beitragen k\u00f6nnten, gleichzeitig in das IR-Team holt. Dort betreiben sie Brainstorming, tauschen Ideen aus und nutzen die Gruppendynamik, um frische und innovative L\u00f6sungen f\u00fcr schwierige IR-Probleme zu finden. <\/p>\n

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