Artikel und Berichte für einen sicheren und stabilen IT Betrieb

Kategorie: ITIL (Seite 1 von 2)

Was ist eine Ursachenanalyse?

Die kindliche Neugier ist grenzenlos. Wann immer Kinder etwas nicht verstehen, wollen sie dieser spannenden neuen Sache auf den Grund gehen. Das führt immer zur Frage an die Eltern: Warum ist das so? Hat man eine einigermaßen kinngerechte Antwort gegeben, folgt sofort das nächste neugierige „Warum?“. Wieder versucht man eine abschließende Antwort zu geben, doch der Nachwuchs läßt sich nicht abspeisen – „Und warum?“.

Die kleinen Kinder gehen damit intuitiv wie bei einer Ursachenanalyse vor. Sie wollen eine Sache auf den Grund gehen. Sie sind auf der Suche nach der Ursache, der ultimativen Erklärung. Auf englisch nennen wir die „Root Cause“.

Unter einer Root Cause wird allgemein gesprochen ein Fehler in einer Software-Applikation oder einem digitalen Prozess verstanden. Genauer ist die Bezeichnung „Non-Konformität“, da das Verhalten nicht unbedingt einen Fehler im umgangssprachlichen Sinne darstellen muss. So könnte z.B. auch eine Hacker-Attacke auf ein System mit einer Root Cause Analyse untersucht und die ausgenutzte Schwachstelle (hoffentlich) gefunden werden.

Im abschließenden Schritt soll mit der RCA die Non-Konformität geschlossen werden. Die Root Cause löst die Ursachen-Wirkungskette aus, die schlußendlich zu einem oder mehreren Problemen führt.

Die Ursachenanalyse (Root Cause Analysis) beschreibt eine Menge an Vorgehensweise, Werkzeugen und Techniken, um zugrundeliegende Probleme einer Störung zu ermitteln.

Es finden sich Methoden der Ursachenanalyse, die die echten technischen Problemursachen zu identifizieren versuchen, während auch eher generelle Problemlösungstechniken genutzt werden können.

Woher kommt die Ursachenanalyse?

Die Ursachenanalyse gehört zum Bereich des Qualitätsmanagements und hier insbes. zur Methode des „Total Qualitäty Managements“ (TQM), die ihren Ursprung in der japanischen Automobilindustrie hat. Im TQM finden sich versch. Methoden und Techniken der Problemanalyse, Problemlösung und Ursachenanalyse (RCA).

Ursachenanalyse ist Teil eines übergreifenden Problemlösungsprozess und ist in der IT ein integraler Bestandteil des ITIL-Prozesses „Continual Service Improvement“.

Wie erfolgt eine (Fehler-) Ursachenanalyse?

Die wichtigsten Methoden finden sich im Folgenden:

Events and Causal Factor (ECF) Analysis: Die Methode ist verbreitet bei der Untersuchung von großen Einzelstörungen, wie z.B. eine Explosion in einer Raffinierie. Der Prozess nutzt die rasche und strukturierte Aufnahme von  Beweise, die in die zeitliche Reihenfolge ihres Auftreten gebracht werden. Wenn die zeitliche Verlauf klar ist, werden die kausalen und unterstützenden Faktoren identifiziert.

Change Analysis: Diese Form der Ursachenanalyse wird genutzt, wenn sich die Performance eines Systems deutlich verschlechtert. Dabei werden alle Veränderungen bei Mitarbeitern, Ausrüstungen und Informationen untersucht sowie weitere Faktoren, die die Performance eines Systems beeinflusst haben könnten.

Fehlerbaumanalyse (Fault Tree Analysis FTA): Diese Methode eignet sich, um ausgehend von einem unerwünschten definierten Ereignis rückwärts gerichtet dessen Ursachen zu ermitteln, auch Top-down-Ansatz genannt. Man geht vom Allgemeinen zum Speziellen und prüft auf jeder Ebene des Systems eine mögliche Beteiligung der Subservices geprüft. Dabei entsteht eine baumartige Struktur der Fehlermöglichkeiten.

