Comcast setzt DevOps, Service-Virtualisierung und Leistungstests ein

Die Herausforderungen

Von Frank Jennings, Director TQM Performance Testing bei Comcast

Mein Team bei Comcast führt Leistungstests in einer Reihe von Branchen im Unternehmen durch – von Geschäftsservices über unsere Enterprise-Services-Plattform bis hin zu kundenorientierten Benutzeroberflächen und Backend-Systemen, die die Bereitstellung und Aktivierung der Geräte für die Abonnenten auf dem Comcast-Netzwerk. Während unsere Testziele (AUTs) in der Regel über Staging-Umgebungen verfügen, die die Leistung der Produktionssysteme genau darstellen, ist dies bei den Staging-Systemen für die Abhängigkeiten der AUT nicht der Fall.

Erschwerend kam hinzu, dass diese Umgebungen schwer zugänglich waren. Wenn wir Zugriff hatten, haben wir manchmal die unteren Umgebungen (die QA- oder Integrationstestumgebungen) heruntergefahren, weil sie nicht angemessen skaliert waren und die Last einfach nicht bewältigen konnten. Auch wenn die Systeme der Belastung standhalten konnten, haben wir von diesen Systemen sehr schlechte Reaktionszeiten erhalten. Dies bedeutete, dass unsere Leistungstestergebnisse die reale Leistung nicht wirklich vorhersagen konnten.

Ein weiteres Problem ist, dass wir häufige und lange Ausfallzeiten in den Staging-Umgebungen umgehen mussten. Die Staging-Umgebung war während der häufigen Upgrades oder Software-Updates nicht verfügbar. Infolgedessen konnten wir unsere vollständigen Leistungstests nicht durchführen. Leistungstestteams mussten wichtige Projekte zu kritischen Zeiten abschalten, um beschäftigt zu bleiben – sie wussten, dass sie ihrer Hauptverantwortung nicht nachkommen konnten, weil die Systeme, auf die sie zugreifen mussten, einfach nicht verfügbar waren.

Diese Herausforderungen trieben die Kosten in die Höhe, verringerten die Effizienz des Teams und wirkten sich auf die Zuverlässigkeit und Vorhersagbarkeit unserer Leistungstests aus. Wir wussten, dass wir handeln mussten – und deshalb begannen wir, uns mit der Service-Virtualisierung zu befassen. Letztendlich stellten wir fest, dass der Zeit- und Kostenaufwand für die Implementierung der Service-Virtualisierung weit geringer war als der Zeit- und Kostenaufwand für die Implementierung all der verschiedenen Systeme in all diesen Staging-Umgebungen – oder für den Aufbau der Konnektivität zwischen den verschiedenen Staging-Umgebungen.

Die Ergebnisse

Wir haben uns aus zwei Hauptgründen der Service-Virtualisierung zugewandt. Zunächst wollten wir die Genauigkeit der Leistungstestergebnisse erhöhen. Zweitens haben wir in den gestuften Testumgebungen ständig mit häufigen und langen Ausfallzeiten gearbeitet.

Unser anfänglicher Fokus lag auf den größten Schwachstellen hinsichtlich Terminüberschneidungen in den Performance-Testteams, nicht verfügbaren Systemen und Systemen, deren Tests andere Entwicklungs- oder Testgruppen beeinträchtigen würden. Seitdem konnten wir rund 98 % der an unseren Tests beteiligten Schnittstellen virtualisieren und den Zeitaufwand für die Erstellung und Pflege von Testdaten (einschließlich der Zeit für die Erstellung und Aktualisierung virtueller Assets) jährlich um 65 % reduzieren. Zudem haben wir die Ausfallzeiten unserer Staging-Umgebung um 60 % gesenkt.

Da wir mit der Arbeit an unseren Skripten im Vergleich zu virtuellen Assets in der Entwicklungsumgebung beginnen können, haben wir in der Regel alles recht früh in jedem Sprint bereit. Früher brauchten wir zwei Wochen, um den Code zu testen, sobald wir ihn in unseren Staging-Umgebungen hatten (z. B. mit durchschnittlichen Lasttests, Spitzenlasttests, Dauertests usw.). Das haben wir auf zwei oder drei Tage geschrumpft.

Lösungsvorteile

Unsere Tests sind jetzt vorhersehbarer, konsistenter und repräsentativer für das, was in der Produktion zu sehen wäre. Darüber hinaus können wir in vielen Fällen auch den Testumfang erhöhen. Wir können beispielsweise bestimmte tatsächliche Dienste nicht mit der Produktionslast belasten, aber wenn wir mit virtuellen Diensten arbeiten, können wir sie mit Lasten auf Produktionsebene hochfahren und realistische Antworten erhalten, sowohl in Bezug auf Daten als auch auf Leistung. Wir können die AUT wirklich isolieren, nicht nur aus der Perspektive des Leistungstests, sondern auch aus der Perspektive des Leistungsprofils. Anstatt der Entwicklung nur zu sagen: „Das ist die Leistung Ihres Systems“, können wir auch sagen: „Hier sehen wir die Engpässe und hier denken wir, dass Änderungen den Durchsatz der Anwendung verbessern könnten.“

Der Hauptvorteil für das Leistungstestteam ist die erhöhte Betriebszeit und Verfügbarkeit der Testumgebungen. Die Servicevirtualisierung hat es uns ermöglicht, von unseren Testmitarbeitern eine hervorragende Auslastung zu erzielen, mehr Projekte zeitgerecht abzuschließen und außerdem Geld zu sparen, indem die Gesamtkosten für die Durchführung der für eine bestimmte Version erforderlichen Tests gesenkt wurden.

Service-Virtualisierung und DevOps

Neben Performance-Tests in unseren Staging-Umgebungen konnten wir die Servicevirtualisierung auch für alles andere nutzen, von Unit-Tests und Regressionstests in der Entwicklungsumgebung über Baseline-Performance-Tests in frühen Downstream-Umgebungen bis hin zu Funktions- und Regressionstests in der QA-/integrierten Umgebung sowie manuellen/explorativen Tests in einer Umgebung, die der Produktion sehr nahe kommt (aber in einigen Fällen virtuelle Assets verwendet).

Die gesamte Konfiguration und Bereitstellung virtueller Ressourcen für die verschiedenen Umgebungen ist als Teil unserer DevOps-Infrastruktur automatisiert. Die Umgebungen wechseln automatisch zwischen virtuellen und realen Ressourcen gemäß den von uns definierten Geschäftsregeln – beispielsweise basierend auf dem Endpunkt, von dem der Datenverkehr stammt, den Daten in den Testpaketen usw. Diese Servicevirtualisierungslösung ermöglicht uns kontinuierliches Testen als integralen Bestandteil unseres DevOps-Prozesses.