Seite 3: 5 Schritte

Inhaltsverzeichnis

Schritt 1: Die richtigen Fragen stellen

War-Room-Szenarien lassen sich durch das Einführen solcher DevOps-Prinzipien deutlich reduzieren – mit den richtigen Tools, die Problemursachen detailliert anzeigen. Denn herkömmliche Infrastrukturüberwachungsdaten, Log-Files oder Nutzerbeschwerden weisen zwar auf die Symptome, jedoch nicht die Ursachen eines Fehlers hin. Was ist aber für den Nachweis der Ursache wichtig? Um das zu ermitteln, können folgende Fragen helfen:

• Beschwert sich ein einzelner Nutzer oder sind alle Anwender von dem Problem betroffen?
• Gibt es einen Fehler in der Lieferkette einer Anwendung, zum Beispiel bei CDNs, Drittanbietern, ISPs, Cloud-Providern, Hosted Services oder mobilen Netzwerken?
• Ist eine geschäftskritische Transaktion betroffen?
• Liegt das Problem in der Applikation, an schlechtem Code, an der virtuellen Maschine, an der Infrastruktur oder am App-Server?

Mit den Antworten auf diese Fragen lassen sich die wirklichen Problemursachen schnell identifizieren, deren Behebung priorisieren und eine Antwort darauf finden. Statt eines War Room mit 20 Personen sind dann oft nur drei Mitarbeiter nötig – ein Entwickler, ein Tester und ein Betriebsexperte –, um die detaillierten Performanceinformationen auszuwerten und bei Bedarf externe Experten einzubinden.

Schritt 2: Die Fähigkeiten erweitern

Wenn die DevOps-Praktiken nicht miteinander abgestimmt sind, besitzen Entwicklung, Test und Betrieb verschiedene Sichten, und ihre Performance wird anhand unterschiedlicher Metriken gemessen: Entwickler erstellen neue Funktionen und vervollständigen so viele Punkte wie möglich. Tester entdecken Fehler und schicken die Software an die Entwickler zurück. Der Betrieb konzentriert sich auf die Stabilität und möchte daher am liebsten laufende Systeme nicht ändern.

Um eine reibungslose Zusammenarbeit zu ermöglichen, sind die Grenzen zwischen den Abteilungen zu überwinden. Sie sollten stattdessen ein Team mit einem gemeinsamen Ziel bilden. Dabei muss das Rad nicht neu erfunden werden. Ein konstanter Zyklus aus Programmieren, Testen und Verbessern ist weiterhin beizubehalten. Doch statt dass Tester zehn Fehler am Tag finden und einfach zurückschicken, sollten sie die Entwickler über häufige Fehler informieren, damit sie diese von Anfang an vermeiden. Anschließend können sich die Tester auf wichtigere Aufgaben wie Akzeptanztests und hochskalierte Performance-Tests konzentrieren – und die Entwickler auf die Gestaltung innovativer Funktionen und Oberflächen.

Daher sollten die Fähigkeiten der drei Expertenteams verbessert werden. Sie müssen die jeweiligen Herausforderungen der anderen Bereiche verstehen. DevOps eignet sich ideal für eine optimierte Zusammenarbeit, die Einigung auf gemeinsame Tool-Sets und einheitliche Metriken.

Application-Performance-Monitoring-Tools (APM) – die Weiterentwicklung reiner System-Monitoring-Werkzeuge durch die Integration umfassender Überwachung der Qualität in der gesamten Anwendungslieferkette – ermöglichen es, dass jeder die gleiche Sprache spricht. Sie können eine einheitliche, automatisierte Performanceansicht bieten, die individuell für die Rolle und die Anforderungen jedes Team-Mitglieds eingestellt ist. Wenn etwas schief läuft, kann das funktionsübergreifende Team das gemeinsam korrigieren, ohne einen War Room einzuberufen.

Schritt 3: Die Prioritäten festlegen

Manches Mal tauchen Hunderte von Problemmeldungen auf. Die IT-Abteilung hat aber nicht die Zeit, sie alle einzeln zu durchforsten. User-Experience- und APM-Tools können bei der Priorisierung der Probleme helfen, indem sie die Datenmengen aller Nutzer über die gesamte Anwendungslieferkette aggregieren. Sie bieten eine Analyse der Auswirkungen mit der Option, tiefer in die technischen Problemursachen hineinzugehen. Sie sorgen außerdem für einen Überblick durch die Identifizierung von Problemmustern im gesamten produktiven System.

