/ post-mortem

Post Mortem zum KreditSmart Incident vom 20.02.2018

Am Dienstag, dem 20. Februar 2018 kam es in der Zeit von 13 bis 17 Uhr zu einem mehrstündigen Ausfall von KreditSmart und dem Vorgangsmanagement. Wir möchten hier kurz schildern, wie es dazu kam und wie wir eine Lösung erarbeitet haben.

Verlauf

Bereits kurz vor 12 Uhr springt unser Monitoring an und meldet sämtliche Services im Umfeld von KreditSmart und dem Vorgangsmanagement als nicht erreichbar. Das ist nicht nur unüblich, sondern auch schwer vorstellbar. Da wir unsere Dienste auf ein paar dutzend Maschinen verteilt betreiben, ist ein kollektiver Ausfall äußerst unwahrscheinlich. Wir vermuten also, dass das Problem eher infrastruktureller Natur ist.

Eine kleine Stichprobe über ein Smartphone im LTE-Netz bestätigt den Verdacht: Wird die Plattform nicht über das Firmennetz aufgerufen, lassen sich alle Module einwandfrei benutzen. Da unsere Monitoring-Server in unserem Hauptquartier in Berlin stehen und von dort mit den Maschinen im Rechenzentrum kommunizieren, scheint also eine Störung der Verbindung zwischen den beiden Standorten vorzuliegen.

Ein kurzer Blick in Slack zeigt schnell, dass wir nicht die einzigen mit dem Problem sind. Unsere für die Konzern-IT zuständigen Kollegen berichten dort, dass eine Leitungsstörung in der Standleitung von unserem HQ ins Rechenzentrum vorliege. Es bestünde für uns vorerst keine Möglichkeit mehr, sich mit unseren Produktivsystemen zu verbinden. Externe Nutzer seien von dieser Störung aber nicht betroffen.

Damit können wir erstmal aufatmen. Wir haben zwar vorerst keine Möglichkeit mehr, neue Versionen unserer Systeme auszurollen, Logs auszuwerten oder kurzfristig Fehler zu beheben; aber immerhin können unsere Nutzer problemlos weiterarbeiten. Zumindest fast alle. Denn einige unserer Nutzer sind Teil des Hypoport-Konzerns und somit leider durch den Ausfall komplett arbeitsunfähig, da auch sie über das Firmennetz ins Internet gehen.

Um diesen Umstand auszuräumen, konfiguriert die Konzern-IT kurzfristig eine Umleitung, wodurch uns aus dem Firmennetzwerk zumindest wieder der Zugriff auf die Domain europace2.de möglich ist.

An diesem Punkt gibt es auch neue Informationen zu dem Leitungsproblem: Bei Bauarbeiten auf der Strecke von der Berliner Niederlassung ins Rechenzentrum wurde das Kabel unserer Standleitung von einem Bagger beschädigt. Sowohl wir als auch der Betreiber unseres Rechenzentrums alarmieren die Telekom über den Ausfall. Daraufhin heißt es abwarten.

Gegen 13 Uhr stellen wir plötzlich fest, dass sich weder KreditSmart noch das Vorgangsmanagement öffnen lassen, während der Rest der Plattform jedoch einwandfrei funktioniert. Da wir durch den Leitungsschaden keinen Zugriff auf unsere Logs haben, tappen wir bei diesem Problem völlig im Dunkeln.

Nach einigen erfolglosen Lösungsversuchen wenden wir uns an die Kollegen in der Konzern-IT. Diese wundern sich genauso, wie es sein kann, dass Teile der Plattform funktionieren, aber genau die beiden oben genannten Module den Dienst verweigern. Nach einigem Brainstorming kommen wir plötzlich durch Zufall darauf, dass alle nichtfunktionierenden Services eines gemeinsam haben: Sie werden über einen relativ neuen, internen Domain-Namen angesprochen.

Wir stellen also die These auf, dass die dazugehörigen DNS-Zonen noch nicht auf die Nameserver im Rechenzentrum gespiegelt wurden und stattdessen immer implizit von dem Nameserver in unserer Hauptniederlassung abgerufen wurden. Ein kurzer Blick in die DNS-Konfiguration bestätigt diesen Verdacht. Unsere Services haben ab dem Leitungsschaden nur aufgrund von zeitlich begrenztem DNS-Caching noch eine kurze Zeit lang funktioniert.

