Probleme mit der Zeitumstellung: Hält von 12 bis Mittag
Ende letzten Jahres haben wir euch aufgerufen , uns eure Worst Practices zu schicken – und viele von euch haben uns geschrieben. Danke dafür! Nun werden wir nach und nach einige eurer Geschichten veröffentlichen, beginnend mit dieser. Wir nehmen auch gern weitere entgegen, schreibt uns dafür unter dem Betreff "Worst Practices" an schreiben@golem.de . Nähere Infos gibt es im oben verlinkten Aufruf.
Es begann wie ein normaler Arbeitstag. Mit dem ersten Kaffee setzte ich mich kurz nach sechs an meinen Schreibtisch. Vermutlich würde heute wieder das Übliche anstehen: die für den dringend nötigen Windows 7 Roll-out neu gekauften PC auspacken, mit Images betanken und den größten Teil des Tages im Anzug unter Schreibtischen verbringen, um diese Rechner bei den neuen Besitzern aufzubauen.
Doch kaum hatte ich mich gesetzt, kam mein Chef ins Büro. Wir müssten uns mal was anschauen, die Zeit an seinem Rechner stimme nicht. In der Nacht war auf die Sommerzeit umgestellt worden und sein PC zeigte noch die alte Uhrzeit an. Die Frage "Schon mal neu gestartet?" war keine Hilfe. Schnell wurde klar, dass nicht nur der PC betroffen war: Fast alle Systeme, das heißt Clients, aber vor allem Domänencontroller, Mail- und Datenbankserver sowie die meisten ERP-Systeme, zeigten die tatsächliche Uhrzeit an.
Spätestens da war klar, dass es kein normaler Tag würde. Erst recht nicht für mich, der ich mitten in meiner Ausbildung zum Fachinformatiker für Systemintegration steckte. Die Umstände des Fehlers und wie damit umgegangen wurde, lassen mich auch heute noch schmunzeln und haben dazu beigetragen, dass ich versuche, in meinem Berufsalltag Krücken – oder den treffenderen englischen Begriff ''kludges''(öffnet im neuen Fenster) – zu vermeiden.
Ratlosigkeit gefolgt von Panik
An dem besagten Tag herrschte zunächst Ratlosigkeit. Versuche, die Uhrzeit an den Rechnern lokal umzustellen, scheiterten spätestens beim Neustart. Auf Anhieb wusste keiner, woher unser Netz die Zeit bezog. Also machten wir uns auf dem Windows-Domänencontroller auf die Suche.
Währenddessen hatten die Kollegen aus den anderen IT-Bereichen ausgeschlafen und merkten, dass bei ihren Systemen irgendwas nicht stimmte. Besonders jene Kollegen waren nicht begeistert, bei denen geschäftskritische Anwendungen liefen. Außendienstler, die sich per VPN einwählen wollten, konnten es nicht, da deren Systemzeit von unserer abwich.
Hinzu kamen permanent Anrufe aus den Büros, und auch der Abteilungsleiter hatte mittlerweile über die angeschlossenen IT-Bereiche erfahren, dass diese quasi arbeitsunfähig geworden waren. Bevor man Datenbankinkonsistenzen riskierte, dachte man darüber nach, mehrere Anwendungen abzuschalten.
Auch die Sachbearbeiter in den verschiedenen Bereichen wollten nicht riskieren, im ERP-System unter den Vorgängen falsche Uhrzeiten zu haben und bearbeiteten nichts. Währenddessen versuchte mein direkter Vorgesetzter sich in Schadensminimierung: Man werde das Problem in Kürze gelöst haben.
Unsere anfängliche Ratlosigkeit verschob sich in Richtung Panik.
Das DCF-77-Zeitsignal
Wir suchten nach einer Dokumentation, wie die Zeit in unserem Netzwerk verteilt wurde. Leider gab die nichts her, da sie nur einmal erstellt und im Laufe der Zeit nicht gepflegt worden war – wie so oft.
Und wir suchten mit dem Windows-Administrator auf dem primären Domänencontroller (PDC) nach den entsprechenden Einträgen. In einer Gruppenrichtlinie wurden wir fündig. Zu unserer Überraschung stand dort nicht time.windows.com, wie man es vielleicht vom heimischen PC kennt, sondern ein mysteriöser Eintrag: timeserv01.
Zum Glück war die Inventarliste (CMDB) fast gepflegt, der Server sollte sich zu meiner Überraschung aber in einem Raum für die Etagenverteilung befinden. Eine Etage höher fanden wir timeserv01 schließlich, einen Windows XP Desktop-PC.
Dieser empfing das Zeitsignal über einen USB-Dongle und fungierte als Zeitserver für den PDC und damit für die Windows-Domäne und die angeschlossenen Systeme. Aber mit einem Neustart war das Problem nicht gelöst, denn auch danach schien das System keine korrekte Zeit auszugeben. Es blieb bei der Normalzeit.
Wenn der Behelf nicht mehr hilft
An dieser Stelle ein kleiner Exkurs zum DCF-77-Zeitsignal: Das DCF-77-Signal basiert auf mehreren Atomuhren und übermittelt die amtlich korrekte Uhrzeit für Deutschland. Das Langwellensignal wird von Mainflingen ausgestrahlt, einem Ort in Südhessen, der vermutlich am ehesten durch seine Sendeanlage bekannt ist, und hat von dort aus eine Reichweite von etwa 2.000 km – unter freiem Himmel.
An sich also eine gute Idee, dies als Quelle für die Uhrzeit von IT-Systemen zu verwenden. Um den Fehler zu verstehen, muss man technisch allerdings tiefer einsteigen.
Im DCF-77-Zeitsignal werden die Zeitinformationen – Jahr, Monat, Tag, Minute, Stunde, Normal- oder Sommerzeit – der jeweils nächsten Minute jeweils über die Dauer eine Minute digital kodiert. Hierfür kommt eine Amplitudenumtastung zum Einsatz, die das Signal zu Beginn einer jeden Sekunde entweder für 100 ms (0) oder für 200 ms (1) stark absenkt. Pro Minute können so 58 Bit übertragen werden.
Grob gesagt, muss der Empfang also mindestens eine Minute vorhanden sein, um ein Zeitsignal zu erhalten. Um zu überprüfen, ob auch die korrekte Zeit empfangen wird, erwartet die auf timeserv01 installierte Software für mindestens drei aufeinanderfolgende Sendeminuten eine konsistente Information, so wie auch viele Funkuhren. Erst dann erfolgt auch eine Umstellung der Uhrzeit.
Seit dem ersten Aufstellen des Servers hatten sich die äußeren Umstände verändert. Der Raum war voller Switches und Telefonleitungen, die Fenster waren speziell beschichtet. Auch rundherum waren zahlreiche bauliche Veränderungen durchgeführt worden. Es war vermutlich auch nicht hilfreich, dass das Kabel der Antenne nicht bis zum Fenster reichte.
Das führte dazu, dass immer mal wieder ein Bit als fehlend interpretiert wurde. All das konnte man wunderbar über die grafische Oberfläche der zugehörigen Software sehen. Damit stimmte die Prüfsumme nicht mehr und die Software verwarf die empfangene Uhrzeit. Vermutlich war dies bereits ein paar Jahre vorher passiert, weswegen das System ursprünglich eine Etage tiefer stand.
Da diese Zeitquelle die einzige im ganzen System war, hätte diesen Fehler auch kein Monitoringsystem auffangen können. Der Zeitserver war ja noch verfügbar, nur die Information war falsch. Daher gibt es zum Thema Zeit auch folgenden Ausspruch: "Ein Mann mit einer Uhr weiß nicht, ob diese richtig geht. Ein Mann mit zwei Uhren kann nie sicher sein, welche der beiden die korrekte Uhrzeit anzeigt."
Problem gelöst?
Damit war der Fehler gefunden und wir waren zumindest etwas erleichtert. Es war bereits Mittag. Zwischenzeitlich war als Workaround auf dem PDC die Uhrzeit händisch gesetzt worden. Bis sich diese Änderung aber durch die gesamte Domäne "geerbt" hatte, dauerte es noch Stunden, bei einigen Systemen auch Tage.
Der timeserv01 wurde im Anschluss verschrottet. Es wurde entschieden, mehrere Zeitserver im Serverraum aufzubauen, die mit jeweils unterschiedlichen Zeitquellen – zum Beispiel DCF 77, GPS – über eine Dachantenne gespeist wurden. Von da an gab es nie wieder Probleme mit der Zeit im Netzwerk.
Ähm, leider nein. Die Rubrik heißt schließlich Worst Practice. Der timeserv01 wurde nicht verschrottet, sondern eine Etage höher gebracht und exakt so wiederaufgebaut. Siehe da: Die Zeit konnte wieder wunderbar empfangen werden.
Offenbar war die Signalstärke ein paar Meter weiter oben besser. Es bestand also gar kein Grund mehr, eine andere Lösung zu verfolgen. Fortan versorgte diese Maschine die Domäne mit der Uhrzeit und es wurde nie wieder darüber geredet oder etwas dokumentiert.
Heute würde ich protestieren
Als Azubi hatte ich weder das Wissen noch die Befugnisse, eine andere Lösung herbeizuführen. Natürlich fand die Behandlung des Problems schnell statt und war im Sinne eines Workarounds sicherlich auch erst mal akzeptabel.
Das vermutlich aber nicht zum ersten Mal aufgetretene Problem auf die nächste Generation zu schieben, ist aber nicht hinnehmbar. Sollte irgendein integraler Teil eurer IT-Architektur ein undokumentierter Server in einem Verteilerraum sein?
In meiner Berufslaufbahn kamen mir bisher einige solcher vermeintlichen Lösungen unter. Sei es der schnell in die Anwendung eingebaute Symlink, der auf irgendeine Netzwerkablage zeigt oder der Dreierverteiler im Serverrack.
Und wer kennt nicht den nächtlichen Neustart eines Servers, weil irgendeine Anwendung immer mal wieder abstürzt. Gemeinsam haben alle diese Krücken, dass jemand früher oder später darüber stolpern wird.
Ich verließ das Unternehmen anderthalb Jahre später und habe keinen Kontakt mehr. Vielleicht läuft dort heute noch der timeserv01. Ein paar Stockwerke gibt es schließlich noch und die Zeitumstellung soll ja ohnehin irgendwann abgeschafft werden.
Tobias Greifzu ist Fachadministrator in der öffentlichen Verwaltung. Er lebt und arbeitet in Thüringen und ist für die Abschaffung der Sommerzeit.
Dieser Text ist der erste aus einer Reihe von Geschichten, die wir von Lesern zu unserem Worst-Practices-Aufruf bekommen haben. Wenn ihr auch eine Geschichte loswerden wollt, schreibt uns gern unter dem Betreff "Worst Practices" an schreiben@golem.de.