Pannen beim Rollout neuer Applikationen, Versionen, Betriebssystem-Patches oder -Hotfixes sind der Albtraum jedes IT-Verantwortlichen, bedeuten sie dch auf alle Fälle Kosten und beim Ausfall geschäftskritischer Systeme auch einen Imageschaden. Der Grund für solche Störungen liegt meist in den Inkompatibilitäten zwischen der neu installierten Software und der existierenden Umgebung. Derzeit hat ein durchschnittliches Unternehmen zwischen 400 und 15.000 Softwarepakete einschließlich unterschiedlicher Versionen der gleichen Software, Patches, Hotfixes, Betriebssystem-Updates etc. im Einsatz. Probleme beim Rollout neuer Applikationen sind somit geradezu programmiert.

Genau aus diesem Grund wird Qualitätssicherung beim Ausrollen neuer Softwarekomponenten immer wichtiger. Ein Beispiel: In einem Großunternehmen sollte eine verhältnismäßig kleine Applikation neu installiert werden, die automatisch einen Mail-Footer erzeugt - an sich eine relativ triviale Angelegenheit. Man hatte allerdings nicht bedacht, dass eine Bestellkomponente, die in den Vertriebsstellen eingesetzt wird, vom Mail-System als Kommunikationskomponente benutzt wird.

Verhängnisvolle Konflikte

Die neue Kombination ist zwar zuvor analysiert worden, aber es war nicht bekannt, dass die Bestellkomponente eine bestimmte Dynamic Link Library (DLL) aus dem MAPI-Interface nutzt, die jedoch durch die Mail-Footer-Applikation verändert wurde. Die Folge war, dass die Bestellkomponente eine Woche lang nicht funktionierte. Die durch den Ausfall entstandene materielle Einbuße ließ sich zwar ermitteln, nicht bezifferbar dagegen war der Imageschaden. Mit einer entsprechenden Analyse (oder einem Test) hätte man diese Abhängigkeit bereits im Vorfeld erkennen und beseitigen können. Ein weiteres Beispiel sind Börsenplätze oder international operierende Call-Center. Wenn dort Handelssysteme über Stunden nicht verfügbar sind, entstehen extreme finanzielle Schäden.

Vermeiden lassen sich solche Pannen nur durch wirksame Maßnahmen zur Qualitätssicherung im Vorfeld des Rollouts, also durch Untersuchungen, ob und wie Softwarepakete sich gegenseitig beeinflussen. Zu reduzieren beziehungsweise vermeiden sind derartige Konflikte durch das so genannte Glass Box Testing, bei dem zwischen statischer (White Box Testing) und dynamischer Analyse unterschieden wird.

Statische Analysen haben in jüngerer Vergangenheit zweifellos die Qualitätssicherung beim Rollout verbessert und die Kosten gesenkt. Bei dieser Technik wird in der Regel das Installationspaket analysiert, wobei man davon ausgeht, dass der Softwarehersteller das Standard-Installationspaketformat MSI von Microsoft verwendet. Dieses Format ist dokumentiert und offengelegt. Allerdings findet je nach Unternehmen nur bei etwa 75 bis 95 Prozent der erwähnten Softwarepakete das MSI-Format Verwendung. Fünf bis 25 Prozent der Installationspakete setzen Non-MSI-Installer ein.

Analyse der MSI-Installer

Im besten Fall wird der MSI-Installer in einer Weise verwendet, die mehr oder weniger vollständig analysierbar ist. Vollständig meint hier, dass ausschließlich Installer-Aktionen genutzt werden, etwa das Kopieren von Dateien durch den Installer, Änderungen an der Registry und die Vergabe von Berechtigungen. In diesem Fall müsste man die Applikation nicht real installieren, es würde genügen, die MSI-Datei mit Hilfe eines Tools zu analysieren. Sämtliche Veränderungen wären in einem Application-Fingerprint enthalten.

So viel zur Theorie. In der Praxis enthalten allerdings zwischen 25 und 55 Prozent der MSI-Installer so genannte Custom Actions, die während der Installation aufgerufen werden. Damit lassen sich beliebige Dateien ansprechen. Das können exe-Dateien sein, aber auch ein weiteres Installer-File (geschachtelte MSI) oder eine Batch-Datei. Alles, was unter einem Windows-Betriebssystem ausführbar ist, kann durch den Installer aufgerufen werden.

