Einheitliche Metriken für Ihre FinOps-Praxis

In diesem Blog erläutere ich die Bedeutung von Einheitsmetriken für FinOps, indem ich ein realistisches Szenario beschreibe, in dem eine Einheitsmetrik aus einer App-Funktion abgeleitet und dann zur Erstellung eines KPI für die Workload-Effizienz verwendet wird.

Einheitliche Metriken

Einheitsmetriken sind normalisierte Metriken, mit denen Sie etwas Wichtiges konsistent messen können. Es handelt sich dabei nicht um etwas, das ausschließlich für die IT oder die Cloud gilt, aber natürlich werden wir in diesem Zusammenhang darüber sprechen. Einheitsmetriken können für eine Vielzahl von Dingen verwendet werden und werden oft mit einem KPI (Key Performance Indicator) verwechselt. Ein KPI wird verwendet, um eine oder mehrere Einheitsmetriken zu überwachen. Und wenn Ihre Einheitsmetrik nicht gut konzipiert ist, ist es wahrscheinlich, dass Ihr KPI nicht von großem Nutzen sein wird. Zumindest nicht für das, wofür Sie ihn ursprünglich gedacht haben.

Um die Cloud-Effizienz trotz der Schwankungen unserer gesamten Cloud-Ausgaben messen zu können, ist es wichtig zu wissen, ob diese Kennzahlen einem bestimmten Trend im Verhältnis zu etwas anderem folgen. Normalerweise wäre das ein KPI, der auf einer Einheitsmetrik basiert. Und dieser Trend ist so zuverlässig wie Ihre Einheitsmetrik(en).

Wenn Einheitsmetriken so wichtig sind, warum werden sie dann nicht überall zur Messung der Cloud-Effizienz verwendet? Vor allem, weil komplexe Organisationen Einheitsmetriken auf Workload-Ebene benötigen. Selbst wenn Sie über ein ausgereiftes FinOps-Team verfügen, ist es für ein zentralisiertes Team nicht möglich, die Effizienz für jede Arbeitslast zu analysieren. Die Effizienz-KPIs sind für jedes Team, jede Produktlinie, jede Geschäftseinheit, jeden Service usw. einzigartig. Ein ausgereiftes FinOps-Team kann jedoch einen großen Einfluss auf die Entwicklung eines datenzentrierten Ansatzes haben, der zu Kennzahlen für die einzelnen Einheiten führt. Und diese sind die Grundlage für gute KPIs.

Die zentrale Rolle des FinOps-Teams

Ein FinOps-Team kann DevOps-Teams dazu anregen, ihre eigenen Effizienzmetriken zu erstellen und diese zu verfolgen. Diese Metriken können sich ausschließlich auf die Cloud beziehen, aber sie sollten einen Bezug zum Geschäft haben. Das FinOps-Team kann keine Einheitsmetriken für alle Arbeitslasten definieren, aber es kann die DevOps-Teams dazu auffordern (natürlich mit einer gewissen Anleitung) und die Übernahme dieser Praktiken und Richtlinien messen. Die Frage ist also: Wie viele Teams haben ihre eigenen Effizienzmetriken in Bezug auf die Cloud erstellt?

Lassen Sie mich das anhand eines Beispiels näher erläutern. Das FinOps-Team gibt einen Leitfaden heraus, der den Teams hilft, ihre eigenen Effizienz-KPIs zu erstellen. Das FinOps-Team sollte nur verfolgen, wie viele Teams/Arbeitslasten es gibt und wie viele davon ihre Effizienz-KPIs verfolgen. Etwa so:

Zentrale Cloud-Effizienzmaßnahme

