Was wir gelernt haben

Acht Wochen ist es nun her, dass eine Verkettung unglücklicher Umstände zu einer Störung der sipgate Telefonie geführt hat. Wie fast immer in solchen Fällen: Wir haben viel gelernt. Unsere Dienstleister im Rechenzentrum haben viel gelernt. Was genau, und was wir in den vergangenen Jahren in unsere Infrastruktur investiert haben, damit wir so ausfallsicher wie möglich sind, erklärt Markus Monka, Product Lead für All in One Net, IP und Telefonienetze, Betrieb und Entwicklung bei sipgate, im Interview.

Markus, du warst am 22. Juni als Vertreter für sipgate am Rechenzentrum vor Ort. Wie war die Situation? Und was war deine dringlichste Aufgabe?

Ich war um 18 Uhr da. Die Situation war natürlich für alle angespannt. Wir sind schon seit 2011 Kunde bei dem Rechenzentrum und haben gute Kontakte zu den Mitarbeiter:innen dort. Gut war, dass sie alle vor Ort waren und immer transparent mit uns gesprochen haben. Mein Ziel war es, dass wir nicht als Letzter Strom bekommen und möglichst schnell wieder angebunden werden. Das gute Gefühl für mich in dieser sehr angespannten Situation war, dass mir klar war, dass wir bei sipgate eine richtig gute Truppe an den Rechnern sitzen haben. Und dass wir, sobald wir wieder Strom haben, alles ziemlich schnell wieder ans Laufen bekommen. Und genau so war es dann ja auch.

Krise hat ja fast immer auch etwas Gutes. Was wurde auf Seite des Rechenzentrums getan, dass so etwas im besten Fall nicht mehr passiert?

Markus Monka (vorne links) ringt den Rechenzentrums-Mitarbeitern am Tag des Ausfalls zumindest fürs Selfie noch ein Lächeln ab.

Man muss es so sagen: Das war schon eine Verkettung ganz ungünstiger Umstände. Der Bagger, zu allem Überfluss auch noch ein sehr großer, hat die Kabel auf einem Nachbargrundstück des Rechenzentrums durchtrennt. Das hat die Sache zusätzlich kompliziert gemacht, weil Zuständigkeiten nicht eindeutig geklärt waren. Und dass der Notfallgenerator nach nicht mal einer Stunde Feuer fängt, ist ja auch eher unüblich. Das Gute am Schlechten: Der Anschluss unseres Cages im Rechenzentrum war ohnehin schon für einen Umzug auf neue Infrastruktur vorgesehen. Das wurde dann in der Krise vorgezogen. Wir haben einen neuen Anschluss an das Stromnetz der Stadtwerke Düsseldorf, einen verbesserten, sichereren Anschluss innerhalb des Rechenzentrums, einen neuen Transformator und einen neuen Generator bekommen. Der Vorteil ist nun, dass wir eine wesentlich verbesserte Anbindungsredundanz haben. Und: Die Hauptstromleitungen liegen nun in einem Bereich des Grundstücks, der von den Betreibern des Rechenzentrums bei etwaigen Bauarbeiten sehr viel besser kontrolliert und beaufsichtigt werden kann, als das vorher der Fall war. Und die Zuständigkeiten sind jetzt eindeutig. Die Kolleg:innen im Rechenzentrum haben ganz viel aus dem Ausfall gelernt, können nun sehr viel schneller und gezielter reagieren. Wir stehen jetzt besser und wesentlich ausfallsicherer da.

Ausfallsicherheit, Redundanz, Hochverfügbarkeit, Resilienz sollen ja nicht nur Schlagworte sein. Was tun wir da bei sipgate? Und wie sind wir aktuell aufgestellt?

Wir machen das jetzt seit 2003 und haben seitdem mehrere Iterationen auf Standorte gemacht, wo wir die Technik betreuen und betreiben. 2022 sind wir an einem Punkt in der Firmengeschichte angekommen, wo wir noch nie besser waren. Wir sind zwar auf die Softwareentwicklung fokussiert, haben in den vergangenen Jahren aber verstärkt in die Infrastruktur investiert. Wir wollen natürlich den Umsatz, den wir generieren, auch schützen. Und dafür muss man in eine resiliente, redundante und hochverfügbare Infrastruktur investieren. Ein für uns wichtiger Wert ist die mean time to recovery (MTTR). Also: Wie lange brauchen wir, um die Systeme bei einem Ausfall wieder ans Laufen zu kriegen? Da liegt unser Fokus drauf und diese MTTR versuchen wir immer kleiner zu kriegen.
Wir betreiben ja das Internet selber. Unsere Tochterfirma, die netzquadrat, macht den kompletten IT-backbone. Wir haben in den vergangenen Jahren massiv investiert und alles auf moderne Hardware gestellt. Da haben wir nicht nur sehr gute Leute, sondern es wurde auch alles automatisiert, so dass die Systeme bei einem Ausfall schnell wiederhergestellt werden und unsere MTTR da sehr gut ist. Als der Strom vom Rechenzentrum wiederkam, waren alle unsere Backbonesysteme sofort wieder online.

Wie sieht es mit der Serverstruktur bei sipgate aus?

Hinter dem IT-backbone betreiben wir die Server. Die laufen mit Linux. Und auch da haben wir zuletzt in modernste, resiliente Hardware investiert. Wir haben bei diesem massiven Stromausfall nicht mal ein Netzteil verloren. Zudem haben wir viel virtualisiert. Wir automatisieren, dass wir security-updates haben. Immer, wenn es ein security-update auf einer Hardware- oder virtuellen Maschine, auf der automatisch nachgeguckt wird, gibt, lädt die sich das security-update neu und startet sich neu. Wir wussten also, dass der Service auf diesen Maschinen definitiv wieder hochkommen wird, weil wir das zuverlässig und stabil automatisiert haben.

