‍

‍

Was ist Beobachtbarkeit?

Beobachtbarkeit bedeutet, das Gesamtbild zu verstehen: Es passiert etwas in Ihrer Anwendungslandschaft, das sich auf Ihre Benutzer, Ihre Kunden oder Ihr Unternehmen auswirkt.

Und Beobachtbarkeit bedeutet auch, dass man in der Lage ist, in die Daten einzudringen, wenn so etwas passiert. Man kann feststellen, was los ist, es beheben, d. h. es schnell beheben, und dann auch eine langfristige Lösung einführen, damit so etwas nicht wieder passiert.

Viele Unternehmen führen ein Monitoring oder Application Performance Monitoring durch. Sie überwachen die Infrastruktur, den Computer und das Netzwerk; im Grunde genommen betrachten sie die typischen Schichten der Infrastruktur (siehe Abbildung unten).

Wir wollen die Unternehmen dahin bringen, dass sie von außen nach innen überwachen; sie überwachen vor allem die Schicht zwischen der IT und den Nutzern, oder wo andere Unternehmen sich mit der Anwendung verbinden.

Ein Blick auf die Benutzererfahrung würde es Unternehmen auch ermöglichen, über die Rechenschicht hinauszugehen, auf der die meisten Überwachungs- und IT-Ops-Teams heute ihre Überwachung durchführen. Mit der Denkweise und den Tools von Full Stack Observability können Teams auch bis in die Netzwerkebene vordringen. Dies hilft IT-Ops-Teams zu verstehen, ob das Problem in der Rechenschicht, im Netzwerk oder in der Anwendung selbst liegt.

Oder ist es sogar ein Problem, das ich gar nicht habe? Es handelt sich um ein Problem, das sich beispielsweise über eine API eines Drittanbieters außerhalb meines Einflussbereichs befindet.

Entscheidend ist jedoch, dass die Priorisierung von Problemen und das KPI-Management darauf basieren, wie sich das Problem auf die Benutzererfahrung und damit auf den Umsatz, die Kundenzufriedenheit/den Net Promoter Score oder (je nach Branche) auf Abläufe wie Versand, Logistik, Fertigung oder interne Softwarebenutzer auswirkt.

Unternehmen tun sich in der Regel schwer, weil es einen zentralen Bereich gibt, der die Werkzeuge bereitstellt und Schulungen zu den Werkzeugen anbietet. Aber es gibt nicht annähernd genug Dialog über die Frage, "wie wir die Beobachtungsfähigkeit gut machen".

Bei Evolutio haben wir eine sehr klare Empfehlung, wie Unternehmen die Beobachtbarkeit gut umsetzen können. Und das ist wirklich der Fokus von außen nach innen.

‍

Wie äußert sich der Mangel an einer Kultur der Beobachtbarkeit heute?

Das wichtigste Ergebnis, das wir sehen, ist, dass die meisten Nutzer und Kunden Probleme melden. Und wenn ein Nutzer ein Problem meldet, haben Sie 10 Nutzer, die überhaupt nichts sagen.

Wenn sie einen großen und anhaltenden Ausfall haben, erfahren sie es erst spät. Und wenn man erst spät von einem Ausfall erfährt, ist es sehr schwer zu sagen, was die Ursache dafür ist.

Full Stack Observability von Cisco hat einen Teil, der sich Application Performance Monitoring (APM) nennt. Mit APM lässt sich leicht feststellen, was der Auslöser für den Ausfall war, denn die gesamte Zeitachse eines Ausfalls sieht aus wie ein großer Haarballen, aber der Beginn eines Ausfalls gibt Aufschluss über das Problem. APM kann sogar auf die Probleme hinweisen, die sich vor dem Ausfall kaskadierten.

In der Welt des APM ist die Zeit bis zur Wertschöpfung kurz, denn durch die Installation der Agenten können Unternehmen in den Rückspiegel schauen und erhalten Antworten.

Was ist der Unterschied zu echter Beobachtbarkeit? Das ist, wenn man anfängt, diese Frühindikatoren zu haben, die sagen: "Okay, Team, wenn das passiert, werden wir in der Regel einen Ausfall haben, und Sie wollen, dass sich jemand sofort darum kümmert und sich genau diese Sache ansieht, damit die Ursache gestoppt und behoben werden kann, bevor ein Großteil Ihres Kundenstamms davon betroffen ist."

