DevOps, APM und der Single Point of Failure

APM

Mehr Effizienz durch Application Performance Management

Für die Beschleunigung beziehungsweise die agile Gestaltung dieser Schritte können Werkzeuge für das Application Performance Management (APM) helfen. Ihre Leistung besteht insbesondere darin, dass sie die Servicequalität von Applikationen aus Sicht der Anwender visualisieren. Wenn sich dadurch ein Problem als "innerhalb der Anwendung" identifizieren lässt, ist das nächste Ziel eines APM-Werkzeugs, die Ursache schnell und effizient einzugrenzen ("mean time to identify") und gleichzeitig konkrete Hinweise auf die Problemursache zu liefern.

Ein APM-Werkzeug stellt tabellarisch und grafisch die Performance der zu betrachtenden Anwendungen dar. Hierbei wird nicht ausschließlich die Performance aus Nutzersicht herangezogen, sondern sie wird mit der Performance und Auslastung der darunterliegenden Hardware abgeglichen.

Übersicht der Servicequalität einzelner Applikationen im Vergleich zur Auslastung der darunterliegenden Server (Abb. 1)

Durch diese Art der Darstellung wird auf einen Blick sichtbar, ob ein Problem vorliegt, bei dem Anwender beeinträchtigt werden, oder ob man "nur" ein Auge auf den Ressourcenbedarf der Hardware werfen muss. Fehlt eine solche Sicht und setzt das Team nur auf das siloseitige Hardware-Monitoring, kommt es häufig zu folgendem Szenario: Das Betriebsteam wird durch zu hohe Auslastung der Server für die Applikation "Movie Tickets Online" alarmiert und bindet Ressourcen für das Troubleshooting dieser Anwendung. Gleichzeitig erreichen das Betriebsteam Beschwerden bezüglich der Performance der E-Commerce-Applikation über den First-Level-Support, die aber zunächst nicht weiter beachtet werden, da die dazugehörigen Server alle "grün" sind beziehungsweise keinen Alarm geschlagen haben.

Dass eine hohe Auslastung eines Servers nicht zwingend mit einer schlechten Performance einer Applikation oder Transaktion einhergeht, ist nichts Neues. Aber nur eine objektive Darstellung wie oben dargestellt hilft dabei, die richtige Entscheidung zu treffen. Kennt man ausschließlich die Werte der Serverauslastung, dann beginnt man üblicherweise auch an dieser Stelle mit dem Troubleshooting.

Den "single point of failure" erkennen

Da Umgebungen und Anwendungen immer komplexer und vielschichtiger werden, hilft die High-Level-Aussage, dass eine Anwendung ein Problem hat, nicht wirklich bei der Eingrenzung der Ursachen. Im Grunde gibt es dann immer noch eine Vielzahl von Heuhaufen, in denen eine oder mehrere Nadeln versteckt sein können. Eine Servicesicht ist für die effektive Zusammenarbeit innerhalb von DevOps-Teams deshalb äußerst hilfreich. Sie stellt grafisch alle beteiligten Komponenten einer Anwendung und deren Abhängigkeiten dar. So lässt sich schnell erkennen, wer mit wem wie häufig kommuniziert und wo es gegebenenfalls einen "single point of failure" in der Architektur der Anwendung gibt.

Service Map, die die Abhängigkeiten aller beteiligten Komponenten einer Anwendung darstellt, sowie deren Performance (Abb. 2)

Zeitgemäße APM-Werkzeuge erkennen diese Service-Maps automatisch. Sie sind ein hilfreiches Mittel, um Abhängigkeiten und Zusammenhänge in einer Anwendung schneller und besser zu verstehen – und im Problemfall die Ursache einzugrenzen.

Es gab schon den Fall, bei dem eine solche Service Map in der Produktivumgebung eine stetige Kommunikation zwischen Application Server und Test-Datenbank aufzeigte. Das eingesetzte APM-Werkzeug erkannte automatisch die jeweiligen Datenbanken und Backends und stellte sie dem DevOps-Team transparent dar. Das Team konnte so schnell erkennen, dass das Produktivsystem weiterhin auf die Test-Datenbank zeigte statt auf die produktive Datenbank und somit alle Buchungen nicht richtig verarbeitet wurden. Diese Erkenntnis hat weitere Schädigungen des Geschäftsbetriebes in der Zukunft verhindert. Ebenso wurde auf diese Weise ein Fehler im automatisierten Deployment erkannt und für spätere Releases behoben.

Bewertung des Business Impact von Problemen

