Sicherheit geht vor: Der Bericht zu unserem vorübergehenden Ausfall

Sicherheit geht vor: Der Bericht zu unserem vorübergehenden Ausfall

Vor Kurzem kam es bei der Nutzung von lexoffice zu einer längeren Downtime. Was ist da passiert?

Lesezeichen setzen

Max Frisch wird das Zitat zugeschrieben: „Krise ist ein produktiver Zustand. Man muss ihm nur den Beigeschmack der Katastrophe nehmen.“ Mitten in einer Systemstörung ist es gar nicht einfach, das so zu sehen – doch das lexoffice Team nutzt den Zwischenfall, um zu lernen und solche Probleme zukünftig zu vermeiden.

Während des Ausfalls haben wir unter www.lexoffice.de/status/ eine Status-Seite eingerichtet, auf der wir über den Zustand unserer technischen Systeme zeitnah informieren. Diese Info-Seite halten wir seitdem durchgehend aktuell. Das ist die erste Verbesserung, die wir implementiert haben – aber nicht die einzige.

lexoffice Downtime – was war denn los?

Doch was war eigentlich los? Viele von Euch haben uns gefragt und um mehr Transparenz gebeten – eine Bitte, der wir mit diesem Blogpost und Interview aus dem Herzen des lexoffice Teams entsprechen möchten. Emily hat für Euch Dr. Carsten Block, Chief Product Owner für lexoffice, interviewt, der an vorderster Front mit dabei war, als es darum ging, das Netzwerkproblem zu lösen.

Dr Carsten Block, lexoffice Product Owner

Dr. Carsten Block

lexoffice Chief Product Owner

Carsten hatte schon immer ein Faible für Technik, Software und Programmierung. Nach einer Ausbildung zum Bankkaufmann absolvierte er ein Studium des Wirtschaftsingenieurswesens und machte dank seiner Promotion einen ausführlichen Abstecher in die Betriebs- und Volkswirtschaft sowie in den Bereich Operations Research. Forschung und Erkenntnisgewinn als Selbstzweck waren ihm aber nicht genug – er braucht die praktische Anwendung und das Gefühl, das sein Tun unmittelbar etwas verändert. Als Chief Product Owner bei lexoffice kann er sein Technik-Faible mit Wirtschaftswissen und der Vorliebe für agiles, kundenzentriertes Arbeiten kombinieren – er liebt das tägliche Spektrum an Aufgaben und Herausforderungen.

Emily: Hallo Carsten, wie ist es zu dem Ausfall gekommen? Könntest Du es bitte so erklären, dass es auch Nicht-Techniker verstehen?

Carsten: Gerne. Tatsächlich wollen wir sogar unbedingt transparent über die Ursache, die zum Ausfall führte, berichten und auch, wie wir das Problem schließlich lösen konnten. Technische Details kann ich dabei nur bis zu einem gewissen Grad preisgeben: Die Sicherheit der Daten unserer Community hat ganz klar Vorrang.

Emily: Verständlich. Aber die Anwender*innen möchten natürlich verstehen, was da eigentlich passiert ist.

Carsten: Um das zu erklären, muss ich zunächst grob erläutern, wie der Ablauf hinter lexoffice funktioniert. Da wir lexoffice inzwischen für über 70.000 Kundenkonten – und damit weit über 200.000 Anwender*innen, die lexoffice regelmäßig nutzen – anbieten, kann ein einzelner Server die Anfragen, die technisch gesehen bei der Anwendung entstehen, nicht mehr abarbeiten. Wir haben daher schon vor Jahren angefangen, lexoffice in kleine “Micro-Services” zu unterteilen, die jeweils autark funktionieren und eine bestimmte Teilfacette von lexoffice abbilden.

Wenn beispielsweise ein Kunde in lexoffice eine Rechnung erstellt, wird die Rechnungsmaske von einem eigenen “Micro-Service” zur Verfügung gestellt. Gibt man oben in der Rechnung einen Kundennamen ein, liefert ein anderer lexoffice Micro-Service passende Suchergebnisse. Wird eine Postleitzahl eingegeben, ist wieder ein anderer Service dafür zuständig, die automagic für die Vervollständigung von PLZ und Ort zu liefern. Auch die automagic-Verbuchung der Rechnung ist in einen eigenen Service ausgelagert. lexoffice ist strukturell gesehen ein Netz von ganz vielen kleinen Services, die eng miteinander verzahnt sind und ständig untereinander kommunizieren, wie das nachfolgende Schaubild verdeutlicht.

