Dienstagabend, 20 Uhr. Unsere Kolleginnen und Kollegen bei der Technik und im Kundenservice stellen sich auf einen ruhigen Abend ein. Das Anrufvolumen bewegt sich im überschaubaren Rahmen und das Monitoring meldet keine besonderen Auffälligkeiten. Alles im grünen Bereich also.
Zwischen ca. 20:30 und 21 Uhr. Erste Anrufer berichten darüber, dass ihre bei uns gehostete Webseiten nicht mehr erreichbar sind. Die ersten Überprüfungen können dies nicht bestätigen: Alle genannten Domainnamen funktionieren aus unserer Sicht und sowohl bei den Servern als auch im Netzwerk sind keine Störungen verzeichnet. Dennoch wird die Technik informiert, damit diese den Meldungen nachgehen kann.
Gegen 21 Uhr: Die Lage spitzt sich zu. Die Anzahl der Anrufer, die einen Ausfall melden, steigt drastisch an. Es kommt zu spürbaren Wartezeiten. Auch in unserem Kundenforum, auf unserer Facebook-Seite und bei Twitter häufen sich die Mitteilungen über ein Problem. Unsere Mitarbeiter nehmen sowohl im technischen Bereich als auch im Kundenservice eine vorsorgliche Notfall-Eskalation vor und informieren u.a. Vorgesetzte, damit diese unterstützend eingreifen und Verstärkung für z.B. die Telefonhotline organisieren können. Ob Feierabend oder nicht ist jetzt keine Frage: Es gibt ein Problem und das muss gelöst werden. Auch die Geschäftsleitung ist aktiv, um die weitere Entwicklung aktiv begleiten zu können.
Kurz nach 21 Uhr: Das anfangs unklare Problem zeichnet sich inzwischen deutlicher ab. Offensichtlich gibt es Routingschwierigkeiten, die einen Teil des Datenverkehrs aus dem Netz der DTAG betreffen. Wir schreiben einen ersten Statusseiteneintrag und geben die Mitteilung auch über unsere Social-Media Kanäle weiter. Alle Beteiligten arbeiten mit Hochtouren an einer Lösung und der Beantwortung aller Kundenanfragen. Das Ziel: Den Datenverkehr so umleiten, dass er wieder normal “fließen” kann.
21:11 Uhr: Die Beeinträchtigung konnte durch eine vorgenommene Routingänderung im Netzwerk umgangen und somit die vollständige Erreichbarkeit aller Dienste für alle Nutzer wiederhergestellt werden. Der betroffene Datenverkehr wird über andere Netzverbindungen von uns geleitet und die “Unfallstelle” somit umgangen. Parallel laufen weitere Analysen, zudem stehen wir mit dem betroffenen Uplinkprovider in Kontakt. Die Stautsseite wird erneut aktualisiert und auch auf Twitter, Facebook und im Forum sind wir weiterhin parallel dazu aktiv. Die Stimmung ist weiterhin angespannt.
21:30 Uhr: Der betroffene Uplinkprovider in München hat uns das in seinem Einflussbereich liegende Problem bestätigt. Die getroffene Einschätzung war also richtig und die Änderung unseres Routings die passende Entscheidung. Wir leiten den Datenverkehr daher auch weiterhin über andere Uplinks und können den um 21:11 Uhr wieder hergestellten reibungslosen Betrieb stabil aufrecht erhalten. Weitere Stellungnahmen auf der Statusseite, im Forum, bei Facebook und auf Twitter runden die Kundenkommunikation bis etwa 21:45 Uhr ab. Die Lage hat sich inzwischen, auch an der Hotline, wieder normalisiert. Wir heben daher die Alarmierung der zusätzlichen Personen auf; die Technik behält jedoch ein besonderes Augenmerk darauf, ob es erneut zu einem Problem kommt.
Mittwoch, 6 Uhr: Das alternative Routing hat gehalten und weitere für Kunden spürbare Einschränkungen sind nicht aufgetreten. Die Nacht ist im normalen Rahmen verlaufen. Wir sind erleichtert.
9 Uhr: Die in der Nacht noch eingetroffene Stellungnahme des betroffenen Uplink-Providers und das abschließende Ergebnis der internen Analyse liegen vor und werden besprochen. Aus den vorliegenden Informationen ergibt sich nun ein vollständiges Bild zu der Frage, weshalb das Problem aufgetreten und für uns anfangs überhaupt nicht eindeutig nachvollziehbar gewesen ist. Konkret kam es bei einem von uns genutzten Uplink, über den wir den DTAG-Datenverkehr abgewickelt haben, zu einem teilweisen Ausfall im Backbone. Dieser hat nicht zu einem vollständigen Ausfall des Standorts geführt, sondern nur bestimmte Absender- und Empfänger-IP-Adressen betroffen. Datenpakete, die über den “kaputten Teil” des Datenkanals gesendet worden sind, haben ihr Ziel erreicht. Die anderen gingen “verloren”.
Aus diesem Grund konnten wir intern die Situation nicht so einfach reproduzieren sondern statt dessen sogar die für die betroffenen Kunden ausgefallenen Dienste ganz normal erreichen. Auch die automatische Routingänderung mittels BGP-Protokoll hat daher nicht funktioniert, da der Backbone des betroffenen Uplinks eben nur zum Teil gestört gewesen ist und alle BGP-Verbindungen intakt geblieben sind. Unser Netzwerk hat daher weiterhin Daten mit dem Uplink ausgetauscht, ohne erkennen zu können, dass er für einen Teil der Internetnutzer nicht mehr funktioniert.
Inzwischen wurde der Defekt dort natürlich bereits behoben und die Verbindung wieder aktiviert. Insgesamt lässt sich festhalten, dass in der Spitze etwa 15% des während des Ausfalls regulär anfallenden Datenverkehrs von dem Problem betroffen worden ist. Dies ist – obwohl sich der Ausfall vollständig außerhalb unseres Einflussbereichs abgespielt hat – ohne jede Frage unerfreulich für die betroffenen Kunden und wir hoffen, den Ärger durch die schnellstmögliche Reaktion und zeitnahe Fehlerbehebung zumindest ein wenig reduziert zu haben.
Hier noch einige Screenshots zur ergänzenden Dokumenation:
Von einem ganz üblen Ausfall mit Datenverlust sind heute rund 40 unserer Kunden betroffen. Diese befinden sich auf einem Webserver, bei dem es in der Nacht zu einer hardwarebedingten Beschädigung des Dateisystems gekommen ist. Trotz vorgenommener und von den Systemprogrammen als erfolgreich eingestufter Reparaturarbeiten mussten wir heute Vormittag feststellen, dass auch als unbeschädigt eingestufte Dateien in Wirklichkeit beschädigt sind.
Dies ist natürlich fatal, da weder wir noch unsere Kunden so erkennen können, welche Daten in welchem Umfang tatsächlich beschädigt oder verloren gegangen sind. Vor diesem Hintergrund verbleibt nur die Einspielung des letzten nächtlichen Backups als Möglichkeit.
Alle Kunden werden durch uns jetzt sehr zeitnah per E-Mail über diesen Sachverhalt informiert; selbstverständlich halten wir wie üblich auch unsere Stautsseite aktuell.
Auch wenn wir den Ausfall weder verschuldet haben noch verhindern konnten, werden wir den betroffenen Kunden natürlich einen vollen Tarif-Monatspreis gutschreiben, um unser Bedauern über diese so ärgerliche Situation deutlich zu machen. Darüberhinaus werden wir selbstverständlich auch individuell bei Problemen zur Verfügung stehen.
Übrigens: Die aktuellen (wenn auch zum Teil beschädigten) Daten werden wir natürlich nicht einfach löschen, sondern aufheben und Kunden auf Anfrage zur Verfügung stellen. Dadurch kann unter Umständen selbst überprüft werden, ob und welche Daten sich ggf. noch retten und übernehmen lassen. Sehr gerne hätten wir dies ja automatisiert getan. Da das Dateisystem aber eben die fehlerhaften Dateien nicht als solche erkennt, fehlt dafür jeder Ansatzpunkt.
Manchmal fühlt man sich richtig, richtig hilflos. 
Der Ausfall der DENIC-Nameserver in der vergangenen Woche hat bei uns zu einem sprunghaften Anstieg des Supportvolumens geführt. Insgesamt dürften rund 1.500 Anrufe und Tickets auf die alle Internetnutzer und Provider betreffenden, nicht durch uns zu beeinflussenden Probleme bei den .de-Domains zurückzuführen gewesen sein. Nicht allen Kunden war dabei gleich zu vermitteln, dass das Problem überhaupt nichts mit uns zu tun hat sondern mit den durch ihren jeweils genutzten Einwahlprovider abgefragten DENIC-Nameservern bei Aufruf einer .de-Domain.
Gleichzeitig hat uns die frühzeitige Kundeninformation auf der Statusseite (status.df.eu) einige Nennungen in der Presse eingebracht, darunter auch bei n-tv, Spiegel online und einigen bekannten Namen mehr. Leider nicht immer ganz akurat. So titelte z.B. die Featurezone vom ORF: “Serverausfälle bei domainfactory”. Gemeinheit! 
Hier der Screenshot des ORF-Artikles (Auszug). Wie die auf “Serverausfälle bei domainfactory” kommen, ist uns rätselhaft:
Hier mal noch ein paar Links:
Einer unserer Kunden hat für seinen dedizierten Server einen Tarifwechsel beauftragt. Dieser wurde auch entsprechend durchgeführt – woraufhin beim Kunden nichts mehr ging. Eine von ihm eingesetzte, für ihn entscheidende Software lief – bei identischer Softwareumgebung – nicht mehr. Erst der kostenpflichtige Kundenservice des Softwareherstellers konnte die Problemursache eingrenzen und den entscheidenden Tipp für die Behebung geben (Änderung einer Serverumgebungseinstellung).
Natürlich haben wir überprüft, ob es im Rahmen der Umstellung zu einem Fehler oder Versäumnis gekommen ist. Da die Original-Konfigurationsdatei auf dem Ursprungsserver jedoch vorgelegen hat, konnten wir dies am Ende ausschließen. Auch dort waren die “normalen” (nicht angepassten) Standardeinstellungen vorhanden, so wie auf dem neuen Server direkt nach dem Tarifwechsel. Der Kunde gibt aber gleichzeitig an, dass bei identischen Rahmenbedingungen bis zum Umzug alles einwandfrei funktioniert hat.
Unser Kunde war trotz der auch für ihn natürlich sehr ägerlichen Situation zum Glück relativ gelassen und hat auch keine pauschalen Schuldzuweisungen gemacht. Das verdient Respekt, zumal häufig und gerne bei Problemen gleich und unerschütterlich die Verantwortung beim Provider gesucht wird. Dafür gibt es aber keinen Grund: Wenn wir etwas falsch machen, stehen wir dazu. Und helfen dem Kunden so oder so partnerschaftlich weiter. Auch ohne Drohungen oder böse Worte.
Was genau im vorliegenden Fall die Problemursache gewesen ist, wird sich wohl nicht mehr aufklären lassen. Daher haben wir für die vom Kunden beauftragten Serverwechsel die bereits vorab auf jeweils 100 € reduzierten Setupgebühren vollständig erlassen, zumal dem Kunden nicht nur Arbeit und Ärger sondern auch Fremdkosten für den Support des Softwareherstellers entstanden sind. Durch die Erstattung beteiligen wir uns daran zumindest und freuen uns auf die weiterhin gute Zusammenarbeit.
(Hätte der Fehler sicher oder wahrscheinlich bei uns gelegen bzw. hätten wir die Original-Konfiguration nicht mehr als “Nachweis” gehabt, wären dem Kunden natürlich die Kosten für den Fremdsupport vollständig erstattet worden.)
Es gibt Dinge, die dürfen einfach nicht passieren. Und sind trotzdem nicht 100,0%ig zu vermeiden. So gestern der Ausfall von gleich zwei unserer Upstreamprovider.
Theoretisch ist alles klar: Wir sind mehrach-redundant angebunden, d.h. nutzen sowohl zwei Gebäudeführungen bei der Netzwerkanbindung als auch mehrere Upstream-Provider. Fällt eine Leitung oder fällt ein anderer Provider aus, kann dies so gut abgefangen werden.
Praktisch sah es gestern leider anders aus:
1. Es kam zu einem Leitungsbruch unserer Upstream-Verbindung zu Lambdanet im Telehouse “Landsberger Str. 155″ in München
2. Die redundant geführte Leitung zum zweiten Upstream TeliaSonera in der Seidelstr. in München ist, nachdem für 2 Stunden dort bereits der Traffic nach Ausfall der ersten Anbindung gelaufen ist, ebenfalls (und ebenfalls außerhalb unseres Einflussbereichs) ausgefallen.
Beide Ursachen lagen nicht bei uns und die Chance, dass das so zusammentrifft, ist enorm gering. Dennoch – irgendwer gewinnt ja auch im Lotto – kam es genau dazu. Zum Glück konnte Noris Networks einspringen und kurzfristig einen Notfall-Upstream zur Verfügung stellen. Dennoch gab es in weiten Teilen des Internet gestern zwischen 21:30 Uhr und 22:50 Uhr (nachdem auch die zweite Leitung durch ein Problem beim Anbieter ausgefallen war) zu Einschränkungen bei unserer Erreichbarkeit.
Dafür bitten wir um Entschuldigung. Die Problematik lag jedoch weder in unserem Einflussbereich noch haben wir Dinge wie Überwachung der Leitungen etc. versäumt.
In der Theorie ist das klar: Hardwaredefekt? Dann Platten raus aus dem Server, in ein anderes Gerät rein – und weiter geht’s. Für diese auch in der Praxis sehr hilfreiche Option stehen stets ausreichende Ersatz- und Bereitschaftsgeräte in allen relevanten Konfigurationen zur Verfügung. Leider hilft uns dies im vorliegenden Fall nicht weiter, da in einer bestimmten Konstellation aus Hardwareplattform + Linux-Kernel-Version ein RAID-Defekt auftritt. Dieser lässt sich auch nicht dadurch beheben, dass die betroffenen Platten in einen anderen Server verbracht werden; dort tritt das Problem identisch wieder auf.
Es ist in solchen Fällen daher z.B. erforderlich, die Festplatten in einem anderen Hardwaresystem zu starten. Die dafür erforderlichen Rekonfigurationen nehmen leider einige Zeit in Anspruch, zumal eine Klärung der Ursache gerade bei RAID-Problemen besonders wichtig ist, da stets latent die Gefahr von Datenverlust mit im Raum steht. Zwar liegen die Daten gespiegelt vor und es gibt auch ein Backup aus der vergangenen Nacht. Dennoch haben wir – um es sprichwörtlich zu sagen – “schon Pferde kotzen sehen” und behandeln daher RAID-Probleme mit noch einmal erhöhter Sensibilität.
Dies geht natürlich leider zur Lasten der Problembehebungsdauer. Betroffene Kunden können aber sicher sein, dass wir Optionen wie Hardwaretausch usw. stets prüfen und wenn immer möglich durchführen.
Derzeit besteht in Folge des heute durchgeführten Serverimage-Updates ein Problem mit mehreren Webservern. Unsere Technik bis hin zum Technik-GF sind an dem Problem dran; in allen Support-Abteilungen sind die jeweiligen MitarbeiterInnen alarmiert um bei Kundenanfragen direkt reagieren zu können. Den aktuellen Wissens- und Lösungsstand veröffentlichen wir zudem auf unseren Statusseiten unter http://status.df.eu sowie in unserem Forum. Dort werden jeweils regelmäßig Updates veröffentlicht.
Die genaue Ursache steht noch nicht fest; es scheint jedoch in Konstellation mit einer bestimmten Hardwarekonfiguration und dem neuen Linux-Kernel teilweise (d.h. bei einigen dieser Server) zu Problemen mit dem RAID-System der Server gekommen zu sein. Dieses Problem hat sich bei den im Vorfeld natürlich durchgeführten Tests nicht gezeigt und konnte daher nicht abgefangen werden. Die genaue Problemursache werden wir nach Abschluss der Problemklärung und -behebung natürlich veröffentlichen; Sie können insofern sicher sein, dass wir dieses Problem vollständig nachvollziehen und ausräumen werden.
An dieser Stelle bitten wir alle betroffenen KundInnen nochmals um Entschuld igung. Selbstverständlich bieten wir in Folge der Betriebsunterbrechnung als Entschädigung und zur Verdeutlichung unseres Bedauers einen Monatstarifpreis als formlos mögliche Gutschrift an und stehen darüber hinaus im Fall enstandener Schäden auch für individuelle Entschädigungsvereinbarungen so weit und unkompliziert wie möglich zur Verfügung. Wir bitten diesbezüglich jeweils um Kontaktaufnahme, um jeden Einzelfall direkt klären zu können.
“Gibt es einen Ausfall oder stehen irgendwelche für mich spürbare Arbeiten an Systemen an?” – Fragen dieser Art beantwortet unsere Statusseite unter http://status.df.eu (bzw. für unsere Lowcost-Marke domain*go unter http://www.domaingo-status.de). Auf dieser versorgen wir unsere Kundinnen und Kunden bereits seit über neun Jahren mit aktuellen Informationen bei angekündigten Wartungsarbeiten oder kurzfristigen Betriebsunterbrechnungen. Auch ein RSS-Feed ist natürlich verfügbar. Die Seite wird vorsorglich extern gehostet, damit sie auch z.B. bei einem vollständigen Netzwerkausfall (unwahrscheinlich, aber trotz mehrfacher Redundanz natürlich theoretisch möglich) erreichbar bleibt. Ein Bookmarking oder die Aufnahme in den RSS-Reader lohnt sich also. Immerhin kann man so im Verdachtsfall schnell feststellen, ob ein allgemeines Problem bei uns vorliegt und sich damit unnötige, zeitraubende Supportanfragen ersparen.
Bei einigen tausend Servern ist es nicht verwunderlich, dass an vielen Tagen ein oder mehrere Einträge über in der Regel zum Glück eher kleinere Probleme informieren. Aufgrund der hohen Gerätezahlen ist das einfach unvermeidbar – zumindest, wenn man eine solche Statusseite ernsthaft als Bestandteil eines guten Kundenservices betreiben und nicht als Pseudo-Aushängeschild (“schaut mal, wir haben nie Ausfälle”) “missbrauchen” möchte.
Aber wie läuft das denn so ab, mit der Statusseite?
Nun, nehmen wir die aktuellen Meldungen als Grundlage:
Alle Einträge werden über ein webbasiertes Verwaltungstool administriert. Dort sieht das dann z.B. so aus:
Direkt auf der Übersichtsseite sind Dinge wie der letzte Zeitpunkt der Bearbeitung jedes Eintrages zu sehen und auch, ob dieser für unsere Marke domainFACTORY und/oder domain*go aktiv ist. Zudem lässt sich direkt die Reihenfolge der Einträge ändern und natürlich auch eine Bearbeitung vornehmen.
Für jede Stautsmeldung lassen sich verschiedene Einstellungen festlegen:
- Vorauswahl aus einigen Standard-Templates
- Art des Eintrages: “Dauerhaft”, z.B. bei einer angekündigten Wartungsarbeit im Voraus oder “Notfall” bei akuten Ausfällen
- Titel inkl. Servername und -nummer
- die Statusmitteilung an sich
- ein Update-Text für Aktualisierungen
- die Angabe, welche(r) Server betroffen ist/sind bzw. – bei betroffenen Kunden erscheint der Eintrag auch automatisch im Kundenmenü. Darüber hinaus kann auch ein allgemeiner Eintragstyp gewählt werden, bei dem die Mitteilung optional in jedem Kundenmenü angezeigt wird
- der Brand (domainFACTORY oder domain*go)
- Start-, Stopp- Updatezeit sowie eine Angabe zur voraussichtlichen Behebung
Über das Tool lassen sich Statusmeldungen sehr einfach durch die zuständigen Mitarbeiterinnen und Mitarbeiter einpflegen. Wichtig ist dabei, dass die Erstellung und Aktualisierung von Statusmeldungen – egal ob an normalen Computern oder über mobile Endgeräte – möglichst schnell und unkompliziert funktioniert. Immerhin sollen einerseits alle betroffenen Kunden über eine Störung so schnell wie möglich informiert werden, ohne dass dies andererseits die Problembehebung spürbar verzögert.
Bei einem (zum Glück sehr seltenen) größeren Problem ist daher auch ein gesonderter Mitarbeiter dafür zuständig, regelmäßig den aktuellen Status bei den mit dem Problem befassten Kollegen zu erfragen und in ausreichend kurzen Intervallen (z.B. 15 Minuten) zu veröffentlichen. Ergänzt wird dies dann je nach Bedarf durch eine aktive Betreuung in unserem Forum. Dazu eröffnen wir einen gesonderten Thread, in dem ebenfalls laufend ein aktueller Status veröffentlicht wird und Rückfragen möglich sind.
Denn unserer Erfahrung nach ist jede Betriebsunterbrechnung natürlich ärgerlich – noch schlimmer ist es aus Kundensicht jedoch, im Dunkeln gelassen und nicht mit aktuellen Informationen versorgt zu werden.
