Performance Test in Produktion (TiP)

Performance Test in Produktion (TiP)

cloudtest-pp-2

Die Zukunft der Performance- und Skalierungs-Tests – Real User Monitoring begleitetet den Belastungstest in Produktion

Einen Performance Test in der Produktionsumgebung (TiP) durchzuführen, heißt für die beim Test eingebundenen Mitarbeiter und Dienstleister in der Regel „Nachtschicht“. Der Performance Test wird (propagierte „Best Practices“) zu einem Zeitpunkt durchgeführt, bei dem sich so wenig wie möglich „echte User“ auf dem digitalen Angebot tummeln. Einen Stresstest tagsüber im „laufenden Betrieb“ (also auch für User laufend) durchzuführen, ist allgemein ein Thema „non grata“ bei den meisten Unternehmen.

Das TiP ist hierzulande negativ belastet, denn es bedeutet für die IT: Aufwand, Kosten und Risiko.

Für die User wird extra eine „Maintenance Seite“ für den Zeitraum des Tests vorbereitet und eingeblendet, damit die Skalierbarkeit dann sehr isoliert – ohne Rauschen durch echte Nutzer – auf spezifische Use-Cases durchgeführt werden kann. Alle Mitarbeiter (Frontend, Backend, Applications, Operations) und Dienstleister (Hosting, Shop, CDN, Telekommunikation) müssen auf den Punkt genau koordiniert werden. Der ungeübte Prozess und die  Arbeits- und Terminabstimmungen erlauben keine Flexibilität und schon gar keine Agilität während der Planung und der Durchführung des Stresstests. Ein unheimlicher Termindruck entsteht, der niemandem Spaß macht. On Top entstehen Kosten für Dienstleister.
Eine Verschiebung des Tests bedeutet die erneute Terminkoordination, Dienstleistergespräche…“auf Wohlwollen hoffen“ etc.

Die Durchführung des Tests reduziert die Aufgabe jedes einzelnen Beteiligten in die Rolle des gebannten Zuschauers. Ein, zwei oder drei Stunden spannendes Kino. Zu oft aber auch nur 20 Minuten bittere Tragödie.

Aufgrund der Komplexität einen solchen TiP durchzuführen und dem damit verbundenen Risiko „dass etwas wirklich abraucht“, lautet die Entscheidung vielerorts: Machen wir nicht oder nur wenn wirklich ein krasser Technologiewechsel bevorsteht.

Bird-in-the-hand-web-performance-testing-categories

Test in Produktion – Gründe. „Ongoing Testing“ nur bei den Unternehmen, die „cloudbased continuous performance Testing“ schon etabliert haben.

Diese oft vorgebrachten Argumentationen zeugen nicht gerade von großem Vertrauen in die eigene Applikationsentwicklung und die umgesetzte Architektur. Angst vor künstlicher Last in Produktion bedeutet aber auch „Angst vor echter Last“, also, dass es „Bitte, kein unerwartetes Event“ geben wird, bei dem tatsächlich so viele Besucher die Applikationen benutzen bis … ja was eigentlich?… passiert.
…Hmm… Anders gesagt: Peak Traffic, aus welchem Grund auch immer, der über das Maß des letzten Peak Traffics hinaus geht ist eher unerwünscht.

Ein klassisches Beispiel ist das sich jedes Jahr wiederholende (Überraschung!) Weihnachtsgeschäft. Nicht unerheblich viele eCommerce Retailer haben im Keller Infrastruktur auf „Halde“, die nur in der Saison implementiert wird. „Weihnachten haben wir doppelt oder dreifach so viel Traffic – da brauchen wir doppelt und dreifach so viel Infrastruktur“. Ob die Investition in die Kellerware berechtig ist, oder ausreicht, wird nicht besonders häufig validiert (getestet). Es wird auch nicht (oder nur selten) getestet, ob man vielleicht mit kleinen Änderungen mit gleicher oder sogar weniger Infrastruktur viel mehr User bedienen kann.
Nicht getestet und validert wird – ein Teufelskreis – weil die Voraussetzung ein Last-Test in der Produktion bedeuten würde. Siehe oben. Argumentation „Wissen Sie, wir hosten nicht selber und das Frontend macht ja die Agentur, und der Shop wird von denen bereitgestellt (Blackbox) – und die Servicemitarbeiter dort Kosten die Stunde XY“ …puh…
Viele Gründe, die gegen ein solches Testverfahren TiP sprechen.

