Alarmflut im Leitstand: Alarmmanagement im Rechenzentrum

Wer im Leitstand eines Rechenzentrums täglich hunderte Meldungen sieht, hört irgendwann auf, genau hinzuschauen. Das ist kein Versagen des Personals, sondern eine vorhersehbare Reaktion auf ein schlecht konfiguriertes Alarmkonzept. Die Folge ist paradox: Je mehr Alarme ein System erzeugt, desto grösser wird die Wahrscheinlichkeit, dass ein wirklich kritischer Zustand übersehen wird. Diesen Zustand nennt die Fachwelt «Alarm Fatigue», und er ist in bestehenden Rechenzentren weit verbreitet.

Dieser fünfte Teil der Serie zeigt, wie ein Alarmaudit vorgeht, welche Meldungen sich zusammenfassen oder abschalten lassen und wie ein Prioritätenschema aufgebaut wird, das im Ernstfall tatsächlich funktioniert. Wir beziehen uns dabei auf IEC 62682, die internationale Norm für Alarmmanagement in industriellen Prozessen, die sich auch für Rechenzentrumsinfrastrukturen als Referenz bewährt hat.

Warum Alarmflut entsteht

Die meisten Alarmprobleme in bestehenden Rechenzentren sind nicht auf einen einzelnen Fehler zurückzuführen. Sie sind das Ergebnis vieler kleiner Entscheide über Jahre hinweg. Jede neue Anlage bringt eigene Schwellwerte mit. Jeder Inbetriebnehmer setzt Grenzen so, dass er während der Inbetriebnahme keine Meldungen sieht. Jeder Lieferant konfiguriert sein System nach eigenen Vorstellungen. Und niemand hat je einen Gesamtüberblick über alle Meldungen erstellt.

Dazu kommt die Tendenz, im Zweifel lieber mehr zu melden als weniger. Das fühlt sich sicher an, ist es aber nicht. Ein System, das bei jedem Temperaturschwankung von einem halben Grad eine Meldung erzeugt, trainiert das Betriebspersonal darauf, Alarme zu ignorieren. Wenn dann ein Kühlkreis wirklich ausfällt, ist die Reaktionszeit länger als nötig, weil die Meldung im Rauschen untergeht.

IEC 62682 beschreibt dieses Problem präzise und gibt Kriterien vor, anhand derer sich beurteilen lässt, ob ein Alarmsystem gut oder schlecht konfiguriert ist. Dazu gehören Kennzahlen wie die Anzahl Alarme pro Stunde im Normalbetrieb, der Anteil stehender Alarme und der Anteil flatternder Meldungen. Diese Kennzahlen sind der Ausgangspunkt jedes Alarmaudits.

Was ein Alarmaudit untersucht

Ein Alarmaudit beginnt mit der Auswertung der Alarmhistorie. Wir exportieren die Meldungen der letzten Wochen oder Monate und analysieren sie systematisch. Die wichtigsten Fragen dabei sind: Welche zehn Datenpunkte erzeugen die meisten Meldungen? Wie viele Alarme stehen dauerhaft an, ohne dass jemand reagiert? Wie viele Meldungen wechseln in kurzer Zeit mehrfach zwischen aktiv und inaktiv?

Die Top-10-Melder sind fast immer aufschlussreich. In vielen Anlagen stammt ein grosser Teil aller Meldungen aus einer Handvoll Datenpunkte. Das können Temperatursensoren mit zu engen Schwellwerten sein, Druckwächter in hydraulischen Kreisen mit normalen Betriebsschwankungen oder Statusmeldungen von Geräten, die im Normalbetrieb zyklisch zwischen zwei Zuständen wechseln. Wer diese Melder kennt, weiss, wo er zuerst ansetzen muss.

Stehende Alarme sind ein eigenes Problem. Sie zeigen an, dass entweder ein echter Zustand dauerhaft toleriert wird, ohne dass jemand handelt, oder dass die Meldung schlicht falsch konfiguriert ist. Beides ist unbefriedigend. Ein Alarm, der seit Wochen ansteht und niemanden mehr interessiert, hat seinen Zweck verloren. Er belastet die Anzeige und verdeckt neue Meldungen.