Wie lief es dann konkret am 22. Juni, als der Strom wieder da war?

Als wir um 23 Uhr wieder Strom hatten, habe ich langsam die Sicherungen der Server wieder eingeschaltet. Die sind dann alle nacheinander mit Versatz von bis zu 40 Sekunden hochgefahren, haben ihre Dienste gestartet und waren wieder online. Das hat bei 95 Prozent aller Maschinen geklappt. Fünf Prozent, mitunter ältere Kisten, brauchten ein bisschen mehr Liebe. Da musste hier und da doch noch mal ein Knöpfchen gedrückt werden, damit sie wieder laufen. Im Hintergrund saßen die sipgate Notfallingenieur:innen und haben geschaut, dass sich das System wieder einschwingt. Es hat nicht mal eine Stunde gedauert, da liefen alle unsere Systeme wieder.

Redundanz ist ein großes Thema. Auch bei uns. Erkläre doch mal kurz das System.

Die Telefonie bei sipgate ist schon immer zu gleichen Teilen auf zwei Rechenzentren verteilt. Die Rechenzentren sind alle redundant mit insgesamt vier upstreams à 10 Gigabit an das Internet angebunden. Und auch da, wo wir Sprache direkt zu den Carriern wie z.B Deutsche Telekom, Telefónica, Vodafone austauschen, haben wir Redundanz. Das ist also alles darauf ausgelegt, dass es auch an einem Standort funktioniert. Unseren Mobilfunk haben wir zuletzt auch immer weiter stabilisiert und ausfallsicherer gemacht. Da haben wir viel in neue Leitungen zu Telefónica und in das Automatisieren des Anfahrens gesteckt. Das lief dann nach dem Stromausfall auch gut. Wir hatten kein Lastproblem. Unsere Telefonie ist so dimensioniert, dass ein Rechenzentrum sie alleine tragen sollte. Die Probleme lagen woanders.

Dann lass uns das mal aufgreifen. Am 22. Juni haben Dinge nicht so gut funktioniert. Was ist da bei uns falsch gelaufen?

An zwei Stellen haben wir uns einen Bock geschossen: In einem System am noch funktionierenden Rechenzentrum gab es einen Verweis auf ein legacy-System, was nur am anderen Standort war, der ja aber leider offline war. Wir haben das da nicht abgebaut, es wurde aber trotzdem die ganze Zeit abgefragt. Da wurden also quasi Anfragen ins Nichts hinein gestellt. Deswegen haben die eingehenden Gespräche so lange nicht funktioniert. Das mussten wir suchen, identifizieren und auskommentieren. Danach war eingehend auf unserer Festnetzschiene die Erreichbarkeit wieder da. Und auch beim Mobilfunknetz gab es Probleme mit einem legacy-System für die Daten zum Accounten, das durch den Ausfall ins Nichts lief. Insgesamt war es so, dass ein Teil der Telefonie bereits gegen 21 Uhr wieder funktionierte, wir in der Hektik aber leider auch Dinge kaputt gemacht und falsch geroutet haben, so dass es bis zum nächsten Vormittag gedauert hat, bis wir das komplett repariert hatten und Telefonie und Mobilfunk wieder vollständig da waren.

Ein Punkt, der Kund:innen und uns ebenfalls länger beschäftigt hat, waren Dinge wie Voicemails und IVR. Das hat ein paar Stunden länger gedauert, bis die alle wieder zur Verfügung standen. Warum war das so?

Eine Ausnahme in unserer Infrastruktur ist storage. Das sind in unserem Fall standardisierte Linux-Maschinen mit ganz vielen Festplatten drin. Und da landen Voicemailansagen, Voicemails, IVR, Rechnungen etc…. Das ist uns tatsächlich ein wenig um die Ohren geflogen. Wir sind keine ausgewiesenen storage-Experten. storage ist nicht unser Kerngeschäft. Wir haben da was Gutes, Solides gebaut, müssen uns da aber noch verbessern. Deshalb planen wir, storage in die Cloud auszulagern. Das ist aber auch grundsätzlich ein Learning aus dem Ausfall: Wir wollen Dinge, in denen wir nicht die Hauptexpertise haben, vermehrt auslagern. Bevor sich zehn Menschen nur um storage kümmern, wollen wir viel lieber mit diesen zehn Menschen Kundenwert schaffen. Auch den kompletten Bereich der Webseite, also Dinge wie Datenbanken, Webservices, Kontaktverwaltung etc., wollen wir in die Cloud auslagern, so mehr Redundanzen schaffen und damit zu mehr Ausfallsicherheit kommen. Heißt: Um die Telefonie- Hochverfügbarkeit und die Businesslogik über zwei Standorte müssen wir uns dann keine Gedanken mehr machen, sondern können uns an diesen Stellen darauf konzentrieren, die Software zu schreiben.

Was wir gelernt haben? Eine ganze Menge, wir ihr ja gerade gelesen habt. Wir haben viele Stunden in die Analyse des Ausfalls gesteckt, haben identifiziert, an welchen Stellen Dinge bei uns nicht so gut funktioniert haben. Und genau diese Stellen werden gerade und in den kommenden Wochen Stück für Stück von unseren Teams repariert.