Cloud-Infrastruktur ist in vielen Unternehmen kein Thema mehr, über das grundsätzlich diskutiert wird. Sie ist einfach da. Anwendungen laufen in der Cloud, Systeme sind verteilt, Skalierung funktioniert.
Wenn man sich nur die technische Seite anschaut, wirkt vieles davon inzwischen fast selbstverständlich. Was dabei oft untergeht: Die technische Umsetzung ist nur ein Teil der Realität. Der andere beginnt erst danach. Und genau dort wird es unscharf.
In Projekten wird viel Energie in Architektur und Deployment gesteckt. Das ist sinnvoll. Systeme müssen stabil live gehen, Entscheidungen müssen getroffen werden, Abhängigkeiten müssen passen. Aber der eigentliche Aufwand beginnt erst, wenn alles läuft.
Betrieb bedeutet nicht nur, dass ein System verfügbar ist. Es bedeutet, dass sich kontinuierlich jemand darum kümmert, dass es so bleibt. Monitoring ist dabei nur ein Teil. Updates, Skalierung, Incident-Response – das alles passiert nicht punktuell, sondern dauerhaft. Und irgendwann stellt sich zwangsläufig die Frage, wer das eigentlich trägt. Nicht im Sinne von „wer hat Zugriff“, sondern ganz konkret: Wer ist verantwortlich, wenn etwas schiefgeht?
An dieser Stelle zeigt sich auch ein grundlegender Unterschied in der Herangehensweise: Einige Modelle liefern primär Infrastruktur. Andere setzen genau beim Betrieb an und verstehen Verantwortung als Teil der Leistung – nicht als nachgelagertes Thema.
Viele Setups funktionieren erstaunlich gut. Gerade im Mittelstand wird viel pragmatisch gelöst. Ein kleines Team betreibt die Infrastruktur, Entwickler kennen die Systeme, vieles läuft über Erfahrung. Das ist oft effizienter, als es auf dem Papier aussehen würde. Solange nichts passiert, fällt auch nicht auf, wo die Grenzen dieses Modells liegen.
Erst wenn ein System nicht mehr erreichbar ist oder sich unerwartet verhält, verändert sich die Situation. Dann reicht es nicht mehr, dass „jemand sich auskennt“. Dann geht es darum, dass Entscheidungen getroffen werden müssen – schnell und unter Druck. Und genau in diesem Moment wird sichtbar, ob Verantwortung wirklich geklärt ist.
In vielen Organisationen gibt es natürlich Verantwortliche. Das Problem ist nicht, dass sich niemand zuständig fühlt. Das Problem ist, dass Verantwortung selten sauber beschrieben ist. Sie ergibt sich aus Rollen, aus Erfahrung oder einfach daraus, wer gerade verfügbar ist. Das funktioniert im Alltag erstaunlich gut, führt aber zu Unsicherheit, sobald mehrere Faktoren gleichzeitig zusammenkommen. Dann wird plötzlich relevant, was vorher keine Rolle gespielt hat:
Ein Punkt, der in diesem Zusammenhang oft unterschätzt wird, ist die Abhängigkeit von einzelnen Personen. Fast jede Infrastruktur hat Menschen, die sie besonders gut kennen. Das ist normal. Problematisch wird es erst, wenn dieses Wissen nicht verteilt ist. Das passiert nicht bewusst. Es entsteht über Zeit. Systeme wachsen, Entscheidungen werden getroffen, Dokumentation bleibt zurück.
Im Alltag fällt das kaum auf. Erst wenn diese eine Person nicht verfügbar ist, wird klar, wie viel tatsächlich an ihr hängt. Der Bus-Faktor ist deshalb kein Extremfall. Er ist eher ein Nebenprodukt von funktionierenden, aber nicht strukturierten Setups.
Wenn Anforderungen steigen, wird oft zuerst die technische Seite erweitert. Monitoring wird ausgebaut, Alerts werden sauber definiert, Automatisierung wird eingeführt. Das ist alles richtig. Gleichzeitig entsteht ein trügerisches Gefühl von Sicherheit. Denn Systeme können heute sehr gut melden, dass etwas nicht stimmt. Was sie nicht können: Entscheidungen treffen. Und genau darum geht es im Betrieb.
24/7 bedeutet nicht nur, dass ein System überwacht wird. Es bedeutet, dass jederzeit jemand da ist, der einschätzen kann, was passiert, welche Auswirkungen es hat und was als nächstes sinnvoll ist. Das lässt sich nicht vollständig automatisieren. Und genau deshalb ist es weniger eine technische als eine organisatorische Frage. Genau an diesem Punkt unterscheiden sich Ansätze deutlich: Ob Betrieb als notwendiger Aufwand intern organisiert wird – oder als eigenständige, klar verantwortete Funktion gedacht ist.
Selbstbetrieb ist für viele Unternehmen der naheliegende Weg. Am Anfang ist er oft sogar die beste Lösung, weil er flexibel ist und wenig Abstimmung erfordert. Mit wachsender Komplexität verschiebt sich jedoch die Perspektive. Systeme werden wichtiger für das Geschäft, Ausfälle haben direkte Auswirkungen, Anforderungen von Kunden oder Partnern steigen. Gleichzeitig wird die Infrastruktur selbst anspruchsvoller.
Der Punkt, an dem sich etwas verändert, ist selten ein klarer Schnitt. Es ist eher ein schleichender Übergang. Was vorher „nebenbei“ funktioniert hat, wird irgendwann zu einer eigenen Aufgabe. Und genau dann stellt sich die Frage, ob die Organisation dafür ausgelegt ist. In vielen Fällen entsteht daraus eine klare Trennung: zwischen Plattformen, die bereitgestellt werden – und Betrieb, der bewusst übernommen wird.
Cloud hat vieles einfacher gemacht. Infrastruktur kann heute schnell bereitgestellt werden, ohne eigene Hardware, ohne lange Vorlaufzeiten. Was sie nicht abnimmt, ist die Verantwortung für den Betrieb.
Viele Modelle sind darauf ausgelegt, Technologie bereitzustellen. Das ist auch sinnvoll. Gleichzeitig bleibt die Frage offen, wer die Verantwortung für Stabilität und Reaktion tatsächlich trägt. In der Praxis wird das oft erst dann sichtbar, wenn ein Problem auftritt – und unklar ist, wer es eigentlich löst.
Die meisten technischen Probleme lassen sich lösen. Die eigentliche Schwierigkeit liegt darin, Strukturen zu schaffen, die auch im Alltag tragen. Das bedeutet nicht, dass alles perfekt organisiert sein muss. Aber es bedeutet, dass klar ist, wie Verantwortung verteilt ist – auch dann, wenn es unbequem wird.
Viele Unternehmen beschäftigen sich mit dieser Frage erst dann, wenn sie konkret wird. Also dann, wenn ein System nicht mehr funktioniert.
Ein realistischer Blick auf den eigenen Betrieb beginnt selten mit Tools oder Architektur, sondern mit einfachen Fragen: