Don’t panic
Es war sicherlich der Albtraum eines jeden Piloten. Kurz nach dem Start von US Airways Flug 1549 am 15. Januar 2009 fielen durch einen Vogelschlag beide Triebwerke des Airbus A320 aus und dem Piloten Chesley Sullenberger bliebt nichts andere übrig als eine Notwasserung im Hudson River durchzuführen. Die Bilder des Flugzeuges nach der erfolgreichen Landung gingen um die Welt und sind uns auch durch die Verfilmung mit Tom Hanks im Gedächtnis geblieben.
Wenn man sich den Funkverkehr anhört, so erkennt man die geradezu stoische Ruhe des Piloten und auch in Interviews erklärte Sullenberger, dass er zu keinem Zeitpunkt in Panik verfallen war, sondern routiniert seine geübten Notfallpläne angewendet hat. Alle Experten sind sich einig, dass gerade diese Ruhe eine der Hauptgründe dafür war, dass die Maschine trotz enormer Schwierigkeiten erfolgreich gelandet werden konnte.
Wie unterschiedliche verlief da manches Problem, dass ich als Softwareentwickler erlebt habe. Sobald sich unsere Systeme anders verhalten, als wir uns das vorstellen verfallen wir häufig in Aktionismus und versuchen irgendetwas zu tun in der Hoffnung, dass es die Lösung bringen wird.
Ein arabisches Sprichwort sagt, dass Panik aus einer Mücke einen Elefanten macht und Geduld aus einem Elefanten eine Mücke. Eine Situation, die mir selbst gezeigt hat, wie kontraproduktive übereiltes Handeln sein kann ist nur wenige Jahre her. Einer unserer Services reagierte nicht mehr, was dazu führte, dass bestimmte Teile der UI vom Benutzer nicht mehr verwendet werden konnten. In Aufregung (vielleicht sogar Panik) aber mit der Intention schnell Abhilfe zu schaffen wählte ich – ohne tiefer auf das Problem zu schauen – eine Aktion, die schon häufiger zum Erfolg geführt hatte: Einen Neustart des entsprechenden Services. Das Problem wurde dadurch allerdings nicht besser, sondern im Gegenteil, nur noch schlimmer. Es stellte sich später heraus, dass die Ursache in der Drosselung der Datenbankzugriffe durch den Datenbankserver aufgrund von aufgebrauchten IO-Credits lag. Durch den Neustart des Services hatte sich diese Situation nur noch verschlimmert, da zunächst verschiedenste Konfigurationsdaten ausgelesen und Caches initialisiert werden mussten. Es fanden daher nur noch mehr Datenbankabfragen statt, die die Last zusätzlich erhöhten. Ich hatte das Problem durch voreiliges Handeln nur verschlimmert anstatt es zu lösen.
Auch wenn es im ersten Moment widersprüchlich zu sein scheint: In einer Ausnahmesituation ist ein tiefes Durchatmen und ein ruhiges Analysieren der Situation der beste Weg zu einer Lösung zu gelangen. Es gilt zuerst zu verstehen, was überhaupt passiert ist und wo das Problem liegt. Erst dann sollten wir in den Lösungsmodus übergehen.