Wir haben festgestellt, dass die Unternehmen oft nicht einmal die eigentliche Ursache herausfinden. Die Suche nach dem Problem kann manchmal fünf Tage oder länger dauern. Und wenn Ihre Teams die Ursache nicht innerhalb dieser fünf Tage finden, muss das Team die Suche oft aufgeben.

Bei der typischen Fehlerbehebung durchsucht das Team verschiedene Anwendungsprotokolle, um herauszufinden, was passiert ist. Die fragliche Anwendung hat mehrere externe Abhängigkeiten, wie hat sie also reagiert, als sich eine Abhängigkeit geändert hat? Wie sieht es mit einer zweiten Abhängigkeit aus? Eine erfolgreiche Ursachenanalyse hängt stark davon ab, dass Sie über die richtige Art von Protokollierung und Tools verfügen. Wenn Fehlerbehebungsteams etwas finden, das nicht in Ordnung zu sein scheint, schieben sie es oft sofort auf diese Ursache. Und oft ist das nicht der Grund (oder der ganze Grund).

Und das, liebe Leser, ist der Grund, warum es in Unternehmen immer wieder zu Ausfällen kommt: Sie glauben, die Ursache gefunden zu haben, und das Problem weist alle Merkmale auf, die auf eine Ursache hindeuten, und die Teams schieben alles darauf, nur um später herauszufinden, dass es nicht die Ursache war, weil es wieder passiert.

Warum ist AppDynamics die beste Observability-Lösung auf dem Markt?

Wir arbeiten mit AppDynamics zusammen, weil wir glauben, dass es die beste Beobachtungsplattform ist, um die Ziele zu erreichen, die ich gerade genannt habe. Die Analysefunktionen sind sehr flexibel und ermöglichen es IT-Mitarbeitern und Geschäftsanwendern gleichermaßen, die Daten so zu segmentieren, dass sie für die Behebung von Problemen und für Geschäftsentscheidungen von Bedeutung sind.

Nehmen wir an, Sie haben mehrere Benutzer, die eine Plattform nutzen, und Sie können sehen, welche Art von Kunde oder Benutzer betroffen ist, aus welcher Region sie kommen, was genau sie tun und wie diese Teile, die auf den ersten Blick nicht zusammenhängen, weil sie nicht durch einen roten Faden verbunden sind, in Wirklichkeit aber Teil eines vollständigen Geschäftsprozesses sind.

Beim eCommerce beispielsweise besteht ein vollständiger Geschäftsprozess (oder eine Geschäftstransaktion) für einen Nutzer darin, eine Bestellung mit einer Kreditkarte aufzugeben, denn damit verdienen die Unternehmen oft ihr Geld. Um also auschecken zu können, muss sich der Benutzer anmelden können, auf die Homepage gehen, eine effektive Suche auf der Website durchführen, etwas in den Warenkorb legen, zur Kasse gehen, den Zahlungsprozess durchlaufen und dann eine Bestätigung erhalten, dass der Checkout erfolgreich war.

Das ist ein vollständiger Geschäftsprozess.

Die Möglichkeit, den gesamten Geschäftsprozess als ein einziges Objekt zu beobachten und zu überwachen, auch wenn er nicht durch einen Thread verbunden ist, ist etwas, was AppDynamics in einzigartiger Weise leisten kann. Und das ist wirklich der Ansatz, den wir mit den meisten unserer Kunden verfolgen. Natürlich wollen wir die Benutzeraktivitäten unserer Kunden beobachten, aber wir wollen, dass sich unsere Kunden auf diese wichtigen Geschäftsprozesse konzentrieren, denn wenn diese Geschäftsprozesse unterbrochen werden oder ausfallen, verlieren unsere Kunden Einnahmen und ihre Kundenzufriedenheit leidet. Wir wollen dabei helfen, Prozesse einzurichten, um dies zu vermeiden, und eine Kultur zu schaffen, die proaktiv an diesen Geschäftsprozessen gemessen wird.

‍

Wettbewerbslandschaft

Die Wettbewerbslandschaft, in der sich AppDynamics befindet, ist eigentlich ziemlich überfüllt. Es gibt mehrere Wettbewerber, die ihren Kunden gute Angebote machen.

DataDog & Dynatrace

Eines der Probleme, auf die wir von Zeit zu Zeit stoßen, ist DataDogeine Plattform, die sich extrem leicht einbinden lässt.

Die Eingabe von Infrastrukturmetriken in DataDog ist einfach. Die Plattform verfügt über eine umfangreiche Synthetik-Funktionalität. Bevor man sich mit APM-Monitoring, Anwendungs- und Performance-Monitoring befasst, beginnen viele Leute mit Synthetik, d. h. mit gefälschtem Datenverkehr, der im Grunde genommen Ihre Website testet, um sicherzustellen, dass bestimmte Geschäftsprozesse funktionieren.

Was sind Kunststoffe? Stellen Sie sich einen Webserver vor, der bei Amazon Web Services steht und auf dem gerade ein Checkout-Prozess abläuft. Die Überwachung dieses Servers ist eine wunderbare Möglichkeit, um zu prüfen, ob ein kompletter Ausfall vorliegt. Sie ist jedoch eine wirklich schlechte Methode, um zu überprüfen, ob Schwärme von Nutzern eines bestimmten Typs entweder eine verschlechterte oder eine fehlgeschlagene Erfahrung haben.

Mithilfe von Application Performance Monitoring und Analysen können Sie feststellen, welches Benutzersegment oder welcher Kunde in welchem Maße betroffen ist. Was Datadog nicht hat, ist die Fähigkeit, Benutzer mit echtem Datenverkehr zu segmentieren, mit echter APM-Überwachung. Da Datadog nicht über die fortschrittlichen Analysefunktionen verfügt, ist es nicht möglich, den beobachteten Datenverkehr sinnvoll aufzuteilen.

Mit DataDog kann ein operativer Benutzer sagen: "OK, wir haben eine Auswirkung". Er kann jedoch nicht nur ein bestimmtes Benutzersegment betrachten, das betroffen ist, und er kann auch nicht den Prozentsatz der Benutzer sehen, die von dem auswirkenden Ereignis betroffen sind.

Dynatracehat andererseits auch eine sehr einfach zu bedienende Plug-in-Schnittstelle. Die Art und Weise, wie Sie Daten in Dynatrace erhalten, ist sehr einfach. Es hat auch sehr gute Agenten für Legacy-Software, was ebenfalls eine große Stärke von App Dynamics ist. Aber auch hier fehlen die Analysemöglichkeiten. Meiner Meinung nach sind also viele der Dinge, die wir für unsere Kunden tun, dort einfach nicht möglich.

Der andere Unterschied zwischen Datadog und AppDynamics besteht darin, dass man bei AppDynamics den Großteil der Konfiguration auf der Backplane vornimmt, d. h. man muss das Hilfsmittel und den Code nicht anfassen, sondern man nimmt die gesamte Konfiguration im AppDynamics-Controller vor, und das ist äußerst effektiv.

Das ist ein frischer Wind und eine große Abweichung von der Art und Weise, wie die Menschen seit jeher die Überwachung durchführen. Sie haben Protokolle gemacht, um Protokolle zu machen. Man muss das, was man tun will, in eine Protokolldatei schreiben, den Code testen, ihn freigeben und ihn veröffentlichen.

Bei DataDog ist es das gleiche Szenario. Wenn Sie das Aussehen von DataDog ändern möchten, müssen Sie den Code ändern, um dies zu ermöglichen. Sie müssen also Änderungen am Code vornehmen, sie testen und sie durch die Freigabe in AppDynamics bringen. Das müssen Sie nicht tun. Das ist also ein großer Vorteil. Eine weitere Sache, die wir an AppDynamics schätzen, sind die dynamische Baseline und die Funktionen. Es ist sofort einsatzbereit, unkompliziert, einfach zu bedienen und immer einsatzbereit.

Andere Plattformen

