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 zeigen kann, ob Infrastruktur gesund, produktiv und wirtschaftlich ist und den erwarteten Service liefert.

Ein gutes Dashboard beantwortet deshalb mehr als „Läuft die Hardware?“. Es beantwortet auch: „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 und Geschäftsverbrauch.

Das interne Share-Material nutzt außerdem eine Zusammenfassung mit vier Kategorien, die den Betriebsfokus in Ressourcenangebot, Produktionseffizienz, Servicequalität und Betriebskosten bündelt. Das detailliertere Cockpit führt den Geschäftsverbrauch als eigene Kategorie. Beide Ansichten passen zusammen und unterscheiden sich nur darin, wie ausdrücklich die Verbrauchsseite gezeigt wird.

Das Fünf-Kategorien-Modell hat den Vorteil, dass es die gesamte Betriebskette von der Infrastrukturkapazität bis zum Service-Output abdeckt.

Was sollte unter Ressourcenangebot gemessen werden?

Ressourcenangebot zeigt, wie viel Kapazität existiert und wie viel davon nutzbar ist. Die Beispiele der Quelle umfassen die Accelerator-Karten insgesamt und die verfügbaren Karten, die Nodes insgesamt und die Online-Nodes, die Verteilung der Cluster-Kapazität, Warnungen zum Kapazitätsniveau und das prognostizierte Erweiterungsdatum.

In breiterer Infrastruktur kann dieselbe Kategorie Server, virtuelle Maschinen, Storage- und Netzwerkkapazität, Rack-Platz, Leistungsreserve und Kühlreserve umfassen. Welche Objekte es genau sind, hängt von der Umgebung ab.

Entscheidend ist der Unterschied 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?

Die Gesamtzahl der Assets kann überzeichnen, was das Geschäft tatsächlich nutzen kann. Das KI-Infrastrukturmodell der Quelle zeigt immer wieder, dass einsetzbare Kapazität von mehreren Einschränkungen abhängt. Ein Rack hat vielleicht U-Platz, aber keine Leistung, eine GPU ist vorhanden, aber degradiert. Ein Ressourcenpool hat freie Karten in der falschen Topologie oder Ressourcenform, und ein Storage-Pool hat freie Terabyte bei unzureichendem Durchsatz.

Der KPI sollte deshalb nominelles und nutzbares Angebot trennen, damit Kapazitätsentscheidungen realistischer werden.

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 in die Irre führt.

Was sollte unter Produktionseffizienz gemessen werden?

Produktionseffizienz zeigt, ob teure Kapazität nützliche Arbeit leistet. Das Dashboard der Quelle umfasst GPU-Auslastung, laufende, wartende und abgeschlossene Tasks, Leerlaufrate, Erfolgsquote der Tasks, Wartezeit sowie Leerlaufgründe und Empfehlungen.

Diese Indikatoren muss man zusammen lesen, denn Auslastung allein täuscht leicht. Ein Node kann hoch ausgelastet sein, während Tasks immer wieder fehlschlagen. Ein Cluster kann niedrig ausgelastet sein, weil wenig Nachfrage besteht, oder weil Storage langsam ist oder Ressourcen fragmentiert sind.

Deshalb koppelt das Modell der Quelle Auslastung mit Warteschlangen- und Task-Metriken, und Effizienz muss im Kontext interpretiert werden.

Warum sollte die Leerlaufrate ein KPI sein?

Die Leerlaufrate macht aus ungenutzter Kapazität ein Betriebssignal. Das Cockpit der Quelle führt sie im Kostenbereich, und das detaillierte Betriebsmodell analysiert zusätzlich die Leerlaufgründe und gibt Empfehlungen.

Das ist sinnvoll, weil Leerlauf viele Ursachen haben kann: fehlende Nachfrage, überdimensionierte Allokation, ein Storage- oder Netzwerk-Engpass, Ressourcenfragmentierung, ein Health-Ausschluss oder eine Quota.

Der KPI sollte deshalb zur Ursache führen und nicht beim Prozentwert stehen bleiben. Eine hohe Leerlaufrate ist ein Symptom, und was zu tun ist, hängt davon ab, warum die Ressourcen stillstehen.

Was sollte unter Servicequalität gemessen werden?

Servicequalität misst, ob der gelieferte Service den 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 und 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 sind alle Nodes online, aber die Token-Erfolgsquote sinkt und die Latenz steigt. Der KPI für Geräteverfügbarkeit sieht dann gesund aus, der Service ist es nicht.

Service-Level-Indikatoren gehören deshalb direkt neben die Infrastruktur-Indikatoren.

Warum sollten MTTD und MTTR einbezogen werden?

Verfügbarkeit allein zeigt nicht, wie gut das Operations-Team mit Incidents umgeht. Das SRE-Framework der Quelle umfasst deshalb Fehlererkennung und Recovery-Dauer. MTTD misst, wie schnell ein Problem sichtbar wird, MTTR, wie schnell der Service nach der Definition der Organisation wiederhergestellt ist.

An diesen Indikatoren sieht man, ob Monitoring, Diagnose, Workflow und Automatisierung besser werden. Bleibt die Zahl der Incidents ähnlich und sinkt der MTTR deutlich, arbeitet 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 verbinden den Kapazitätsverbrauch mit seiner finanziellen Wirkung. Das Cockpit der Quelle umfasst monatliche Accelerator-Kartenstunden, Leerlaufrate und Token-Stückkosten. Die interne Share-Version erfasst zusätzlich Kosten pro tausend Token sowie Projekt- und Tenant-Abrechnung. Das umfassendere Metering-Modell verbindet Accelerator-Stunden, Energie, Token, Projekte, Tenants und Modelle.

Daraus ergeben sich mehrere nützliche Kostenansichten, nämlich Gesamtverbrauch, Stückkosten, Leerlaufkosten und Kosten nach Verantwortlichem.

Voraussetzung sind einheitliche Definitionen. Bedeuten Kartenstunden auf einer Seite allozierte und auf einer anderen aktive Zeit, kann man dem KPI nicht mehr trauen.

Was sollte unter Geschäftsverbrauch gemessen werden?

Geschäftsverbrauch zeigt, wie Projekte, Tenants, Modelle oder Anwendungen die Infrastruktur nutzen. Das Cockpit der Quelle enthält Ansichten zu Token-Volumen und Quota, und die Metering-Schicht kann außerdem Projekt-, Tenant- und Modellnutzung, API-Aufrufe und Accelerator-Kartenstunden zeigen.

Die Kategorie zählt, weil Operations mehr leisten soll, als die Infrastruktur gesund zu halten: Es soll Kapazität an Nutzer und Services liefern. Verbrauchs-KPIs zeigen, ob sich die Nachfrage verändert und welche Unternehmensbereiche sie treiben. Sie helfen auch bei Planung und Chargeback.

Welche Kapazitätsrisiko-KPIs sollten einbezogen werden?

Das Betriebsmodell der Quelle umfasst Warnungen zum Kapazitätsniveau, das prognostizierte Erweiterungsdatum, Kapazitätsprognosen, Fragmentierungserkennung und Ablaufrisiken. Das Dashboard braucht also vorausschauende Indikatoren zusätzlich zur aktuellen Auslastung.

Beispiele dafür sind der aktuelle Allokationsprozentsatz, die verfügbare Kapazität, Schwellenwert-Warnungen, das prognostizierte Datum, an dem ein Schwellenwert erreicht wird, Ressourcenfragmentierung, physische Engpässe und auslaufende Verträge oder Support.

Die genaue Prognosemethode definiert die Quelle nicht, also sollte der KPI keine Präzision vortäuschen, die das zugrunde liegende Modell nicht hergibt. Er soll Operatoren helfen, herannahende Einschränkungen früh genug zu sehen, um handeln zu können.

Welche Alarm-KPIs sollten einbezogen werden?

Das Cockpit der Quelle zeigt offene Alarme, die neuesten Alarme und Ausnahmen beim Node-Status. Die AIOps-Schicht ergänzt Incident-Konsolidierung und Root-Cause-Analyse.

Auf dem übergeordneten Dashboard muss nicht jede rohe Alarmzahl stehen. Es braucht genug Information, um das aktuelle operative Risiko zu zeigen, etwa offene Incidents, offene kritische Alarme, betroffene Nodes oder Services, die Dauer ungelöster Probleme und wiederkehrende Incidents.

Das rohe Event-Volumen kann weiterhin im Alarm-Center verfügbar bleiben. Das Dashboard sollte die Aufmerksamkeit auf das lenken, was Handeln erfordert.

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

Ja, wenn die Beziehungsdaten vorhanden sind. Das Datenfundament der Quelle unterstützt Business-Topologie und Impact-Analyse. Ein KPI kann damit vier ausgefallene Geräte ohne aktive Auswirkung auf einen Service von einem einzigen ausgefallenen Gerät unterscheiden, an dem ein kritischer Service hängt. Die zweite Situation verdient möglicherweise die höhere Priorität.

Der Infrastrukturbetrieb wird nützlicher, sobald 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 und Energiekosten. Diese Indikatoren gehören in die Ansichten zu Betriebskosten und Facility-Effizienz und helfen auch bei der Kapazitätsplanung.

Hohe Rack-Leistung kann die einsetzbare Kapazität verringern, obwohl noch U-Platz übrig ist. Einschränkungen bei Liquid Cooling und Leistung tauchen deshalb sowohl als Facility-KPIs als auch als Kapazitätsrisiko auf. Das Dashboard sollte diese Beziehung sichtbar halten, statt Energie auf eine isolierte Nachhaltigkeitsseite auszulagern.

Wie sollten KPI-Definitionen verwaltet werden?

Mit einem gemeinsamen Kennzahlen-Verzeichnis. Laut Quelle stammen die Zahlen im Cockpit aus den bestehenden Erfassungs- und Metering-Systemen und werden nicht manuell neu eingegeben, und das ist die richtige Regel.

Definieren Sie für jeden KPI Name, Quelle, Berechnung, Zeitfenster, Aggregationsmethode, Einheit, Verantwortlichen und Drill-down-Ziel. Dann erzeugen verschiedene Teams keine eigenen Versionen von „Auslastung“ oder „verfügbarer Kapazität“, und das Cockpit zeigt die vereinbarte operative Definition.

Wie viele KPIs sollte der erste Bildschirm zeigen?

Das Design der Quelle setzt auf wenige Kategorien mit anschließendem Drill-down, und das ist ein brauchbares Prinzip. Der erste Bildschirm sollte genug zeigen, um den aktuellen Betrieb schnell zu erfassen, während detaillierte Komponentenmetriken in Fachansichten gehören.

Eine Center-Leitung braucht nicht jeden Storage-Zähler auf dem ersten Bildschirm, ein Storage-Engineer braucht sie nach dem Drill-down trotzdem. Das Dashboard sollte also die Indikatoren nach vorne stellen, die Entscheidungen verändern. Mehr Metriken bringen nicht automatisch mehr Sichtbarkeit.

Wie sollten sich KPIs nach Rolle unterscheiden?

Das Modell der Quelle setzt je nach Nutzer andere Prioritäten. Die Center-Leitung sieht Gesamtangebot, Trends, Kapazitätsrisiko und Kosten. Die Operations-Rolle achtet auf Effizienz, Leerlaufrate, Kosten und Kapazität, die Bereitschaft auf Node-Status, aktuelle Alarme, Ausfälle und Recovery. Geschäftsanwender interessieren sich für Verbrauch, Quota und Servicequalität.

Die zugrunde liegenden Definitionen bleiben dabei gleich, nur die Darstellung ändert sich je nach Rolle. Das macht die Ansicht übersichtlicher, ohne getrennte Versionen der Wahrheit zu erzeugen.

Was ist der minimal nützliche KPI-Satz?

Ein an der Quelle orientiertes Minimum umfasst verfügbare Kapazität, Anzahl der Online-Nodes, Auslastung, laufende und wartende Tasks, Erfolgsquote von Tasks oder Services, offene Betriebsalarme, Leerlaufrate, Stückkosten, Verbrauchsvolumen und das Datum, an dem ein Kapazitätsschwellenwert erreicht wird. Damit sind Angebot, Effizienz, Zuverlässigkeit, Kosten, Verbrauch und künftiges Risiko abgedeckt.

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

Würde ich die erste Version eines einheitlichen Operations-Dashboards entwerfen, finge ich mit einer Kennzahl aus jeder Entscheidungskategorie an statt mit 50 Fachmetriken. Ich würde nutzbares Angebot, Auslastung, Service-Erfolg, aktuelles operatives Risiko, Stückkosten und Geschäftsverbrauch zeigen und jeden KPI zu den Belegen dahinter führen lassen.