Was den Ausfall angeht: All diese Services liegen hinter einer Firewall. Diese sorgt dafür, dass nur “legitime” Anfragen über einen definierten Eingangspunkt (im Bild als Trichter dargestellt) an die Micro-Services durchgelassen werden. Bislang haben alle unsere Services untereinander ebenfalls über diese Firewall kommuniziert, um so auch die Kommunikation zwischen den lexoffice Micro-Services mit einem zusätzlichen “doppelten Boden” abzusichern. Das kann man sich so vorstellen, wie in dem linken Teil des Bildes dargestellt.
Am Tag des Ausfalls ist es dann bei unseren Firewall-Servern trotz mehrfach redundanter Auslegung zu einem Netzwerk-Engpass gekommen – bedingt durch eine außergewöhnlich hohe Zahl gleichzeitiger Kundenzugriffe. Das haben wir nicht kommen sehen, weil unsere Monitoring-Systeme an dieser Stelle genügend freie Kapazität angezeigt hatten.

Netzwerk-Engpass auf den Firewall-Servern

Zusammengefasst wurde unsere äußere Schutzschicht, die Firewall, durch die unerwartete hohe Auslastung zum Flaschenhals, der einen Mega-Stau verursachte. Weil nämlich jeder Service und jede Firewall mehrfach redundant sind, haben sich die Anfragen wie eine Welle aufgebaut. Sie konnten nicht mehr alle gleichzeitig abgearbeitet werden und der Stau vergrößerte sich nach und nach in allen mitarbeitenden Systemen, bis schließlich alles zum Stillstand kam. Natürlich waren wir sofort mit der Problemlösung beschäftigt, aber: Wir mussten erst verstehen, dass die „Stauungen“ bei den einzelnen Micro-Services nicht die Problemursache waren. Als Sofortmaßnahme hatten wir eine Erhöhung der Serverkapazitäten dort durchgeführt, die aber  nicht zum Abbau des Rückstaus führte. Die Anzahl der nun zusätzlichen Netzwerkverbindungen der weiteren Server hat das Problem eher noch vergrößert.

Emily: Ohne sicherheitsrelevante Details zu verraten: Wie wurde das Problem letztlich gelöst?

Carsten: Wir haben das System umgebaut. Vereinfacht gesagt, funktioniert lexoffice jetzt, wie im rechten Teil des Schaubildes dargestellt. Die Firewalls schützen immer noch das Gesamtsystem. Neu ist, dass die lexoffice Micro-Services jetzt ohne Umweg über die Firewall direkt miteinander kommunizieren. Dazu haben wir neue Sicherungsmaßnahmen eingeführt, über die die Micro-Services sich untereinander identifizieren und mit eigenen Firewall (im Bild rechts die gestrichelten Linien um jeden Micro-Serivice) vor unzulässigen Anfragen von Fremdsystemen schützen. Mit anderen Worten: Die Sicherheit der Direktkommunikation der Micro-Services untereinander ist nun auf eine andere Art gewährleistet. Gleichzeitig ist der ursprüngliche Flaschenhals aufgelöst. Das Problem, das zu diesem Ausfall geführt hat, kann  so also nicht mehr auftreten, das verhindern unsere Gegenmaßnahmen effektiv.

Emily: Wieso hat es gedauert, bis die Lösung da war?

Carsten: Der Netzwerk-Engpass bei unseren Firewall-Servern durch die außergewöhnlich hohe Zahl gleichzeitiger Kundenzugriffe war das Problem, aber unsere Monitoring-Systeme haben an dieser Stelle trotzdem ausreichend freie Kapazitäten angezeigt. Die Analyse hat daher mehr Zeit in Anspruch genommen als die Problemlösung, weil wir erst verstehen mussten, dass die angezeigten Werte im Monitoring nicht korrekt waren. Auch das haben wir natürlich sofort korrigiert, nachdem wir das erkannt hatten. Zudem haben wir unsere technischen Tests auf unseren „Staging-Systemen“ (das sind lexoffice Systeme, die wir zum Testing und zur Qualitätssicherung verwenden) erweitert, um genau dieses Szenario vor jedem Release automatisch zu testen.

Kein Angriff – außergewöhnlich viele Kundenzugriffe parallel

Emily: War die Datensicherheit der Kunden zu jedem Zeitpunkt gewährleistet?

Carsten: Ja, auf jeden Fall. Wir haben den Vorfall genau analysiert und keinerlei Anzeichen dafür gefunden, dass die Überlastung auf einen böswilligen Angriff zurückzuführen war – und wir haben auch keinerlei Anzeichen dafür gefunden, dass jemand versucht haben könnte, ungewöhnlich viele Daten abzurufen.

Emily: Wer hat sich um das Problem gekümmert? Wie kann ich mir das vorstellen?

Carsten: Bei lexoffice haben wir spezielle Notfallpläne und wir machen regelmäßig Notfallübungen in allen – inzwischen neun – lexoffice Teams. Nach diesen Plänen haben wir gearbeitet.

In diesem Fall war es so, dass wir zunächst Unregelmäßigkeiten in unserer System-Anzeige bei den Antwortzeiten der Server festgestellt haben. Die gingen auf einmal drastisch hoch. Parallel haben sich die Kundenanfragen in unserem Support-Ticketing System gehäuft: Daraufhin hat der diensthabende Notfallkoordinator unseren Notfallplan in Kraft gesetzt.

Dieser Plan sieht vor, dass zunächst das gesamte lexoffice Team inklusive unserer Geschäftsleitung alarmiert wird. Damit einher geht, dass die Problemlösung vor allen anderen Aufgaben priorisiert wird und sich schnellstmöglich Vertreter aus allen Teams für ein Lagebild versammeln. Alle verfügbaren Informationen werden gesammelt. Anhand dieses ersten Überblicks verteilen wir Aufgaben, offene Fragen und mögliche Antworten zur Prüfung. Dann vereinbaren wir einen Zeitpunkt, zu dem wir uns wieder treffen – und legen ohne Verzögerungen los.

Während Engineering und Operations Spezialisten damit beschäftigt sind, die Problemursache einzugrenzen und so zeitnah wie möglich zu beheben, arbeiten unsere Support-Heros und Kommunikationsprofis daran, unsere Kunden bestmöglich über den Fortschritt auf dem Laufenden zu halten. Alle lexoffice Mitarbeiter sitzen im gleichen Gebäudeteil auf dem Haufe.Group Campus in Freiburg, sodass unsere internen Kommunikationswege kurz sind.

Emily: Wie häufig treten solche Probleme denn auf?

Carsten: Ein Ausfall dieser Größenordnung? Das war der erste in den fünf Jahren überhaupt, seit es lexoffice gibt und wir haben ihn zum Anlass genommen, unsere Notfallprozeduren insgesamt anzupassen und zu optimieren.

Wir lernen aus jeder Krise und auf allen Ebenen aus Problemen – das Problem, welches den Ausfall ausgelöst hat, wird nicht mehr auftreten, denn wir haben unsere Systeme angepasst und unsere automatischen Tests um genau dieses Szenario erweitert.

Emily: Welche Schritte werden jetzt unternommen, um Ausfälle zukünftig zu verhindern?

Carsten: Systempflege und Optimierungen sind immer fester Bestandteil unserer Aufgaben neben der Weiterentwicklung von neuen Funktionen und Vorteilen. Dazu bedarf es keines Notfalls.

Ist es aber passiert, versuchen wir so gut wir möglich auf allen Ebenen aus dem Problem zu lernen. Das ist ein Prinzip von lexoffice. Alle gemachten Erfahrungen – seien sie technisch, seien sie kommunikativ – fließen also als Anpasungen in unsere Notfallprozeduren und -trainings ein. Nach dem Ausfall haben wir ein „Post Mortem“ gemacht. Etwa eine Woche später – zurück im normalen Fahrwasser der Abläufe rund um lexoffice – hat sich das gesamte Notfall-Team für eine Retrospektive getroffen. Hier kam alles auf den Tisch, das Gute und das Optimierbare. Wir erfahren durch solche Zwischenfälle mehr über technische Problempotenziale, aber nehmen auch Learnings für die Standardprozeduren und die Kommunikation mit. Wir haben jetzt zum Beispiel eine Status-Infoseite und kommen damit dem Wunsch nach mehr Transparenz entgegen.

Zusammengefasst: Das Problem, das den Ausfall ausgelöst hat, wird so nicht mehr auftreten, denn wir haben unsere Systeme angepasst und unsere automatischen Tests um genau dieses Szenario erweitert. Wir sind jetzt durch diese Erfahrung also generell besser vorbereitet. Und wir verstehen noch besser, was Anwender*innen von uns in einer solchen Situation erwarten.

Emily: Das klingt gut! Vielen Dank für das Interview 🙂

Aktuelle Informationen zum System-Status: www.lexoffice.de/status

Über den Autor
Emily Metcalfe
Insider: Die Software fest im Blick

Beitrag kommentieren

  1. Gregor D. | 29.06.2018 | 22:49

    Vielen Dank für die transparente Aufarbeitung, auch wenn ich über die Gendersternchen etwas schmunzeln musste, zumal sie nicht ganz konsequent durchgeführt ist (müsste es nicht neben Kundenkonten auch Kundinnenkonten geben?) – ist für mich sicherlich nicht die eleganteste Lösung zur schriftlichen Gleichberechtigung der Geschlechter.

    Außerdem hat es mich gefreut zu lesen, dass alle Mitarbeiter im schönen Freiburg sitzen. Ich wünsche weiterhin viel Erfolg, hat mich gefreut, mal ein bisschen was von hinter den Kulissen von LexOffice lesen zu können.