FinOps für Teams ohne eigenes FinOps-Team

FinOps ist einer dieser Begriffe, die je nach Unternehmensgröße sehr unterschiedliche Dinge bedeuten. Für ein Fortune-500-Unternehmen ist es eine 30-köpfige Practice mit CFO-Sponsor, einem Tooling-Budget größer als Ihre Gehaltsabrechnung und vierteljährlichen Steering Committees. Für Ihr 30-köpfiges SaaS-Unternehmen ist es eher: „warum ist die AWS-Rechnung 27 % höher als letztes Quartal, und wessen Aufgabe ist es, das herauszufinden?“ Dieser Beitrag ist für die zweite Gruppe.

Zuerst die beruhigende Nachricht: Cloud-Verschwendung ist langweilig. Der überwältigende Großteil davon entsteht durch dieselben fünf Muster, in jedem Unternehmen, auf jeder Skala. Ungenutztes Compute, das niemand abgeschaltet hat. Überdimensionierte Instanzen, provisioniert für einen Peak, der nie wiederkam. Nicht getaggte Ressourcen, die niemand zuordnen kann, weshalb sich niemand verantwortlich fühlt. Vergessene Entwicklungs- und Staging-Umgebungen, die rund um die Uhr laufen für Software, die zweimal im Monat released wird. Und Storage, der Jahre nach dem letzten Zugriff noch auf Premium-Tiers liegt. Keines davon braucht eine FinOps-Foundation-Zertifizierung, um behoben zu werden. Alle brauchen nur jemanden, der tatsächlich hinschaut.

Das Muster, das wir am häufigsten sehen, verdient einen eigenen Absatz. Ein Entwickler startet donnerstags eine c5.4xlarge für einen Lasttest. Der Test ist freitags um 16 Uhr abgeschlossen. Die Instanz läuft übers Wochenende weiter, weil das Abschalten ein manueller Schritt in einer Konsole ist, die samstags niemand öffnet. Bis zum Montags-Standup hat das Team 180 € für eine untätige Maschine verbrannt - nicht aus Unfähigkeit, sondern weil der Standard des Systems „weiter abrechnen“ lautet. Multiplizieren Sie das mit jedem Team, jedem Wochenende, jedem vergessenen Experiment, und Sie haben einen beachtlichen Anteil Ihres Infrastrukturbudgets, der exakt nichts tut.

Warum lösen Dashboards das nicht? Weil Sichtbarkeit nie der Flaschenhals war - Ihr Cloud-Provider hat bereits einen Cost Explorer, und Sie öffnen ihn bereits nicht. Ein Dashboard sagt Ihnen, was passiert ist, nachdem das Geld weg ist, an einem Ort, den Sie sich merken müssen zu besuchen, in einem Format, das zwanzig Minuten Filtern braucht, bevor es irgendetwas Umsetzbares sagt. Zwischen „die Daten existieren“ und „jemand hat danach gehandelt“ liegt die gesamte eigentliche Disziplin von FinOps - und genau dafür hat ein kleines Team keine freie Kapazität.

Es gibt auch ein strukturelles Problem, das Dashboards nicht lösen können: Multi-Cloud-Fragmentierung. Sobald Sie AWS für das Produkt, Hetzner für Batch-Workloads und ein verirrtes DigitalOcean-Projekt betreiben, das jemand 2024 gestartet hat, hat „was geben wir aus“ keine eindeutige Antwort mehr. Jeder Provider exportiert Kosten in seinem eigenen Format, nach seinem eigenen Zeitplan, mit seiner eigenen Vorstellung davon, was ein Projekt ist. Die meisten kleinen Teams reagieren, indem sie die große Rechnung sorgfältig verfolgen und die kleinen abdriften lassen - so überlebt ein Leck von 400 €/Monat zwei Jahre.

Wie sieht FinOps also tatsächlich für ein Team ohne FinOps-Team aus? Unserer Erfahrung nach decken vier Gewohnheiten den Großteil des Werts ab. Eins: eine einzige Quelle der Wahrheit für Ausgaben über alle Provider hinweg, aufgeschlüsselt nach Service, Projekt und Umgebung - nicht weil Dashboards Dinge lösen, sondern weil Diskussionen über Zuordnung sterben, wenn alle dieselben Zahlen sehen. Zwei: Anomalieerkennung, die klüger ist als ein Schwellenwert - Cloud-Rechnungen sind naturgemäß verrauscht, und ein statisches „warne mich über X €“ löst entweder ständig oder nie aus; echte Abweichungen von Ihrer eigenen Baseline zu erkennen, ist Arbeit für ML, nicht für einen Cronjob und Hoffnung. Drei: Right-Sizing-Empfehlungen in einem festen Rhythmus - eine monatliche Liste „diese zwölf Instanzen sind überdimensioniert, hier die sichere kleinere Größe, hier die Ersparnis“, die jemand in fünfzehn Minuten durchgeht. Vier: eskalierende Budget-Alerts - eine leise Warnung an den Engineer bei 80 %, eine lautere an den Team Lead bei 100 %, denn ein Budget, für das niemand verantwortlich ist, ist ein Wunsch.

Bemerken Sie, was alle vier gemeinsam haben: Sie verkürzen die Schleife von Erkenntnis zu Aktion. Das ist das ganze Spiel. Nicht mehr Daten - weniger Abstand zwischen „das System hat es bemerkt“ und „ein Mensch hat entschieden“. Ein kleines Team braucht keine FinOps-Practice; es braucht die zwanzig Minuten pro Woche, in denen Kostenentscheidungen gut vorbereitet, vorpriorisiert und an einem Ort stattfinden.

Genau das haben wir in Sencai gebaut: Ausgaben nach Service, Projekt und Umgebung über jeden verbundenen Provider hinweg; ML-erkannte Kostenanomalien; planmäßige Right-Sizing-Empfehlungen; eskalierende Budget-Alerts. Die Schleife von Erkenntnis zu Aktion, komprimiert, damit sie in ein Standup passt. Und der nächste Schritt auf der Roadmap - Autopilot - schließt diese Schleife für die langweiligen Fälle vollständig: getaggte Dev-Ressourcen planmäßig automatisch stoppen, genehmigtes Right-Sizing während Wartungsfenstern ausführen. Die Beurteilung bleibt bei Ihnen; das Knöpfchen-Drücken muss es nicht.

Wenn Sie wissen wollen, wo Sie heute stehen, hier eine Fünfzehn-Minuten-Übung: Ziehen Sie die Rechnung des letzten Monats von jedem Provider, den Sie nutzen - auch die, die Sie vergessen hatten. Sortieren Sie nach Service. Markieren Sie alles, das Sie nicht innerhalb von zehn Sekunden einem laufenden Produkt-Feature zuordnen können. Bei den meisten Unternehmen sind das 25-35 % der Gesamtsumme. Das ist kein Budgetierungsproblem. Das ist einfach Entropie - und Entropie lässt sich sehr, sehr gut beheben.