Kepner-Tregoe Methode (KT) und Entscheidungsfindung: Dieses Modell unterscheidet vier einzelne Phasen des Problemlösungsprozesses:

  • Situationsanalyse
  • Problemanalyse
  • Lösungsanalyse
  • Analyse potentieller Probleme

KT wird insbes. im Umfeld von Operational und Service Excellence angewendet. KT wird im Prozess „Problem Management“ von ITIL empfohlen.

RCA Prozess
Schritte der Ursachenanalyse

Durchführung einer Root Cause Analyse

Bei der Durchführung einer Ursachenanalyse sollten zwei grundlegende Rahmenbedingungen beachtet werden:

  1. Viele Methoden zur Ursachenanalyse können grundsätzlich von einer einzelnen Person angewendet werden, doch ist das Ergebnis in der Regel besser, wenn eine Gruppe von Personen gemeinsam an der Suche nach den Problemursachen arbeitet. Dabei können auch Kreativitätstechniken wie Brainstorming hilfreich sein. Dies gilt insbes. bei komplexen IT-Problemen.
  2. Diejenigen, die letztendlich für die Beseitigung der ermittelten Ursache(n) verantwortlich sind, sollten prominente Mitglieder des Analyseteams sein, das sich daran macht, sie aufzudecken.

Der ideal-typische Ablauf einer Ursachenanalyse ist wie folgt:

Es wird die Entscheidung getroffen, ein Team zusammenzustellen, das die Ursachenanalyse durchführen soll. Bei Organisationen, die nach den ITIL-Best Practices arbeiten, wird dies im Prozess „Problem Management“ abgearbeitet.

Die Team-Mitglieder werden aus dem Fachbereich ausgewählt, der das Problem berichtet. Ein verantwortlicher Manager sollte die Ursachenanalyse als Sponsor unterstützen, damit das Team auch die nötige Unterstützung durch andere Abteilungen und Bereiche erfährt. Es sollte weiterhin ein Kunde bzw. User dem Team angehören, der mit dem Problem im täglichen Arbeitsablauf zu tun hat. 

Wie viel Zeit die Ursachenanalyse in Anspruch nimmt, hängt natürlich von der Komplexität des untersuchten Systems ab. Bei IT-Systemen wird nach einer größeren Störung meist erwartet, dass die Ursache innerhalb weniger Stunden oder Tage feststeht. Wird ein komplexer Produktionsablauf untersucht, kann die Analyse auch Wochen oder Monate dauern.

Dabei sollten während der Analyse alle Phasen gleich gewichtet werden:

  • Definition des Problems
  • Brainstorming möglicher Gründe
  • Analyse von Ursache und Wirkung
  • Ableitung einer dauerhaften Problemlösung

Während der Untersuchungen sollte das Team regelmäßige Meetings vereinbaren (mindestens wöchentlich, aber auch tägliche Meetings sind denkbar). Die Meetings sollten möglichst kurz gehalten werden (max. 2 Stunden) und sie sollten im Sinne der Problemfindung kreativ gestaltet werden, auf eine starre Agenda sollte verzichtet werden.

Ein Verantwortlicher (z.B. der Problem Manager) stellt sicher, dass die Ursachenforschung Fortschritte macht und das den Team-Mitglieder Aufgaben zugewiesen werden. Aufgaben und Beschlüsse sollten in einem Protokoll festgehalten und nach den Meetings an alle versendet werden.

Wenn eine Fehlerursache und eine Lösung dazu gefunden wurde, wird die Implementierung dieser Lösung geplant. Je nach erforderlichen Ressourcen und Skills kann die Implementierung der Lösung Tage, Wochen oder Monate in Anspruch nehmen.

DevOps – Was ist das?