Wobei, wenn ich ehrlich bin, ich kann diese Abwehrhaltung verstehen. Sind doch die meisten am Markt verfügbaren Last-Test-Lösungen jene, die überhaupt in der Lage sind die Produktivumgebung tatsächlich an die Kapazitätsgrenzen zu bringen. Häufig starre Systeme, die eine gute Analyse erst nach dem Testabschluss zulassen und deren Real Time-Analyse Daten sich auf die gerade verwendete Anzahl virtueller User und einen „Response Time“ Wert beschränkt. Eine manuelle Justierung der Last unter dem Last-Test ist nicht möglich.
Der Test läuft und läuft, bis etwas schief läuft, oder der Test vermeintlich gut abgeschlossen wurde. Das wird der Report, der irgendwann kommt, zeigen. Das alles kostet Zeit und ist in hohem Maße unflexibel.

Läuft schon frühzeitig bei einem Test etwas aus dem Ruder – oder gibt es einen unerwünschten „smoke“, dann heißt das „Stop“ für den gesamten Test. Mit „Stop“ meine ich den totalen Stopp des Testdurchlaufes, Auswertung des Tests, Behebung des Fehlers und nochmal ganz von vorne anfangen. Den ganzen Aufwand also noch einmal. Termin finden, Maintenance Fenster planen und hoffen, dass der gefundene Fehler tatsächlich der richtige war. Ein Stop ist ein hoher Kostenfaktor. Eine angebrochene virtuelle User Stunde gilt als volle genutzte virtuelle User Stunde.
Da kann man sich gut vorstellen, warum – wenn schon in Produktion – echte User lieber draußen bleiben sollen.

Ein manuelles justieren der Testszenerien, wie

  • beibehalten der Last auf einem spontan entschiedenen Niveau
  • manueller Eingriff in die Lasterzeugung einzelner Test-Strecken – „jetzt lass uns doch mal bei diesem Feature die Nutzerzahlen erhöhen“
  • dezente Lastreduzierung, um den „break even“ genau zu ermitteln und dabei einen genauen Blick auf das APM werfen
  • Sekundengenaue Einstellungsmöglichkeit der Lastgeneratoren
  • Einflussnahme auf die Last, wenn sich negative Entwicklungen andeuten (Server, Loadbalancer, Bandbreite, Garbage Collection….)
  • Lasterzeugung minimieren, wenn echte User sehr dezent beeinflusst sind. (Heißt natürlich: diese gibt es und wir können diese in Echtzeit monitoren)

lassen diese Werkzeuge nicht zu – ist aber nötig, um nicht nur Zuschauer zu sein, sondern aktiv in das Testgeschehen eingreifen zu können, fixen zu können, TESTEN zu können.

Status Quo: Gründe für den Verzicht auf Skalierungstests in Produktion:

  • Komplexität – daher nur selten nach großen Veränderungen im Frostend oder Backend / uneingespielter Prozess
  • Risiko echte User negativ zu beeinflussen – daher zu Uhrzeiten, bei denen möglichst wenige User die Angebote besuchen (Nachts)
  • Umfangreiche Organisation (viele verschiedene beteiligte Personengruppen / externe etc. koordinieren)
  • Träge Reaktion der Lastgeneratoren / mangelnde Eingriffsmöglichkeit – Gefahr eines „Smokes“
  • Unsicherheit ob nach einem „Smoke“ alle Systeme wieder hoch fahren
  • Bereitstellung von Last-Generatoren ist komplex und für einzelne Events auch kostenintensiv
  • Analyse und Reporterstellung ist Arbeitsintensiv

Also – und dieses Fazit ziehen viele Unternehmen – lieber nicht in der Produktion testen und wenn schon, dann bitte komplett isoliert, also ohne echte User Zugriff auf die Online Präsenz zu erlauben.

Performance Tests werden, in Folge dessen, in der Regel beschränkt oder eingeschränkt durchgeführt. Beschränkt auf eine Umgebung, die mit der Produktivumgebung wenig gemein hat.

Eine Einschränkung findet häufig auf einer anderen Ebene statt. Die Einführung von DevOps verführt viele Unternehmen dazu, Fokus auf einzelne Mikroservices oder Units zu setzen. Sprich auf die Entwickler einer Applikation, die diese auch selber testen (und die Testscripte dafür auch selber entwickeln). Eine Skalierungsdefinition für die Produktion wird durch Hochrechnen (Skalierungsannahme) der Testumgebung auf die Produktivumgebung durchgeführt (die Stagingumgebung hat allerdings nicht wirklich etwas mit der Produktivumgebung gemein). Unit Tests – keine Frage – sind erforderlicher Bestandteil im Application Lifecycle Management Prozess. Im besten Fall automatisiert, sind sie zwingend erforderlich. Der Prozess ist dann: der intern auf eigene Skalierbarkeit getestete Code geht live. Test-Ende.

Beschränkt man sich bei der Beantwortung der Frage: „Können wir diese Menge User mit unserem System bedienen?“ jedoch auf die Skalierungsannahme, ist ein Scheitern vorprogrammiert. Es wird z. B. oft nicht mit berechnet, dass Teile der ausgelieferten Daten „produktiv“ von externen Dienstleistern ausgeliefert werden. Namentlich: Content Delivery Networks, Font, Code, Marketing-Dienstleister etc. Bei internen und nur auf die Stagingumgebung reduzierten Tests, werden diese Lieferanten nie wirklich mit getestet.

Unit Tests/Micro Services Tests sind zudem blind beim Thema Wechselwirkungen und Artefakte durch andere Applikationen – die jede für sich gut läuft. Diese Einschränkungen jedoch führt dazu, dass zur „Wechselwirkungen unter Last“ zwischen zwei unabhängigen Applikationen, innerhalb eines digitalen Angebots (z. B. Warenkorb-Prozess und Recommendation Engine), keine verlässliche Aussage getätigt werden kann.
So agil kleine DevOps Teams auch arbeiten, der Blick für das große Ganze kann verloren gehen.
Resultat: Schuld hat der DB Admin, der Architekt, das Marketing.

Eine weitere Problematik, die allerdings dank „Cloud Technologie“ etwas reduziert wurde, ist die Generierung von Last, die tatsächlich erwarteter Userlast oder Peakuseranzahlen entsprechen kann.
A apropos Peak User: Es ist jedem digitalen Business schon einmal passiert, dass unfreiwillig ein Crowd Testing TiP durchgeführt wurde. (Unabgesprochene Marketingkampagne, Erwähnung in den News, Virales irgendetwas, Wettbewerber offline…)

Status Quo: Selbstaufgelegte Beschränkungen beim Performance Testing

  • Performance Tests werden in einer Umgebung durchgeführt, die mit der Produktionsumgebung wenig gemein hat
  • Performance Tests werden häufig auf einzelne Applikationen durchgeführt, ohne Artefakte mit anderen Applikationen zu berücksichtigen
  • Performance Tests berücksichtigen meist nicht die Auslieferungskapazitäten von eingebundenen Dienstleistern (3rd Party delivery, Marketing, Analytics)
  • Testscripte entsprechen der Applikationslogik – aber nicht der Userlogik.

 

TiP Erfahrungen

In einem interessanten Blog Eintrag hat mein Kollege Dan Boutin einmal ausgerechnet, welches die häufigsten „Bottlenecks“ waren, die bei den Tests (TiP) unserer Kunden identifiziert wurden.
https://www.soasta.com/blog/web-performance-testing-production/

Bei nur 30% aller Tests wurde das Testziel erreicht, bevor Bottlenecks auftauchten – das ist eine positive Zahl. Im Umkehrschluss heißt das aber auch, dass bei 70% aller TiP Bottlenecks auftauchten. Bandbreitenprobleme und Load Balancer Probleme ergeben 10% Webserverprobleme gab es bei 11% und die Applikationsserver schlagen mit 21% aller Bottlenecks zu Buche, während der eigentliche Code nur 5% Fehlergrund darstellte. Die Fehler waren also provoziert durch Bandbreite, Lastenverteilung und Artefakte. Dinge, die sich in einer „simulierten“ Umgebung gar nicht testen lassen, bzw. wo die Skalierungsannahme sehr vage ist. 9% „others“ hier verstecken sich die Dienstleister, CDN, Analytic Tools und weitere „Dienstleister“.

