Validierung im Rechenzentrum (Teil 3)

Nach den ersten beiden Teilen (hier und hier) der Blogserie folgt nun der dritte und letzte Teil zum Thema Validierung in Rechenzentrum. Viel Spaß dabei!

Die Risikoanalyse
Jede Validierung erfordert eine Risikoanalyse. Aber was ist überhaupt ein Risiko? Ein Risiko tritt ein, wenn ein System gewissen Gefahren ausgesetzt ist. Zu jeder Gefahr lassen sich die Eintrittswahrscheinlichkeit und der Schaden ermitteln. Diese Kennzahlen können mit  verschiedenen Einheiten angegeben werden. In unserem Rechenzentrum genügt nach Absprache mit externen Prüfern die Klassifizierung in die Risikoklassen gering / mittel / hoch.

Das Risiko selbst ergibt sich dann nach folgender Formel: Risiko = Eintrittswahrscheinlichkeit × Schaden

Die Ergebnisse der Multiplikation werden in der Spalte „Kritikalität“ hinterlegt und sind wie
folgt definiert:

Eine Herausforderung der Risikoanalyse ist die Bewertung von Auftrittswahrscheinlichkeit und Auswirkung. Es gibt diverse Normen, die sich mit dem Thema „Risikomanagement“ befassen und in unserem Rechenzentrum zum Einsatz kommen. Unsere Zertifizierung gemäß ISO 27001
und unser Qualitätsmanagement nach ISO/IEC 20000-1 erfordern ein Risikomanagement. Projektmanagement-Empfehlungen (z. B. der GPM, IPMA) oder DIN 69901 beschreiben ebenfalls Vorgehen und Prozesse, u. a. für die Bewertung von Wahrscheinlichkeiten und Auswirkungen.

Ziel der Risikoanalyse ist es, Maßnahmen zur Reduzierung der Risiken zu ergreifen. Dazu müssen zunächst die Risiken vollständig benannt werden. Risiken zurückzuhalten ist nicht zielführend, weil das Risiko damit nicht ausgelöscht wird. Auch im Kundenkontakt ist es sinnvoller, Risiken offen anzusprechen und ergriffene Maßnahmen offensiv zu kommunizieren.

Die Liste der Risiken ist nie vollständig. Neue Risiken kommen mit neuen Techniken oder veränderten Prozessen hinzu. Externe Einflussfaktoren (z. B. Gesetze, Richtlinien) ändern sich. Um ein möglichst umfassendes und aktuelles Bild zu erhalten, diskutieren wir die Risiken regelmäßig im Expertenteam. Dabei werden neue Risiken erkannt und mögliche Gegenmaßnahmen besprochen. So umfasst unsere Risikoanalyse für die Monitoring-Landschaft inzwischen über 70 Gefahren. Einige Risiken haben wir als „kritisch“ eingestuft, dazu zählen neben technischen Gefahren auch:

• Verstöße gegen das Change Management
• Mängel im laufenden Betrieb

Der Installationsplan
Der Risikoanalyse folgt der Validierungsplan. Ist dieser erstellt, folgt der Installationsplan, der sich ebenfalls an der Anforderungsspezifikation orientiert: Er beschreibt die Installation jeder einzelnen Komponente. Der Plan selbst dient als Checkliste, die Vorgaben zur Installation sind
dem Lastenheft zu entnehmen.

Da wir im Rahmen unserer Monitoring-Landschaft mehrere Systeme aufsetzen, müssen einige im Installationsplan definierte Arbeiten im Rahmen der Installation auf jedem System durchgeführt werden. Im Plan beschreiben wir diese Schritte nur einmal, das später anzufertigende
Protokoll enthält jedoch für jedes einzelne System ein Ergebnis.

Die Testanleitungen
Nach dem Installationsplan werden die Testanleitungen erstellt.
Häufig werden die Testpläne dabei als Kontrolle angesehen, ob Systeme richtig installiert wurden. Dies ist allerdings eine Fehlinterpretation. Mit den Tests soll verifiziert werden, dass die Systeme einsatzbereit sind und den Anforderungen genügen. Bei solch komplexen Systemen wie
der beschriebenen MAI-Monitoring-Landschaft können immer einmal Probleme auftreten oder Fehler gemacht werden. Tests bieten da eine letzte Chance, Korrekturen vor dem Go-Live vorzunehmen.