Nun wissen wir endlich, wo die Ursache liegt. Allerdings haben wir nach wie vor keine Möglichkeit, an die Server im Rechenzentrum zu kommen, um die fehlende Konfiguration nachzuziehen. Wir beginnen, mit dem Gedanken zu spielen, uns persönlich auf den Weg ins Rechenzentrum zu machen und die Konfiguration von Hand einzupflegen. Bevor es dazu kommen konnte, ist glücklicherweise jemandem eingefallen, dass wir noch einen speziellen Zugang über eine KVM-over-IP-Konsole haben, die mit etwas Glück über eine noch intakte Leitung läuft.

Und siehe da: Nach einigen Einrichtungsschwierigkeiten schaffen wir es tatsächlich, uns über diese Konsole auf einem Maintenance-Rechner anzumelden und von dort per SSH auf einige unserer Produktivsysteme zu gelangen. Wir beginnen also damit, die DNS-Konfiguration von Hand anzupassen. Ein nicht ganz einfaches Unterfangen, weil die Konsole wahnsinnig langsam und alles andere als benutzerfreundlich ist.

Doch letztendlich gelingt es uns, die Konfiguration korrekt anzupassen, so dass die von unseren Services verwendete Domain nun auch im Rechenzentrum ohne Verbindung zum Hauptquartier aufgelöst werden kann. Eine kurze Stichprobe zeigt, dass unmittelbar nach der Änderung alle unsere Services wieder erreichbar sind.

Zu diesem Punkt ist es ungefähr 16:30 Uhr und wir betrachten das Problem als gelöst. Zwar besteht weiterhin ein Leitungsschaden, aber dieser ist zumindest aus Nutzersicht nicht mehr wahrnehmbar.

Gegen Abend um 20 Uhr meldet unser Monitoring, dass die Services wieder erreichbar sind. Ein offizielles Wort von der Telekom gibt es allerdings noch nicht. Am nächsten Morgen um 8 Uhr bestätigt dann auch unsere Konzern-IT, dass das Problem offiziell behoben ist.

Abgeleitete Maßnahmen

Im Nachgang von solchen Incidents setzen sich bei uns die beteiligten Personen immer zu einem Post Mortem zusammen. Dabei erstellen wir eine genaue Timeline über den Ablauf von Eintritt bis zur Lösung des Problems. Anhand dieser Timeline leiten wir im Anschluss Schritte ab, um das Problem in Zukunft zu vermeiden oder zumindest die Wahrscheinlichkeit für ein erneutes Auftreten zu minimieren.

  • Es wird überlegt, wie wir unsere Standleitung als Single Point of Failure für Systemzugriffe ausräumen können
  • Es wird in Frage gestellt, warum Zugriffe auf die Domain europace2.de aus dem Firmennetz überhaupt anders behandelt werden als externe Zugriffe
  • Es wird mit dem Gedanken gespielt, die Struktur unserer DNS-Server umzubauen, um sie übersichtlicher und somit weniger fehleranfällig zu machen
  • Wir haben unser Bewusstsein geschärft, dass wir unsere Services so schreiben wollen, dass sie innerhalb eines Rechenzentrums komplett autark laufen können
  • Wir legen nun noch stärkeren Wert als ohnehin schon darauf, dass unsere Services wartungsarm sind und ohne manuelle Eingriffe dauerhaft laufen
  • Allen Beteiligten ist nochmal deutlich bewusst geworden, dass unser Firmennetzwerk teilweise auch von Endnutzern mit Kundenkontakt genutzt wird

Normalerweise sind unsere abgeleiteten Maßnahmen deutlich konkreter und mit unmittelbaren Aktionen verknüpft. In diesem Fall waren die Ursachen für das Problem leider höhere Gewalt in Verbindung mit ungünstigen Umständen. Deshalb hat dieser Incident primär zur Schärfung unseres Mindsets und zum Überdenken einiger bestehenden Lösungen geführt.