Welche KPIs sollten Teams für den Infrastrukturbetrieb in einem einheitlichen Betriebs-Dashboard verfolgen?

Teams für den Infrastrukturbetrieb sollten KPIs verfolgen, die Angebot, Effizienz, Servicequalität, Kosten und Verbrauch gemeinsam erklären. Das Betriebsmodell der Quelle nutzt genau diese fünf Kategorien, weil keine einzelne Kennzahl erklären kann, ob Infrastruktur gesund, produktiv, wirtschaftlich ist und den erwarteten Service liefert.

Ein gutes Dashboard sollte daher mehr beantworten als „Läuft die Hardware?“ Es sollte auch beantworten: „Wie viel nutzbare Kapazität bleibt übrig, wie gut wird sie genutzt, welche Qualität wird geliefert, was kostet es, und wer verbraucht es?“

Was sind die fünf KPI-Gruppen im Modell der Quelle?

Das einheitliche Operations-Cockpit gruppiert Indikatoren in fünf Kategorien:

Ressourcenangebot
Produktionseffizienz
Servicequalität
Betriebskosten
Geschäftsverbrauch

Das interne Share-Material verwendet außerdem eine Zusammenfassung mit vier Kategorien, die den Betriebsfokus in Ressourcenangebot, Produktionseffizienz, Servicequalität und Betriebskosten bündelt.

Das detailliertere Cockpit fügt Geschäftsverbrauch als eigene Kategorie hinzu.

Beide Ansichten sind konsistent.

Der Unterschied liegt darin, wie viel von der Verbrauchsseite explizit gezeigt wird.

Das Fünf-Kategorien-Modell ist nützlich, weil es die gesamte Betriebskette von der Infrastrukturkapazität bis zum Service-Output abdeckt.

Was sollte unter Ressourcenangebot gemessen werden?

Ressourcenangebot sollte zeigen, wie viel Kapazität existiert und wie viel davon nutzbar ist.

Die Beispiele der Quelle umfassen:

Accelerator-Karten insgesamt
Verfügbare Accelerator-Karten
Nodes insgesamt
Online-Nodes
Verteilung der Cluster-Kapazität
Warnungen zum Kapazitätsniveau
Prognostiziertes Erweiterungsdatum

Für breitere Infrastruktur kann dieselbe Kategorie Folgendes umfassen:

Server
Virtuelle Maschinen
Storage-Kapazität
Netzwerkkapazität
Rack-Platz
Leistungsreserve
Kühlreserve

Das genaue Objekt hängt von der Umgebung ab.

Die wichtige Unterscheidung ist die zwischen installiert und nutzbar.

Ein Node, der offline, degradiert, in Wartung oder durch eine andere Einschränkung blockiert ist, sollte nicht als voll verfügbare Produktivkapazität gezählt werden.

Warum ist verfügbare Kapazität wichtiger als Gesamtkapazität?

Weil die Gesamtzahl der Assets überzeichnen kann, was das Geschäft tatsächlich nutzen kann.

Das KI-Infrastrukturmodell der Quelle zeigt wiederholt, dass einsetzbare Kapazität von mehreren Einschränkungen abhängt.

Ein Rack kann U-Platz haben, aber keine Leistung.

Eine GPU kann vorhanden, aber degradiert sein.

Ein Ressourcenpool kann freie Karten haben, aber die falsche Topologie oder Ressourcenform.

Ein Storage-Pool kann freie Terabyte haben, aber unzureichenden Durchsatz.

Der KPI sollte daher nominelles Angebot von nutzbarem Angebot unterscheiden.

Das macht Kapazitätsentscheidungen realistischer.

Für die physische Seite erklärt wie Rechenzentren gestrandete Kapazität erkennen können, die durch Strom-, Kühl-, Netzwerk- oder Storage-Einschränkungen verursacht wird, warum eine einzelne Zahl für freie Ressourcen oft irreführend ist.

Was sollte unter Produktionseffizienz gemessen werden?

Produktionseffizienz zeigt, ob teure Kapazität nützliche Arbeit leistet.

Das Dashboard der Quelle umfasst:

GPU-Auslastung
Laufende Tasks
Wartende Tasks
Abgeschlossene Tasks
Leerlaufrate
Erfolgsquote der Tasks
Wartezeit
Leerlaufgrund und Empfehlungen

Diese Indikatoren wirken zusammen.

Auslastung allein kann irreführend sein.

Ein Node kann hohe Auslastung zeigen, während Tasks wiederholt fehlschlagen.

Ein Cluster kann niedrige Auslastung zeigen, weil wenig Nachfrage besteht.

Er kann auch niedrige Auslastung zeigen, weil Storage langsam oder Ressourcen fragmentiert sind.

Deshalb koppelt das Modell der Quelle Auslastung mit Warteschlangen- und Task-Metriken.

Effizienz sollte im Kontext interpretiert werden.

Warum sollte die Leerlaufrate ein KPI sein?

Die Leerlaufrate übersetzt ungenutzte Kapazität in ein Betriebssignal.

Das Cockpit der Quelle führt die Leerlaufrate im Kostenbereich.

Das detaillierte Betriebsmodell analysiert außerdem Leerlaufgründe und liefert Empfehlungen.

Das ist wichtig, weil Leerlaufkapazität mehrere Ursachen haben kann.

Keine Nachfrage.

Überdimensionierte Allokation.

Storage-Engpass.

Netzwerk-Engpass.

Ressourcenfragmentierung.

Health-Ausschluss.

Quota.

Der KPI sollte daher zur Ursache führen, statt beim Prozentwert stehen zu bleiben.

Eine hohe Leerlaufrate ist ein Symptom.

Die Maßnahme hängt davon ab, warum die Ressourcen im Leerlauf sind.

Was sollte unter Servicequalität gemessen werden?

Servicequalität sollte messen, ob der gelieferte Service seinen erwarteten Betriebsstandard erfüllt.

Die Beispiele der Quelle umfassen:

Token-Erfolgsquote
Erfolgsquote der Tasks
Offene Alarme
Gesunde, warnende und ausgefallene Nodes
SLO
Error Budget
Fehlererkennungszeit
Recovery-Zeit

Diese Kategorie verbindet den Infrastrukturbetrieb mit der Service-Erbringung.

Eine Ressource kann online sein, während die Servicequalität schlecht ist.

Zum Beispiel:

Alle Nodes online.

Token-Erfolgsquote sinkt.

Latenz steigt.

Der KPI für Geräteverfügbarkeit sieht gesund aus.

Der Service ist es nicht.

Deshalb gehören Service-Level-Indikatoren neben Infrastruktur-Indikatoren.

Warum sollten MTTD und MTTR einbezogen werden?

Weil Verfügbarkeit allein nicht zeigt, wie effektiv das Operations-Team mit Incidents umgeht.

Das SRE-Framework der Quelle umfasst Fehlererkennung und Recovery-Dauer.

MTTD misst, wie schnell ein Problem sichtbar wird.

MTTR misst, wie schnell der Service gemäß der Definition der Organisation wiederhergestellt wird.

Diese Indikatoren zeigen, ob sich Monitoring, Diagnose, Workflow und Automatisierung verbessern.

Bleibt die Anzahl der Incidents ähnlich, sinkt aber der MTTR deutlich, wird Operations effektiver.

Für das vollständige Framework erklärt wie SRE-Kennzahlen wie MTTD, MTTR, SLO, Error Budgets und Burn Rate auf KI- und Infrastrukturbetrieb angewendet werden, wie die Zuverlässigkeitskennzahlen zusammenwirken.

Was sollte unter Betriebskosten gemessen werden?

Betriebskosten sollten Kapazitätsverbrauch mit finanzieller Auswirkung verbinden.

Das Cockpit der Quelle umfasst:

Monatliche Accelerator-Kartenstunden
Leerlaufrate
Token-Stückkosten

Die interne Share-Version erfasst außerdem:

Kosten pro tausend Token
Projektabrechnung
Tenant-Abrechnung

Das umfassendere Metering-Modell verbindet Accelerator-Stunden, Energie, Token, Projekte, Tenants und Modelle.