An dieser Stelle beginnt die Crux: Executables und andere Binärdateien können - technisch bedingt - nicht analysiert werden. Damit tut sich in der Analyse die erste Lücke auf, da man nicht vollständig feststellen kann, wie eine Installation das System beeinflusst.

Die zweite Lücke beginnt mit dem ersten Start einer neuen Applikation. Dabei werden von der Applikation oft selbst noch Einträge in der Registry vorgenommen, weitere Dateien auf das System kopiert oder Berechtigungen geändert. Alle diese Vorgänge lassen sich mit rein analytischen Verfahren technisch bedingt nicht erfassen. Ein Applikations-Monitoring ist nötig, um solche Veränderungen zur Laufzeit der Software feststellen zu können.

Wenn kein MSI-Format vorliegt

Das nächste Problem, mit dem die analytischen Methoden in der Realität zu kämpfen haben, ist die Tatsache, dass zwischen fünf und 25 Prozent der Softwarepakete nicht im MSI-Format vorliegen. Theoretisch ist es zwar möglich, die verwendeten Batch- oder Script-Dateien auf ihr Verhalten gegenüber dem Zielsystem zu analysieren, aber der Aufwand, Pseudo-Interpreter für all diese unterschiedlichen Skriptformate zu schreiben, steht in keinem vernünftigen Kosten-Nutzen-Verhältnis. Diese Überlegungen führen zu einem Schluss: Bei der statischen Analyse ist der Anwender an ein bestimmtes Format gebunden, er muss mit einigen "schwarzen Löchern" leben und weiß nicht exakt, was die Applikation bei der Installation, beim ersten Starten oder zur Laufzeit tut. Der Application-Fingerprint ist in vielen Fällen unvollständig.

Verschärft werden diese Probleme durch die Themen Virtualisierung und Cloud Computing. Der Anteil virtualisierter Applikationen liegt momentan zwischen 15 und 55 Prozent des gesamten Applikationsportfolios - mit steigender Tendenz. In zunehmendem Maße werden auch Desktops virtualisiert, die dann entsprechende Anwendungssoftware benötigen. Dabei muss sichergestellt sein, dass diese Applikationen, auch in unterschiedlichen Versionen, auf den physischen oder virtuellen Desktops kollisionsfrei nebeneinander laufen. Wird beispielsweise ein Hotfix ausgerollt, das eine Sicherheitslücke im Betriebssystem schließen soll, muss der IT-Verantwortliche sicher sein, dass die gesamte Installation auch nach dem Rollout reibungslos funktioniert.

Grenzen der statischen Analyse

In diesem Kontext stoßen statische Analyseverfahren vollends an ihre Grenzen, denn virtuelle Applikationen lassen sich mit statischen Methoden nur teilweise analysieren, nie aber vollständig. Besondere Aufmerksamkeit verdienen geschäftskritische Applikationen, die häufig als Fachanwendungen mit unternehmensspezifischen Erweiterungen im Einsatz sind. Gerade hier sind die Installationsvorgänge und Abhängigkeiten von hoher Bedeutung.

Die logische Konsequenz ist ein physikalischer Test, der auch mögliche Konflikte wie Probleme mit Benutzerberechtigungen oder Konflikte beim Zugriff auf Ressourcen aufdecken kann. Hier greift die dynamische Analyse; treffender wäre eigentlich die Bezeichnung "dynamischer Test".

Bei einer dynamischen Analyse wird die Applikation real in einer definierten Umgebung installiert. Damit ist der Test vollkommen unabhängig vom eingesetzten Installer, die Ergebnisse bei MSI-Installern sind ebenso zuverlässig wie die bei Non-MSI-Installern. Der grundsätzliche Unterschied zur statischen Analyse besteht darin, dass hier das tatsächliche Ergebnis einer Aktion betrachtet wird und nicht die Installer-Komponente, die eine Aktion anstößt. Das Ergebnis ist eine 100-prozentige Testabdeckung.

Den Veränderungen auf der Spur

Für die weitere Untersuchung gibt es nun zwei Möglichkeiten. Die erste besteht darin, einen Base-Snapshot des "jungfräulichen" Systems aufzunehmen, die Applikation zu installieren und zu starten, dann einen zweiten Snapshot zu erstellen und beide miteinander zu vergleichen, also eine Differenzmenge zu ermitteln. Diese Vorgehensweise hat jedoch einen gravierenden Nachteil: Aufgrund der großen Datenmengen muss man mit erheblichen Laufzeiten rechnen.