APM-Tools sollen des Weiteren bei der Priorisierung von Verbesserungen für eine höhere Kundenzufriedenheit unterstützen, unter anderem durch die Beantwortung folgender Fragen:

• Folgen die Nutzer dem Pfad, der für die Anwendung vorgesehen ist?
• Nutzen sie alle Funktionen?

Diese Tools machen das Nutzerverhalten transparent, heben Möglichkeiten für die Verbesserung des Nutzungsflusses hervor und entfernen überflüssigen Code, damit nicht auch noch Arbeit in ohnehin nicht genutzte Funktionen gesteckt wird.

Durch die Kombination der Daten mit Erkenntnissen aus dem Business, welche Transaktionen, Anwendungen und Nutzergruppen geschäftskritisch sind, kann sich das IT-Team auf die wichtigen Punkte konzentrieren. Das sind die Probleme, die Unternehmen am meisten kosten – in Sachen Vertrieb, Markenwert und Nutzerzufriedenheit.

Schritt 4: Den Anwendungsbereich erweitern

Continuous Delivery bringt zahlreiche Vorteile, doch manchmal bleiben die Unternehmen bei der Einführung auf halbem Wege stehen. Die Kosten für das Beheben von Fehlern in der Produktivphase können bis zu 150-mal höher sein als im frühen Entwicklungszyklus. Das hat eine Studie des bekannten US-amerikanischen Softwarespezialisten Barry Boehm ergeben. Um eine echte und umfassende Continuous Delivery zu erreichen, ist daher der Anwendungsbereich über den gesamten Entwicklungslebenszyklus zu erweitern.

Unternehmen können neuen Code schneller installieren, ohne schneller Fehler zu erzeugen, indem sie eine einheitliche Version der Performancedaten aus Entwicklung, Test und Produktion verwenden. Damit reduzieren sie ungeplante Tätigkeiten und technische Lücken. Entsprechend können sich die IT-Mitarbeiter wieder vermehrt auf die Entwicklung neuer Funktionen und Oberflächen konzentrieren. Dadurch lässt sich eine enorme Geschwindigkeit in der Bereitstellung neuer Funktionen erreichen. Zum Beispiel führt Amazon nach eigenen Angaben etwa alle 10 Sekunden ein neues Deployment durch. Dabei erzeugt nur 0,001 Prozent der Neuinstallationen ein Problem. Im Vergleich zu 2006 verzeichnete das Unternehmen 2012 um 75 Prozent weniger Ausfälle und um 90 Prozent weniger Ausfallminuten.

Schritt 5: So viel wie möglich automatisieren

Inzwischen stehen so viele Daten zur Verfügung, dass Unternehmen sie möglicherweise nicht mehr alle verarbeiten können. Das Gute am Application Performance Management ist aber, dass nicht jeder Nutzer das Wissen und die Zeit benötigt, um alle Vorgänge genau zu verstehen. Sind einmal die Prioritäten gemeinsam mit den Fachabteilungen festgelegt, die wichtigsten technischen Metriken identifiziert und die Key Performance Indicators (KPIs) gesetzt, lässt sich die Überwachung der Performance weitgehend automatisieren.

Selbst in der Prozesskette lassen sich viele Schritte automatisieren. Zum Beispiel können nach einem Lasttest ohne weiteres Zutun Change Requests direkt an die Entwickler gesandt werden. Während eines Integrationstests ist ebenfalls der automatische Versand von Fehlermeldungen an die Entwickler möglich. Zudem warnen Alarmmeldungen bei Überschreiten der Toleranzgrenzen für KPIs oder SLAs.

Unternehmen können damit eine kontinuierliche Qualität in ihre Continuous-Delivery-Prozesse einbauen. Dazu werden auf Metriken basierende Qualitäts-Gateways in jede Stufe der Prozesskette integriert, insbesondere zwischen Unit-, Acceptance- und Performance-Testing. Der Ansatz verstärkt das Sicherheitsnetz und unterstützt das Team beim Umgang mit sich verändernden Anforderungen. Denn die Mitarbeiter können sofort erkennen, ob sie eine neue Funktion mit der nötigen Qualität ausliefern. Zudem entdecken sie Fehler früher.