Verhalten im Ernstfall
- Urspruenglicher Autor: Ramon Kukla
- Urspruengliches Datum: 25.11.2011
Weil es in meinem Umfeld die Tage wieder so eine Situation gab geht es heute um das Thema „Verhalten im Ernstfall“. Ein Ernstfall kann mehr oder weniger ausgepraegt sein. Auf unserem gemeinsamen Server hatten wir Anfang 2010 einen Ernstfall, denn ich mal als Notfall kategorisieren wuerde, der uns (Dirk, Hampa, mich) einige Stunden fuer die Wiederherstellung gekostet hat.
Die gemachten Erfahrungen haben Dirk und ich spaeter in einem gemeinsamen Talk auf der Ubucon 2010 verarbeiten „muessen“.
Eine Definition einer Stoerung oder Groesserem kann beispielsweise dem BSI entnommen werden. Letzlich laesst sich ein Problem nicht immer eindeutig kategorisieren. Aber halten wir uns nicht mit Definitionsdetails auf.
Was mache ich nun, wenn es zu einer Stoerung kommt? Ich versuche erst einmal einzuschaetzen wie gross der Einfluss der Stoerung ist. Ist „nur“ ein Testserver ausgefallen, der hier und da von Entwicklern genutzt wird oder ist ein Firewallcuster ausgefallen, so dass 4.000 Menschen kein Internet und damit auch keine Partneranwendungen mehr nutzen koennen? Oft zeigt das Telefon einem schon an, ob es ein wichtiges System getroffen hat oder nicht :)
Wir gehen mal von einem harten Fall aus, wo viele Anwender nicht mehr arbeiten koennen. Welche Moeglichkeiten habe ich als Administrator, dessen Server gerade abgestuerzt ist oder einfach nicht mehr reagiert? Da gibt es natuerlich den Klassiker frei nach den Simpsons. Ein Hinweis auf „Schau mal da hinten der Hund! Der wedelt mit dem Schwanz!“ und dem anschliessenden Geraeusch eines startenden Flugzeuges. Da viele von uns aber Familie haben gehen wir den harten und ehrlichen Weg. Wir stellen uns dem Problem.
Hier gibt es einige Punkte, die einem helfen koennen die Situation ohne Herzklappenabriss zu bestehen. Das wichtigste ist immer die Ruhe zu bewahren! Das sagt sich oft so locker und ist sicher nicht leicht, wenn um einen herum die Anwender/Vorgesetzten stehen und einen mit panischen und (in dem Moment) stoerenden Fragen immer wieder aus der Arbeit reissen. Was uns zu einem weiteren Punkt bringt, der hilft die Ruhe zu bewahren.
Sorgt dafuer, dass ihr euch auf das Problem konzentrieren koennt indem ihr alle Leute raus werft, die nicht zur Loesung des Problems beitragen koennen. Das kann man freundlich aber bestimmt machen. Ich habe bei einem Problem auch schon mal einen Vorgesetzten mit den Worten „Wenn Sie mich nicht alle fuenf Minuten unterbrechen wuerden, waere ich schon ein Stueck weiter“ dazu gebracht mich alleine zu lassen. Natuerlich habe ich meinem Vorgesetzten spaeter auch noch mal erklaert, um was es mir ging und dass es eben niemandem hilft, wenn ich alle fuenf Minuten den Stand der Situation erklaeren muss. Er hat es dann auch verstanden, auch wenn er nach meinen Rauswurf doch einen leicht roten Kopf hatte. Damit kann man natuerlich auch mal auf die Nase fallen. Aber auch der Kollege hier, der Dirk, hatte sich mal bei einer groesseren Stoerung gegenueber einem weiter ueber ihm stehenden Vorgesetzten entsprechend geaeussert.
Nicht vergessen sollte man in dem Zusammenhang so Dinge wie das Telefon. Wenn moeglich leitet nach Absprache euren Apparat auf einen Kollegen, den Chef oder, wenn es das gibt, das Service Center um. Der Kollege kann auch als Ergaenzung die Kommunikation in Richtung Anwender uebernehmen.
Kommen wir zum dritten Punkt, der wiederum prima am vorherigen Punkt anschliesst. Die Kommunikation! Vielen Leuten ist nicht klar, wie wichtig Kommunikation ist. Man selber merkt das aber oft selber, wenn man auf etwas wartet und es wird nichts kommuniziert. Sei es, dass man auf einem Amt wartet der Naechste zu sein. Oder sei es am Rechner, wo einem, wie beispielsweise bei dem Linux cp kein Balken anzeigt, wie weit er mit dem Kopieren der 10.000 Dateien ist. Das ist der Grund,
weshalb man rsync -P statt cp benutzt.
Es steht ausser Frage, dass die Prozentangaben (Dirk hatte da auch eben noch was in seinem Blog) im Grunde Stuss sind. Aber sie geben einem erst einmal ein gutes Gefuehl. Und das braucht auch der Anwender und der Vorgesetzte. Die Betroffenen muessen das Gefuehl bekommen, dass sich da jemand kuemmert. Daher schreibe ich gerne mal eine Statusmail. Da verzichte ich auf die Angabe von Zeiten, so ich diese nicht vernuenftig einschaetzen kann. Aber ich gebe durch, was ich gemacht habe und was noch fuer Schritte fehlen. Das mache ich uebrigens auch bei Projekten, die sich ueber einen laengeren Zeitraum hinziehen. Jede Woche eine kleine Statusmail an den Auftraggeber. Das dauert fuenf Minuten, gibt dem Auftraggeber aber das Gefuehl, dass sein Thema/Auftrag noch in der Bearbeitung ist.
Was haben wir noch?
Aus meiner Sicht fehlen hier noch drei Punkte. Zum einen die Systemdokumentation. Ab einer bestimmten Anzahl von betreuten Systemen kann ich nicht alles im Kopf behalten. Da ist eine Dokumentation erforderlich. Wichtig ist also zu wissen, wo ich die diese finde und… wo ich die Replik der Informationen finde. Denn es kann ja auch passieren, dass der Server weg ist, auf dem die benoetigten Dokumente liegen. Und bitte nicht auf die Dokumentation bestimmter Prozesse oder Punkte verzichten, weil es da einen prima Link im Internet gibt. Das Internet koennte am Arbeitsplatz auch mal nicht funktionieren.
Des Weiteren finde ich es immer hilfreich eine Liste der moeglichen Ansprechpartner zu haben. Das betrifft sowohl die internen Kollegen, als auch die Personen beim Dienstleister oder Hersteller. Bei den internen Kollegen handelt es sich durchaus nicht nur um Techniker. Gibt es auch ein IT-Stoerungsmanagement? Einen Ansprechpartner im Fachbereich, welche die Anwendung nutzt?
Abschliessend gibt es noch eine Uebersicht moeglicher Vertragsdetails. Aus denen kann ich dann alles entnehmen, was beispielsweise fuer den Austausch von defekter Hardware oder zur Ticketerstellung benoetigt wird.
Als Ergaenzung sei fuer die Zukunft auf jeden Fall noch ein Punkt empfohlen. Die Nacharbeit! Ich moechte wissen, was zum Ausfall eines Systems gefuehrt hat und es abstellen. Ich moechte auch pruefen, wo meine Vorgehensweise noch verbessert werden kann. Alleine schon um beim naechsten Problem besser vorbereitet zu sein und den Anwender schnell(er) wieder ans Arbeiten zu bekommen.