Alle Kunden, die in dieser Auswertung berücksichtigt wurden, testen übrigens auch in Units und ihre Mikroservices – automatisiert oder manuell – und dennoch wurden Fehler gefunden! Man könnte das als Beweis nehmen, warum ein Test in Produktion „Pflicht“ sein sollte. Auch bei denjenigen, die gut intern Testen.

Ich möchte hier einmal besonders auf die 70% Fehler eingehen. Oder „Ziel nicht erreicht“. Auf den ersten Blick scheint das sehr hoch und würde das oben genannte „Risiko“ in Produktion zu testen bestätigen.
TiP welche während der „business hours“ also mit echten Usern durchgeführt werden, erlauben eine komplett andere Zieldefinition, als man auf isolierte Tests anwenden kann. Isolierte Tests erlauben eine Beurteilung nach „Verfügbarkeit in % “ oder „Response Time minus x%“.
Echte User hingegen beginnen sich bei Veränderungen der Ladezeit anders zu verhalten. D. h. eine Zieldefinition kann sich zusätzlich am Userverhalten orientieren. Die Bouncerate steigt um 3% – Test = fail, Verweildauer auf dem Angebot sinkt um 2 Min = fail. Vielleicht hat sich die „interne Response Zeit“ und die interne „Verfügbarkeit“ zu dem Zeitpunkt noch gar nicht verändert – oder es zwackt an einer Stelle, die man ohne echte User gar nicht wahrgenommen hätte?
Wenn also unsere Kunden sagen: 70% wurden Bottlenecks – beim Testen in Produktion – gefunden, dann heißt das nicht, dass der durchgeführte Test signifikanten Einfluss auf die User hatte. Viel wahrscheinlicher ist es, dass der Test weniger Einfluss negativen Einfluss auf User hatte, als wenn die Seite für Stunden vom „Netz“ genommen worden wäre.

Bird-in-the-hand-web-performance-problems

SOASTA wo ist der Unterschied?

Während Last-Test Tool Hersteller gerne den „Maintenance Mode“ für einen Test in Produktion empfehlen, geht SOASTA mit seiner CloudTest Lösung einen einzigartigen Weg. SOASTA empfiehlt alles so zu lassen wie es ist, und im ganz normalen Tagesgeschäft in Produktion zu testen. Am besten sogar nach jedem kleinen Release.
Ein Real User Monitoring (RUM), welches in Echtzeit Performance Daten aus den Clients echter User (100%) darstellt, begleitet einen Last-Test. Bestenfalls kommt sogar die Grundlage für die Testscripte schon aus den durch das Real User Monitoring ermittelten Bewegungsprofilen der User.

Wohlwissend, dass bei dem Thema „Real User Monitoring“ die „Datenschutz“ Glocken geläutet, sei hier angemerkt, dass SOASTAs RUM Lösung mPulse keine Daten speichert, die zu einer Identifikation einzelner User führen kann. PCI Konformität und Datenschutz ist ein hohes Gut und Recht – welches unbedingt von SOASTA geachtet wird. SOASTA erzeugt lediglich Cookies, die nur für die jeweilige aktuelle Session des Users Gültigkeit behalten und nicht dauerhaft beim User zur Identifizierung gespeichert sind.

Die Lastgeneratoren, sowie die einzelnen Test-Cases, können in Echtzeit über ein patentiertes Grid beeinflusst werden. Dieses Grid – eine Cloud über der Cloud – sorgt dafür, dass manuelle Eingriffe unmittelbar an die unterschiedlichen Lastgeneratoren (auch Cloud-Provider übergreifend) weitergeben werden und im einstelligen Sekundenbereich adaptiert sind.
Die Analyse der Testdaten erfolgt „in Memory“ – d. h. alle Performance Metriken, werden in Echtzeit in verständlichen Dashboards dargestellt – und ermöglicht dadurch eine einflussnehmende Aktion der Test-Durchführenden schon zur Laufzeit.
Die Lastgeneratoren sind innerhalb von wenigen Minuten provisioniert – auch Cloud-Provider übergreifend. Somit ist es jederzeit möglich nahezu jede erdenkliche Last aus unseren über 80 Standorten weltweit zu erzeugen.