Beschwerden von Kunden oder Anwendern liefern häufig äußerst wertvolle Informationen zur Problemlösung, wie "Anwendung XYZ geht nicht", "alles ist langsam" oder "das Internet geht nicht". Wie kann man auf Basis dieser Informationen entscheiden, ob ein wirklich kritisches, anwendungsübergreifendes Problem vorliegt oder nur ein punktuelles, das nur einen einzelnen Anwender betrifft? Nun könnte man einwenden: Diese Analyse ist doch Aufgabe des Betriebs und nicht des DevOps-Teams. In gewisser Weise ist das auch richtig. Aber zu einer guten Zusammenarbeit gehört eben auch, die Aufgaben des Betriebs und dessen Herausforderungen zu verstehen. Das hat den Vorteil, dass das DevOps-Team und die Entwicklung nur hinzugezogen werden, wenn es sie tatsächlich betrifft.

Um zu bewerten, ob es ein generelles Problem gibt oder nur ein auf eine Funktion begrenztes, sollte man die Performance und Verfügbarkeit aller einzelnen Anwenderaktionen beziehungsweise Services getrennt betrachten. Es ist selten eine gute Idee, von außen und als Nichtanwender zu bestimmen, was wichtig ist. Betriebs- und DevOps-Teams sollten deshalb immer alle Anwenderaktionen betrachten – und nicht nur einige wenige.

Anhand der Übersicht über Verfügbarkeit und Performance aller einzelnen Anwenderaktionen können die Betriebs- und DevOps-Teams besser einschätzen, welches Problem den höchsten, negativen Einfluss auf den Geschäftsbetrieb hat. Üblicherweise sind das Aktionen und Services, die einen direkten Bezug auf den Umsatz haben. Oder Services, die besonders häufig eine schlechte Performance abliefern. Oder sie haben eine hohe Fehlerrate und beeinträchtigen somit eine Vielzahl von Anwendern negativ in deren User Experience.

End-to-End-Betrachtung

Ein weiterer wichtiger Aspekt einer effizienten und effektiven Zusammenarbeit zwischen Betrieb und Entwicklung ist die durchgehende Betrachtung einer Anwenderaktion. Das heißt, vom Klick auf den Browser oder Fat Client über das Netzwerk bis in das Backend und die Datenbanken. Das Verfolgen einer Anwenderaktion über alle beteiligten Komponenten hinweg ist das Hilfsmittel schlechthin, um schnell die Ursachen von den Problemen abzugrenzen und den richtigen Verantwortlichen zuzuweisen.

Effiziente Zusammenarbeit heißt auch, die Ressourcen der jeweiligen anderen Partei nur in Anspruch zu nehmen, wenn es notwendig ist. Gerade bei den hochkomplexen und heterogenen Anwendungslandschaften von heute ist es zwingend erforderlich zu wissen, welche APIs, Komponenten, Codezeilen und SQL-Statements wie, wann und wie häufig innerhalb einer Anwenderaktion verwendet werden. Nur dann kann man sicher entscheiden, welches Entwicklungsteam oder welcher Bereich der Anwendungsarchitektur die Problemlösung übernehmen soll.

Viele APM-Werkzeuge bieten hierzu eine Service Map gefiltert auf eine einzelne Anwenderaktion, die zusätzlich die prozentuale Verteilung der gemessenen Performance auf die beteiligten Komponenten darstellt. Blicken nun Entwicklung und Betrieb gemeinsam auf diese Sicht, gibt es keine Reibungsverluste bei der Ursachenermittlung und Verantwortungszuweisung. Außerdem lassen sich die Anzahl der Teilnehmer eines War Room oder Troubleshootings auf das Wesentliche reduzieren und damit viel Zeit und Ressourcen sparen.

Service Map für eine einzelne Anwenderaktion. 99,5 Prozent der gemessenen Antwortzeit wird zwischen E-Commerce-Service und XE-Oracle-DB verbraucht. Bei einem War Room würde man sich auf diese beiden Teams beschränken (Abb. 3).

Ohne APM-Tools bestehen diese meist aus Experten des beteiligten Teams einer Anwendung. Dabei gibt es eine lineare Abhängigkeit zwischen Komplexität der Anwendung und Anzahl der beteiligten Personen. Und dennoch schaut jeder der Beteiligten nur auf sein Kerngebiet – eine echte Zusammenarbeit bleibt damit aus. Das führt beispielsweise zu War-Room-Szenarien, die über mehrere Wochen dauern und alles andere als agil sind.