Flatternde Meldungen entstehen, wenn ein Messwert um einen Schwellwert pendelt. Ohne Hysterese oder Verzögerung erzeugt das in kurzer Zeit viele Meldungen, die alle denselben Zustand beschreiben. IEC 62682 empfiehlt, Schwellwerte mit einer Hysterese zu versehen und Meldungen erst nach einer definierten Verzögerungszeit auszulösen. Das reduziert Flattern erheblich, ohne die Reaktionszeit bei echten Störungen wesentlich zu verlängern.

Prioritäten vergeben, die im Ernstfall tragen

Ein Prioritätenschema ist nur dann nützlich, wenn es konsequent angewendet wird und wenn die Prioritäten tatsächlich unterschiedliche Handlungen auslösen. IEC 62682 empfiehlt in der Regel vier Prioritätsstufen. Die genaue Benennung kann variieren, aber die Logik ist immer dieselbe: Die höchste Stufe verlangt sofortige Reaktion, weil Verfügbarkeit oder Sicherheit unmittelbar gefährdet sind. Die nächste Stufe verlangt rasche Reaktion innerhalb von Minuten. Die dritte Stufe erlaubt eine Reaktion innerhalb von Stunden. Die vierte Stufe ist eine Information, die keine sofortige Handlung erfordert.

Im Rechenzentrum lässt sich das gut auf die tatsächlichen Risiken abbilden. Ein Ausfall der Kühlung in einem Serverraum ist eine sofortige Gefahr für die IT-Last und gehört in die höchste Stufe. Ein erhöhter Differenzdruck in einem Filterkreis ist ein Hinweis auf Wartungsbedarf, aber keine unmittelbare Gefahr. Er gehört in die dritte oder vierte Stufe. Eine Statusmeldung, die nur zur Information dient, gehört gar nicht in die Alarmliste, sondern in die Ereignishistorie.

Das klingt einfach, ist in der Praxis aber aufwendig. Für jeden Alarm muss jemand entscheiden: Was passiert, wenn dieser Zustand eintritt? Wie lange kann man warten? Was ist die richtige Reaktion? Diese Fragen lassen sich nicht pauschal beantworten. Sie erfordern Kenntnis der Anlage, der Redundanzen und der Betriebsprozesse. Genau deshalb ist ein Alarmaudit eine Ingenieuraufgabe und kein reines Konfigurationsprojekt.

Ein häufiger Fehler ist es, alle Meldungen auf die höchste Priorität zu setzen, weil man im Zweifel auf der sicheren Seite sein will. Das Gegenteil ist der Fall. Wenn alles dringend ist, ist nichts mehr dringend. Das Betriebspersonal verliert das Gefühl für den Unterschied, und die Priorität verliert ihre Wirkung.

Handlungsanweisungen: Was beim Alarm zu tun ist

Ein Alarm ohne Handlungsanweisung ist eine halbe Information. Das Betriebspersonal weiss, dass etwas nicht stimmt, aber nicht, was es tun soll. Das führt zu Verzögerungen, zu falschen Reaktionen oder dazu, dass der Alarm quittiert und ignoriert wird, weil niemand weiss, wie er zu behandeln ist.

IEC 62682 verlangt, dass jeder Alarm eine klare Handlungsanweisung hat. Diese muss nicht lang sein. Sie muss aber eindeutig sagen, was zu tun ist, wer zu informieren ist und was das Ziel der Massnahme ist. Im einfachsten Fall ist das ein Satz: «Kühlaggregat 2 prüfen, Schaltschrank vor Ort öffnen, Störmeldung am Regler ablesen, Pikett informieren.» Das reicht, um die erste Reaktion zu steuern.

In der Praxis fehlen diese Anweisungen häufig. Sie wurden nie erstellt, weil das Alarmkonzept nie systematisch erarbeitet wurde. Oder sie existieren in einem Handbuch, das niemand kennt und das im Leitstand nicht zugänglich ist. Ein gutes Alarmkonzept verknüpft die Handlungsanweisung direkt mit der Alarmmeldung, sodass das Personal sie im Leitstand sofort sieht.

Dieser Punkt ist besonders wichtig für Alarme, die ausserhalb der Bürozeiten auftreten. Wenn der Pikettdienst um drei Uhr morgens eine Meldung erhält, muss er ohne Rückfragen wissen, was zu tun ist. Eine fehlende oder unklare Handlungsanweisung kostet in diesem Moment wertvolle Zeit.

Alarmweiterleitung und Eskalation

Ein Alarm, der nur im Leitstand angezeigt wird, ist nutzlos, wenn der Leitstand nicht rund um die Uhr besetzt ist. Die meisten Rechenzentren haben ausserhalb der Bürozeiten einen Pikettdienst, der per Telefon oder Nachricht erreichbar ist. Die Frage ist, welche Alarme weitergeleitet werden und auf welchem Weg.

Hier empfiehlt sich eine klare Eskalationslogik. Alarme der höchsten Priorität werden sofort weitergeleitet, unabhängig von der Tageszeit. Alarme der zweiten Priorität werden weitergeleitet, wenn sie nach einer definierten Zeit nicht quittiert wurden. Alarme der dritten und vierten Priorität werden gesammelt und am nächsten Arbeitstag als Zusammenfassung übermittelt.

Die Weiterleitung muss zuverlässig sein. Das klingt selbstverständlich, ist es aber nicht. Wir sehen in der Praxis regelmässig Systeme, bei denen die Alarmweiterleitung auf einer veralteten E-Mail-Adresse oder einer Mobilnummer konfiguriert ist, die längst nicht mehr aktiv ist. Ein Alarmaudit prüft deshalb auch die Weiterleitungskonfiguration und testet, ob Meldungen tatsächlich ankommen.

Die Schnittstelle zwischen dem Gebäudemanagementsystem (BMS) und dem Energiemanagementsystem für die Stromversorgung (EPMS) ist dabei ein besonderer Punkt. Beide Systeme erzeugen Alarme, und beide müssen im Leitstand sichtbar sein. Wie diese Systeme getrennt und trotzdem verbunden werden, haben wir in Teil 5 der Serie «Leittechnik im Rechenzentrum» unter dem Titel «BMS und EPMS trennen und trotzdem verbinden» ausführlich beschrieben. Für das Alarmmanagement ist entscheidend, dass Meldungen aus beiden Systemen im Leitstand mit einheitlichen Prioritäten angezeigt werden und dass keine Meldung durch die Schnittstelle verloren geht.

Verantwortung zwischen BMS und EPMS

Die Trennung zwischen BMS und EPMS hat Konsequenzen für das Alarmmanagement, die oft unterschätzt werden. Beide Systeme überwachen kritische Infrastruktur, aber mit unterschiedlichem Fokus. Das BMS überwacht Kühlung, Lüftung, Zutrittskontrolle und Brandschutzschnittstellen. Das EPMS überwacht Stromversorgung, USV, Generatoren und Verteilungen.

In vielen bestehenden Rechenzentren sind diese Systeme historisch gewachsen und haben eigene Alarmkonzepte, die nie aufeinander abgestimmt wurden. Das führt dazu, dass ein Ereignis, das beide Systeme betrifft, zum Beispiel ein Spannungseinbruch mit Auswirkung auf die Kühlung, in beiden Systemen separate Meldungen erzeugt, die im Leitstand nicht als zusammengehörig erkennbar sind.

Ein gutes Alarmkonzept definiert deshalb, welches System für welche Meldungen zuständig ist, und verhindert Doppelmeldungen. Das erfordert eine Abstimmung zwischen den Verantwortlichen beider Systeme und eine gemeinsame Prioritätenlogik. Es ist keine technische Frage allein, sondern auch eine organisatorische.

Die Norm EN 50600-2-3 gibt Anforderungen an die Umgebungsbedingungen im Rechenzentrum vor und definiert, welche Parameter überwacht werden sollen. Sie ist damit eine wichtige Grundlage für die Frage, welche Messgrössen überhaupt in die Alarmliste aufgenommen werden müssen. Temperatur, Feuchte und Differenzdruck in den Kühlanlagen sind dort ebenso genannt wie die Anforderungen an die Überwachung der Stromversorgung.

Alarme reduzieren ohne Risiko

Die grösste Sorge bei einem Alarmaudit ist oft, dass man etwas Wichtiges abschaltet. Diese Sorge ist verständlich, aber in der Praxis selten berechtigt, wenn man systematisch vorgeht.

Der erste Schritt ist die Unterscheidung zwischen Alarmen und Ereignissen. Nicht jede Zustandsänderung muss eine Alarmmeldung erzeugen. Viele Informationen gehören in die Ereignishistorie, wo sie protokolliert werden, aber keine aktive Reaktion verlangen. Das entlastet die Alarmliste erheblich, ohne Information zu verlieren.

Der zweite Schritt ist die Zusammenfassung von Meldungen. Wenn fünf Temperatursensoren in einem Kühlaggregat jeweils einzeln melden, ist das fünf Mal so viel Information wie nötig. Eine Gruppenmeldung, die anzeigt, dass das Aggregat einen Temperaturalarm hat, reicht für die erste Reaktion. Die Details sind dann im Detailbild des Aggregats abrufbar.

Der dritte Schritt ist die Anpassung von Schwellwerten. Viele Alarme entstehen, weil Schwellwerte zu eng gesetzt sind. Ein Temperatursensor, der bei 24 °C Alarm gibt, obwohl ASHRAE TC 9.9 einen empfohlenen Zulufttemperaturbereich bis 27 °C vorsieht, erzeugt im Sommer regelmässig Meldungen, die kein Handeln erfordern. Die Anpassung des Schwellwerts auf einen technisch begründeten Wert reduziert die Alarmrate, ohne die Sicherheit zu verringern.

Der vierte Schritt ist die Einführung von Verzögerungen und Hysteresen. Ein Alarm, der erst nach einer Minute dauerhafter Überschreitung ausgelöst wird, filtert kurze Spitzen heraus, ohne echte Störungen zu verzögern. Eine Hysterese von einem oder zwei Kelvin verhindert Flattern an Schwellwerten.

All diese Massnahmen lassen sich dokumentieren und begründen. Das ist wichtig, weil Betreiber und Auditoren nachvollziehen können müssen, warum ein Alarm geändert oder entfernt wurde. Ein Alarmaudit ohne Dokumentation ist kein Audit, sondern eine Konfigurationsänderung ohne Nachweis.

Alarmkonzept als lebendes Dokument

Ein Alarmkonzept, das einmal erstellt und dann nie wieder angefasst wird, veraltet schnell. Jede Erweiterung der Anlage, jeder Geräteersatz und jede Änderung der Betriebsprozesse kann dazu führen, dass Alarme nicht mehr passen. Deshalb gehört das Alarmkonzept zu den Betriebsdokumenten, die regelmässig überprüft werden müssen.

IEC 62682 empfiehlt einen regelmässigen Überprüfungszyklus und die Auswertung der Alarmkennzahlen als Grundlage. Wenn die Anzahl Alarme pro Stunde im Normalbetrieb wieder steigt, ist das ein Zeichen, dass neue Meldungen hinzugekommen sind, die noch nicht bewertet wurden. Wenn der Anteil stehender Alarme zunimmt, ist das ein Zeichen, dass Zustände toleriert werden, die eigentlich behoben werden sollten.

In der Praxis empfehlen wir, die Alarmkennzahlen mindestens quartalsweise auszuwerten und das Alarmkonzept mindestens einmal jährlich zu überprüfen. Bei grösseren Änderungen an der Anlage sollte die Überprüfung unmittelbar nach der Inbetriebnahme erfolgen, bevor neue Meldungen in den Normalbetrieb übergehen.

Wer das Alarmkonzept als lebendes Dokument führt, hat auch eine bessere Ausgangslage für Audits und Zertifizierungen. Die Nachvollziehbarkeit von Änderungen und die Begründung von Schwellwerten sind Punkte, die bei Betriebsaudits regelmässig geprüft werden.

Der rote Faden zu unseren Fachbeiträgen

