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.
Betrieb ist kein Zustand, sondern eine dauerhafte Aufgabe
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.
Im Alltag funktioniert vieles – weil nichts passiert
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.
Verantwortung ist häufig vorhanden – aber nicht definiert
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:
- Wer entscheidet?
- Wer priorisiert?
- Wer trägt die Konsequenzen?
Wenn diese Fragen nicht vorab geklärt sind, entstehen sie im Incident selbst. Und das ist selten der Moment, in dem Organisationen besonders strukturiert handeln.
Der Bus-Faktor kommt nicht plötzlich
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.
24/7 klingt nach Technik – ist aber Organisation
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 verändert sich mit der Zeit
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 nimmt Arbeit ab – aber nicht die Verantwortung
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 eigentliche Herausforderung liegt nicht in der Technologie
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.
Nächster Schritt
Ein realistischer Blick auf den eigenen Betrieb beginnt selten mit Tools oder Architektur, sondern mit einfachen Fragen:
- Wie ist Verantwortung heute tatsächlich verteilt?
- Was passiert, wenn zentrale Personen nicht verfügbar sind?
- Und wer trifft Entscheidungen, wenn es darauf ankommt?
Ein externer Blick hilft oft, diese Punkte klarer zu sehen und strukturiert einzuordnen.
Gespräch anfragenFAQ: Cloud-Infrastruktur und Betriebsverantwortung
Cloud-Infrastruktur beschreibt die technische Bereitstellung von Ressourcen: Server, Netzwerke, Speicher. Cloud-Betrieb beschreibt alles, was danach kommt: Monitoring, Updates, Incident-Response, Skalierung. Infrastruktur lässt sich schnell bereitstellen. Betrieb ist eine dauerhafte Aufgabe, die kontinuierlich jemanden erfordert. Viele Cloud-Modelle liefern ersteres. Letzteres bleibt häufig beim Kunden.
Der Übergang ist selten ein klarer Schnitt. In frühen Phasen funktioniert interner Betrieb oft gut: Das Team ist klein, die Systeme sind überschaubar, Wissen ist verteilt. Sobald Anwendungen geschäftskritisch werden, Ausfälle direkte Konsequenzen haben und Anforderungen an Verfügbarkeit, Compliance oder Support steigen, reicht das frühere Modell nicht mehr. Der entscheidende Punkt ist nicht die Unternehmensgröße, sondern die Frage, ob ein Ausfall tolerierbar ist oder nicht.
24/7-Verfügbarkeit bedeutet nicht nur, dass ein System überwacht wird. Es bedeutet, dass jederzeit eine Person erreichbar ist, die einschätzen kann, was ein Alert bedeutet, welche Konsequenzen ein Incident hat und welche Maßnahme sinnvoll ist. Monitoring-Systeme können Anomalien melden. Entscheidungen treffen sie nicht. Ohne klare On-Call-Verantwortung und definierte Eskalationswege entsteht auch bei vollständigem Monitoring eine organisatorische Lücke.
Thomas Huber