Das gibt dem Dashboard mehrere nützliche Kostenansichten.

Gesamtverbrauch.

Stückkosten.

Leerlaufkosten.

Kosten nach Verantwortlichem.

Die wichtige Anforderung sind konsistente Definitionen.

Wenn Kartenstunden auf einer Seite allozierte Zeit bedeuten und auf einer anderen aktive Zeit, wird der KPI unzuverlässig.

Was sollte unter Geschäftsverbrauch gemessen werden?

Geschäftsverbrauch zeigt, wie die Infrastruktur von Projekten, Tenants, Modellen oder Anwendungen genutzt wird.

Das Cockpit der Quelle umfasst Ansichten zu Token-Volumen und Quota.

Die Metering-Schicht kann außerdem zeigen:

Projektnutzung
Tenant-Nutzung
Modellnutzung
API-Aufrufe
Accelerator-Kartenstunden

Diese Kategorie ist wichtig, weil Operations nicht nur dazu da ist, die Infrastruktur gesund zu halten.

Operations existiert, um Kapazität an Nutzer und Services zu liefern.

Verbrauchs-KPIs zeigen, ob sich die Nachfrage verändert und welche Unternehmensbereiche sie treiben.

Sie unterstützen außerdem Planung und Chargeback.

Welche Kapazitätsrisiko-KPIs sollten einbezogen werden?

Das Betriebsmodell der Quelle umfasst:

Warnung zum Kapazitätsniveau
Prognostiziertes Erweiterungsdatum
Kapazitätsprognose
Fragmentierungserkennung
Ablaufrisiko

Das bedeutet, das Dashboard sollte vorausschauende Indikatoren enthalten, nicht nur die aktuelle Auslastung.

Beispiele sind:

Aktueller Allokationsprozentsatz
Verfügbare Kapazität
Schwellenwert-Warnung
Prognostiziertes Schwellenwertdatum
Ressourcenfragmentierung
Physischer Engpass
Ablauf von Vertrag oder Support

Die genaue Prognosemethode ist in der Quelle nicht definiert.

Der KPI sollte daher keine Präzision beanspruchen, die über das zugrunde liegende Modell hinausgeht.

Wichtig ist, dass das Dashboard Operatoren hilft, herannahende Einschränkungen früh genug zu erkennen, um zu handeln.

Welche Alarm-KPIs sollten einbezogen werden?

Das Cockpit der Quelle zeigt:

Offene Alarme
Neueste Alarme
Node-Status-Ausnahmen

Die AIOps-Schicht fügt Incident-Konsolidierung und Root-Cause-Analyse hinzu.

Das übergeordnete Dashboard braucht nicht jede rohe Alarmzahl.

Es braucht genug Information, um das aktuelle operative Risiko zu zeigen.

Nützliche Indikatoren sind:

Offene Incidents
Offene kritische Alarme
Betroffene Nodes oder Services
Ungelöste Dauer
Wiederkehrende Incidents

Das rohe Event-Volumen kann weiterhin im Alarm-Center verfügbar sein.

Das Dashboard sollte die Aufmerksamkeit auf das lenken, was Handeln erfordert.

Sollten Infrastruktur-KPIs die Auswirkung auf Business-Services einbeziehen?

Ja, wenn die Beziehungsdaten verfügbar sind.

Das Datenfundament der Quelle unterstützt Business-Topologie und Impact-Analyse.

Das bedeutet, ein KPI kann unterscheiden zwischen:

Vier ausgefallenen Geräten ohne aktive Auswirkung auf den Service.

Einem ausgefallenen Gerät, das einen kritischen Service unterstützt.

Die zweite Situation verdient möglicherweise höhere Priorität.

Der Infrastrukturbetrieb wird nützlicher, wenn der Gerätestatus mit der Gesundheit des Business-Service verknüpft ist.

Für die Service-Schicht erklärt was Business Service Management ist und wie es sich von Infrastruktur-Monitoring unterscheidet, warum Impact und Verantwortlichkeit wichtig sind.

Wie sollten Energie-KPIs in das Dashboard passen?

Das Infrastrukturmodell der Quelle umfasst:

