AUSGANGSLAGE
IST‑Zustand: Reaktiver Betrieb statt früher Erkennung
Kritische Ereignisse auf Servern und in Diensten wurden oft erst spät sichtbar – wenn Nutzer bereits betroffen waren oder Ressourcenengpässe den Betrieb bremsten. Monitoring-Abdeckung und Alarmierung waren nicht durchgängig; Patch-Status und Wartungsroutinen variierten je nach System und Verantwortlichkeit. Für eine öffentliche Hochschule mit hohen Verfügbarkeitsanforderungen war das Ziel klar: weg vom „gefühlt stabilen“ Betrieb, hin zu messbarer Transparenz und planbaren Updates.
