…und Annahmen zum Angst kriegen.

Egal wie perfekt gearbeitet wird: IT-Aktivitäten gehen unweigerlich schief. Umso wichtiger, dass Admins wissen, wie sie am besten vorgehen, um Verantwortlichkeit, Effizienz und Genauigkeit sicherzustellen.

Der Umgang mit einem IT-Problem ist einer der wichtigsten Aspekte im Job eines SysAdmin. Sicher, schöner wären gar keine Probleme, aber wir leben nun mal in keiner perfekten Welt. Wahr ist auch, dass Unternehmen den Wert ihrer IT-Abteilung eher danach bemessen, wie Probleme behoben werden und nicht, wie lange sie schon ohne ein Problem auskommen.

Wenn es dir gelingt die folgenden drei Fallen zu vermeiden und stattdessen unseren Best Practices für Incident-Management folgst, werden sich die Reputation und das Image deiner IT-Abteilung nachhaltig verbessern.

Erkenne Probleme an

Annahme: Kommunizier nur die Probleme, über die sich auch Nutzer beschwert haben. Andernfalls wird die IT schlecht aussehen und man wird denken, du hättest es nicht unter Kontrolle.
Best Practice: Notiere und melde jede Serviceverschlechterung. Stell diese Informationen denjenigen zur Verfügung, die sie benötigen, vor allem aber den Entscheidungsträgern.

Im Idealfall identifiziert und behebt die IT ein Problem so schnell und genau wie möglich, um Ausfallzeiten für Endbenutzer zu minimieren. Wenn du ein Problem feststellst, bevor ein Benutzer es meldet, und du es beheben kannst, bevor es tatsächlich bemerkt wird, bist du der Held.

Gerade deshalb sollten IT-Mitarbeiter Monitoring-Tools zur Überwachung der Service-Levels verwenden. Dabei ist es erst einmal unerheblich ob es sich dabei um ein internes Skript-Setup oder ein gekauftes Tool wie bsw. Augoory von Braintower handelt. Verwende, was für den gegebenen IT-Einsatz, das Budget, für deine Kollegen und dich funktioniert. Aber verwende es!

Es ist verlockend, Problemberichte unter den Teppich zu kehren. Wir aber sagen: Akzeptiere diese Vorfälle und mach sie öffentlich.

Wichtig ist auch, dass eure Monitoring- und Business Intelligence Tools Berichte über Ausfälle erstellen. Es ist verlockend, diese Problemberichte unter den Teppich zu kehren. Wir aber sagen: Akzeptiere diese Vorfälle und mach sie öffentlich. Wenn du diesen Rat befolgst, wird du dazu beitragen, dass euer IT-Team das Wie und Warum hinter jedem Ausfall verstehen muss. So wirst du passende Lösungen für diese Probleme finden, anstatt nur schnelle, temporäre Fixes oder Work Arounds zu produzieren.

Und wenn du irgendwann mehr Geld oder Ressourcen benötigst, um ein Problem zu lösen, zeigen diese historischen Beweise, dass der Vorfall (oder ein Trend von Vorfällen) tatsächlich Auswirkungen auf das Geschäft haben. Bewaffnet mit diesen Informationen und dem Willen zur Verbesserung, bist du definitiv in einer besseren Position als ein SysAdmin, der IT-Probleme nicht offen kommuniziert.

Was tun wenn’s brennt?

Annahme: Jede Veränderung des Problems ist automatisch eine Verbesserung.
Best Practice: Ein schlecht durchdachter Schnellschuss kann zu größeren Problemen führen. Verstehe und vereinbare eine schnelle Lösung nur, wenn eine dauerhafte Lösung nicht möglich ist.

Und gerade deshalb ist das der perfekte Zeitpunkt, indem sich die Dinge von schlimm zu noch schlimmer wandeln.

Wenn das Helpdesk-Telefon nicht stillsteht und vom Management schon eine wütende E-Mails gesendet wurden, spürt die IT-Abteilung den massiven Druck ganz schnell eine Lösung präsentieren zu müssen. Es ist einfach sich genötigt zu fühlen, irgendetwas zu unternehmen, nur um zu sehen, ob es dadurch besser wird. Und gerade deshalb ist das der perfekte Zeitpunkt, indem sich die Dinge von schlimm zu noch schlimmer zu wandeln. Einer im IT-Team überschreibt versehentlich eine Datenbank, Daten gehen verloren oder jemand verschlimmbessert den Service so, dass der dann nicht mehr mit wenigen Tastendrücken zu reparieren ist [Murphy’s Law].