Stromverbrauch
PUE
WUE
Energie pro Token
Spitzen- und Schwachlastpreise
Energiekosten

Diese Indikatoren gehören in die Ansichten zu Betriebskosten und Facility-Effizienz.

Sie können außerdem die Kapazitätsplanung unterstützen.

Hohe Rack-Leistung kann die einsetzbare Kapazität verringern, selbst wenn noch U-Platz übrig ist.

Liquid-Cooling- und Leistungseinschränkungen können daher sowohl als Facility-KPIs als auch als Kapazitätsrisiko-Indikatoren erscheinen.

Das Dashboard sollte diese Beziehung erhalten, statt Energie als isolierte Nachhaltigkeitsseite darzustellen.

Wie sollten KPI-Definitionen verwaltet werden?

Nutzen Sie ein gemeinsames Kennzahlen-Verzeichnis.

Das Cockpit der Quelle gibt an, dass seine Zahlen aus den bestehenden Erfassungs- und Metering-Systemen stammen und nicht manuell neu eingegeben werden.

Das ist die richtige Regel.

Definieren Sie für jeden KPI:

Name
Quelle
Berechnung
Zeitfenster
Aggregationsmethode
Einheit
Verantwortlicher
Drill-down-Ziel

Das verhindert, dass verschiedene Teams mehrere Versionen von „Auslastung“ oder „verfügbarer Kapazität“ erzeugen.

Das Cockpit sollte die vereinbarte operative Definition zeigen.

Wie viele KPIs sollte der erste Bildschirm zeigen?

Das Design der Quelle bevorzugt eine kleine Anzahl an Kategorien mit anschließendem Drill-down.

Das ist ein nützliches Prinzip.

Der erste Bildschirm sollte genug zeigen, um den aktuellen Betrieb schnell zu verstehen.

Detaillierte Komponentenmetriken gehören in Fachansichten.

Eine Center-Leitung braucht nicht jeden Storage-Zähler auf dem ersten Bildschirm.

Ein Storage-Engineer braucht diese Zähler weiterhin nach dem Drill-down.

Das Dashboard sollte daher die Indikatoren priorisieren, die Entscheidungen verändern.

Mehr Metriken schaffen nicht automatisch mehr Sichtbarkeit.

Wie sollten sich KPIs nach Rolle unterscheiden?

Das Modell der Quelle definiert unterschiedliche Prioritäten je nach Nutzer.

Center-Leitung:

Gesamtangebot
Trends
Kapazitätsrisiko
Kosten

Operations-Rolle:

Effizienz
Leerlaufrate
Kosten
Kapazität

Bereitschaftsrolle:

Node-Status
Aktuelle Alarme
Ausfälle
Recovery

Geschäftsanwender:

Verbrauch
Quota
Servicequalität

Die zugrunde liegenden Definitionen bleiben gleich.

Die Darstellung ändert sich je nach Rolle.

Das reduziert Unübersichtlichkeit, ohne getrennte Versionen der Wahrheit zu erzeugen.

Was ist der minimal nützliche KPI-Satz?

Ein an der Quelle orientiertes Minimum könnte umfassen:

Verfügbare Kapazität
Anzahl der Online-Nodes
Auslastung
Laufende und wartende Tasks
Erfolgsquote von Tasks oder Services
Offene Betriebsalarme
Leerlaufrate
Stückkosten
Verbrauchsvolumen
Kapazitätsschwellenwert-Datum

Diese Indikatoren decken Angebot, Effizienz, Zuverlässigkeit, Kosten, Verbrauch und zukünftiges Risiko ab.

Ein Plattformbeispiel, das Operations um diese KPI-Kategorien herum organisiert, ist Sensaka.

Würde ich die erste Version eines einheitlichen Operations-Dashboards entwerfen, würde ich mit einer Kennzahl aus jeder Entscheidungskategorie beginnen statt mit 50 Fachmetriken. Zeigen Sie nutzbares Angebot, Auslastung, Service-Erfolg, aktuelles operatives Risiko, Stückkosten und Geschäftsverbrauch. Lassen Sie dann jeden KPI zu den dahinterliegenden Belegen führen.