Zwei Betriebsebenen, eine Lücke: was zwischen Infrastrukturteam und Applikationsmanagement oft übersehen wird
Server läuft, Netzwerk erreichbar, Kubernetes-Cluster grün – auf dieser Ebene ist Managed-Service-Qualität heute Standard. Trotzdem entstehen viele Störungen erfahrungsgemäß weder allein im Infrastrukturbetrieb – noch im Applikationsmanagement, sondern genau dazwischen: an der Schnittstelle, wo plötzlich unterschiedliche Verantwortlichkeiten aufeinandertreffen. Ein Blick darauf, wo diese Lücke entsteht – und wie man sie in der eigenen IT-Organisation überprüfen – und schließen kann.
Applikationsmanagement folgt eigenen Regeln
Der Markt für Infrastruktur-Managed-Services ist gut entwickelt: Compute, Storage, Netzwerk, Kubernetes-Plattformen. Die Applikationsebene folgt jedoch anderen Regeln. Wer kümmert sich, wenn die Applikation einen Fehler wirft? Wer managt Updates der Applikation, Konfigurationsänderungen, Datenbankverbindungen, Integrationspunkte zu externen Systemen?
Diese Fragen werden oft erst dann gestellt, wenn etwas nicht funktioniert – und dann zeigen sich die unterschiedlichen Verantwortungsgrenzen zwischen den einzelnen Betriebsteams.
Unser Applikationsmanagement deckt genau diese Verantwortungslücke ab: Betrieb, Updates & Patches, Konfigurationsmanagement, Migration, Incident-Handling und auditierbare Dokumentation über den gesamten Lebenszyklus der Applikation hinweg. Kenntnis der Applikation, der Technologie und des fachlichen Kontexts sind hier essenziell.
Auswirkungen am Beispiel von Finanzinstituten
Bei einer Bank oder einem Neobroker läuft keine generische Web-Applikation. Es läuft ein Trading-System, das in Echtzeit Marktdaten verarbeitet, Orders routet und mit dutzenden externen Systemen kommuniziert. Läuft diese Applikation fehlerhaft, hat dies weitreichende Auswirkungen: Mobile Apps können nicht genutzt werden, Kunden können keine Orders aufgeben, und je nach Umfang müssen Vorfälle gemeldet werden.
Das Beispiel Patchmanagement
Patchmanagement zeigt das Schnittstellenproblem am konkretesten, weil es in beide Richtungen wirkt:
Betriebssystem- oder Plattform-Patch trifft Applikation. Ein Sicherheitsupdate für das Betriebssystem oder die Kubernetes-Plattform verändert eine Bibliotheksversion oder ein Systemverhalten. Die Applikation selbst wurde nicht angefasst – trotzdem reagiert sie plötzlich anders, weil sie sich auf ein Detail der alten Umgebung verlassen hat.
Applikations-Patch trifft Betriebssystem oder Plattform. Ein Update der Trading-Applikation bringt eine neue Abhängigkeit mit, braucht mehr Arbeitsspeicher oder öffnet eine zusätzliche Netzwerkverbindung. Ohne ausreichendes Testing und der rechtzeitigen Anpassung würde dies zum Problem führen. Kommunikation zwischen den verschiedenen Teams ist daher entsprechend wichtig – besonders dann, wenn mehrere unterschiedliche Dienstleister involviert sind.
Am Ende des Tages ist es nicht wichtig, dass jeder Beteiligte sagen kann, in seinem Zuständigkeitsbereich liefe alles gut – es zählt, dass die Applikation zuverlässig und fehlerfrei läuft.
Eine Selbstprüfung, unabhängig vom Anbieter
Unabhängig davon, wie die eigene IT-Landschaft heute aufgestellt ist, lohnt sich eine ehrliche Antwort auf drei Fragen:
- Wer wird involviert, bevor ein Patch eingespielt wird, der die Applikation betreffen könnte?
- Wer prüft vor einem Applikations-Update, ob neue Systemanforderungen existieren?
- Gibt es eine abgestimmte Planung zwischen den verschiedenen Aktualisierungszyklen?
Wenn die Antwort auf eine dieser Fragen „das müssten wir erst klären“ lautet, liegt genau dort die Lücke, die im Ernstfall dann sichtbar wird.
Full-Stack aus einer Hand: eine mögliche Antwort
Eine Möglichkeit, diese Lücke strukturell zu schließen, ist der Betrieb aus einer Hand: Wer Infrastruktur und Applikation gemeinsam verantwortet, kann Patch-Zyklen genau aufeinander abstimmen.
cloudopserve betreibt den vollständigen Stack – von der Infrastruktur über Kubernetes-Plattformen bis zum Applikationsmanagement. Beispielsweise bei unseren Finance-Kunden bedeutet das den vollständigen Betrieb der Trading-Applikationen inklusive aller Integrationspunkte, in einem Umfeld, in dem Fehler echte Konsequenzen haben.