Wie bei jeder Aufgabe, die in einer Live-Umgebung ausgeführt wird, sollte man verstehen, was man tut, warum man es tut und wie man sich im Zweifelsfall wieder aus der Situation befreien kann. Die beste Aktion ist so simpel, wie das Erstellen eines Snapshots einer VM, bevor du eine Änderung vornimmst. Wenn du tägliche Sicherungen hast, führ eine weitere Teilsicherung aus, so dass sie bei Bedarf wiederhergestellt werden kann. Behebe das Problem, aber schütze auch das IT-Team und das Unternehmen mit umsichtigen Schritten. Denk darüber nach, wie du dich der Änderung nähern würdest, wenn es gerade nicht lichterloh brennen würde. Die Kunst ist Risiko und Geschwindigkeit in Balance zu halten.

Lessons-Learned

Annahme: Du hast überlebt und alles auf dem Dashboard ist wieder grün. Weiter zum nächsten Task.
Best Practice: Nachdem du erfahren hast, dass ein Service wiederhergestellt wurde, führe ein Lessons-Learned durch.

Die Erleichterung das Betrieb wieder reibungslos funktioniert ist groß, aber das ist ein Erfolg, der unweigerlich zu mehr Arbeit führen sollte. Unsere Best Practice hierfür gliedert sich gleich in mehrere Schritte:

  1. Durchdenken was da genau passiert ist,
  2. die Mitarbeiter, die für den Service verantwortlich sind, über die Ursache und Lösung beraten lassen
  3. und schließlich entscheiden, welche Maßnahmen die Auswirkungen des gleichen Problems reduzieren oder in der Zukunft verhindern können.

Lessons-Learned sind die perfekte Gelegenheit, um sich auszutauschen und zu diskutieren, wie die gesammelten Erkenntnisse auch für andere Dienste oder Unternehmensbereiche gelten. Ohne diese Follow-Ups bleiben Risiken bestehen und eine große Chance wird vertan.

Fehler sind eine Chance etwas zu lernen. Nur wenn wir uns aus Scham oder Hektik verweigern aus Fehlern zu lernen, sind Fehler ein unlösbares Problem.

Es ist doch so: Probleme werden immer auftauchen. Genauso wichtig, wie sie von vorne hinein ausschließen zu wollen, ist es daraus zu lernen und dafür zu sorgen, dass sie kein zweites Mal mehr passieren. Wir haben beste Erfahrungen gesammelt, Probleme und Fehler offen anzusprechen, um nicht nur gemeinsam an Problemen zu arbeiten, sondern durch die Fehler anderer eigene Fehler in Zukunft zu vermeiden. Ein weiterer positiver Nebeneffekt ist das Punkt 1. „Probleme anerkennen“ uns damit viel leichter fällt.

Fehler sind eine Chance etwas zu lernen. Nur wenn wir uns aus Scham oder Hektik verweigern aus Fehlern zu lernen, sind Fehler ein unlösbares Problem. Das ist kein Hexenwerk, sondern braucht einfach nur diesen Moment der bewussten Reflexion und den Willen statt eines Schuldigen zu suchen, anzuerkennen, dass Fehler menschlich und damit auch Maschinen-Systemen immanent sind.

Fazit

Im Nachhinein ist man immer schlauer und es ist einfach zu sagen, was die IT alles hätte besser machen können. Im Eifer des Gefechts vergisst man leicht Best Pratices zum Incident-Management und Annahmen bleiben hartnäckig bestehen. Das ist eine Kulturfrage: Überprüfe die Incident-Prozesse deines Unternehmens. Führe Gespräche mit deinen Kollegen und Vorgesetzten, wie auf Vorfälle reagiert werden kann, um schlechte Angewohnheiten zu minimieren. Euer Team wird nicht nur die Ausfallsicherheit verbessern. Die Arbeit wird auch mehr Spaß machen. Versprochen.

Welche Best Pratices haben sich für dich im Incident Management bewährt? Welche schlechten Angewohnheiten hast du dir im Laufe des Arbeitsleben angewöhnt und wie bist du sie wieder losgeworden? Teile deine eigenen Beispiele von guter oder schlechter Fehlerkultur im Kommentarbereich.

Tim Hassdenteufel

Tim Hassdenteufel

Marketing

Tim mag Menschen, Ideen die ihn nervös machen und seinen Hund Stevie (meistens). Als er aufwuchs träumte er davon, der nächste van Gogh zu werden oder Werbung zu machen. Träume werden eben doch wahr. Dieser Music-Snob pflegt eine gefährliche Liebschaft zu Instagram und bestellt sich auf der Speisekarte mit Sicherheit das Seltsamste.

Gefällt dir der Artikel? Bitte teile ihn!
Share on Facebook
Facebook
7Share on Google+
Google+
0Share on LinkedIn
Linkedin
Email this to someone
email
Tweet about this on Twitter
Twitter