Hauptgedanke

Die Datenbank der Gehaltsabrechnung liegt jetzt in der Azure-Umgebung des Kunden. Eines Morgens antwortet die Anwendung nicht mehr. Liegt es an der Engine des Herstellers, am SQL Server des Kunden, an einer Netzwerkregel, die am Vortag geändert wurde, an einem Zertifikat, an einer IAM-Konfiguration, an einer Sättigung der Verbindungen, an einem Kontingent, an der Latenz?

Zu antworten „Die Datenbank liegt beim Kunden, das ist nicht unser Problem“ funktioniert nicht. Für den Nutzer, der seine Gehaltsabrechnung nicht erledigen kann, ist der Service des Herstellers ausgefallen.

Der Vertrag hat eine Verantwortung verschoben; die Wahrnehmung hat sich nicht vom Fleck bewegt.

Warum das wichtig ist

Daraus folgt eine Pflicht, die sich nicht aus dem Vertrag ergibt, sondern aus der Lage: die ausgelagerte Ressource und ihre Anbindung ausreichend zu überwachen, um zu verstehen, woher ein Vorfall kommt. Nicht die Infrastruktur des Kunden verwalten, sondern über die Signale verfügen — Verfügbarkeit, Latenz, Verbindungsfehler, Sättigung, Health-Status.

Diese Kosten zeigt die Vereinbarung nicht, solange man sie verhandelt, und sie verschwinden danach nie wieder.

Nuancen und Grenzen

Überwachung macht den Hersteller nicht handlungsfähig: Den Ausfall zu sehen und ihn beheben zu können, sind zwei verschiedene Dinge.

Und die Pflicht hat eine Grenze: Ab einem bestimmten Punkt läuft die Überwachung der gesamten Kundenumgebung darauf hinaus, sie zu betreiben — genau das, was die Aufteilung vermeiden sollte.

Offene Fragen

• Welches Maß an Überwachung genügt für die Diagnose, ohne in den Betrieb des Kunden einzugreifen?