Um menschliches Versagen zu vermeiden, werden gerne einige wichtige Abläufe automatisiert. In der Regel funktionieren Automatismen, wenn sie richtig eingestellt wurden. Wir von der ComConsult mussten am 11.07. leider feststellen, dass in der Regel nicht immer bedeutet.
Nach einem entspannten Wochenende fuhr man montags morgens um halb 7 nichtsahnend in die Firma, um dort festzustellen, dass die Firmen-Webseite nicht ordnungsgemäß funktioniert. Die Fehlermeldung beim Aufrufen lautete „Ihre Verbindung ist nicht privat“ und der Error-Code „NET:ERR_CERT_DATE_INVALID“ wurde angezeigt, sprich eines unserer Zertifikate war abgelaufen. Die Verwirrung war groß, da die Aktualisierung der Zertifikate automatisiert wurde und diese Automatisierung bis dato immer funktioniert hatte. Schnell loggte man sich auf der Webseite unseres Web-Hosters ein, um den Status der Zertifikate zu prüfen und dort mit der nächsten Fehlermeldung begrüßt zu werden. „Entschuldigung. Der Vorgang konnte nicht ausgeführt werden (Fehler: E000FF). Bitte versuchen Sie es später erneut. Sollte der Fehler erneut auftreten, kontaktieren Sie bitte unsere freundlichen Kundenbetreuer“. Mittlerweile war es 7 Uhr, und das Problem musste so schnell wie möglich behoben werden. Und das nicht nur, weil es etwas peinlich ist, wenn man als IT-Unternehmen, welches unter anderem Schulungen in dem Bereich anbietet, die eigene Webseite vermeintlich nicht im Griff hat. Des Weiteren möchte man den Besuchern auch wieder eine angenehme Zeit auf der firmeneigenen Webseite ermöglichen. Der vermeidbare Ansturm von Kunden-Meldungen über diesen Fehler und vermutlich witzig gemeinte Kommentare wären ein kleiner Bonus gewesen.
Da wir weder die Zertifikate prüfen noch das abgelaufene erneuern konnten, mussten wir ein Support-Ticket bei unserem Web-Hoster eröffnen. Alle nötigen Informationen wurden niedergeschrieben und die Priorität entsprechend auf hoch eingestellt. Jetzt konnten wir nur noch abwarten und Tee trinken. Kurze Zeit später wurde das Ticket in den Status „in Bearbeitung“ versetzt. Die Zeit verging und der erste Ansturm an Meldungen unserer Kunden und Mitarbeiter kam bei uns an. Unser Web-Hoster hatte sich bis dato jedoch noch nicht gemeldet. Was hätten wir also in der Zwischenzeit tun können? Mit dem Kundenservice telefonieren, um zumindest ein paar mehr Informationen zu bekommen. Das taten wir und erfuhren somit, dass unser Ticket beim First-Level-Support lag und dieser die Aktualisierung des Zertifikates bereits angestoßen hatte, welches eine Zeit von bis zu 6h beanspruchen konnte. Man hätte das Ticket zwar jetzt zum Second-Level-Support verschieben können, doch teilte man uns mit, dass wir doch bitte lieber diese 6 Stunden abwarten mögen. Es wäre sehr schön gewesen, wenn wir diese Information direkt im Ticket bekommen hätten. Bis 13:30 Uhr haben wir gewartet, und das Problem wurde nicht gelöst, weswegen wir wieder anrufen mussten. Gegen 16:30 Uhr kam beim erneuten Anruf die Rückmeldung, dass das Support-Team dem Problem auf der Spur sei. Einige Wochen zuvor gab es einen großen Server-Umzug. Man vermutete, dass deswegen die Aktualisierung fehlgeschlagen sei. Es mussten nochmals 1,5h vergehen, bis das Problem behoben und das Zertifikat erneuert werden konnte.
Was lernen wir jetzt aus der Geschichte? Never change a running system, wenn Automatismen im Spiel sind. Sollte es doch aus Sicherheits- oder Performance-Gründen nötig sein, dann muss alles ausgiebig getestet werden, vor allen Dingen die Automation. Eine weitere gelernte Lektion ist, dass Rückmeldungen frei machen. Das Gefühl, ohne Informationen auf heißen Kohlen zu sitzen, ist nicht gerade angenehm. Da hätte ich mir als Kunde vom Support Service schon mehr gewünscht.