Wer verstehen will, wie Trenddaten die Grundlage für ein Alarmaudit liefern, findet dazu den zweiten Teil dieser Serie unter dem Titel «Was die Trenddaten über Ihre Kühlung verraten». Die Frage, wie Redundanzen im Bestand tatsächlich vorhanden sind und ob ein Alarm bei Redundanzverlust korrekt konfiguriert ist, behandeln wir in Teil 4 der Serie «Rechenzentrum im Bestand: Analyse, Optimierung, Sicherheit» unter dem Titel «Ist N+1 noch N+1? Redundanz im Bestand prüfen».

Die Schnittstelle zwischen BMS und EPMS, die für das Alarmmanagement zentral ist, beschreiben wir in Teil 5 der Serie «Leittechnik im Rechenzentrum» unter dem Titel «BMS und EPMS trennen und trotzdem verbinden». Wer die technischen Grundlagen von BACnet-Alarmobjekten verstehen möchte, findet dazu unseren Beitrag «BACnet Objekte verstehen, Teil 5: Event Enrollment & Notification Class. Alarmmanagement richtig planen». Und wer wissen will, wie ein Alarmkonzept bereits in der Planungsphase richtig aufgesetzt wird, findet Hinweise dazu in «Trending, Alarming & Scheduling: Die drei Betriebsfunktionen, die oft vergessen werden».

Die Betreibersicht auf das Alarmmanagement, ohne den technischen Tiefgang dieses Artikels, behandeln wir in einem separaten Beitrag ausserhalb dieser Serie. Wer sich für die übergeordnete Frage interessiert, wie ein Leittechnik-Check im bestehenden Rechenzentrum aufgebaut ist, findet den Einstieg in Teil 1 dieser Serie unter dem Titel «Leittechnik-Check im bestehenden Rechenzentrum».

Fazit

Wenige, klar priorisierte Alarme mit eindeutiger Handlungsanweisung erhöhen die Verfügbarkeit eines Rechenzentrums mehr als zusätzliche Sensoren. Das ist keine Vereinfachung, sondern eine Erkenntnis, die IEC 62682 systematisch begründet und die wir in der Praxis immer wieder bestätigt sehen.

Ein Alarmaudit zeigt schnell, welche Meldungen wegfallen, zusammengefasst oder in die Ereignishistorie verschoben werden können. Die Auswertung der Top-10-Melder, der stehenden Alarme und der flatternden Meldungen liefert in kurzer Zeit ein klares Bild. Die eigentliche Arbeit liegt dann in der Bewertung: Welche Priorität ist richtig? Was ist die korrekte Handlungsanweisung? Wer wird wann informiert?

Diese Fragen lassen sich nicht automatisieren. Sie erfordern Kenntnis der Anlage, der Betriebsprozesse und der Redundanzkonzepte. Aber sie lassen sich strukturiert beantworten, und das Ergebnis ist ein Alarmkonzept, das im Ernstfall trägt.

Sie haben Fragen dazu?

Sie möchten wissen, wie ein Alarmaudit in Ihrem Rechenzentrum abläuft und was er konkret bringt? Wir analysieren Ihre Alarmhistorie, bewerten die Meldungen nach IEC 62682 und erarbeiten mit Ihnen ein Prioritätenschema, das zum Betrieb passt. Nehmen Sie Kontakt auf über wenget.ch oder info@wenget.ch.

Quellenverzeichnis

• IEC 62682 / ISA-18.2: Management of Alarm Systems for the Process Industries (Alarmmanagement, Kennzahlen, Prioritätenschema, Handlungsanweisungen)
• EN 50600-2-3: Informationstechnik, Einrichtungen und Infrastrukturen von Rechenzentren, Teil 2-3: Umgebungsbedingungen (Überwachungsanforderungen für Temperatur, Feuchte und weitere Parameter)
• ASHRAE TC 9.9: Thermal Guidelines for Data Processing Environments (empfohlener Zulufttemperaturbereich)
• Eigene Projekterfahrung der WENGET GmbH aus Alarmaudits, Leittechnikanalysen und Betriebsbegleitung in Rechenzentren