Die zweite, zeitsparende Alternative besteht darin, die Applikation durch einen so genannten Agent während der Installation auf die vorgenommenen Änderungen hin beobachten zu lassen. Der Agent protokolliert, welche Dateien tatsächlich in das Sys-tem geschrieben, welche Registry-Einträge vorgenommen werden und was generell am Betriebssystem verändert wird. Damit erhält man ein exaktes Abbild der Modifikationen, die die Applikation während der Installation und beim ersten Start vorgenommen hat. Hier versagen natürlich die rein analytischen Methoden, da sie an dieser Stelle technikbedingt "blind" sind.

Der erwähnte Agent, der die Änderungen am System aufzeichnet, muss selbstverständlich möglichst portabel konzipiert sein, so dass er selbst keine Modifikationen am System vornimmt, die dann eventuell dem Fingerprint der Applikation zugerechnet werden.

Bei dieser Methode wird jede in Frage kommende Applikation einmal gegen das Betriebssystem getestet und so ein spezifischer Application Fingerprint erzeugt, der dann in ein Repository geladen werden kann. Durch das Vergleichen dieser Fingerprints lassen sich nun potenzielle Konflikte ermitteln.

Um nichtrelevante Konfliktmeldungen zu unterdrücken, wird der Test durch ein lernfähiges Expertensystem unterstützt. Es enthält einen vorkonfigurierten Regelsatz, kann aber ebenso bestimmte Ausnahmen lernen, die nicht relevant für die Funktion des Betriebssystems oder der Applikation sind. Ebenso lassen sich Include-Filter definieren, die dem Testsystem mitteilen, nur bestimmte Teile der Registry, des Dateisys-tems oder auch nur bestimmte Dateien zu betrachten. Damit lässt sich das Datenvolumen des OS-Snapshots reduzieren, schließlich nimmt der Snapshot einer aktuellen Windows-7-Version mit allen Patches rund 500 MB in Anspruch. Der Fingerprint eines SAP-GUI ist rund 200 MB groß, immerhin werden hier rund 750.000 Änderungen gespeichert.

Abschätzen des Konfliktpotenzials

Im weiteren Verlauf wird eine Konfliktmatrix erstellt, die zeigt, zwischen welchen Applikationen es Schnittmengen gibt, die Konfliktpotenzial bergen. Benötigen beispielsweise zwei Applikationen gleiche DLLs, allerdings in unterschiedlichen Versionen, besteht die Gefahr eines Konflikts. Es lässt sich so zwar nicht zu 100 Prozent prognostizieren, dass es tatsächlich zu Konflikten kommt, man hat aber einen Ansatzpunkt für zusätzliche Tests.

Deren Ergebnisse fließen wiederum in die Wissensbasis zurück, auf die in späteren Fällen ohne weitere Tests zurückgegriffen werden kann. Dabei ist es vollkommen gleichgültig, ob es sich um Applikationen, Patches, Hotfixes oder unterschiedliche Versionen des Betriebssystems handelt. Mit zunehmender Größe und Aktualität der Wissensbasis verringert sich der zeitliche Aufwand bei der Bewertung von Problemstellungen. Die automatische Bewertung durch Erkennung bekannter, ähnlicher Situationen unterstützt und verkürzt die Entscheidungsfindung und sorgt für eine höhere Qualität der Entscheidungen.

Virtualisierung verlangt Qualität

Die Erfahrungen der jüngeren Vergangenheit zeigen, dass der Trend zur Virtualisierung der IT-Landschaft geht, und zwar in Form von Basis-Arbeitsstationen verbunden mit einer definierten OS-Umgebung einschließlich einiger Zusatzkomponenten wie etwa einer Java-Runtime-Umgebung. Die benötigten Applikationen sucht sich der Anwender aus einem Shop-System (Private Cloud) seines Unternehmens nach Bedarf aus. Dazu ist es aber Voraussetzung, dass im Shop nur solche Applikationen angeboten werden, die nachweislich kein Konfliktpotenzial in sich bergen. Dieser Nachweis lässt sich mit einem sinnvollen technischen und wirtschaftlichen Aufwand nur durch dynamische Analysen, also durch physikalische Tests in Verbindung mit einem Repository, führen. Damit liegt der Zeitrahmen, in dem qualitätsgeprüfte Applikationen an den Anwender ausgeliefert werden können, im Bereich von wenigen Stunden. Das entspricht etwa der Zeit, die man für die Bereitstellung benötigter Hardwareressourcen aus der Cloud gewöhnt ist. (ph)