Der Begriff DevOps, mit dem agile Arbeitsmethoden in den Arbeitsalltag einziehen, beschreibt eine Kombination aus Denkweisen, Praktiken und Tools, die es Unternehmen und Organisationen ermöglichen, Anwendungen und Dienste schneller und einfacher bereitzustellen. Der Begriff bezieht sich auf einen Ansatz zur Prozessverbesserung, der hauptsächlich im IT-Betrieb, vor allem in der Systemadministration im Zusammenspiel mit der Softwareentwicklung, eingesetzt wird. Es ist ein sogenanntes Kofferwort, das sich aus den englischen Begriffen für „Entwicklung“ und „IT-Sicherheitsbetrieb“ ableitet. DevOps hat das Ziel, in den Bereichen Implementierung, IT-Sicherheitsbetrieb und Qualitätssicherung für eine effizientere und effektivere Zusammenarbeit zu sorgen. Zu diesem Zweck werden spezielle Anreize, Instrumente und Prozesse eingesetzt. DevOps richtet sich methodisch sowohl an die Technik als auch auf die Prozessebene und stellt klassische ITIL-Prozesse wie Incident Management, Change Management oder Release Management auf den Prüfstand. ITIL (IT System Infrastructure Library) beschreibt eine strukturierte Prozesssammlung von Best Practices für das Service Management von IT-Systemen. IT Service Management oder ITSM ist seit mindestens 20 Jahren als Best Practice in der IT etabliert. Es ist ein Modell, das die zuverlässige Bereitstellung von Informationstechnologie als Dienstleistung für den Kunden als Ziel propagiert.

Motivation und Entstehung

Der Ansatz entstand aus dem erkenntnistheoretischen Denken, dass standardisierte Prozesse heute nicht mehr ausreichen, um wettbewerbsfähig zu bleiben. Der Übergang dorthin erfordert einen Wandel der Kultur und der Denkweise, denn traditionelle Unternehmen haben ihre, meist vor langer Zeit, etablierten Ansätze. Die Softwareentwickler-Communities auf der einen Seite und die IT/Ops-Experten auf der anderen Seite verfolgten unterschiedliche, oft konkurrierende Ziele, gehörten verschiedenen Abteilungen an, wurden nach verschiedenen KPIs (Key Performance Indicators) bewertet und arbeiteten auf verschiedenen Etagen oder sogar in verschiedenen Gebäuden. Es bedarf eines gemeinsamen Verständnis der Aufgaben, der Akzeptanz und der guten Zusammenarbeit der Entwickler. Der Kern von DevOps ist die Überwindung der Trennlinien zwischen zwei ehemals sehr isolierten Geschäftsbereichen, der Entwicklung und dem IT-Betrieb. Das Konzept basiert auf einer Kultur der Zusammenarbeit zwischen gemeinsamen Teams. Einfache Prozesse werden mit einem DevOps-Ansatz zunehmend programmierbar und dynamisch. Er zielt darauf ab, die Vorhersehbarkeit, Effizienz, Sicherheit und Wartbarkeit von Betriebsprozessen zu maximieren. Die Auswirkungen auf den IT-Betrieb nach der Einführung von DevOps wird in einem Artikel bei Heise Developer beleuchtet.

Praxis

Der Übergang zu DevOps erfordert einen grundlegenden Wandel der Unternehmenskultur und der Denkstrukturen. Unter anderem sind die Entwickler nun für mehr Prozesse verantwortlich. Es verändert die Denkweise, indem es alle Entwicklungsprozesse berücksichtigt und die Grenzen zwischen Entwickler- und Betriebsteam überwindet. Neu ist die Beschäftigung mit Automatisierung sowie die Handhabung von Versionsmanagement und automatisierten Tests. Entwickler im IT-Betrieb müssen sich möglicherweise an neue, bereichsübergreifende Key Performance Indicators (KPIs) und damit an gemeinsame Anreizkennzahlen anpassen. Oftmals agieren Unternehmen dabei in ihren Projekten nach Scrum in kleineren Teams von 5-9 Mitarbeitern, die autonom arbeiten dürfen.

