„Vier Stunden Reaktionszeit“ bedeuten nicht „vier Stunden bis die Anwendung wieder läuft“. Zwischen einem Monitoring-Alarm und einem nutzbaren Geschäftsprozess liegen Diagnose, Freigaben, Zugang zum Rack, ein passendes Ersatzteil, technische Prüfung und die fachliche Abnahme. Gerade bei einem Server im österreichischen Housing entscheidet die vorbereitete Übergabe zwischen IT, Betreiber und Hersteller darüber, ob diese Schritte parallel beginnen oder nacheinander warten.
Der veröffentlichte DAXS-Beitrag zu handlungsfähigen Zabbix-Alarmen behandelt die Alarmqualität. Hier geht es um den weiteren Ablauf bis zur wieder nutzbaren Anwendung. Eine geprüfte Sicherung bleibt Teil des Rückwegs, falls kein Bauteiltausch genügt. Die folgende Housing- und Zeitrechnung ist ausdrücklich fiktiv; sie beschreibt weder einen bestimmten DAXS-Kunden noch einen zugesagten Servicelevel.
Ein Alarm muss die richtige Arbeit auslösen
Ein Dienst ist von außen nicht erreichbar. Das Monitoring meldet den Ausfall des Geschäftsfalls und die letzte erfolgreiche Prüfung. Gleichzeitig werden Strom- und Temperaturwerte, Managementzugang, Switchport und andere Hosts betrachtet. So lässt sich ein Netzproblem von einem ausgefallenen Server oder einer defekten Anwendung abgrenzen. Zabbix löst eine Benachrichtigung nur aus, wenn ein passender Trigger samt Aktion konfiguriert ist; das Empfangsziel und die Eskalation gehören deshalb in den Betriebsplan.
Vor dem Vor-Ort-Einsatz stehen vier konkrete Angaben im Ticket: Rack und Höheneinheit, erlaubte Tätigkeiten, Ansprechpartner mit Rückrufweg sowie Seriennummer und Lage des freigegebenen Ersatzteils. Wer darf den Host ausschalten? Wer entscheidet über einen Failover? Darf Remote Hands ein Modul tauschen oder nur Sichtkontrolle und Kabelprüfung leisten? Diese Antworten müssen zum tatsächlichen Vertrag und zur Zutrittsregel des Rechenzentrums passen. Digital Realty beschreibt Remote Hands allgemein als technische Vor-Ort-Aufgaben an Kundenequipment; daraus folgt keine automatisch verfügbare oder in Wien für jeden Vertrag gleiche Reaktionszeit.
Ein fiktiver Vorfall in sechs Zeitfenstern
Im Beispiel verliert ein einzelner Virtualisierungshost seinen produktiven Netzpfad. Die Fernprüfung zeigt einen erreichbaren Managementzugang und einen ausgefallenen optischen Transceiver am produktiven Port; ein kompatibles, vorher getestetes Ersatzmodul liegt beschriftet im Rack. Die Anlage hat hier keinen zweiten funktionsfähigen Pfad. Das ist eine bewusst gewählte Schwachstelle des Beispiels, keine Empfehlung für einen realen Aufbau. Der Betreiber bestätigt die Anweisung, bevor jemand am Port arbeitet.
| Zeit ab Alarm | Schritt | Nachweis / nächste Entscheidung |
|---|---|---|
| 0–10 Minuten | Alarm empfangen und Rufbereitschaft erreicht | Dienstcheck und Kontaktzeit im Ticket |
| 10–35 Minuten | Fernanalyse von Managementzugang, Port und Gegenstelle | Verdacht auf Transceiver, keine blinde Hardwareänderung |
| 35–60 Minuten | Freigabe, Remote-Hands-Ticket und Rackzugang | Konkrete Tätigkeit und Rückrufweg bestätigt |
| 60–95 Minuten | Ersatzmodul zuordnen, tauschen, Link prüfen | Portstatus, Seriennummer und Fotos dokumentiert |
| 95–125 Minuten | Host-, VM- und Netzpfad prüfen | Dienste erreichbar; Monitoring stabilisiert sich |
| 125–140 Minuten | Fachbereich testet Auftrag und zugehörige Datei | Erst danach ist der Geschäftsfall wieder freigegeben |
Die 140 Minuten sind die Summe dieser erfundenen Zeitfenster. Wird der Fehler erst nach einer Anfahrt erkannt, ist das Ersatzmodul nicht kompatibel oder fehlt die Zutrittsfreigabe, verändert sich der Ablauf sofort. Ein Hardware-Supportvertrag kann außerdem eine erste Reaktion, Vor-Ort-Ankunft oder Reparatur unterschiedlich definieren. HPE führt solche Servicevarianten und Bedingungen ausdrücklich getrennt; die konkrete Produktnummer, Servicezone, Uhrzeit und Deckung müssen vor einem Versprechen geprüft werden. Keine externe Reaktionszeit ersetzt die fachliche Anwendungsprüfung.
Was Vorbereitung über drei und fünf Jahre kostet
Eine offene Beispielrechnung vergleicht denselben Host, dasselbe Monitoring, denselben Dienst und dieselben zwei jährlichen Übungen. Die ohnehin vorhandene Server- und Housing-Miete wird in beiden Wegen ausgeklammert. Gemeinsamer Aufbau: 20 Personenstunden für Kontaktbaum, Rackdokumentation und Runbook × 80 € angenommener Vollkostensatz = 1.600 €. Gemeinsamer Jahresrahmen: 1.200 € Monitoring-Leistung, 1.200 € Budget für Remote Hands ohne zugesicherte Verfügbarkeit, 12 × 4 Stunden Pflege × 80 € und zwei Übungen mit je acht Teamstunden × 80 €; zusammen 7.520 € pro Jahr.
Variante A bestellt Ersatzteile erst im Vorfall. Variante B hält einen kompatiblen, beschrifteten kleinen Ersatzteilsatz am Standort vor: einmalig angenommene 600 € für Komponenten und 12 zusätzliche Teamstunden zur Prüfung und Hinterlegung; jährlich angenommene 600 € Lagerung/Test sowie eine zusätzliche Stunde pro Monat zur Kompatibilitätskontrolle. Der Satz deckt nicht Mainboard, Host oder jeden anderen Defekt ab.
| Weg | Einmalig | Jährlich | 3 Jahre | 5 Jahre |
|---|---|---|---|---|
| A · Ersatz erst bei Bedarf | 20 × 80 = 1.600 € | 1.200 + 1.200 + 12 × 4 × 80 + 2 × 8 × 80 = 7.520 € | 24.160 € | 39.200 € |
| B · passender Satz vor Ort | 1.600 + 600 + 12 × 80 = 3.160 € | 7.520 + 600 + 12 × 1 × 80 = 9.080 € | 30.400 € | 48.560 € |
Sensitivität: Wenn das Remote-Hands-Budget in beiden Varianten um 100 € pro Monat steigt, wachsen die Dreijahreswerte um jeweils 3.600 €, die Fünfjahreswerte um jeweils 6.000 €. Das Budget ist keine Buchung einer garantierten Einsatzzeit und keine feste Preisangabe eines Rechenzentrums. Reale Zutritts- und Stundenregeln, Bereitschaftsfenster, Hersteller-Servicelevel, Komponentenlebensdauer, Lagerort und Versandzeiten gehören in das Kundenangebot. Die zusätzliche Ausgabe für B ist nur sinnvoll, wenn genau diese Teile zur kritischen Fehlerklasse gehören und im Test wirklich Zeit sparen.
Vor der Vertragsunterschrift vier Dinge klären
Erstens: Welche Alarme lösen nachts, am Wochenende und während Wartungen tatsächlich eine personell besetzte Eskalation aus? Zweitens: Wer darf beim Betreiber den Rackzugang und Remote Hands anfordern und den Tausch freigeben? Drittens: Welche Teile sind mit Seriennummer, Firmware und Gerät kompatibel und wem gehören sie? Viertens: Wie wird der Dienst nach Hardwarearbeit, Failover oder Restore fachlich wieder freigegeben? Diese Fragen machen aus einer Produkt-Reaktionszeit einen überprüfbaren Betriebsweg.
DAXS kann Monitoring, Ticketweg, Ersatzteilübersicht und Abnahmeprotokoll für eine konkrete Housing-Umgebung gemeinsam mit Kunde, Betreiber und Hersteller aufnehmen. Kontakt zu DAXS.
Quellen: Zabbix: Problem Detection with Triggers · Digital Realty: Remote Hands Service · Digital Realty: Rechenzentren in Wien · HPE: Tech Care Servicebedingungen.