Einführung
Warum nunmehr jedes Unternehmen auch Technologiezentrum ist
Für Unternehmen quasi aller Branchen sind Entwicklung, Bereitstellung und Betrieb von Software nunmehr strategische Priorität.
Einigen geht es dabei insbesondere darum, auf sich konstant ändernde Kundenanforderungen reagieren und wettbewerbsstark bleiben zu können. Andere möchten auf Märkten mit einem steten Einströmen neuer Konkurrenten disruptiv auftreten.
Ganz branchenunabhängig steht jedoch fest: In nahezu jeder Hinsicht ist Software der Dreh- und Angelpunkt zur Definition von Erlebnissen für bestehende wie potenzielle Kunden gleichermaßen. Dies beginnt bei der ersten Kontaktaufnahme und erstreckt sich konsistent bis zum detailliertesten Interaktionspunkt.
Umso wichtiger also, dass diese Kundenerlebnisse stets verfügbar, online abrufbar und zudem von einem hochperformanten Rückgrat gestützt sind.
100 % Verfügbarkeit: Ein Luftschloss
Anwendungen erhalten fortlaufend Updates und Verbesserungen, es kommt also unweigerlich zu Downtime.
Das komplexe Geflecht aus Systemkomponenten und Infrastruktur, das all diese Anwendungen am Laufen hält, erschwert die Arbeit von Tech- und DevOps-Teams in diesem Zusammenhang zudem. Und dann wäre da ja auch die noch komplexere Vernetzung aus verteilten Web-Agents zur Überwachung aller Stack-Bestandteile.
Wenn also etwas schief läuft und die Software reagiert langsam oder fällt sogar komplett aus, ist jede zusätzlich für Fehlerdiagnose und -behebung verwendete Minute eine zu viel.
Den Fehler ausmachen zu können reicht jedoch nicht aus. Wichtig ist es vielmehr ebenso, die genaue Ursache und eine geeignete Reaktion identifizierbar zu machen. Hierfür ist ein kompletter Verlauf aller Ereignisse und Systeminteraktionen vonnöten. Nur wie kommt man an diesen?
Auf den Kontext kommt es an
Und für den benötigen Sie eine konsolidierte Übersicht Ihrer Telemetriedaten. Denn nur dann offenbaren sich direkte Zusammenhänge zwischen dem Erlebnis Ihrer Kunden und Ihren Anwendungen, Ihren Anwendungen und Ihrer Infrastruktur und letztlich zwischen dieser und allen anderen Systemen.
Können Sie diese Verbindungen sichtbar machen, wird erkennbar, was schief gehen könnte, was schief gegangen ist und warum sowie was dagegen zu tun ist.
In diesem Leitfaden sehen wir uns an, warum diese Kontext-Observability so wichtig ist und warum sie Ihnen bislang noch fehlt.
Downtime und harte Kosten (und noch härtere Kosten, die viele übersehen)
Oberflächlich betrachtet sind die harten Kosten von System-Downtime recht schnell berechnet.
Durchschnittliche Kosten pro Minute Downtime multipliziert mit der Anzahl selbiger – voilà.
Zu Thanksgiving 2019 war die Website des US-Großhändlers Costco für mehrere Stunden nicht erreichbar. Experten bezifferten den dabei entstandenen Schaden durch entgangene Verkäufe auf rund 11 Millionen US-Dollar.
Die durch Downtime verursachten Kosten variieren natürlich von Branche zu Branche und fallen auch bei jedem Unternehmen anders aus. Gewisse Durchschnittswerte bieten jedoch eine brauchbare Richtschnur.
Die durchschnittlichen Downtime-Kosten pro Minute etwa bemisst Gartner mit ca. 5.600 US-Dollar. Die gesamte Bandbreite erstreckt sich jedoch von 140.000 bis 540.000 US-Dollar pro Stunde – ein signifikantes Spektrum.
Für 98 % aller Unternehmen belaufen sich die Downtime-Kosten auf über 100.000 US-Dollar pro Stunde, wobei 81 % den Wert auf über 300.000 US-Dollar/Stunde spezifizieren und wiederum 33 % dieser sogar auf zwischen 1 und 5 Millionen US-Dollar.
Die quantifizierbaren Kosten
Im besten Fall wird ein Fehler vom Engineering-Team bemerkt, bevor er kundenseitig zum Problem wird. Im schlimmsten Fall jedoch bleibt er sekunden-, minuten- oder sogar stundenlang unbemerkt, bis er einem Kunden und erst durch dessen Hinweis auch dem Unternehmen auffällt.
Stellen wir uns ein E-Commerce-Unternehmen vor, bei dem das Zahlungs-Gateway für fünf Minuten ausgefallen ist.
Befassen sich nun fünf Engineering-Mitarbeiter zwei Stunden lang mit der Prüfung, Behebung und Dokumentation des Incidents, entsprechen die Kosten für die Wiederherstellung der Verfügbarkeit dem Stundensatz eines Engineers multipliziert mit dem Faktor 10.
Fehlt da nicht noch etwas? In der Tat: Entgangene Verkäufe müssen ebenfalls berücksichtigt werden.
Nehmen wir an, das Unternehmen verkauft im Schnitt 24.000 Artikel pro Minute mit einem Gesamtvolumen von 280.000 US-Dollar. Pro Minute kann man die entgangenen Verkäufe also mit eben diesen 280.000 US-Dollar beziffern, allerdings sind da ja nun auch noch 24.000 unzufriedene Kunden.
Die Aufwendungen dafür, diese überhaupt jemals als Kunden gewonnen zu haben, die Auswirkungen negativer Berichterstattung und entsprechender Mundpropaganda sowie die Kosten zur Neukundengewinnung müssen somit auch noch mit eingerechnet werden.
Die härteren Kosten
Ausfälle und Downtime haben auch Humankosten zur Folge. Von Weckerklingeln um 3 Uhr nachts über Urlaubsunterbrechnungen bis hin zu Jobverlust – Analyse und Behebung von Downtime-Problemen belasten Ihre Teams auf ganz verschiedene Art und Weise. Und ob es nun das konstante Aufleuchten von Instant-Messenger-Nachrichten ist oder das Frustrationspotenzial, das Fehlern ganz naturgemäß innewohnt, vor gewissen Abnutzungserscheinungen ist kein Team gefeit.
Die Opportunitätskosten sind sogar noch höher. Werden etwa DevOps- und IT-Mitarbeiter von strategisch wichtigen Projekten abgezogen und stattdessen Aufgaben rund um Ausfälle und Performance-Probleme zugeteilt, geht dies mit Produktivitätsverlusten einher.
Dabei handelt es sich um die womöglich signifikantesten Geschäftskosten, die gleichzeitig auch am schwersten zu bemessen sind.
Ihre Quantifizierung wird von der jeweiligen Wachstumsstrategie abhängen sowie von der Rolle, die die Software-Bereitstellung dabei einnimmt, und dem Wert der Infrastruktur im Unternehmen.
Einen hohen Preis wird man aber in jedem Fall bezahlen müssen, und die indirekten Konsequenzen sind weitreichend. So ist mit dem Verlust von Kunden an Wettbewerber, verpassten Marktchancen und geschäftlicher Stagnation zu rechnen.
Die Grenzen der Verlässlichkeit und Wiederherstellung nach Maß
Downtime kostet Geld. Noch teurer wird es jedoch bei einem Mangel an Kontext, denn dieser ist gleichbedeutend mit wiederkehrender Downtime. Die Folge dieser wiederum: immer umfangreichere Anstrengungen in punkto Fehlerbehebung und zunehmende Unzufriedenheit seitens der Kunden.
Ohne den Kontext hinter Ihrer Downtime zu kennen, ist keine smarte Wiederherstellung möglich – denn egal, wie schnell diese gelingt, Sie bleiben anfällig wie eh und je.
Wieso ist dieser aber so schwer zu erfassen?
1. Zunehmende Komplexität von Anwendungen, Infrastruktur und Services
Die Tools, die bei Monitoring und Fehlersuche im Kontext von Monolith-Anwendungskonzepten und statischen Infrastrukturen zum Einsatz kommen, sind für die Komplexität heutiger Tech-Stacks gänzlich ungeeignet.
Moderne containerbasierte Infrastruktur im Kontext von Hybrid- oder Multicloud-Umgebungen ist naturgemäß so komponentenreich wie im steten Wandel begriffen. Sie erfordert also komplett neue operative Herangehensweisen.
Automatisierung, CI/CD-Pipelines und Kubernetes-basierte Computing-Strukturen sind stets in flux, Ressourcen werden fortlaufend migriert.
Modulare Anwendungen bestehen aus verschiedenen Open-Source- und proprietären Technologien, geschrieben in diversen Programmiersprachen und sich rasch verändernden Frameworks.
Eine höchst komplexe Angelegenheit also.
2. Diskrepanz zwischen Anwendungen und Infrastruktur
Informierte Entscheidungen erfordern eine 360°-Ansicht. Voraussetzung dieser wiederum: vollständige Transparenz für alle Anwendungen und Infrastrukturkomponenten einschließlich der Services von Drittanbietern, auf die über APIs zugegriffen wird. Wichtig ist ebenso, dass alle Zusammenhänge korrelierbar sind.
Da Infrastruktur und Anwendungen so individuell sind wie Ihr Unternehmen selbst auch, reichen statische Standard-Dashboards dafür jedoch nicht aus.
Die pro Server bereitgestellte Rechenleistung mag sich damit noch ablesen lassen. Um den Health-Status eines Systems im Kontext eines Multicloud-Workflows zu analysieren, wird hingegen eine zieloptimierte Observability-Anwendung zu entwickeln sein.
3. Tooling-Tohuwabohu
Kommen zum Monitoring verschiedener Stack-Bereiche unterschiedliche Tools zum Einsatz, entstehen unweigerlich blinde Flecken. Schlimmer noch: Es wird kaum mehr möglich sein, sich einen Gesamtüberblick der Interaktionen zwischen den einzelnen Systemen zu verschaffen.
Die Ursache von Incidents liegt oft im Verborgenen. Genau hier zeigt sich auch der indirekt anfallende Preis kostenloser Open-Source-Monitoring-Tools.
Ihnen mangelt es an Verlässlichkeit und ihre Verwaltung kostet viel wertvolle Arbeitszeit.
Jede einzelne Sekunde, in denen ein DevOps-Mitarbeiter zwischen Tools wechseln muss, ist schlicht unproduktiv und unnötig.
Die 3 Kontext-Grundessenzen
Nur mit präziser Kontext-Observability kann Fehlern präventiv entgegengewirkt, potenziell doch auftretende Problemstellungen effizient adressiert werden. Eine entsprechende Observability-Plattform sollte dabei unbedingt die folgenden Attribute aufweisen:
- Offen. So ist konsistentes Monitoring für alle aktuellen wie zukünftigen Systeme und Ausgangspunkte Ihrer Performance-Daten möglich.
- Vernetzt. So können Sie die Performance vom Kundenerlebnis im Browser oder auf dem Mobilgerät bis in die Infrastruktur nachvollziehen – ganz gleich, ob es sich dabei um eine Cloud-, On-Premise- oder Hybrid-Infrastruktur handelt.
- Programmierbar. So erstellen Sie Ihre eigenen Dashboards, Visualisierungen und Workflows in Abstimmung mit genau den Kontext-Zusammenhängen und Datenpunkten, die für Ihr Unternehmen relevant sind.
Mit diesem Dreigespann an Möglichkeiten sichern Sie Ihre Verfügbarkeit und Uptime und helfen Ihrem Team, künftige Incidents pro-aktiv zu verhindern.
Monitoring als Startpunkt, 360°-Observability als Ziel.
Fazit
Observability als Erfolgsschutz einer softwaregestützten Geschäftswelt
Software bildet den wichtigsten Interaktionspunkt zwischen Ihrem Unternehmen und Ihren Kunden. Bei Uptime, Verfügbarkeit und Performance geht es also nicht nur um Kostenfaktoren.
Es sind vielmehr drei ganz entscheidende Faktoren für die erfolgreiche Umsetzung Ihres Markenversprechens.
Der Schlüssel zu Uptime, Verfügbarkeit und Performance auf hohem Niveau liegt darin, wichtige Daten zu Ihrer Software erfassen, in Zusammenhang zu bringen und kontextgenau abbilden zu können.
Kontextdetails sind dabei wichtig, damit Sie Downtime im Stile eines führenden Software-Unternehmens angehen können: offensiv und selbstbewusst.
Ihre Betriebsabläufe gestalten sich kosten- und ressourcenschonender. DevOps- und Infrastruktur-Teams dürfen endlich entspannten Abenden und Wochenenden entgegenblicken.
Am wichtigsten: Ihre Kunden werden spüren, dass sie sich stets auf Ihre Aussagen verlassen können.
Es geht um die Umsetzung Ihres Markenversprechens – in Vollendung.
Wir sind New Relic. Und bei diesem E-Book geht es um Sie.
New Relic One ist eine offene, vernetzte und programmierbare Plattform, die Ihnen umfassende Kontext-Observability für Ihren gesamten Tech-Stack vermittelt. Sie verschafft Ihnen einen konsolidierten Überblick all Ihrer Daten: vom Kundenerlebnis über Browser und Mobilgeräte bis hin zu Ihren Anwendungen und Ihrer Infrastruktur, ganz unabhängig von der Umgebung. Blinde Flecken werden reduziert, komplexe Zusammenhänge über Abteilungsgrenzen hinweg durch Kontext aufgelöst. Probleme können so rasch identifiziert und behoben werden.
Hier erfahren Sie, wie wir Ihnen bei Ihrer Verfügbarkeit und Uptime helfen können.