Diese Funktionalitäten erlauben die Durchführung von Last Tests zu jedem erdenklichen Zeitpunkt.
Bei geringsten Veränderungen der Experience der echten User, kann dann die Last für einzelne Test-Cases reduziert/erhöht werden, oder auch ein vorher festgelegtes „Ramp up“ der Last pausiert werden. Unter der Laufzeit des Tests können Bottlenecks identifiziert werden und – abhängig von deren Natur – direkt beseitigt werden. APM Lösungen wie Dynatrace, AppDynamics oder NewRelic können integriert werden und deren Daten können direkt in die Echtzeit-Analyse mit einfließen.

Diese Testart hat viele Vorteile:

  • Durch RUM erfährt ein Unternehmen die tatsächliche Verteilung der User / Devices und kann dieses in den Test-Szenarien mit umsetzen. Dieses führt zu einer realistischeren Last-Test Umsetzung
  • TiP – ohne Maintenance Mode und zu normalen Geschäftszeiten – heißt = es gibt schon eine Grundlast, es muss also weniger zusätzliche Last erzeugt werden (Kosten Einsparung)
  • Behebung von Bottlenecks während des Tests reduziert die Anzahl der Iteration (Zeitaufwand reduziert)
  • Es muss nicht jedes mal wieder von Null angefangen werden, weil man einfach auch mal einen Test „pausieren“ kann (Zeitaufwand reduziert)
  • Die Möglichkeit manueller Beeinflussung erlaubt andere Testvorgehensweisen
  • Ziel- oder Fail Definition orientiert sich am echten User und nicht von artifiziellen Annahmen. SOASTAs RUM Lösung korreliert User Performance Metriken mit Business Daten. Diese empirisch gewonnenen Daten beeinflussen die Zieldefinition.
  • Verwendung von Metriken, die Last-Test Lösungen nicht liefern: Z. B. Verzögerung der „Time to first impression“ beim User um 500ms = fail
  • Artefakte zwischen Applikationen werden erkannt, selbst wenn diese gar nicht Bestandteil der Tests sind. (Erweiterter Einblick)
  • Bestätigung, dass alle externen Auslieferungsdienste (3rd Party) „standhalten“ (SLA Management)
  • Keine (oder viel weniger) Nachtschichten mehr (eigene Kosten, Kosten für Dienstleister reduziert)
  • Keine „Maintenance-Fenster“ mehr (Zeitersparnis, Planung)
  • Schnelle Lastbereitstellung führt zu wesentlich höherer Agilität. (Kein Druck)
  • Generell höhere Flexibilität mit unlimitierter Testhäufigkeit
  • Reduzierung des Risikos der Überinvestition in Hardware/Infrastruktur
  • Langsames herantasten an Belastungsgrenzen

Die Liste der Vorteile lässt sich noch weiter ausführen. Eines lässt sich sicher festhalten: Ein Unternehmen weiß, wie Belastbar die Plattform ist. Jeder Dienstleister ist froh, dass nicht Nachtschichten gefahren werden müssen. Das gesamte IT Team wird wesentlich selbstbewusster mit dem Thema Last umgehen.
Erstmalig sind Unternehmen in der Lage, auch Schritte zu definieren und zu testen, welche Maßnahmen zu ergreifen sind, wenn Lastgrenzen erreicht werden. Also proaktiv eine ToDo-Liste für den Fall des Falles zu erarbeiten. Es können über das Real User Monitoring Alerts eingerichtet werden, die zielgerichtet Notifikationen senden um lastreduzierende Maßnahmen zu ergreifen.

Jeder User in einem Flash Sales wird dankbar sein, wenn er das Produkt seiner Wünsche ergattern konnte und statt einer dynamischen Recommendation Engine einen Text vorfindet: „Um sicherzustellen, dass Sie Ihr Produkt problemlos bestellen können, haben wir temporär auf die Einblendung der weiteren Kaufempfehlungen verzichtet. Ihr XYZ Team“.

SOASTA ist auf dem GermanTestingDay2016 präsent und freut sich auf Ihren Besuch am Stand.

http://www.soasta.com