So stellen unsere Testanleitungen zum einen sicher, dass die installierten Systeme der Anforderungsspezifikation genügen. Andererseits berücksichtigen sie aber auch die in der Risikoanalyse aufgeführten Kontrollen und Tests. Beide zuvor erstellten Dokumente, Anforderungsspezifikation und Risikoanalyse, finden hier also Verwendung.

In der Testanleitung werden einzelne Testschritte aufgeführt. Für jeden Schritt ist anzugeben, ob er direkt erfüllt werden konnte oder ob zuvor noch Korrekturen vorgenommen werden mussten. Diese Anpassungen werden im Rahmen des Testprotokolls dann genauer beschrieben. Testprotokolle können die Wissensdatenbank mit Fehlern und Lösungen anreichern. Es ist daher unbedingt erforderlich, Tests nicht als Kontrolle der eigenen, individuellen Arbeit zu sehen, sondern als Abnahme eines bereitgestellten Systems. Mit den Testanleitungen ist der Planungsprozess abgeschlossen – nun folgt die Umsetzung der Validierung. Und die startet mit der Installation.

Die Installation
Die Installation der MAI Monitoring-Landschaft erfolgt auf Basis des Lastenheftes und des Installationsplans.

Die Systeme sind mittels VMWare virtualisiert und werden über eine Software-Verteilung installiert. Wir setzen dazu die HP Software Automation Suite (HPSA) ein. Erst wenn unser Servermanagement-Team alle erforderlichen Dokumentationen erstellt hat, liefert die HPSA ein bereits valides Betriebssystem.

Eine weitere Herausforderung ergibt sich aus der VMWare-Landschaft. Der Betrieb von virtualisierten Systemen muss ebenfalls den Anforderungen der Validierung genügen. Die dazu erforderlichen Dokumente werden derzeit erarbeitet.

Testprotokolle und Validierungsbericht
Ist die Validierungslandschaft installiert, so werden die einzelnen Systeme anhand der Testpläne geprüft und abgenommen. In den Testprotokollen wird vermerkt, ob es zu Abweichungen bei den Testergebnissen gekommen ist und welche Korrekturmaßnahmen ggf. ergriffen wurden. Wenn all diese Tests abgeschlossen sind, werden die Dokumente unterschrieben und archiviert. Diese Aktivitäten stehen dann ebenfalls noch für die Produktivlandschaft an, bevor die Systeme letztlich ihrer Bestimmung übergeben werden. Sämtliche Testprotokolle werden in einem Validierungsbericht zusammengefasst. Danach ist die Validierung unserer MAI-Monitoring-Landschaft abgeschlossen.

Was ist bei Änderungen zu tun?
Wenn nach Freigabe von Dokumenten, z.B. der Anforderungsspezifikation, noch Änderungen nötig werden, werden solche Nacharbeiten als Change dokumentiert, getestet und abgenommen.

Die Verwaltung der Dokumente
Die Validierung erfordert eine revisionssichere Ablage der verschiedenen Dokumente, denn diese müssen insbesondere vor Änderungen geschützt werden. Deshalb werden die Dokumente üblicherweise ausgedruckt, unterschrieben und an einem sicheren Ort archiviert.

Die Dokumente liegen zunächst in elektronischer Form vor. Über eine geschickte Namensgebung gewährleisten wir die Wiederauffindbarkeit und eine gewisse Strukturierung der Dokumente. In größeren Projekten, die viele Dokumente umfassen, stellt dies eine echte Herausforderung
dar: Der Überblick geht schnell verloren, zumal Dokumente nach und nach erstellt und teilweise laufend angepasst werden. Zur Namensgebung tritt also noch die Versionierung hinzu. Im Rahmen unserer Validierung werden die Dokumente mit einer Nummer versehen, die sich auf das Validierungsmodell bezieht.

Eine softwaregestützte Dokumentenverwaltung (DMS) ist hier sehr hilfreich. Es ist jedoch darauf zu achten, dass die Dokumente revisionssicher abgelegt sind, um den Anforderungen der diversen Zertifizierungen (z.B. ISO 20000-1) gerecht zu werden. Mittels  elektronischer Unterschriften lassen sich im DMS abgelegte Dokumente finalisieren und gegen künftige Änderungen schützen. Dadurch wird der Umfang der auszudruckenden Dokumente reduziert.

– Rainer Kunert, itelligence Outsourcing & Services GmbH –