Bildquelle: Bildquelle: Pexels / Foto-ID 257736 / https://www.pexels.com/photo/257736/ / C00 Lizenz
Green IT scheitert im Alltag selten an fehlenden Absichtserklärungen. Schwieriger ist die kleine Dauerlast im Betrieb: Testserver bleiben an, Pilotumgebungen werden nicht beendet, Cloud-Ressourcen laufen nach einer Migration weiter und niemand fühlt sich zuständig. Jede einzelne Umgebung wirkt harmlos. Zusammen werden daraus Kosten, Stromverbrauch und zusätzliche Betriebsfläche.
Für ITSM-Generalisten ist Green IT deshalb keine reine Nachhaltigkeitskampagne. Es geht um saubere Betriebssteuerung. Wer eine Umgebung nicht einem Owner, einem Zweck und einem Ende zuordnet, kann später weder Kosten noch Energieverbrauch verlässlich erklären.
Green IT meint den bewussten Umgang mit Energie, Ressourcen und Lebenszyklen digitaler Systeme. Im Betrieb wird das praktisch, wenn Services, Testumgebungen und Cloud-Ressourcen nicht unbegrenzt laufen, sondern regelmäßig auf Nutzen, Abhängigkeiten und Abschaltfähigkeit geprüft werden. Die beste Nachhaltigkeitsregel ist deshalb oft eine einfache Owner- und Enddatumsregel.
Testsysteme brauchen ein Ende, nicht nur einen Start
Eine neue Testumgebung ist schnell begründet. Ein Release muss geprüft werden, ein Provider liefert eine Schnittstelle, ein Fachbereich testet ein Portal oder ein Team probiert eine neue Automatisierung aus. Beim Start ist der Nutzen sichtbar. Beim Ende fehlt oft die gleiche Aufmerksamkeit.
Genau dort entsteht Dauerlast. Die Umgebung bleibt erreichbar, weil vielleicht noch jemand Daten braucht. Der Cloud-Dienst läuft weiter, weil niemand sicher ist, ob er noch in einem Prozess steckt. Das Monitoring ignoriert die Umgebung, weil sie nicht produktiv ist. Die Rechnung oder der Energiebericht zeigt später nur, dass Verbrauch entstanden ist. Er erklärt aber nicht, warum.
Owner-Regel schlägt Abschaltaktion
Eine einmalige Aufräumaktion kann helfen, löst das Grundproblem aber nicht. Nach wenigen Wochen entstehen neue Testsysteme. Besser ist eine einfache Betriebsregel: Jede nicht produktive Umgebung bekommt beim Anlegen einen Owner, einen Zweck, ein geplantes Prüfdatum und eine Abschaltentscheidung.
Der Owner ist dabei nicht nur ein Name in einer Liste. Er bestätigt, wofür die Umgebung gebraucht wird, welche Abhängigkeiten existieren und wann der Nutzen endet. Wenn der Owner wechselt oder die Umgebung länger läuft, muss diese Entscheidung sichtbar erneuert werden. So bleibt der Betrieb handlungsfähig, statt alte Systeme aus Angst vor Nebenwirkungen stehen zu lassen.
Green IT braucht dieselben Nachweise wie Kostensteuerung
Die Internationale Energieagentur beschreibt Rechenzentren und digitale Infrastruktur als wachsenden Energieverbraucher. AWS stellt im Sustainability Pillar des Well-Architected Frameworks ebenfalls die Frage, wie Workloads mit weniger unnötigem Ressourcenverbrauch betrieben werden können. Für ITSM heißt das: Energie- und Kostenfragen gehören näher an Servicekatalog, Change-Prozess und regelmäßige Betriebsreviews.
Wer nur monatlich auf Kosten oder Energie schaut, reagiert spät. Besser ist ein kleiner Nachweis direkt am Arbeitsobjekt. Warum existiert die Umgebung? Wer nutzt sie? Welcher Service wäre betroffen, wenn sie abgeschaltet wird? Wann wurde zuletzt geprüft? Gibt es ein Ticket zur Verlängerung oder Beendigung? Diese Informationen machen Green IT konkret.
Cloud-Ressourcen brauchen eine sichtbare Rückfrage
In der Cloud ist das Problem besonders leicht zu übersehen. Ressourcen können schnell erstellt werden, verursachen aber weiter Kosten und Energiebedarf, solange sie laufen oder Speicher halten. Ein ausgeschalteter Server ist nicht automatisch kostenfrei, wenn Volumes, Snapshots, Datenbanken oder öffentliche IP-Adressen bleiben. Ein gelöschter Test kann außerdem riskant sein, wenn noch ein Fachbereich Daten daraus erwartet.
Deshalb sollte die Rückfrage nicht nur lauten: Kann das weg? Besser ist: Welcher Zweck ist noch offen, welcher Service hängt daran und wer bestätigt das Ende? Diese Formulierung schützt den Betrieb und macht trotzdem Druck auf überflüssige Ressourcen.
So baust Du die Abschaltregel in den ITSM-Alltag ein
- Erlaube neue Testsysteme nur mit Owner, Zweck und geplantem Prüfdatum.
- Setze für Pilot- und Migrationsumgebungen ein Enddatum im Ticket oder Servicekatalog.
- Prüfe vor der Abschaltung Service-Abhängigkeiten, Datenbedarf und offene Fachbereichszusagen.
- Dokumentiere die Entscheidung: verlängern, umwandeln, archivieren oder abschalten.
- Lege fest, wer eine Verlängerung fachlich und finanziell bestätigt.
- Berichte nicht nur Euro-Kosten, sondern auch die Zahl offener Dauerläufer.
- Wiederhole die Prüfung in einem festen Betriebsrhythmus, nicht erst nach einer hohen Rechnung.
Der Service Desk profitiert ebenfalls
Eine saubere Abschaltregel hilft nicht nur Nachhaltigkeit und Kosten. Sie reduziert auch Störungen. Alte Testsysteme erzeugen Alarme, verwirren Inventardaten, enthalten veraltete Zugänge oder werden bei Sicherheitsprüfungen falsch bewertet. Wenn klar ist, welche Umgebung noch lebt und warum, werden Tickets schneller eingeordnet.
Auch Audits werden einfacher. Ein Prüfer muss nicht glauben, dass eine Ressource noch gebraucht wird. Er sieht Owner, Zweck, Prüfdatum und Entscheidung. Das ist deutlich belastbarer als eine nachträgliche Erklärung, warum ein Testsystem seit Monaten weiterlief.
Green IT beginnt mit einer Betriebsentscheidung
Stromverbrauch im IT-Betrieb lässt sich nicht allein durch neue Technik steuern. Entscheidend ist, ob die Organisation unnötige Last erkennt und sicher beendet. Dafür braucht es keine große Nachhaltigkeitsplattform als ersten Schritt. Es reicht oft eine verbindliche Owner-Regel für Testsysteme und Cloud-Ressourcen.
Die praktische Frage lautet: Welche Umgebung läuft noch, obwohl ihr Zweck nicht mehr geprüft wurde? Wenn diese Frage regelmäßig im ITSM-Prozess auftaucht, wird Green IT vom Leitbild zur Betriebsroutine.
Quellen und Stand: Quellenprüfung am 27.07.2026. Einordnung zum Energiebedarf digitaler Infrastruktur nach International Energy Agency, Energy and AI, zu nachhaltiger Workload-Gestaltung nach AWS Well-Architected Sustainability Pillar und zu Cloud-Kosten- und Nachhaltigkeitsarbeit nach FinOps Foundation Workload Optimization.
Bildquelle: Pexels / Foto-ID 257736 / https://www.pexels.com/photo/257736/ / C00 Lizenz