• Zielsetzung: Sicherstellen, dass die DevOps-Teams die Effizienz der Arbeitsbelastung im gesamten Unternehmen verfolgen.
• Wie: Jedes DevOps-Team meldet seine Arbeitslast an das CCoE (FinOps-Team) und definiert Arbeitslast-Metriken, die verfolgt werden;
• Ziel: Innerhalb von 12 Monaten müssen alle Workloads über Effizienz-Dashboards/Berichte verfügen (vom FinOps-Team aktiviert, aber von den DevOps-Teams verwaltet und nachverfolgt)
• FinOps Team Zentrale Maßnahmen: # Anzahl der Workloads (mit Dashboards/Berichten)
• Metrik: % der Workloads mit Dashboards/Berichten
• Grundprinzip: Stellt sicher, dass sich das Unternehmen auf die Cloud-Effizienz konzentriert und nicht auf die Cloud-Kosten ohne Cotext.

Denken Sie daran, dass das FinOps-Team nicht für die individuellen Ergebnisse der einzelnen Workloads verantwortlich ist, sondern dafür, die Übernahme der Richtlinien voranzutreiben und schließlich den DevOps-Teams bei der Optimierung ihrer Workloads zu helfen. Wenn Sie diese Richtlinien befolgen, können DevOps-Teams verstehen, wie der Workload-Output am Geschäftserfolg gemessen wird. Jeder Workload hat in der Regel eine kleine Anzahl von Hauptoutputs, die die Leistung anzeigen. Die DevOps-Teams können festlegen, welche Einheitsmetriken verwendet werden sollen. Diese Metrik wird verwendet, um die Effizienz des Workloads und/oder die Kosten für jeden Geschäftsoutput zu verstehen.

Effizienz-KPIs - ein praktisches FinOps-Beispiel

Bisher habe ich gesagt, dass Effizienz-KPIs gute Einheitsmetriken erfordern und dass sie von einem FinOps-Team zentral beeinflusst und nachverfolgt werden können, aber in komplexeren Organisationen nicht von ihm erstellt werden. Aber was ist eine gute Einheitsmetrik für aussagekräftige Effizienz-KPIs?

Um dies zu beantworten, lassen Sie uns näher darauf eingehen, wie ein Team zu einem Effizienz-KPI kommen kann. Nehmen Sie zum Beispiel ein Logistikunternehmen, das Pakete ausliefert, namens "Global Post Services", kurz GPS. Wir alle lieben eine gute Track & Trace-App. Im Grunde basiert die App auf einer Datenbanktabelle mit einer eindeutigen ID, dem Track-and-Trace-Code (TTC) und allen Informationen über das Paket. Jedes Mal, wenn das Paket an einen neuen Ort gebracht wird, wird es gescannt und die Aktualisierung wird der Tabelle hinzugefügt.

Wenn der TTC generiert ist, wird er an den Kunden gesendet, der ihn verwenden kann, um die Tabelle über die schöne App abzufragen und die neuesten Informationen über sein Paket zu erhalten. Gehen wir davon aus, dass die Informationen innerhalb von 45 Tagen gelöscht werden, sobald ein Paket als zugestellt markiert wurde, und der TTC außer Betrieb genommen wird.

Eine Einheitskennzahl, die sich auf das Geschäft bezieht könnte sein, wie viel ein TTC kostet (Kosten pro TCC). Ein KPI wäre dann, die Kosten für den TCC niedriger als $"X" zu halten. Die Rechnung ist einfach: die gesamten Cloud-Kosten der App, geteilt durch die Anzahl der TTCs. Wenn dieser Wert niedriger ist als $"X", ist Ihr KPI gut. Man kann leicht dem Eindruck erliegen, dass ein solcher KPI Ihnen einen echten Einblick in Ihre Cloud-Effizienz gibt, aber in Wirklichkeit ist das nicht der Fall.