Der DevOps-Kreislauf

Vorteile

Die schlechte Nachricht ist, dass es keine Magie ist und Transformationen nicht über Nacht stattfinden. DevOps selbst ist kein Instrument, aber Softwaretools für die automatisierte Automatisierung und Messung sind wesentliche Bestandteile einer erfolgreichen Implementierung. Aber das Herz dieser Anstrengung sind die Mitarbeiter und die Art und Weise, wie sie mit anderen zusammenarbeiten. Vorbei sind die Zeiten, in denen die IT-Abteilung einmal im Jahr ein größeres Update durchführen konnte. Noch relevanter sind die Konzepte der kontinuierlichen Verbesserung und Fehlerabdeckung. Dank der agilen Entwicklung ist die kontinuierliche Verbesserung zum Thema geworden. Diese Idee finde sich auch in ITIL Version 3 mit dem Prozess „Continual Service Improvement“, wobei dieser Prozess auf den IT-Betrieb gemünzt war. Zu den versprochenen Vorteilen von DevOps gehören mehr Vertrauen, schnellere Software-Releases, eine schnellere Beseitigung kritischer Softwarefehler und eine bessere Verwaltung ungeplanter Aufgaben. Vollständige Transparenz und nahtlose Kommunikation sorgen für minimale technische Ausfallzeiten und eine stark beschleunigte Problemlösung für DevOps-Teams. 

Auf kultureller Ebene verspricht DevOps zufriedenere, produktivere Mitarbeiter und Teams, mehr individuelles Engagement und bessere Möglichkeiten zur persönlichen Entfaltung und Weiterentwicklung. Auf der wirtschaftlichen Ebene geht es darum, die Bereitstellung neuer zusätzlicher Funktionen, stabilerer Anwendungen, effizienterer Prozesse und mehr Raum für Innovationen zu beschleunigen. Gerade die wirtschaftlichen Vorteile machen die Einführung von DevOps für viele Unternehmen attraktiv.

Nachteile

Die Vorteile werden ohnehin viel häufiger diskutiert als die Nachteile, da technische, kulturelle und wirtschaftliche Vorteile viel prägnanter behandelt werden können. Nicht alle Mitarbeiter sind immer offen für solche Veränderungen. Meistens sind die noch immer meist strengen Hierarchien in den Unternehmen in Deutschland ein Hindernis auf dem Weg zur erfolgreichen Einführung von DevOps. Dennoch bleibt die Tatsache bestehen, dass es aus dem Wunsch heraus entstanden ist, Softwareentwicklungen schneller zu liefern und damit auf dem deutschen Markt lukrativ zu bleiben.

Erfahrungen mit DevOps

Erfahrungsgemäß braucht eine Umstellung der Unternehmenskultur seine Zeit – und vor allem ist Geduld gefragt, denn oftmals muss DevOps in vielen kleinen Schritten sukzessive eingeführt werden. Wichtig ist vor allem, dass im Unternehmen geeignete Rahmenbedingungen geschaffen werden. Dinge wie Vertrauen und respektvoller Umgang müssen vorgelebt werden. Dann lassen sich die unter dem Punkt „Nachteile“ beschriebenen Bedenken und Probleme leichter aus der Welt schaffen. Oftmals findet es in der Praxis schon statt, ohne dass es so genannt wird und zeigt so, dass es sich immer mehr in den Unternehmen etabliert.

British Airways – Erneuter IT-Systemausfall

Am Samstag, den 27. Mai 2017, kam es bei der britischen Fluggesellschaft British Airways zu einer schwerwiegenden technischen Störung, die als IT-Systemausfall in der Presse vermeldet wurde. 

Was war passiert?

Betroffen waren Check-In,  Website und Call Center der Airline. Weltweit waren Hunderte Flüge betroffen, es kam zu massiven Verspätungen und Flugausfällen. An den Flughäfen Heathrow und Gatwick kam es zu chaotischen Zuständen. Die Meldung auf ba.com las sich so:

Die Mitteilung von British Airways zum IT-Systemausfall am 27. Mai 2017

Mitteilung von British Airways zum IT-Systemausfall am 27. Mai 2017

Aus Kundensicht ist damit wohl der Super-GAU eingetreten. In Großbritannien war ein langes Wochenende und Tausende Urlauber wollten in den Urlaub fliegen. Die wirtschaftliche Dimension des Systemausfalls kann als dramatisch bezeichnet werden.

Die Frage ist nun, wo die Ursache des Problems lag. BA hat recht schnell einen Cyberangriff ausgeschlossen und auf einen Fehler in der Stromversorgung verwiesen. Doch kann ein Stromausfall in einem Rechenzentrum die IT-Systeme einer gesamten Airline mit einer Flottenstärke von mehr als 250 Flugzeugen lahmlegen? Hat sich etwa einen zweiten RZ-Standort gespart, der im Ernstfall den IT-Betrieb hätte übernehmen können? Experten für den Aufbau von Rechenzentren bezweifeln diese Theorie mittlerweile.

Weiterlesen

Erfolgskriterien für Level-0-Support

Im vorigen Artikel (hier) habe ich die verschiedenen Möglichkeiten betrachtet, einen sog. Level-0-Support aufzubauen, um die Anwenderzufriedenheit zu verbessern und das eigene Support-Team von den immer gleichen Fragen der Anwender zu entlasten. Falls Sie in Ihrem Unternehmen bereits ein ITSM-Tool nutzen, so bietet dieses sehr wahrscheinlich auch die Funktionalitäten eines Service-Portals. Die Platzhirsche auf dem Tool-Markt, BMC und ServiceNow, bieten entsprechende Module in ihren ITSM-Lösungen an (siehe hier und hier).

support-1699891_1920

Mit der Einführung eines Service-Portals ist es jedoch meist nicht getan. Es gibt viele Stolperfallen, die das Projekt „Self Help Portal“ zum Rohrkrepierer werden lassen können. Die wichtigsten Erfolgskriterien finden Sie im Folgenden.

Weiterlesen

Was versteht man unter Level-0-Support ?

Bei der Einführung einer Supportstruktur kommt man ziemlich schnell zu der Fragestellung, welche Unterstützung von welcher Organisationseinheit geleistet werden soll. Unter dem Level-1-Support wird gemeinhin der Service Desk verstanden, der einfache Hilfestellungen wie z.B. Passwort-Rücksetzungen anbietet. Level-2-Support wird oft durch die Administratoren der IT-Systeme geleistet. Beim Level-3-Support wird in aller Regel der Applikationshersteller oder Betriebssystemlieferant befragt. Als Anwender muss man bei Problemen eine Hotline anrufen oder eine E-Mail an den IT-Support senden. Telefonische Anfragen landen oftmals in einer Warteschlange, bei Anfragen per E-Mail ist ungewiss, ob und wann man eine Antwort zu seinem Problem erhält. In allen Fällen werden Ressourcen der Organisation gebunden, das Vorhalten eines Support-Teams ist teuer. Hier kommt nun der sog. Level-0-Support ins Spiel. Bevor der Anwender den Support kontaktiert, wird er bei Google nach einer Lösung für sein Problem zu suchen – und meistens wird er fündig. Das gesamte Internet bildet somit die Plattform des Level-0-Supports.

Da jedoch nicht jeder Nutzer gewillt ist, komplexe Suchaufträge in die Google-Suchleiste zu tippen, sollten IT-Organisationen die folgenden, oft kostengünstigen, Möglichkeiten einsetzen, um Anwender zu unterstützen.

Weiterlesen

« Ältere Beiträge
Diese Website benutzt Google Analytics. Bitte klicke hier wenn Du nicht möchtest dass Analytics Dein Surfverhalten mitverfolgt. Hier klicken um dich auszutragen.