© Excellent backgrounds/Shutterstock.com
Teil 2: Preproduction

Production-ready?


Im ersten Teil dieser Serie (siehe Java Magazin 11.2014) ging es um das Zusammenspiel zwischen Entwicklern und Betreibern rund um das Themengebiet des Loggings, und wir konnten aufzeigen, wie wichtig es bereits während der Entwicklung ist, gemeinsam zu arbeiten und sich abzustimmen. Dieses Mal werden wir uns mit der Phase der Produktionsvorbereitung beschäftigen. Die Entwicklung hat die benötigen Features und Storys umgesetzt und bereitet sich nun auf die Produktion vor. Was muss ein Team in dieser Situation leisten, um sicherstellen zu können, dass alle relevanten Schrauben korrekt sitzen? Welche Themen müssen berücksichtigt werden, und welche Tools kann man zur Unterstützung einsetzen?

Stellen wir uns folgendes Szenario vor: Ein Team hat mehrere Wochen/Monate an einem neuen, auf der grünen Wiese entstandenen Softwareprojekt gearbeitet und dabei jede für den Livegang relevante und abnahmepflichtige Story umgesetzt (Abb. 1). Was kommt nun? Was sollte passieren und was passiert üblicherweise?

arrasz_1.tif_fmt1.jpgAbb. 1: Reise durch die Entstehung (das Development) über die Stabilisierungs­phase der Preproduction bis hin zur Produktion

Zunächst wird die komplette Umgebung des Systems mit der zu erwartenden Last konfrontiert. Wichtig ist hierbei, alle Szenarien, die an einem Tag vorkommen können, abzudecken. Wie aber macht man das? Man erstellt Lasttests für alle Herausforderungen, die sich aus verschiedenen Szenarien ergeben (Beispiele s. u.). Hierbei entstehen, anders als bei menschlicher Interaktion, komplett andere Lastszenarien, die es sehr genau zu beobachten gilt.

Was hilft einem ein nächtlicher Batch-ETL-Job, der irgendwann so lange benötigt, dass die Nacht schlicht nicht mehr ausreicht, um alle Aufgaben zu verarbeiten? Die einzelnen Lasttests kann man einfach mit Tools wie JMeter erstellen (Abb. 2), automatisieren und pflegen. Fassen wir also die verschiedenen abzudeckenden Szenarien zusammen:

  • Durchschnittliche Last, über den Tag verteilt

  • Durchschnittliche Last, über den Tag verteilt, an Wochenenden

  • Feierabendlastspitzen

  • Guten-Morgen-Lastspitzen

  • Lastspitzen durch Werbung

  • Verhalten der Applikation bei Überlastung (Slashdot-Effekt)

  • Session Handling

arrasz_2.tif_fmt1.jpgAbb. 2: Beispielhaftes Apache-JMeter-Set-up

Tipp

Im Team sollten mittlerweile auch dringend Systemadministratoren oder DevOps vorhanden sein. Idealerweise ist ein Team von Beginn an cross-funktional aufgestellt (vgl. Teil 1 der Serie).

Nach den erfolgreich durchgeführten Tests sollte dieses Team die Sicherheit haben, dass das System die zu erwartenden Lastanforderungen im Betrieb erfüllt, inklusive eines Puffers.

Tipp

Sessions sind eine althergebrachte Technik zur Identifikation eines Users und seiner applikationsrelevanten Daten. Viele moderne Anwendungen werden auf Basis von Frameworks entwickelt, die „das Session Handling auch erledigen“.

Braucht man sie, erzeugt man sie pro Anwender und erst, wenn es unbedingt nötig ist, nicht mit dem ersten Aufruf des Systems, wie es oft üblich ist. Weiterhin ist es unabdingbar, die Größe einer einzelnen Session im Auge zu behalten, da Sessions leider viel zu oft als Ablage für beliebige Daten verwendet werden. Somit kann eine Session schnell ein paar Megabyte an Daten enthalten. Ein klarer Fall für Feedback an das Entwicklungsteam.

Im nächsten Schritt werden wir nun die Betriebsbedingungen genauer betrachten, um die Failover- und Load-Balancing-Mechanismen zu testen. Das Team sollte bereits seit einigen Wochen nächtliche Builds auf eine Stage-Umgebung installieren. Diese Stage sollte zwingend gleich der Produktion sein. Hier ist aber nicht die exakt gleiche Hardwareausstattung gemeint, sondern dass

  • die Konfiguration,

  • die Versionen der Systeme,

  • die aktivierten Module,

  • die Patchlevel,

  • die Firewalls und DMZs

gleich sind. Nachdem sich ein Team exakt das Produktionssystem auf dem erklärten Niveau erarbeitet hat, kann es nun gezielt daran gehen, Störungen zu erzeugen und das System dabei genau zu beobachten (Abb. 3):

arrasz_3.tif_fmt1.jpgAbb. 3: Beispielhafter Failover-Verlauf
  • Funktionieren alle Failover-Mechanismen wie erwartet?

  • Reagieren die Replikationsmechanismen wie erwartet?

  • Wie verhält sich die Last der Systeme bei Ausfall einzelner Systeme bzw. Verbindungen?

  • Erreichen wir den gewünschten Durchsatz des Systems (wie viele gleichzeitige fachliche Transaktionen hält ein System innerhalb der SLA*-Grenzen aus)?

  • Wurde eine Kapazitätsberechnung des Systems gemacht?

Hat das Team auch diese Hürde genommen und sich ein sauberes „Nach-dem-Livegang“-Set-up erarbeitet, kann es damit beginnen, die weiteren Schritte der Preproduction in Angriff zu nehmen.

Info

Wie schreibt man eigentlich gute Produktionstests?

Ein guter Test beginnt damit, dass man sich die Akzeptanz des Kunden einholt und sich sicher ist, das Richtige zu implementieren. Der Kunde muss nicht zwingend menschlich sein, auch eine Maschine ist hier ein guter Kunde. (Eigentlich sogar ein besserer, da Maschinen einfacher zu interpretieren sind.) Wir befinden uns mit der Artikelserie al...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Gewinner-Teams

Wir bieten Lizenz-Lösungen für Teams jeder Größe: Finden Sie heraus, welche Lösung am besten zu Ihnen passt.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang