Cloud-Stromdaten nützen wenig, wenn niemand sie einem Service zuordnet

Nachhaltigkeitsdaten aus der Cloud klingen auf den ersten Blick nach einem Thema für Reporting, Einkauf oder Unternehmenskommunikation. Für den IT-Betrieb werden sie aber genau dort relevant, wo aus abstrakten Emissionswerten konkrete Serviceentscheidungen werden. Ein Dashboard kann zeigen, dass eine Region, ein Konto oder ein Workload Emissionen verursacht. Es beantwortet aber noch nicht die wichtigere Betriebsfrage: Welcher Service steckt dahinter, wer verantwortet ihn fachlich, und welche Änderung wäre tatsächlich sinnvoll?

Für ITSM- und IT-Management-Generalisten ist GreenOps deshalb kein grünes Zusatzprojekt neben FinOps. Es ist die Fortsetzung bekannter Steuerungsfragen mit einer weiteren Messgröße. Kosten, Verfügbarkeit, Risiko und Leistung werden schon heute Services zugeordnet. Wenn CO₂- und Energiedaten getrennt danebenstehen, bleiben sie ein Bericht. Erst wenn sie denselben Servicebezug bekommen, können sie in Architektur, Kapazitätsplanung, Beschaffung, Change-Management und Priorisierung wirken.

Ein Cloud-Konto ist noch kein Service

Die ersten Nachhaltigkeitsdaten kommen oft entlang technischer oder kaufmännischer Strukturen: Cloud-Konto, Subscription, Projekt, Region, Produktfamilie oder Rechnungseinheit. Diese Sicht ist notwendig, aber für ITSM nicht ausreichend. Ein Cloud-Konto kann mehrere Services enthalten. Ein Service kann über mehrere Konten laufen. Eine Plattform kann von vielen Produktteams genutzt werden. Genau an dieser Stelle verlieren Carbon-Dashboards ihren Nutzwert, wenn sie nicht mit dem Servicekatalog verbunden werden.

Ein sinnvoller Betriebsblick beginnt deshalb mit Zuordnung. Welche Emissionsdaten gehören zu welchem Business-Service, zu welchem internen Plattformservice oder zu welcher technischen Basisleistung? Welche Daten sind exakt genug, welche nur Näherung? Welche Services nutzen gemeinsam eine Infrastruktur, deren Emissionen verteilt werden müssen? Ohne diese Fragen entsteht schnell ein scheinbar präziser Bericht, der im Alltag niemandem gehört. Dann sieht die Organisation eine Kurve, aber keine verantwortbare Entscheidung.

Reporting darf nicht am Monatsende stecken bleiben

AWS beschreibt sein Customer Carbon Footprint Tool als Möglichkeit, Emissionen im Zusammenhang mit AWS-Nutzung zu verstehen. Google Cloud stellt Carbon-Footprint-Daten für Projekte und Services bereit. Microsoft Sustainability Manager bündelt Nachhaltigkeitsdaten für betriebliche Auswertungen. Solche Werkzeuge sind hilfreich, aber sie entfalten im IT-Betrieb erst Wirkung, wenn ihre Ergebnisse nicht nur rückblickend im Monatsbericht landen.

GreenOps braucht einen Rhythmus, der zur Betriebssteuerung passt. Ein monatlicher Bericht kann Trends zeigen. Für konkrete Maßnahmen reicht das oft nicht. Wenn ein neues Datenprodukt in einer energieintensiven Region startet, ein Batch-Job jede Nacht unnötig lange läuft oder Testumgebungen dauerhaft aktiv bleiben, muss die Information näher an Architektur-Reviews, Kapazitätsplanung und Change-Freigaben liegen. Sonst werden Emissionen erst sichtbar, wenn die technische Entscheidung längst zur Gewohnheit geworden ist.

Service Owner brauchen eine verständliche Metrik

Die Software Carbon Intensity Specification lenkt den Blick auf Emissionen pro funktionaler Einheit. Vereinfacht gesagt geht es nicht nur darum, wie viel CO₂ eine Software insgesamt verursacht, sondern welche Emissionen für eine definierte Nutzungseinheit anfallen können. Für Generalisten ist dieser Gedanke wertvoll, weil er die Diskussion weg vom abstrakten Gesamtwert führt. Ein Service Owner kann eher steuern, wenn sichtbar wird, ob ein Berichtslauf, eine Transaktion, ein Nutzerkonto oder ein Analysejob im Verhältnis zum Nutzen zu schwer wird.

Dafür müssen IT- und Plattformteams die Metrik übersetzen. Niemandem hilft eine Zahl, die nur Experten aus Nachhaltigkeits- oder Cloud-Abteilungen verstehen. Besser sind wenige, belastbare Leitfragen: Welche Services haben steigende Emissionen trotz gleichbleibender Nutzung? Welche Workloads laufen außerhalb sinnvoller Zeitfenster? Welche Datenhaltung wächst ohne Aufbewahrungsentscheidung? Welche Regionen oder Ressourcenklassen treiben den Fußabdruck, ohne dass ein fachlicher Grund dokumentiert ist?

Tagging wird zur Nachhaltigkeitsgrundlage

FinOps hat vielen Organisationen bereits gezeigt, wie wichtig sauberes Tagging ist. Ohne Kostenstelle, Produkt, Umgebung, Owner und Servicebezug bleiben Cloud-Kosten schwer steuerbar. Für GreenOps gilt dasselbe, nur mit einer zusätzlichen Konsequenz: Unklare Zuordnung verhindert nicht nur Kostenkontrolle, sondern auch Nachhaltigkeitssteuerung. Wenn produktive Workloads, Testumgebungen, Datenpipelines und Experimente gleich aussehen, kann niemand unterscheiden, welche Emissionen akzeptierter Betriebsaufwand sind und welche aus vergessenen Ressourcen entstehen.

Ein pragmatischer Start ist deshalb keine große Nachhaltigkeitsplattform, sondern eine verbindliche Mindestlogik für Cloud-Ressourcen. Jede relevante Ressource braucht mindestens Service, Owner, Umgebung, Kritikalität und Lebenszyklus. Für große Daten- und Rechenlasten sollten zusätzlich Zweck, geplante Laufzeit und Review-Datum sichtbar sein. Diese Informationen helfen nicht nur beim Reporting. Sie machen auch Changes, Stilllegungen und Architekturentscheidungen leichter, weil die fachliche Verbindung nicht jedes Mal neu gesucht werden muss.

Regionen sind eine Architekturentscheidung, nicht nur ein Preisfeld

Cloud-Regionen unterscheiden sich bei Latenz, Verfügbarkeit, Funktionen, Datenschutzanforderungen, Kosten und Energieprofil. Nachhaltigkeitsdaten können daher nicht isoliert über die Region entscheiden. Ein Umzug in eine andere Region kann Emissionen senken, aber Compliance, Betriebsstabilität oder Nutzererlebnis verschlechtern. Umgekehrt kann eine teurere oder emissionsärmere Option sinnvoll sein, wenn sie zu den fachlichen Anforderungen passt. Genau deshalb gehört GreenOps in Architektur- und Serviceentscheidungen, nicht nur in ein späteres Reporting.

Für ITSM bedeutet das: Change-Vorlagen und Architektur-Reviews sollten zumindest prüfen, ob die gewählte Region, Ressourcengröße und Betriebszeit begründet sind. Nicht jeder kleine Service braucht eine ausführliche Nachhaltigkeitsakte. Aber bei datenintensiven Plattformen, KI-Workloads, dauerhaften Entwicklungsumgebungen und großen Analysejobs sollte die Frage erlaubt sein, ob Laufzeit, Region, Speicherdauer und Skalierung zum tatsächlichen Nutzen passen.

Abschalten ist oft der schnellste Fortschritt

GreenOps klingt schnell nach komplexen Berechnungen. Im Alltag beginnt es häufig mit einfachen Aufräumarbeiten. Nicht mehr genutzte Entwicklungsumgebungen, überdimensionierte Datenbanken, vergessene Volumes, nächtliche Jobs ohne Nutzer, dauerhaft laufende Testcluster und unnötig lange Log-Aufbewahrung verursachen Kosten und Emissionen zugleich. Wer solche Ressourcen stilllegt oder sauber taktet, verbessert FinOps und GreenOps gemeinsam.

Der entscheidende Unterschied liegt im Prozess. Eine einmalige Aufräumaktion bringt kurzfristig Wirkung, verhindert aber keine Rückkehr alter Muster. Nachhaltige Betriebssteuerung braucht deshalb Lifecycle-Regeln: Jede nichtproduktive Umgebung hat ein Ablaufdatum, jede Ausnahme bekommt einen Owner, jede große Datenhaltung braucht eine Aufbewahrungsentscheidung, und jede automatische Skalierung wird nach realer Nutzung überprüft. Damit wird GreenOps nicht zur Moralfrage, sondern zu normaler Betriebshygiene.

Der Servicekatalog wird zum Übersetzer

Der Servicekatalog ist der natürliche Ort, um Nachhaltigkeitsdaten handhabbar zu machen. Dort stehen bereits Servicebeschreibung, Owner, Zielgruppe, Kritikalität und Supportmodell. Ergänzt man dort die wichtigsten Cloud-Zuordnungen, Datenlasten, Betriebszeiten und Reportingquellen, entsteht eine Brücke zwischen Carbon-Dashboard und Entscheidung. Der Service Owner sieht nicht nur, dass Emissionen existieren, sondern welche technische Realität dahintersteht.

Für den Einstieg reicht eine schmale Erweiterung. Pro kritischem Cloud-Service sollten die verantwortlichen Konten oder Projekte, die wichtigsten Regionen, die größten Ressourcenklassen und die zuständigen technischen Owner dokumentiert sein. Danach kann ein regelmäßiger Review prüfen, ob Kosten, Nutzung und Emissionen gemeinsam plausibel sind. Auffälligkeiten gehen nicht als abstrakter Nachhaltigkeitshinweis in die Organisation, sondern als konkrete Servicefrage an die richtige Rolle.

GreenOps braucht Governance, aber keine zusätzliche Bürokratie

Die größte Gefahr liegt darin, GreenOps als neues Parallelgremium aufzubauen. Dann entstehen eigene Tabellen, eigene Berichte und eigene Diskussionen, während die echten Entscheidungen weiter in Architektur, Beschaffung, Betrieb und Produktplanung fallen. Besser ist es, bestehende Prozesse gezielt zu ergänzen. FinOps-Reviews bekommen eine Emissionsspalte. Architekturentscheidungen dokumentieren die Region und den Betriebsmodus. Change-Reviews fragen bei großen Workloads nach Laufzeit und Rückbau. Service-Reviews betrachten Kosten, Nutzung und Emissionen gemeinsam.

So wird aus Cloud-Stromdaten ein Steuerungssignal. Nicht jede Zahl ist perfekt, und nicht jede Einsparung ist fachlich sinnvoll. Aber eine Organisation, die ihre Services sauber zuordnet, Owner sichtbar macht und Emissionen in bestehende Entscheidungen einbindet, kann überhaupt erst sinnvoll abwägen. Ohne diese Verbindung bleibt Nachhaltigkeit im IT-Betrieb ein schönes Dashboard. Mit ihr wird GreenOps zu einer praktischen Disziplin: weniger Blindflug, weniger Verschwendung und bessere Entscheidungen über die Services, die wirklich gebraucht werden.

Quellen: Green Software Foundation, Software Carbon Intensity Specification; AWS Customer Carbon Footprint Tool; Google Cloud Carbon Footprint documentation; Microsoft Sustainability Manager documentation.