Site icon bintorosoft.com

Fiber-Cut-Incident: NOC-Runbook vom Alarm bis zum Field Dispatch

Red Snapper

Ein Fiber-Cut-Incident ist im Provider- und Telco-Betrieb einer der klarsten, aber gleichzeitig operativ anspruchsvollsten Störfälle: Die physische Verbindung ist unterbrochen oder so stark degradiert, dass der Dienst aus Kundensicht ausfällt. Obwohl die Ursache „physisch“ ist, entstehen in der Praxis schnell komplexe Folgeeffekte: Traffic verschiebt sich auf Schutzpfade, Congestion steigt, Routing konvergiert mehrfach, Services wie DNS/AAA/Mobile/Voice geraten unter Druck, und Support meldet „Internet langsam“ statt „Trasse getrennt“. Ein NOC-Runbook für den Fiber-Cut muss deshalb zwei Dinge gleichzeitig leisten: Es muss die Fault-Location schnell in eine konkrete Fault Domain (Span/SRLG/Ring/PoP) übersetzen und parallel die Stabilisierung der Dienste steuern, bis Field Dispatch oder Carrier Repair die physische Strecke wiederherstellt. Entscheidend ist dabei ein standardisierter Ablauf vom Alarm bis zum Field Dispatch: klare Rollen, eindeutige Zeitfenster in UTC, ein Minimal-Evidence-Set, frühe Mitigation mit Guardrails und eine robuste Kommunikationsroutine. Dieses Runbook ist so formuliert, dass es direkt als Template in NOC-Prozesse, War-Room-Dokumente oder Ticketing übernommen werden kann.

Ziele und Scope des Runbooks

Rollen im Fiber-Cut-Incident

Ein Fiber-Cut eskaliert schnell. Damit Diagnose und Dispatch parallel laufen, sind Rollen wichtig. In kleinen Teams können Rollen kombiniert werden, aber die Verantwortlichkeiten sollten klar benannt sein.

Vorbedingungen: Was im NOC vorbereitet sein muss

Ein Fiber-Cut lässt sich nur dann schnell lokalisieren und dispatchen, wenn Grunddaten vorhanden sind. Im Idealfall sind diese Informationen bereits im Inventory und in Dashboards verlinkt.

Phase 1: Alarmaufnahme und Sofortklassifikation

In den ersten 2–5 Minuten geht es um die richtige Einordnung: Handelt es sich um einen echten Fiber Cut (harte Unterbrechung) oder um Degradation (schleichend)? Und ist der Scope regional, ringbasiert oder service-spezifisch?

Sofortsignale, die stark auf Fiber Cut hindeuten

Ticketing und SSoT sofort starten

Phase 2: Minimal Evidence Set – genug Daten für Fault-Location und Dispatch

Bei Fiber Cuts ist Geschwindigkeit wichtiger als Vollständigkeit. Ein Minimal Evidence Set reicht, um Dispatch auszulösen und parallel die Stabilisierung zu starten.

ImpactRate als schnelle Einordnung (MathML)

ImpactRate = impacted_units total_units

Die „units“ müssen zur Produktlinie passen (z. B. aktive Sessions, VPN-Sites, Mobile Registrierungen). Für den Dispatch genügt zunächst eine grobe, konsistente Schätzung („hoch/mittel/niedrig“ plus Zahl, wenn verfügbar).

Phase 3: Fault-Location bestimmen – Span, SRLG, Ring oder PoP?

Das wichtigste Ergebnis vor Field Dispatch ist eine plausible Fault-Location. Das bedeutet: nicht „irgendwo im Netz“, sondern eine konkrete Domain, in der Field Service handeln kann.

Heuristik: „Gemeinsame Kachel“ über betroffene Links finden

OTDR-/Power-Messung: Wann und wie sie in den Ablauf passt

OTDR ist ideal zur Lokalisierung, aber nicht immer sofort verfügbar. Das Runbook sollte festlegen, wann OTDR zwingend ist: bei unklarer Fault-Location, bei mehrfachen Spans in Frage, oder wenn der Carrier eine Distanzangabe für Dispatch verlangt.

Phase 4: Sofort-Mitigation – Stabilisieren, bevor Folgeprobleme eskalieren

Ein Fiber Cut löst häufig Traffic-Shifts aus. Diese können sekundäre Störungen erzeugen: Congestion auf Schutzpfaden, erhöhte Latenz, Paketverlust, Routing-Churn. Das Runbook muss daher eine kontrollierte Mitigation vorsehen.

Mitigation-Optionen (staged)

DropRate als Guardrail (MathML)

DropRate = dropped_packets total_packets

Phase 5: Kommunikation – konsistent, knapp, ohne Spekulation

Fiber Cuts erzeugen hohen Kommunikationsdruck. Eine robuste Routine verhindert widersprüchliche Aussagen und sorgt dafür, dass Support und Management das gleiche Lagebild haben.

Update-Takt und Inhalte

Für Kommunikationsmuster und „confirmed facts“-Disziplin sind praxisnahe Leitfäden hilfreich, z. B. Atlassian Incident Communication und Prozessressourcen wie PagerDuty Incident Response.

Phase 6: Field Dispatch – vom Verdacht zur konkreten Beauftragung

Field Dispatch ist der Wendepunkt: Jetzt wird aus der NOC-Diagnose eine physische Entstörung. Damit Dispatch schnell läuft, braucht es ein standardisiertes Dispatch-Paket, das ohne Rückfragen nutzbar ist.

Dispatch-Pflichtdaten

Carrier vs. eigenes Field Team: Entscheidungskriterien

Phase 7: Evidence Pack – Beweise für Carrier/Vendor und späteres RCA

Ein Fiber-Cut wird häufig später für SLA-Nachweise, Gutschriften und RCA benötigt. Ein kleines Evidence Pack spart Stunden Arbeit und beschleunigt externe Eskalationen.

Phase 8: Recovery und Validierung – wann ist „wiederhergestellt“ wirklich stabil?

Nach dem physischen Fix ist der Incident nicht automatisch beendet. Häufig folgen Recovery-Wellen: Sessions bauen sich neu auf, DNS-Caches laufen aus, Traffic kehrt zurück, und Schutzpfade werden zurückgebaut. Ein Runbook muss daher klare Validierung und ein Stabilitätsfenster definieren.

Validierungskriterien (Minimum)

Stabilitätsfenster als Gate (MathML)

Stable ⇐ DropRate≈Baseline ∧ RoutingChurn≈Baseline ∧ ServiceSLI≥Target

Phase 9: Cleanup und Sign-off – Second Outage vermeiden

Viele Teams machen den Fehler, nach dem Fix sofort „alles zurückzudrehen“. Gerade nach Fiber Cuts ist das riskant: Traffic kehrt zurück, aber Schutzpfade oder Policies sind noch in Übergangszuständen. Cleanup sollte deshalb staged erfolgen.

Typische Fehler beim Fiber-Cut-Handling und Gegenmaßnahmen

Outbound-Ressourcen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version