COMPAREX AG
Testen am Produktivsystem (Header)

Testen am Produktivsystem? Das geht wirklich?

Der eine hat sie, der andere wünscht sie sich. Eine Testumgebung, in der Veränderungen an Systemen vorab überprüft werden können. Denn der produktive Betrieb der für das Unternehmen kritischen IT-Systeme muss sichergestellt sein. Was würde da mehr helfen als eine Infrastruktur zum Testen. Doch eine solche Infrastruktur bringt neben den Vorteilen auch einige Nachteile mit sich. Unser Fachexperte umreißt die Problematik und zeigt auf, wie sich mit der Cloud ein vielversprechender Lösungsansatz bietet.

Ein Blogbeitrag von Eric Berg, IT-Architekt und Microsoft MVP

In der Regel müssen für eine separate Testumgebung auch entsprechende Hardware sowie Lizenzen vorgehalten werden. Daher machen Test-Infrastrukturen einen nicht unerheblichen Anteil am Budget eines Unternehmens aus. Zudem bedarf es der Pflege des Systems. So müssen Server gewartet, Updates eingespielt und Backups geprüft werden. Alles in allem also ein nicht zu unterschätzender Aufwand - doch wofür eigentlich?

Testen am Produktivsystem: Visualisierung

Je nach Umgebung und Anwendungsfall werden Testumgebungen mehr oder weniger intensiv genutzt. Zum Teil werden Systeme wie virtuelle Server nur selten verwendet, beispielsweise für wenige Stunden während der regulären Arbeitszeiten. In anderen Fällen, beispielsweise vor der Einführung eines neuen Software-Releases, kann die Nutzung der Systeme entsprechend ansteigen. Gerade User Acceptance Tests, womöglich auch noch global, setzen die Infrastruktur unter Last.

Das Problem: Testumgebung ist nicht gleich Testumgebung

Obwohl so viel getestet wird, geht von Zeit zu Zeit etwas schief. Ein Update führt nicht zum gewünschten Ergebnis, eine Software funktioniert nicht mehr wie gewünscht oder es gibt unerwartete Nebeneffekte. In diesen Momenten denkt sich der Endanwender: „Warum haben die das nicht getestet?“

Genau an dieser Stelle liegt das Problem. Ein Test ist ein Test und bleibt ein Test. In der Regel sieht eine Testumgebung nie exakt gleich der Produktivinfrastruktur aus. Dies ergibt sich schon durch die Ressourcenanforderungen, die verwendete Hardware oder die Last auf den Systemen. Somit kann ein Test in einer solchen Infrastruktur auch nie alle Wahrscheinlichkeiten abfangen.

Nimmt man diese Faktoren nun zusammen, so stellt sich ein Test am Produktivsystem als Lösung heraus. Doch wie soll das realisiert werden?

Snapshots als Allheilmittel?

Im Zuge der Virtualisierung von Server-Ressourcen hat sich in vielen Unternehmen eine Vorgehensweise durchgesetzt: Vor einem Update oder einer Änderung am Produktivsystem wird ein Snapshot des virtuellen Servers angelegt. Somit kann im Falle eines Fehlers auf den gespeicherten Zustand des Systems zurückgegriffen werden und der Betrieb wird fortgesetzt.

Doch diese Vorgehensweise birgt einige Tücken. Einer der häufigsten Fehler hierbei ist, dass Snapshots nach dem Update nicht wieder bereinigt werden. Je nach verwendetem Hypervisor kann es nun zu mehr oder weniger großen Hürden kommen. So ist beispielsweise das Volllaufen der Speichersysteme ein bekanntes Problem, da nach einem Snapshot differenzierende Daten separat abgespeichert werden.

Testen am Produktivsystem: Snapshot der Speichersysteme 

Abb. 1: Nach einem Snapshot laufen Speichersysteme schnell voll.

Aber auch im System selbst kann es zu Problemen kommen, stellt man sich zum Beispiel die Aktualisierung eines Systems mit Querverbindungen zu weiteren Systemen vor, beispielsweise ein ERP System, das beim Update auch eine Aktualisierung der Datenbank durchführt. Nun muss also zum erfolgreichen Rollback des Systems nicht nur das ERP System, sondern auch die Datenbank aus einem Snapshot wiederhergestellt werden.

Nicht zu vergessen sind hierbei auch Einflüsse wie physische Systeme, unterschiedliche Hypervisor und Lastzustände. Snapshots können also helfen, sind aber nicht die Allzweckwaffe für Test-Szenarien.

Die Lösung: Eine Kopie des Produktivsystems in der Cloud

Eine mögliche Lösung für diese Zwickmühle zwischen ungenauem Testsystem und riskantem Speil am offenen Herzen ist eine Kopie des Produktivsystems. Mit Hilfe von Replikationsmechanismen wird eine 1:1 Kopie des Systems in einer anderen Infrastruktur angelegt. Anstatt hier nun wieder auf eine teure und Wartungsintensive On-Premises Infrastruktur zurückzugreifen, bedient man sich der Flexibilität der Cloud.

 Testen am Produktivsystem: Replikation des Systems in die Cloud
Abb.2: Durch Replikationsmechanismen wird das System in die Cloud kopiert. Quelle: Microsoft

Die Replikation erfolgt beispielsweise nach Azure. Hier können die replizierten Systeme dann zu Testzwecken in Betrieb genommen werden. Da sowohl physische als auch virtuelle Systeme unterschiedlicher Hypervisoren übernommen werden können, lässt sich eine nahezu identische Infrastruktur bereitstellen. Nun können Tests am Produktivsystem vorgenommen werden, ohne das Produktivsystem zu beeinflussen.

Hierbei lassen sich neben den Infrastrukturkosten auch noch Betriebskosten sparen. Durch die Replikation der Systeme werden alle Änderungen, wie Updates und Co, am Produktivsystem auch in die Testwelt übernommen. Zudem können die Systeme zum Test eingeschaltet und anschließend wieder abgeschaltet werden. Aufgrund der minutengenauen Abrechnung von Ressourcen fallen hier also nur Kosten während aktiver Tests an.

Fazit

Testen an der produktiven Infrastruktur ist grundsätzlich möglich. Dank der Cloud wird dies flexibler und sicherer. Gleichzeitig lassen sich Kosten einsparen und neue Szenarien ermöglichen.

Sie benötigen weitere Informationen zu Testumgebungen in der Cloud?

Erfahren Sie, wie eine Testumgebung entspannt mit COMPAREX Azure Adapt gelingt und Sie so Geld und Zeit sparen.

Alle Infos zu COMPAREX Azure Adapt

Diesen Artikel teilen

Artikel vom:
23.08.2017

geschrieben von:

TAGS:
Azure Adapt, Cloud

Thema:

Kommentieren sie diesen Artikel...

© COMPAREX AG
Zurück nach oben