Bei vielen anderen Plattformen müssen Sie Konfigurationen vornehmen, indem Sie dem Tool sagen : "Ich möchte, dass diese Basislinie so aussieht." Auf diesen anderen Plattformen gibt es mehr Tipps und Tricks, z. B. die Nutzung saisonaler Baselines, und Sie können die Funktionsweise dieser Baselines wirklich beeinflussen.

AppDynamics verfügt nicht über diese spezifischen Baseline-Shaping-Funktionen, aber es bietet überall unkomplizierte Baselines.

Szenario-Beispiele für Beobachtbarkeit

1. Große Transformationen: Für große Kunden, die über eine sehr große IT-Landschaft verfügen, ist es ein großer Vorteil, dass sie nicht für jeden Datenpunkt, für den ein Alarm ausgelöst werden soll, spezifische Schwellenwerte festlegen oder eine Baseline konfigurieren müssen, da dies eine Menge Arbeit spart. Evolutio wird in der Regel eingesetzt, wenn ein Benutzer oder ein Unternehmen eine große Umstellung durchläuft. Vielleicht bringt der Kunde eine Menge neuer Anwendungsfunktionen und neue Möglichkeiten auf den Markt, und er hat eine große Investition getätigt, um die Änderungen zu implementieren. Es darf nicht scheitern.
   ‍
2. Die Migration in die Cloud oder die Migration in eine andere Umgebung: Migrationen sind ein riesiger, programmatischer Aufwand; manchmal ist es ein mehrjähriges Projekt, das nicht scheitern darf. Und große Projekte sind anstrengend. Mühsam bedeutet, dass IT-Teams viel Zeit mit der Fehlersuche, der Problemanalyse und der manuellen, zeitaufwändigen Ursachenanalyse verbringen. Bei der Beratung unserer Kunden durch Evolutio geht es vor allem darum, Arbeitsaufwand zu vermeiden und zu verhindern, dass Mitarbeiter ihre Zeit mit etwas verbringen, das nicht den Geschäftszielen dient, nämlich entweder neue Funktionen auf den Markt zu bringen oder in die Cloud zu wechseln oder beides gleichzeitig zu tun. Wenn wir unseren Kunden helfen, den Arbeitsaufwand zu reduzieren, können wir die Effektivität einer IT-Organisation, die neue Funktionen aufbaut, erheblich steigern. Ihre Supportstruktur unterstützt sie bei der Markteinführung dieser neuen Funktionen. Die Erfahrung, die Evolutio in den AppDynamics-Implementierungsprozess einbringt, besteht darin, dass wir es verstehen, Unternehmen bei der Skalierung von Governance und kulturellem Wandel zu helfen, und sie sind schneller... und ich meine Lichtjahre schneller.

Zentrum der Exzellenz: Schulung des Kunden zur Nutzung von AppDynamics

Wenn ein Unternehmen AppDynamics einführen will, muss es sich selbst umfassend in das Tool einarbeiten und dann alle Grundsätze der Beobachtbarkeit verstehen, wie man es richtig macht und wie man seine Teams so schult, dass sie es auf skalierbare Weise tun können. Das ist wirklich eine unüberwindbare Aufgabe.

Aber da wir schon so viele dieser großen und erfolgreichen Implementierungen durchgeführt haben, haben wir das Playbook und können die Teams schulen, wenn wir eine App einführen.

Erfolgreiche Implementierung ist ein fünfstufiger Prozess

Und das ist etwas, das wir über unser Center of Excellence in Form von Videoschulungen anbieten. Wenn wir damit fertig sind, ermöglichen wir es dem Kunden, eine Fähigkeit vollständig zu besitzen, die durch die Technologie von AppDynamics unterstützt wird, und die viel mehr mit der Fähigkeit der Beobachtbarkeit zu tun hat.

Evolutio möchte sicherstellen, dass unsere Kunden nicht das Gefühl haben, dass ein beliebiger Implementierungspartner kommt, einfach AppDynamics installiert, es zum Laufen bringt und dann ohne Auswirkungen auf das Geschäft oder eine Änderung der Teamkultur wieder geht.

Unser Center of Excellence ermöglicht eine vollständige End-to-End-Fähigkeit. Es gehört zu unserem Ethos, dass Evolutio die Organisation in die Lage versetzt, eine Kultur der Beobachtbarkeit zu entwickeln.

