© Ekaphon maneechot/Shutterstock.com
Best Practices für performanceoptimierte DevOps

Was wir aus Obamacare lernen können


Abgestürzte Websites, Anwendungen im Schneckentempo, ärgerliche Funktionsfehler: Schon bei der Entwicklung lassen sich viele Probleme mit der Stabilität und Performance vermeiden. Dazu muss der aktuelle DevOps-Ansatz aber um die Einbindung von Testszenarien und Businessanforderungen erweitert werden.

Etwa 80 Prozent der kritischen IT-Probleme werden von nur 20 Prozent aller Ursachenmuster ausgelöst. Dies zeigen diverse Untersuchungen und Expertendiskussionen. Die meisten Ursachenmuster hängen dabei mit Performance- oder Architekturproblemen in der Applikation selbst oder der darunter liegenden Infrastruktur zusammen. Die Folge: Gemäß einer aktuellen Studie werden 80 Prozent der Entwicklungszeit mit der Erkennung und Behebung von Problemen verschwendet. Daraus resultieren alleine in den USA geschätzte Gesamtkosten von etwa 60 Milliarden Dollar pro Jahr. Und dieser Aufwand für die Fehlersuche dürfte sich aufgrund der steigenden Komplexität durch Cloud-Angebote sowie der immer schnelleren App-Entwicklung vor allem für Mobilgeräte weiter erhöhen. Oft noch schlimmer als der finanzielle Verlust schmerzt aber der durch Abstürze und lange Reaktionszeiten ruinierte Ruf des Anbieters.

Empfehlenswerte DevOps-Vorgehensweisen

Es gibt viele Definitionen von DevOps. Der wichtigste Aspekt ist die „gelebte“ Kollaboration aller Entscheider in Softwareentwicklung, Test und Betrieb und die gemeinsame Verantwortung für alles, was zum Erfolg der Software führt. Das bedeutet, dass der Betrieb der Entwicklung zu verstehen gibt, wie die Betriebsumgebung wirklich aussieht, in der die Anwendung in Zukunft laufen wird und was es bedeutet, wenn Fehler auftreten. Der Betrieb wiederum muss sowohl den Testern als auch den Entwicklern dabei helfen, eine betriebsähnliche Umgebung zur Verfügung zu stellen. Die Entwickler müssen sich dazu verpflichten, dass ihre Software in dieser Umgebung stabil läuft. Eine Ausrede wie „Es läuft auf meiner Maschine“ gibt es dann nicht mehr. Außerdem sind die Entwickler gefordert, dem Betrieb dabei behilflich zu sein, automatische Deployment-Tools zu entwickeln, die sicherstellen, dass beim Aufziehen neuer Versionen nichts übersehen wird. Leider gibt es viele prominente Gegenbeispiele, bei denen genau das übersehen wurde. Diese könnten zukünftig verhindert werden. Im nächsten Schritt gilt es zusammen zu definieren, welche Daten aus dem Betrieb für Entwicklungs- und Testabteilung zugreifbar sind und welche Tools dafür verwendet werden. Mit diesen Daten kann man im Fehlerfall schneller auf Probleme reagieren. Außerdem können die Tester ihre Testszenarien um reale Anwendungsfälle erweitern.

Ein prominentes Problembeispiel ist die Internetseite von „Obamacare“ für den Zugang zur Krankenversicherung in den USA. Trotz jahrelanger Vorbereitung stürzte sie kurz nach dem Start Ende 2013 mehrmals und nachhaltig ab. Um solche Peinlichkeiten zu vermeiden, sollte die Entwicklung von Anwendungen mit schlanken, flexiblen und lösungsorientierten Methoden erfolgen. Vor allem DevOps zur Integration von Entwicklung und Betrieb der Software bietet sich hierfür an, sollte aber mit einem Fokus auf Performance und kurze Reaktionszeiten aus Sicht des Nutzers erweitert werden. Doch was bedeutet das genau und wie lässt sich das umsetzen?

Diagnose der Obamacare-Website

Nicht nur in den USA beherrschte der politische Streit über die neu eingeführte Pflicht zur Krankenversicherung die Schlagzeilen. Nach jahrelangen Diskussionen und diversen Gerichtsurteilen wurde Ende 2013 die Registrierungsmaske auf healthcare.gov für alle US-Bürger freigeschaltet. Kaum online, war sie aber auch schon wieder offline, denn sie hielt dem Ansturm der Eintragungswilligen nicht einmal ansatzweise stand. Das Portal wurde auch in den Wochen danach von Abstürzen, Blackouts, inaktiven Links und unverständlichen Fehlermeldungen dominiert. Schnell waren vier vermeidbare Fehler des neuen Portals identifiziert:

  • die großflächige Nutzung von Inhalten, die durch Drittanbieter bereitgestellt wurden

  • das Fehlen von Web Performance Optimization (WPO) und grundlegender Best Practices

  • prozessaufwändiges JavaScript

  • langsame serverseitige AJAX Requests

Selbst nach dem anfänglichen Komplettzusammenbruch hatten die IT-Verantwortlichen in den folgenden Wochen nicht viel auf der Website ändern lassen. Nur aufgrund der geringer werdenden Nutzerzahlen stabilisierte sich das Angebot ein wenig. Dabei hätten ein paar einfache Maßnahmen genügt, um die Website dauerhaft und zuverlässig zu stabilisieren.

Bei den Inhalten von Drittanbietern fiel beispielsweise auf, dass healthcare.gov verschiedene Real-User-Monitoring-Lösungen nutzte. Dafür mag es zwar gute Gründe geben, doch eine Konsolidierung der Lösungen sowie die Nutzung eines Monitoring-Tools, das viele Funktionen und Anwendungsmöglichkeiten bietet, hätte die Performance deutlich erhöht. Die Missachtung grundlegender Best Practices sah man beispiel...

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