Green IT beginnt im Betrieb mit einer unbequemen Abschaltliste

Green IT klingt oft nach Rechenzentrum, Einkauf und moderner Hardware. Im Alltag des IT-Betriebs beginnt es aber viel früher: mit der Frage, welche Systeme tatsächlich laufen müssen, wer den Stromverbrauch verantwortet und wer ein Testsystem wieder abschaltet, wenn der Zweck erledigt ist.

Warum Rückbau denselben Status braucht wie Aufbau

Eine Abschaltliste ist dabei kein Sparprogramm gegen den Betrieb. Sie ist eine Betriebsroutine. In ihr steht, welche temporären Systeme existieren, welchen Zweck sie haben, wem sie gehören, bis wann sie gebraucht werden und welche Folgen eine Abschaltung hätte. Ohne diese Liste bleiben alte Testumgebungen, vergessene Datenbanken, doppelte Monitoringinstanzen oder kaum genutzte Schnittstellen oft unauffällig aktiv. Sie fallen nicht auf, weil sie keinen Incident auslösen. Genau deshalb brauchen sie einen eigenen Kontrollpunkt.

Der Fehler entsteht meistens nicht beim Anlegen eines Systems. Ein Projekt braucht schnell eine Testumgebung, ein Provider richtet eine zusätzliche Verbindung ein, ein Team klont eine Datenbank für eine Migration oder ein Fachbereich verlangt eine Übergangslösung. Das kann fachlich richtig sein. Riskant wird es, wenn der Rückbau nie denselben Status bekommt wie der Aufbau. Dann wird aus einer kurzfristigen Hilfe ein dauerhafter Verbrauchsposten.

Eine Liste verbindet Nachhaltigkeit mit Servicequalität

Für den Service Desk ist das Thema praktischer, als es zunächst klingt. Wenn ein alter Dienst noch in der CMDB steht, noch überwacht wird und noch Tickets erzeugt, bindet er Aufmerksamkeit. Wenn er nicht mehr dokumentiert ist, aber technisch weiterläuft, bindet er Strom, Lizenzen und Sicherheitsprüfung. Beides stört die Betriebsübersicht. Eine Abschaltliste verbindet deshalb Nachhaltigkeit mit Servicequalität: Sie zeigt, wo ein Dienst noch gebraucht wird, wo ein Besitzer fehlt und wo ein Rückbau geplant werden muss.

Wichtig ist die Trennung zwischen Abschalten und Stilllegen. Abschalten meint zunächst, eine laufende Ressource gezielt aus dem Dauerbetrieb zu nehmen. Stilllegen bedeutet zusätzlich, Daten, Zugänge, Verträge, Abhängigkeiten und Dokumentation sauber zu schließen. Ein Server kann ausgeschaltet sein und trotzdem als offener Rest im Betrieb liegen. Umgekehrt kann ein System weiterlaufen müssen, obwohl seine Zukunft schon entschieden ist. Die Liste muss beide Zustände sichtbar machen.

Abschalten und Stilllegen sind nicht dasselbe

Ein sinnvoller Eintrag ist kurz, aber verbindlich. Er nennt Service oder System, technischen Ort, Service Owner, fachlichen Zweck, Startdatum, geplantes Enddatum, letzte Nutzung, Abhängigkeiten, Datenklasse, Rückbauentscheidung und nächste Prüfung. Dazu gehört eine einfache Ampel: behalten, prüfen, abschalten, stilllegen. Diese Ampel ersetzt keine Architekturentscheidung, aber sie verhindert, dass niemand sich zuständig fühlt.

Besonders hilfreich ist ein monatlicher Abgleich zwischen Betrieb, Finanzen und Service Ownership. Die Betriebssicht kennt Laufzeit, Monitoring, Tickets und technische Abhängigkeiten. Die Finanzsicht sieht Cloudkosten, Lizenzpositionen oder Energiekennzahlen. Der Service Owner weiß, ob der Dienst noch gebraucht wird. Erst zusammen entsteht ein klares Bild. Ohne diese Verbindung kann ein System technisch sauber erscheinen, obwohl es fachlich keinen Nutzen mehr hat.

Cloudkosten verstecken Strom nicht, sie verschieben nur den Blick

Für Cloud-Umgebungen gilt die gleiche Logik. Dort verschwindet Stromverbrauch hinter Rechnungen, Regionen, Instanztypen und Speicherkosten. Das macht ihn nicht weniger real. Ein guter Green-IT-Prozess fragt deshalb nicht nur nach Kilowattstunden, sondern nach Betriebsgründen: Warum läuft diese Ressource, wer nutzt sie, wann endet der Zweck und welche Automatisierung verhindert Dauerbetrieb nach Feierabend oder Projektende?

Auch Sicherheitsrisiken sprechen für die Abschaltliste. Alte Systeme haben oft schwächere Pflege, unklare Patchfenster oder vergessene Zugänge. Ein Dienst, der nur noch aus Gewohnheit läuft, ist nicht nur ein Nachhaltigkeitsproblem. Er kann auch zum blinden Fleck in der Resilienz werden. Green IT, Security und ITSM greifen hier ineinander: Was nicht mehr gebraucht wird, sollte nicht heimlich weiter Angriffsfläche, Kosten und Betriebsrauschen erzeugen.

Der erste Kontrollblock darf klein sein

Der Einstieg muss klein bleiben. Eine Organisation muss nicht sofort jedes Watt inventarisieren. Sinnvoller ist ein erster Kontrollblock: alle temporären Systeme der letzten drei Monate, alle Dienste ohne aktuellen Owner, alle Cloud-Ressourcen ohne Projektbezug und alle Monitoringobjekte ohne klares Serviceziel. Daraus entsteht eine Liste, die Entscheidungen vorbereitet statt Schuldige zu suchen.

Am Ende ist Green IT im Betrieb keine moralische Zusatzaufgabe. Es ist eine Frage der Steuerbarkeit. Wer weiß, welche Systeme laufen, warum sie laufen und wann sie wieder verschwinden dürfen, reduziert Stromverbrauch, Kosten, Sicherheitslücken und unnötige Betriebsarbeit. Die unbequeme Abschaltliste macht sichtbar, welche Entscheidungen bisher nur vertagt wurden.

Quellen und Stand

• Internationale Energieagentur zu Rechenzentren und Datenübertragungsnetzen, abgerufen am 09.07.2026: Data centres and data transmission networks
• Internationale Energieagentur, Report `Energy and AI`, abgerufen am 09.07.2026: Energy and AI
• ENERGY STAR zu energieeffizienter Rechenzentrumstechnik, abgerufen am 09.07.2026: Data Center Equipment