Warum eine Kultur der Beobachtbarkeit schulen und fördern?

Indem wir ein relativ kleines Projekt planen, das gut geplant und ausgeführt wird, und indem wir nur wenig Zeit für die Organisation und Einrichtung der Überwachung aufwenden, können wir dafür sorgen, dass sich die Kunden auf ihre normale tägliche Arbeit konzentrieren können, die in der Regel in der Anwendungsentwicklung besteht, wo sie neue Funktionen entwickeln oder eine Cloud-Migration durchführen. Dann haben sie den Vorteil, dass sie hauptsächlich geplante Arbeiten durchführen und die Teams sich auf die Arbeit an der Roadmap für die digitale Transformation konzentrieren können, anstatt während eines Ausfalls Brandschutzübungen durchzuführen.

Wenn es zu einem Ausfall kommt und ein Benutzer davon betroffen ist, handelt es sich um ungeplante Arbeit. Und oft handelt es sich um ein sehr großes Problem, bei dem jeder alles stehen und liegen lässt, um das Problem sofort zu beheben.

Wenn Unternehmen in einen Kreislauf geraten, in dem sie ständig diese ungeplanten Arbeiten erledigen müssen, die auf Mühsal hinauslaufen, hat das wirklich psychologische Auswirkungen auf die IT-Teams. Sie erreichen nie ihre Zielvorgaben, sie erreichen nie ihre Zielvorgaben.

Und die IT-Mitarbeiter haben das Gefühl, dass sie jedes Mal, wenn sie einen Sprint oder ein Burndown-Meeting abhalten, um über die Geschehnisse zu sprechen, sagen : "Der Grund, warum ich meine Ziele nicht erreicht habe, ist, dass ich sehr wichtige Arbeit für das Unternehmen geleistet und dafür gesorgt habe, dass dieser Ausfall behoben wurde."

Wir wollen nicht, dass sich unsere Teams in diesem Zustand befinden. Wir wollen sie in einem Zustand haben, in dem sie die Dinge vorantreiben. Sie haben das Gefühl, dass sie produktiv sind, dass sie Projekte, die sie beginnen, auch zu Ende bringen können. Und zwar deshalb, weil sie nicht durch ungeplante Arbeiten zur Behebung von Ausfällen von ihrem Arbeitsplan gestoßen werden.

‍

Was machen die IT-Teams von Big Tech und Google?

Bedenken Sie, wie sich unsere Kultur zu einer IT-getriebenen und IT-orientierten Kultur gewandelt hat. Sehen Sie sich die kulturelle Akzeptanz von Facebook und Instagram an: Millennials und GenZ, die mit diesen Plattformen und Tools aufgewachsen sind, die ihnen buchstäblich zur Verfügung stehen, haben eine immer geringere Geduld, wenn Anwendungen nicht funktionieren. Eine Benutzeraktion in einer Anwendung, die 2013 noch 2 Sekunden dauerte, sollte 2022 nur noch 2 Millisekunden dauern. Sie haben diese Einstellung.

Wenn Sie eine Fluggesellschaft sind und ein Benutzer versucht, ein Flugticket zu kaufen, möchte er dieses Flugticket ohne Probleme kaufen können, oder er wird zu einer anderen Website gehen und das Flugticket kaufen.

Es wird immer wichtiger, dass sich Unternehmen mit diesen Benutzerproblemen auseinandersetzen, wenn sie die Kundenbindung und das Unternehmenswachstum fördern wollen und wenn sie wollen, dass neue Funktionen, die veröffentlicht werden, erfolgreich sind.

Deshalb gibt es immer mehr Initiativen zur Beobachtbarkeit. Technologieführer beschließen: "OK, wir brauchen Teams, die sich darum kümmern".

Die Kunden von Evolutio entwickeln sich zu einem Site Reliability Engineering (SRE)-Modell, das wir ihnen ermöglichen, weil bei SRE die Denkweise der Beobachtbarkeit durchgängig verankert ist. SRE ist wirklich Teil der täglichen Arbeit von Entwicklungsteams, indem das Monitoring-as-Code-Denken früher in den SDLC eingebettet wird.

Das Site Reliability Engineering (SRE)-Spielbuch

