Stell dir vor, es ist Montagmorgen um drei Uhr. Dein Telefon vibriert ununterbrochen. In deinem Posteingang stapeln sich viertausend E-Mails, alle mit dem Betreff „Heartbeat Failure“ oder „Disk Space Low“. Während du versuchst, die Nadel im Heuhaufen zu finden, bricht das ERP-System endgültig zusammen. Das ist der Moment, in dem die meisten Administratoren feststellen, dass ihre Instanz vom Microsoft System Center Operations Manager sie nicht rettet, sondern im Chaos ertränkt. Ich habe das oft gesehen: Ein mittelständisches Unternehmen investiert sechsstellige Beträge in Lizenzen und Hardware, nur um ein Jahr später festzustellen, dass niemand mehr auf die Konsole schaut, weil sie zu 90 Prozent aus Fehlalarmen besteht. Der Fehler liegt fast nie an der Software selbst, sondern an der arroganten Annahme, man könne dieses Werkzeug einfach installieren und vergessen. Wer so denkt, verbrennt Zeit und Nerven in einem Ausmaß, das jedes Projektbudget sprengt.
Die Falle der automatischen Erkennung im Microsoft System Center Operations Manager
Einer der größten Fehler, den ich immer wieder beobachte, ist das blinde Vertrauen in die Management Packs der Hersteller. Ein Administrator importiert alles, was er finden kann – SQL, Exchange, IIS, Active Directory – und lehnt sich zurück. „Das System erkennt ja alles von selbst“, heißt es dann. Das Ergebnis ist eine Alarm-Flut, die jede sinnvolle Reaktion im Keim erstickt.
Das Problem ist, dass Standard-Schwellenwerte in den seltensten Fällen zu deiner spezifischen Infrastruktur passen. Wenn ein SQL-Server so konfiguriert ist, dass er bei 80 Prozent Speicherauslastung warnt, du aber eine Anwendung fährst, die konstruktionsbedingt 95 Prozent belegt, hast du einen Dauer-Alarm. In meiner Praxis habe ich Teams erlebt, die Wochen damit verbracht haben, Alarme zu löschen, anstatt die Ursache zu beheben.
Die Lösung ist mühsam, aber alternativlos: Jedes Management Pack muss seziert werden. Du darfst nur das aktivieren, was du wirklich brauchst. Schalte alle Monitore aus, auf die du ohnehin nicht reagieren würdest. Wenn ein Alarm erscheint und deine einzige Reaktion ist, ihn zu schließen, dann darf dieser Alarm gar nicht erst existieren. Das spart nicht nur Speicherplatz in der Datenbank, sondern schont vor allem die Aufmerksamkeit deiner Mitarbeiter. Wer alles überwacht, überwacht am Ende gar nichts.
Das Märchen von der Standard-Konfiguration
Viele glauben, die Standard-Einstellungen seien ein guter Startpunkt. Das ist falsch. Die Standards sind darauf ausgelegt, im Zweifelsfall lieber zu viel als zu wenig zu melden, damit der Softwarehersteller rechtlich abgesichert ist. Für den Betrieb ist das pures Gift. Ein gesundes System braucht Wochen der Feinjustierung, in denen man Schwellenwerte schrittweise an die Realität anpasst.
Warum deine Datenbankstrategie dich in den Ruin treibt
Ein klassisches Szenario: Das Monitoring läuft sechs Monate perfekt. Plötzlich wird die Konsole quälend langsam. Berichte brauchen Minuten zum Laden. Der Grund ist fast immer eine völlig falsch dimensionierte Operations Database oder ein Data Warehouse, das unter der Last unzureichender Pflege zusammenbricht. Ich habe Installationen gesehen, bei denen die Protokolldateien der SQL-Datenbanken die gesamte SAN-Kapazität gefressen haben, nur weil jemand vergessen hat, die Grooming-Einstellungen anzupassen.
Viele unterschätzen die Schreiblast. Jeder Statuswechsel, jedes Leistungsdatum muss irgendwo hin. Wenn du die Aufbewahrungsfristen im Data Warehouse auf Standard lässt, sammelst du Terabytes an Daten, die du nie wieder ansiehst. Das kostet nicht nur Speicherplatz. Es verlangsamt das gesamte System, bis die Überwachung selbst zum Performance-Fresser für die gesamte IT-Umgebung wird.
Ein erfahrener Praktiker weiß, dass die SQL-Konfiguration das Rückgrat ist. Wenn die IOPS auf den Platten nicht reichen, ist das Monitoring wertlos. Es bringt nichts, das teuerste Tool zu kaufen, wenn man bei den SQL-Lizenzen oder der Festplattenperformance spart. Du brauchst eine klare Strategie für das Data Grooming. Behalte Leistungsdaten nur so lange, wie es für Kapazitätsplanungen absolut notwendig ist. Alles andere ist digitaler Müll.
Die Illusion der Vollständigkeit ohne Serviceorientierung
Hier machen fast alle den gleichen Denkfehler: Sie überwachen Server, keine Services. Ein Server kann technisch gesehen „grün“ sein – die CPU ist ruhig, der RAM ist frei –, aber die Webanwendung, die darauf läuft, antwortet trotzdem nicht, weil ein Zertifikat abgelaufen ist oder ein Port in der Firewall klemmt.
In meiner Laufbahn habe ich oft erlebt, wie Admins stolz auf ihre grünen Dashboards blickten, während der Kundensupport von Beschwerden überrannt wurde. Das liegt daran, dass sie vergessen haben, Distributed Applications zu konfigurieren. Sie schauen auf das Blech und das Betriebssystem, aber nicht auf den Datenfluss. Ein Prozess, der nur Einzelkomponenten prüft, ist blind für die Benutzererfahrung.
Man muss die Perspektive wechseln. Überlege dir, was passieren muss, damit ein Benutzer seine Arbeit erledigen kann. Das sind meistens Abhängigkeiten über mehrere Systeme hinweg: DNS, Loadbalancer, Webfrontends, Datenbanken. Nur wenn du diese logischen Ketten im Monitoring abbildest, erfährst du von einem Ausfall, bevor der erste Nutzer zum Hörer greift. Alles andere ist nur eine Bestandsaufnahme von Hardware, keine echte Überwachung des Geschäftsbetriebs.
Der fatale Verzicht auf eigene Management Packs
Es gibt diese Tendenz, nur das zu nutzen, was „out of the box“ kommt. Doch wer keine eigenen Management Packs erstellt, nutzt das volle Potenzial nie aus. Microsoft System Center Operations Manager ist ein Framework, kein fertiges Produkt. Wer versucht, Anpassungen über die grafische Oberfläche direkt in den Default-Management-Packs vorzunehmen, begeht einen strategischen Selbstmord.
Ich habe Umgebungen bereinigt, in denen hunderte von Overrides in einem einzigen, riesigen Management Pack lagen. Wenn du dann ein Update für eine Komponente einspielen musst oder das System migrierst, bricht das Kartenhaus zusammen. Es gibt keine einfache Möglichkeit, diese Anpassungen sauber zu trennen oder zu versionieren. Das führt dazu, dass Teams Angst vor Updates haben und jahrelang auf veralteten Versionen sitzen bleiben, was wiederum Sicherheitsrisiken birgt.
Der richtige Weg ist strikt: Jede Applikation bekommt ihr eigenes Management Pack für Overrides. Diese Dateien gehören in eine Versionsverwaltung wie Git. Das klingt nach unnötiger Bürokratie, spart dir aber bei der nächsten Migration oder beim nächsten Versionssprung Monate an Arbeit. Es ist der Unterschied zwischen professionellem IT-Management und „Herumfrickeln“ am offenen Herzen.
Vorher und Nachher: Ein Realitätscheck in der Praxis
Schauen wir uns an, wie sich ein falscher Ansatz im Vergleich zu einer durchdachten Strategie auswirkt. Nehmen wir ein typisches Szenario: Ein Update für eine wichtige Datenbank steht an.
Im falschen Szenario, das ich leider viel zu oft gesehen habe, weiß das Monitoring-Team nichts vom Update. Die Datenbank wird heruntergefahren. Innerhalb von Sekunden generiert das System dreihundert Alarme. Das Monitoring-System schickt SMS an die Rufbereitschaft, E-Mails an das Management und löst automatisierte Tickets im Helpdesk aus. Die Administratoren sind so damit beschäftigt, die Alarmflut zu unterdrücken und die Tickets manuell zu schließen, dass sie sich nicht auf das eigentliche Update konzentrieren können. Nach dem Update bleibt ein Dienst hängen, aber niemand merkt es, weil der Alarm in der Masse der „normalen“ Fehlermeldungen untergeht. Das System ist instabil, und der Fehler wird erst Stunden später durch einen wütenden Anruf der Geschäftsführung entdeckt.
Im richtigen Szenario wurde im Vorfeld ein Wartungsmodus geplant. Das Monitoring-System weiß genau, welche Dienste für diesen Zeitraum keine kritischen Alarme werfen dürfen. Die Overrides sind in einem spezifischen Management Pack gespeichert, das nur für diese Anwendung zuständig ist. Während des Updates bleibt die Konsole ruhig. Sobald die Wartung beendet ist, wird der Modus deaktiviert. Das System führt einen automatischen Health-Check durch. Da nur die wirklich relevanten Monitore aktiv sind, sticht ein nicht gestarteter Dienst sofort als einziger roter Punkt in einer ansonsten grünen Konsole hervor. Der Administrator sieht das Problem innerhalb von Sekunden, startet den Dienst manuell nach, und die Anwendung ist für die Benutzer verfügbar, noch bevor die Arbeitszeit beginnt. Der Zeitaufwand für die Fehlersuche reduziert sich von Stunden auf Minuten.
Die Unterschätzung der Berechtigungskonzepte
Ein oft ignorierter Reibungspunkt ist die Rechtevergabe innerhalb der Monitoring-Umgebung. In vielen Firmen haben entweder alle Vollzugriff oder das System ist so restriktiv eingestellt, dass die Fachabteilungen gar nicht erst damit arbeiten können. Beides ist fatal. Wenn jeder Overrides erstellen darf, herrscht nach drei Monaten Wildwuchs. Wenn niemand außer dem Monitoring-Admin etwas sieht, bleibt die Arbeit an einer Person hängen, die dann zum Flaschenhals wird.
Ich habe erlebt, wie Monitoring-Instanzen abgeschaltet wurden, weil die Applikationsverantwortlichen das Gefühl hatten, das Tool gehöre „der IT-Infrastruktur“ und habe nichts mit ihren Problemen zu tun. Das ist ein politischer Fehler mit technischen Konsequenzen. Du musst Rollen definieren. Die SQL-Admins müssen ihre eigenen Dashboards sehen und ihre eigenen Schwellenwerte pflegen können – aber innerhalb eines festen Rahmens.
Ein gut geführtes System ist eine Dienstleistung für andere Teams. Wenn du es schaffst, dass die Exchange-Admins morgens zuerst auf ihr SCOM-Dashboard schauen, weil sie dort Informationen finden, die sie sonst nirgends bekommen, dann hast du gewonnen. Wenn sie es als Überwachungsorgan wahrnehmen, das ihnen nur zusätzliche Arbeit durch unnötige Tickets beschert, werden sie es sabotieren, wo sie nur können.
Der Realitätscheck: Was es wirklich braucht
Machen wir uns nichts vor: Erfolgreiches Monitoring ist keine technische Aufgabe, die man nebenher erledigt. Es ist ein Full-Time-Job, zumindest in der Aufbauphase und bei größeren Umgebungen. Wenn du denkst, du kannst das Tool installieren und es wird dir einfach so sagen, was in deinem Rechenzentrum schiefläuft, hast du bereits verloren.
Es braucht Disziplin. Du musst bereit sein, Nein zu sagen. Nein zu unnötigen Management Packs. Nein zu unsinnigen Alarmen. Nein zu Administratoren, die zu faul sind, ihre eigenen Schwellenwerte zu definieren. Es erfordert ein tiefes Verständnis deiner eigenen Anwendungen. Wer seine Prozesse nicht kennt, kann sie nicht überwachen.
Die bittere Wahrheit ist: Ein Monitoring-System spiegelt den Zustand deiner gesamten IT-Organisation wider. Wenn deine Prozesse chaotisch sind, wird dein Monitoring chaotisch sein. Wenn deine Kommunikation zwischen den Teams nicht funktioniert, wird das System nur dazu dienen, mit dem Finger auf andere zu zeigen. Es gibt keine Abkürzung. Entweder du investierst die Zeit in die saubere Konfiguration, die Pflege der Datenbanken und die Erstellung eigener Logiken, oder du sparst dir das Geld für die Lizenzen gleich ganz. Ein schlechtes Monitoring ist nämlich teurer als gar kein Monitoring – es wiegt dich in einer falschen Sicherheit, während es gleichzeitig deine Ressourcen durch Lärm und Fehlalarme verbrennt. Wer diesen Aufwand scheut, sollte lieber bei einfachen Ping-Tests bleiben. Das ist wenigstens ehrlich und kostet fast nichts. Alles dazwischen ist nur eine teure Illusion von Kontrolle.
