Beruf

Die meisten Anwender an den 105 Workstations, die zu administrieren ich bei uns im Klinikum die Ehre habe, gehen nicht gerade pfleglich mit dem System um. Dazu gehört auch ein kontrollierter täglicher Reboot bei Windows-Systemen, einfach um viele Klippen zu umschiffen. Ich habe mittlerweile schon die krudesten Fehler gesehen, die daraus resultieren, daß ein System einfach eine Woche durchgelaufen ist (und in der Zeit exzessiv damit gearbeitet wurde). Die Ursachen müssen in den meisten Fällen nicht einmal Memory Holes im Windows-OS sein. Beispielsweise werden im Rahmen von Softwareverteilungen viele Updates bei Anwendungen durch Reboots bzw. bei Neuanmeldung eines Benutzers am System ausgelöst. Und wenn ein System niemals rebootet, bekommt es auch niemals Updates.

Aus diesem Grund habe ich mir ein kleines VBS gebastelt, welches folgende Aufgabe erledigt: Prüfe die aktuelle Uhrzeit des Systems und die Uptime. Liegt ersteres zwischen 00 und 06 Uhr und ist letzteres bei größer als 24 Stunden, so frage den Anwender, ob rebootet werden darf. Klickt der Anwender auf 'Nein' (weil er z.B. gerade bei einem sehr wichtigen Arbeitsschritt ist), so nerve frage ihn in Abständen von zehn Minuten immer wieder (auch wenn inzwischen 12 Uhr sein sollte). Sollte der Anwender die Dialogbox für 15 Minuten nicht beantworten, so reboote eigenständig.
Ist der Zeitpunkt oder die Uptime nicht wie oben angegeben, so soll natürlich nichts gemacht werden.
Die Reboot-Vorgang macht dasselbe wie ein "forced" Reboot, wie er z.B. nach Windows-Updates ausgelöst wird, wenn man sagt "Jetzt neu starten". Ein "unforced" Reboot hängt sich sehr oft noch an offenen Programmen auf.

Ich habe vorher im Netz geschaut, ob es schon vorhandene Scripts zu diesem Thema gibt, aber scheinbar wird dieses Problem immer durch Zusatzprogramme, die sich in die TrayBar legen, gelöst. Für mich ist jede zusätzliche Anwendung ein zusätzlicher Fehlerfall, darum vermeide ich dies am liebsten. Außerdem wird auf diesem Weg kein Speicher benötigt.
Apropos Speicher: Die regelmäßige Überprüfung geschieht aus Speicherspargründen per Cronjob Scheduled Task. Den Befehl, um diesen Taks zu erstellen, hänge ich unten mit an. Man kann natürlich auch dem Script eine Endlosschleife verpassen, und die Überprüfung auch so abfackeln. Aber bei meinem Arbeitsrechner benötigt die wscript-Umgebung 7 MB im Speicher, und bei einer Workstation mit 4 GB Memory sogar satte 100 MB (Warum?!).

Ennonymous hat neulich über Cacti geschrieben, da dachte ich, ich streu mal noch etwas motivierenden Zucker, was man so alles damit machen kann. Die Graphen bitte anklicken, um sie in ihrer korrekten Größe zu sehen.



Hier ist sehr gut der Verlauf bei einem Authentifizierungs-Server zu sehen. Wie man sieht liegt die Hauptarbeitszeit der Nutzer in der Mitte des Tages, also ca. um 12:00 Uhr. Der 26. und 27. waren Wochenendtage, wo nur leichte Anstiege zu verzeichnen sind.

Die insgesamt 120 Workstation, die später die Clients für das PACS spielen werden und an denen unter anderem die Radiologen dann die Röntgen-, CT-, MRT- oder andere Bilder befunden werden, sind getrennt von den Grafikkarten angeliefert worden. Da jede Workstation bis zu fünf (meistens aber zwei oder drei) Displays zur Ausgabe bekommt, heißt das ordentlich Grafikkartenstöpselei. Der Müll, der bei so etwas anfällt, sei im folgenden präsentiert:



Das ist die Hälfte des Haufens für Lübeck.

Dieses Blog muss reaktiviert werden. Diese Maxime habe ich mir auf die Fahnen geschrieben. Den Anfang soll ein knapper Artikel über die momentane Arbeitssituation bei mir in der Firma machen.

Bedingt durch das aktuelle Großprojekt ist die Stimmung im Büro allgemein sehr gehetzt und gestresst. Am 2.1.08 soll das neue Krankenhaus-Informations-System online gehen. Zur Verdeutlichung: Ein komplettes Krankenhaus, verteilt auf zwei große Campi in zwei Städten, mit ungefähr 10.000 Mitarbeitern stellt die gesamte EDV um. Einige Systeme bleiben zwar bestehen, werden aber an das neue KIS angebunden, weswegen man von 'komplett' guten Gewissens sprechen kann.

Da es keine nennenswerten Neueinstellungen gab, müssen alle Mitarbeiter (rund 80) in der IT nun neben dem Routinejob auch die Installation, Konfiguration und Vorbereitung des neuen Systems mit erledigen. Glücklicherweise leistet die Firma, die das System anbietet, den Löwenanteil. Jedoch genügt die Restarbeit, um alle zum Schwitzen zu bringen.