Lassen Sie uns das in Zahlen ausdrücken: Nehmen Sie ein KPI-Ziel, das besagt, dass 100 TCCs weniger als $1,06 kosten sollten. Wenn nun im Januar 100 Codes 1,05 $ kosten und im Februar 100 Codes 1,10 $ kosten, würden Sie auf den ersten Blick denken, dass der Januar effizienter war als der Februar. Aber was können Sie damit anfangen? Woran können Sie erkennen, dass Ihr DevOps-Team nicht effizient ist? Es kann sehr gut sein, dass der Anstieg zu 100 % auf das Kundenverhalten zurückzuführen ist, das wiederum durch Faktoren verursacht worden sein könnte, die nicht vom DevOps-Team kontrolliert werden. Aber wenn Sie zu dem Team gehören, das diese App entwickelt, kennen Sie all die kleinen Maßnahmen und Variablen, die sich auf die Kosten Ihrer App auswirken können. Lassen Sie uns unser Szenario näher beleuchten, um das zu verdeutlichen.

Unabhängige FinOps-Variablen

Stellen Sie sich vor, ich schicke ein wichtiges Dokument an einen Notar und möchte sichergehen, dass es ankommt. Ich zahle einen kleinen Aufpreis für die Zustellung am nächsten Tag und eine TTC. Da ich es an einen Notar in einer nahe gelegenen Stadt schicke, wird mein Paket wahrscheinlich innerhalb eines Werktages ankommen. Ich gehe davon aus, dass es innerhalb eines Werktages ankommt, und schaue daher vielleicht zweimal am Tag in der App nach, bis es zugestellt wird. Das stimmt, es sei denn, es vergeht ein ganzer Arbeitstag und ich habe keine Zustellungsbestätigung. Dann werde ich die App jede Stunde aktualisieren und wahrscheinlich 5-10 Mal auf die Schaltfläche "Mein Paket verfolgen" klicken. Vergessen wir nicht, dass je nach Gestaltung der App jedes Mal, wenn die Schaltfläche "Mein Paket verfolgen" in der App gedrückt wird, eine tatsächliche Abfrage sein könnte, die Kosten verursacht.

Wenn ich nun 12 Flaschen italienischen Wein aus Sizilien gekauft habe und sie in die Niederlande geliefert haben möchte, erhalte ich eine andere voraussichtliche Lieferzeit (EDT), sagen wir 10 Tage. Ich werde den Code wahrscheinlich einmal am Tag überprüfen. Das heißt, bis ich ein Update erhalte. Denn wenn die Sendung am ersten Tag von Sizilien nach Mailand verschoben wurde, besteht in meinem Kopf die Chance, dass sie innerhalb von weniger als 10 Tagen in den Niederlanden ankommt. In diesem Szenario werde ich wahrscheinlich jeden Morgen, jeden Nachmittag und jeden Abend nachsehen, weil ich auf ein Update warte.

Diese nicht Das so weit hergeholte Beispiel dient zur Veranschaulichung, dass das Kundenverhalten eine wichtige Variable ist, die nur jemand erkennen kann, der dem Arbeitsaufkommen nahe steht. Wenn Sie sagen können, dass das veränderte Kundenverhalten die Ursache für den Anstieg ist, können Sie untersuchen, wie Sie damit umgehen können. Unser Unternehmens-GPS kann nicht garantieren, dass äußere Bedingungen keinen Einfluss auf die Lieferzeit haben, aber es kann davon ausgehen, dass es bei Paketen mit einer geschätzten Lieferzeit von mehr als 2 Tagen nicht jede Stunde oder 4 signifikante Aktualisierungen geben wird. Das Team kann dann beschließen, die Ergebnisse zwischenzuspeichern und die Dinge alle 12 Stunden oder sogar einmal am Tag zu aktualisieren, wodurch der Einfluss des Kundenverhaltens auf die Kosten der App begrenzt wird.

In Zahlen ausgedrückt

Wenn ich der Product Owner (PO) bin und nach einer aussagekräftigeren Effizienzmetrik suche, kann ich mir eine Einheitsmetrik ansehen, die die Arten von TTC (Entfernung, international, Größe...) berücksichtigt und wie lange sie aktiv sind. Dann wird die neue Einheitsmetrik zu TTC-Kosten pro Typ, pro aktivem Tag.

Ein TTC Typ 1 könnte der einfachste sein. Er ist national und wird voraussichtlich 2 Tage lang aktiv sein. Wenn ich 2000 TTCs habe, die 1 Tag lang aktiv waren und 2000, die 2 Tage lang aktiv waren, dann beträgt die durchschnittliche aktive Dauer der Codes 1,5 Tage. Das macht insgesamt 4000 Codes und jeder Code war durchschnittlich 1,5 Tage lang aktiv.

Wenn die Gesamtkosten der Lösung für den Monat 500 $ betragen und ich die Kosten pro Code und aktiver Dauer wissen möchte, muss ich die Gesamtkosten durch die Anzahl der Codes und die durchschnittlichen aktiven Tage teilen (500/4000/1,5 = 0,0833).

Im folgenden Monat ändert sich das Szenario für TTC Typ 1 ein wenig. Dann hatten wir die gleichen 4000, aber 500 Codes waren 1 Tag lang aktiv, und 3500 waren 2 Tage lang aktiv. Die durchschnittliche aktive Dauer beträgt 1,875 Tage. In diesem Monat kostet uns unsere App 700 $.

Dies ist der Moment der Wahrheit für unsere Einheitsmetrik "durchschnittliche aktive Dauer". Wird sie gültig sein? Wenn unser KPI, der auf dieser Einheitsmetrik basiert, gestiegen ist, dann lautet die Antwort ja.

Wir sind davon ausgegangen, dass das Kundenverhalten die Kosten der TTC-App beeinflusst. Und je länger ein TTC aktiv ist, desto teurer wird unsere App. Auch hier werden die Gesamtkosten durch die Anzahl der Codes und die durchschnittlich aktiven Tage geteilt (700/4000/1.875 = 0,0933). In diesem Fall sind wir einer Sache auf der Spur. Wir haben eine treibender Faktor der sich direkt auf unseren KPI bezieht.

Was wäre, wenn dem nicht so wäre? Was wäre, wenn die TTC-Kosten pro Typ und pro aktivem Tag im Januar 0,0833 betragen hätten und im Februar auf 0,08 gesunken wären? Dann ist das nicht unsere Einheitsmetrik, denn eine Zunahme der aktiven Zeit sollte die Kosten erhöhen. Wir müssten einen zuverlässigeren Faktor finden, der unsere Einheitsmetrik sein könnte, und es gibt keinen besseren Ort, um mit der Suche danach zu beginnen, als Ihr DevOps-Team.

Einheitsmetriken sind einzigartig in ihrem Kontext. Die Erstellung von KPIs auf der Grundlage willkürlich definierter Einheitsmetriken ist ein Schuss ins Blaue, wenn es um die Effizienz der Cloud geht. Dies zu tun und einem DevOps-Team einen Effizienzrückgang anzulasten, ist einfach nur unfair.

Schlusswort

Zusammenfassend lässt sich sagen, dass wir uns der Einschränkungen bewusst sein müssen, die ein zentralisiertes FinOps-Team hat, aber auch über seinen wichtigen Einfluss auf die Cloud-Effizienz. Um Ihre Cloud-Effizienz zu steigern, sollten FinOps-Teams mit DevOps-Teams zusammenarbeiten, damit sie gute Unit-Metriken identifizieren und aussagekräftige FinOps-KPIs erstellen können. Binden Sie Ihre DevOps-Teams in Ihre FinOps-Praxis ein und engagieren Sie sie. So können sie mehr über ihre Arbeitslasten erfahren und ihre Arbeit besser erledigen. Ich hoffe, dieses Beispiel hilft Ihnen, ihnen zu zeigen, wie!

Dieser Blog wurde auch in der FinOps Alliance veröffentlicht.