Sind die Risiken noch beherrschbar?

Die Autoren sind QA-Spezialisten bei der Mentopolis CSC GmbH. Pannen beim Rollout neuer Applikationen, Versionen, Betriebssystem-Patches oder -Hotfixes sind der Albtraum jedes CIOs, denn sie bedeuten auf jeden Fall Kosten. Beim Ausfall businesskritischer Systeme leidet nicht nur das Image, im schlimmsten Fall kostet es den Kunden. Der Grund für solche Störungen liegt meist in Inkompatibilitäten zwischen der neu installierten Software und der existierenden Umgebung. Derzeit hat ein durchschnittliches Unternehmen zwischen 400 und 15000 Software-Pakete im Einsatz, einschliesslich unterschiedlicher Versionen, Patches, Hotfixes, OS-Updates und so weiter. Probleme beim Rollout neuer Applikationen sind damit vorprogrammiert. Vermeiden lassen sich solche Pannen nur durch eine wirksame Qualitätssicherung im Vorfeld des Rollouts. Dazu muss geprüft werden, ob und wie die Software-Pakete sich gegenseitig beeinflussen. Beim «Glass box testing» wird zwischen statischer und dynamischer Analyse unterschieden (siehe Grafik 1).

Statische Analysen haben in jüngerer Vergangenheit zweifellos die Qualitätssicherung beim Rollout verbessert und die Kosten reduziert. Bei dieser Technik wird in der Regel das Installa­tionspaket analysiert, wobei davon ausgegangen wird, dass der Software-Hersteller das Standard-Installationspaketformat MSI von Microsoft verwendet. Dieses Format ist dokumentiert und offengelegt. Allerdings findet je nach Unternehmen nur bei ca. 75 bis 95 Prozent der Installa­tionspakete das MSI-Format Verwendung. Im besten Fall wird der MSI-Installer in einer Weise eingesetzt, die mehr oder weniger vollständig analysierbar ist. Mehr oder weniger vollständig heisst, dass ausschliesslich 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 mithilfe 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 sogenannte 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 Krux: Executables und andere Binärdateien können – technologisch 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 nicht erfassen. Um solche Veränderungen zur Laufzeit der Software feststellen zu können, ist ein Applikations-Monitoring nötig. Das nächste Problem, mit der die analy­tischen Methoden in der Realität zu kämpfen haben, ist die Tatsache, dass zwischen 5 und 25 Prozent der Software-Pakete 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 Script-Formate zu schreiben, steht in keinem vernünftigen Kosten-Nutzen-Verhältnis. Bei der statischen Analyse muss der Anwender daher mit einigen «schwarzen Löchern» leben: Er   weiss nicht exakt, was die Applikation bei der Installation, beim ersten Starten oder zur Laufzeit wirklich tut. Verschärft wird die Problematik durch vir­tuelle oder Cloud-Umgebungen. Der Anteil virtualisierter Applikationen liegt momentan zwischen 15 und 55 Prozent des gesamten Applikationsportfolios – mit steigender Tendenz. In diesem Kontext stossen statische Analyseverfahren vollends an ihre Grenzen, denn virtuelle Applikationen lassen sich mit statischen Methoden nur teilweise analysieren, nie aber vollständig. Besondere Aufmerksamkeit verdienen businesskritische Applikationen, die häufig als Fachanwendungen mit unternehmensspezifischen Erweiterungen im Einsatz sind. Gerade hier sind die Installationsvorgänge und Abhängigkeiten von grosser Bedeutung.

Die logische Konsequenz ist die Durchführung eines physikalischen Tests, der auch mögliche Konflikte wie Probleme mit Benutzerberechtigungen, Konflikte beim Zugriff auf Ressourcen etc. aufdecken kann. Hier greift die dynamische Analyse – treffender wäre eigentlich die Bezeichnung «dynamischer Test». Der Test ist damit vollkommen unabhängig vom eingesetzten Installer. 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össt. Das Ergebnis ist eine 100-prozentige Testabdeckung (siehe Grafik 2). Um irrelevante Konfliktmeldungen zu unterdrücken, wird der Test durch ein lern­fähiges Expertensystem unterstützt. Das Expertensystem 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 Test-system mitteilen, nur bestimmte Teile der Registry, des Dateisystems oder auch nur bestimmte Dateien zu betrachten. Im Weiteren wird eine Konfliktmatrix erstellt, die zeigt, zwischen welchen Applikationen es potenziell konfliktanfällige Schnitt­mengen gibt. 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, der Anwender hat aber einen Ansatzpunkt für zusätzliche Tests.

Die Erfahrungen der jüngeren Vergangenheit zeigen, dass der Trend zur Virtualisierung der IT-Landschaft (Cloud Computing) geht, mit Basis-Arbeitsstationen und einer definierten OS-Umgebung einschliesslich einiger Zusatzkomponenten wie einer Java-Runtime-Umgebung u.ä. Die benötigten Applikationen sucht sich der Anwender aus einem Shop-System seines Unternehmens nach Bedarf aus. Voraussetzung ist aber, dass im Shop nur solche Appli­kationen angeboten werden, die nachgewiesenermassen kein Konfliktpotenzial in sich bergen. Dieser Nachweis lässt sich mit einem sinnvollen technischen und wirtschaftlichen Aufwand nur durch dynamische Analysen führen, also durch physikalische Tests in Verbindung mit einem Repository.