Für meine Person heißt das neue System: An der Einrichtung von 10-15 neuen Servern beteiligt zu sein, und die Aufstellung von 120 Clients auf zwei Campi (ergo in zwei Städten, ergo viele Diestreisen) zu managen, von der Installation bis zur Aufstellung. Was das im Detail heißt, möchte ich in den folgenen Artikeln noch näher erläutern.

Es genügt für den Moment zu sagen: Dank Telefon-(Hotline-)Dienst diese Woche habe ich insgesamt 57 Arbeitsstunden abgeleistet. Angenehm ist was anderes. Aber es ist all-in-all durchaus spannend.

Die letzten Wochen bersteten vor privaten Aktivitäten und Terminchen, und auch auf der Arbeit ist momentan reichlich zu tun. Zur Erinnerung: Das Krankenhaus, in dem ich arbeite, will zum Jahreswechsel ein komplett neues Informationssystem für all ihre Patientendaten, etc. einführen. Ein echtes Mammutprojekt, in das ungefähr 100 Personen direkt durch die Einrichtung und Inbetriebnahme und tausende Angestellte indirekt als Anwender involviert sind. Und mittlerweile habe auch ich als Hardware-Administrator des neuen PACS, des Teils des Systems, das Bilddaten aus CTs, MRTs, etc. speichert, die erste Hardware vor der Bürotür stehen. Davor haben aber die Götter die Routine gesetzt: Das alte System wurde vorletzte Woche noch einmal upgedated, was zu einem abendlichen Ausfall und zu vermehrten Überstunden bei der EDV-Belegschaft führte. Da ich an diesem Tag Frühdienst hatte, war ich satte 16 Stunden auf der Arbeit, von 6:15 bis 22:30 Uhr. An dem Abend war ich mehr als erledigt.

Montag und Dienstag diese Woche befand ich mich in Oldenburg auf einer Schulung, was mir wieder eine gute Ausrede verschafft, warum ich länger nichts geschrieben habe. Die Vorträge waren höchst interessant, und ich fühlte mich in die Zeit meines Studiums versetzt, als ich noch die ganze Woche das Glück hatte, dersolchen zu lauschen. So waren die zwei Tage auch trotz des frühen Aufstehens um 04:30 Uhr am Montag fast wie Urlaub: Gemütlich im Vorlesungsraum sitzen, Abends ein wenig durch eine fremde Stadt schlendern und dann im Hotel abhängen. Und am nächsten Morgen ein reichhaltiges Frühstück.

In der Schulung selbst ging es um den Bereich DICOM. Dabei handelt es sich um eine Art Protokollsprache zwischen Modalitäten wie CTs oder MRTs und dem Bildarchivierungssystem PACS. Wie man sich leicht vorstellen kann, benötigt es eines vernünftigen (Quasi-)Standards, damit die zahlreichen Modalitäten verschiedenster Hersteller und die verschiedenen PACS-Systeme miteinander komunizieren können. Der DICOM-Standard liefert diese Funktionalität.

Ein Beispiel: Ein Tomographiegerät soll eine ganze Serie von Bildern liefern, da ein Patient sich den Arm gebrochen hat. Zuerst werden daher die Patientendaten eingeben, was entweder per Hand an der Modalität geschehen kann (wohl kaum noch) oder auf digitalem Wege durch ein Informationssystem, vielleicht ein RIS (Radiologie-IS). Die MTA positioniert den Patienten im Tomographen und stößt die Untersuchung an. Das Gerät erkennt dann die Position und schießt eine ganze Serie von Bildern, die es danach auf bestimmte Weise im DICOM-Format kodiert. Entweder werden die unkomprimierten Pixeldaten einfach so mit den Patientendaten, Aufnahmezeitpunkt, Modalitätsname, etc.pp. im Header verknüpft oder die Bilder werden noch vorher beispielsweise in JPEGs komprimiert, was verlustfrei (z.B. Lauflängenkodierung) oder verlustbehaftet (näheres in JPEG) geschehen kann. Der Bilderstrom wird schließlich über das LAN ans PACS geschickt.

Dummerweise ist der Standard DICOM ein ziemlich weicher Standard. DICOM selbst deckt nämlich extrem viele Funktionalitäten in Form von sogenannten Diensten ab. Und nicht jedes Gerät, das sich DICOM-Konformität auf die Fahnen schreibt, muss wirklich alle Dienste beherrschen, um DICOM-konform zu sein. Ist ja auch sinnvoll: So muß eine Modalität kaum den DICOM-Druckdienst anbieten, wenn sie nicht drucken kann. Jedoch gibt es auch innerhalb der Header-Segmente innerhalb der DICOM-Klassen bestimmte Segmente, die Modalitäten nicht implementieren müssen. Einzig vorgeschrieben ist daher, daß jedes Gerät, das sich DICOM-konform nennt, ein sogenanntes "Conformance Statement" mitführt. Dies ist ein Paper von ungefähr zwanzig Seiten Länge, wo genau aufgeführt ist, was an DICOM-Diensten und Header-Segmenten unterstützt wird und was nicht. Und wenn man selbst als Firma beispielsweise ein neues PACS einführt, muß man selbst genau darauf achten, ob das PACS sich auch mit allen Modalitäten unterhalten kann. Ergo: Haufenweise Conformance Statements wühlen.