Cloud-Kosten nach Verantwortlichen statt nach Kennnummern

Ausgangslage

Der Projektordner sagt dazu nichts. Kein README, keine Anforderungsdokumentation, keine Commit-Nachricht, die das Ausgangsproblem beschreibt — die vorhandene Dokumentation erklärt ausschließlich den Ist-Zustand.

Ableitbar, aber nicht belegt: Der Aufwand, der im Code in die Zuordnung von Kosten zu Verantwortlichen fließt — ein zweistufiges Ownership-Modell, Kennzeichnung nicht zugewiesener Ressourcengruppen, ein Regelwerk zur automatischen Zuordnung — legt nahe, dass genau diese Zuordnung vorher das Problem war. Das ist eine Vermutung und wird hier als solche benannt.

Ansatz

Zwei getrennte Anwendungen auf einer gemeinsamen Datenbank.

Die Sammel-Schicht ist eine Function App: 13 zeitgesteuerte Jobs und ein Queue-Trigger holen gestaffelt Daten — Kosten über die Cost Management API, Ressourcenbestand über Resource Graph, Empfehlungen über Advisor, dazu Reservierungs-Abdeckung, verwaiste Ressourcen und Speicher-Auslastung. Ergebnisse landen in rund 25 Tabellen.

Die Web-Schicht ist eine Flask-Anwendung mit 80 Routen. Sie liest ausschließlich aus der Datenbank — im gesamten Anwendungsverzeichnis existiert kein einziger Aufruf einer Azure-Management-API. Seiten laden damit aus vorbereiteten Daten statt aus Live-Abfragen. Löst jemand manuell eine Synchronisation aus, schreibt die Web-Schicht lediglich eine Nachricht in eine Warteschlange; die Function App arbeitet sie ab.

Darüber liegen zwei Auswertungen. Die Anomalie-Erkennung vergleicht gegen eine 14-Tage-Basislinie, gruppiert aufeinanderfolgende Tage zu einem Ereignis, unterdrückt Wiederholungsmeldungen nach fünf Tagen und sortiert nach Euro-Auswirkung statt nach statistischem Wert. Die KI-Prüfung erzeugt je Projekt eine priorisierte Empfehlungsliste; die Antwort wird über einen erzwungenen Werkzeugaufruf gegen ein Schema validiert, nicht frei geparst.

Der Punkt, an dem es anders hätte laufen können

Geteilte Ressourcen werden nicht einem Projekt zugerechnet — auch wenn das die Zahlen unbrauchbarer aussehen lässt.

Ein App Service Plan oder ein SQL-Server bedient oft mehrere Projekte. Der einfache Weg wäre gewesen, die vollen Kosten dieser Ressource dem Projekt zuzuschlagen. Das hätte große, ordentlich aussehende Einsparpotenziale ergeben — und wäre falsch gewesen.

Der Code tut bewusst das Gegenteil: zwei getrennte Kostensichten, Einzelressourcen-Kosten ausdrücklich als Obergrenzen markiert, und Ressourcen, deren Rohkosten die Monatssumme des Projekts übersteigen, werden automatisch als vermutlich geteilt oder falsch zugeordnet geflaggt. Der System-Prompt weist das Modell an, in diesem Fall „Nutzung aufteilen“ zu empfehlen statt „löschen und X sparen“ — und die Schätzung auf null zu setzen, wenn keine belastbare Zahl möglich ist.

Dieselbe Zurückhaltung steckt in der Reservierungsrechnung: Die Liste reservierbarer Posten ist eine bewusst enge Positivliste, damit Einsparpotenziale nicht durch Speicher- und Netzwerkkosten aufgebläht werden, die sich gar nicht reservieren lassen.

Die Entscheidung kostet Wirkung in der Präsentation und gewinnt Vertrauen in die Zahl. Für ein Werkzeug, dessen einziger Zweck es ist, dass jemand danach handelt, ist das der richtige Tausch.

Ergebnis

Rund 19.000 Zeilen in etwa 100 Dateien, 80 Routen, 25 Tabellen, 14 Hintergrundjobs, neun angebundene Datenquellen. Aufgebaut von einer Person in etwa einem Quartal, mit einer dichten Bauphase und danach gezielter Performance-Arbeit samt eigener Index-Migration.

Bewusst begrenzt: Das System ändert nichts in Azure. Es gibt keine Lösch-, Stopp- oder Deallocate-Aufrufe. „Implementiert“ ist ein Status in der Datenbank — die Umsetzung macht ein Mensch. Die KI empfiehlt mit Konfidenzstufen; bei niedriger Konfidenz ist die Prüfung durch den Nutzer ausdrücklich vorgesehen.

Offen benannt: Es gibt keine automatisierten Tests. Einsparpotenziale sind Schätzungen mit einer im Code hinterlegten Rabattannahme, keine Angebotslage. Und die Zuordnung geteilter Ressourcen bleibt unscharf — das System kennzeichnet das Problem, es löst es nicht.