Evolutio folgt wirklich dem SRE-Modell, das von Google vor etwa drei Jahren positioniert wurde.

Was ist das? Das Modell des Site Reliability Engineering besteht aus einem Team von Site Reliability Engineers, das von einer Gilde an der Spitze zusammengehalten wird. Das SRE-Team ist eigentlich in die Software-Entwicklungsteams eingebettet, aber seine Kontrollspanne umfasst Dutzende oder Hunderte von Anwendungen. Ein einziger SRE-Ingenieur oder -Analyst hat vielleicht zwei, drei oder zehn Anwendungen, die in seinen Zuständigkeitsbereich fallen. Von dort aus setzt dieser SRE alle seine Standards um, und die Regeln werden von der SRE-Gilde aufgestellt.

Mit dem Google SRM-Modell wollen sich Unternehmen auf die vier goldenen Signale konzentrieren, die der Endnutzer wahrnimmt.

Die vier goldenen Signale sind:

1. Anzahl der Anrufe, die durch das System laufen
2. Durchschnittliche Antwortzeit (oder 95. Perzentil der Antwortzeit, je nachdem, wie die Daten beschaffen sind)
3. Anzahl der im System vorhandenen Fehler
4. Durchsatz

Stellen Sie sich das so vor: Das Verhältnis zwischen dem gesamten Verkehrsaufkommen und dem verfügbaren Datenvolumen wird auch als Sättigung bezeichnet. Wie viel von einer bestimmten Leitung ist gesättigt? Wie viel von einer bestimmten Speicherplattform ist gesättigt? Typischerweise sehen wir, dass man dort, wo der Nutzer lebt, alle vier Goldenen Signale haben muss.

Man muss verstehen, wo man steht. Und wenn man dann nach unten geht, hat man manchmal nur ein oder zwei dieser Signale, weil die Anzahl der Fehler, die passieren, kein Problem darstellt.

Aber vielleicht ist die Sättigung wichtiger, wenn es sich um eine Speicherschicht handelt. Sie haben also vier verschiedene Schichten in Ihrem Tech-Stack, Sie haben verschiedene Versionen dieser Signale, aber das sind die, auf die Sie sich konzentrieren wollen. Wir haben eine Standard-Alarmierungsstrategie, die wir mit unseren Kunden ausrollen, wenn sie AppDynamics implementieren. Und die konzentriert sich wirklich auf die vier goldenen Signale, die für jede App, die wir entwickeln, als Standard gelten.

Evolutio arbeitet intensiv mit seinen Kunden zusammen, um eine Kultur der Beobachtbarkeit zu schaffen, so dass die Beobachtbarkeit bei wachsendem und sich veränderndem Geschäft sofort auf der Plattform vorhanden ist, sei es bei der Entwicklung oder bei der Einarbeitung von Beobachtungsinitiativen, so dass am Ende keine große Nacharbeit erforderlich ist.

Das beste Gefühl ist, wenn ich erlebe, dass Unternehmen den Moment haben, in dem ihnen ein Licht aufgeht und sie über den Horizont hinausblicken: "Wo werden wir in 3 bis 5 Jahren stehen?" Und sie sind bereit, heute die richtigen Instrumente und KPIs einzusetzen, um die gewünschten Ergebnisse in der Zukunft zu erzielen. Sie fangen an, Dinge zu sagen wie: "Lasst uns jetzt eine Monitoring-as-Code-Initiative starten, um uns für den Erfolg in 36 Monaten zu rüsten, denn wir fangen an, die Daten zu sammeln."‍

Ich finde es toll, wenn unsere Kunden nicht nur für künftige Leistungsentscheidungen gerüstet sind, sondern auch in die Lage versetzt werden, Entscheidungen darüber zu treffen, wie sie unser Unternehmen führen und die Software zur Lösung der größten betrieblichen Probleme einsetzen können, mit denen sie konfrontiert werden.

‍

‍

Evolutio kann Sie bei Ihren Observability-Initiativen unterstützen und den kulturellen Wandel vorantreiben, damit Site Reliability Engineering in Ihren Teams auf der Roadmap steht. Besuchen Sie unsere Kontakt-Seite um mit uns in Kontakt zu treten und mehr zu erfahren.