Design KPIs: Konvergenz, Availability, Cost/Bit und Operational Complexity

Design KPIs sind im Carrier- und Provider-Umfeld der Unterschied zwischen „Design sieht gut aus“ und „Design ist nachweislich gut“. Viele Netzarchitekturen werden noch immer primär über Diagramme, Feature-Listen und Erfahrungswerte diskutiert. Das führt schnell zu Missverständnissen: Ein Team optimiert auf schnelle Konvergenz, ein anderes auf minimale Kosten, ein drittes auf maximale Redundanz – und am Ende entsteht eine komplexe Topologie, die weder billig noch stabil noch gut betreibbar ist. Design KPIs schaffen hier Klarheit, weil sie die wichtigsten Qualitätsmerkmale eines Netzes messbar machen: Konvergenz (wie schnell erholt sich das Netz nach einem Fehler), Availability (wie häufig und wie lange sind Services wirklich verfügbar), Cost/Bit (wie effizient wird Kapazität in Euro pro transportiertem Bit bereitgestellt) und Operational Complexity (wie viel Betriebsaufwand und Change-Risiko erzeugt die Architektur). In Telco-Netzen sind diese KPIs eng miteinander gekoppelt: Mehr Redundanz kann Availability erhöhen, aber auch Komplexität steigern; aggressive Timer können Konvergenz verbessern, aber Flapping verursachen; zusätzliche Links senken Cost/Bit durch bessere Auslastung, können aber die Control Plane belasten. Ein professionelles Design bewertet deshalb nicht nur einzelne Kennzahlen, sondern das Zusammenspiel – und definiert Zielwerte pro Domäne (Core, Metro, Access, Internet Edge, FTTH, Mobile Backhaul) sowie pro Serviceklasse (Retail, Wholesale, Enterprise). Dieser Artikel zeigt, wie Sie die zentralen Design KPIs definieren, messen und als Experten-Gates in Architekturentscheidungen integrieren, damit Ihre Topologie skalierbar bleibt und der Betrieb planbar wird.

Warum KPIs ins Design gehören und nicht erst in den Betrieb

KPIs werden häufig erst im laufenden Betrieb betrachtet: Monitoring zeigt Latenz, Ausfälle und Auslastung – und man reagiert. Carrier-Grade Engineering dreht diese Logik um: KPIs werden bereits im Design als Zielwerte definiert und später als „Expected vs. Observed“ verifiziert. Das reduziert Change Risk, verhindert Architekturdrift und macht Investitionsentscheidungen nachvollziehbar.

• Objektive Entscheidungen: Statt „gefühlt stabil“ gibt es messbare Zielwerte und Trade-offs.
• Vergleichbarkeit: Ring vs. Mesh, SR vs. MPLS, zentraler vs. regionaler BNG – Entscheidungen werden KPI-basiert.
• Governance: Architecture Reviews werden zu Gate-Prozessen (Go/No-Go) mit Nachweisen.
• Kontinuierliche Verbesserung: Incidents und Rollouts liefern Feedback zur Anpassung von Blueprints.

Leitprinzip: Ein KPI ohne Zielwert ist nur eine Zahl

Für Carrier-Grade Designs müssen KPIs immer mit Zielwerten, Messmethode, Scope (Domäne/Serviceklasse) und Verantwortlichkeit definiert sein.

KPI 1: Konvergenz – wie schnell wird das Netz nach Fehlern stabil?

Konvergenz beschreibt, wie schnell ein Netz nach einem Ereignis (Link down, Node down, IXP-Ausfall, DCI-Problem) wieder einen stabilen Zustand erreicht. In Telco-Netzen ist nicht nur „time to reroute“ relevant, sondern die gesamte Erholung: Detection, Schutzumschaltung (FRR), Control-Plane-Stabilisierung und Service-Recovery. Eine gute KPI-Definition trennt diese Phasen, weil unterschiedliche Mechanismen optimiert werden.

Konvergenz als Phasenmodell

$\mathrm{Convergence}=\mathrm{Detection}+\mathrm{Protection}+\mathrm{ControlPlane}+\mathrm{ServiceRecovery}$

• Detection: Link-Down, BFD, Loss-of-Signal – wie schnell wird ein Fehler erkannt?
• Protection: FRR/TI-LFA, Ring-Protection, ECMP-Next-Hop Switch – wie schnell wechselt der Datenpfad?
• Control Plane: IGP/BGP Stabilisierung, SPF/Update-Churn – wie lange dauert „ruhig werden“?
• Service Recovery: Sessions/State (BNG/CGNAT/Firewalls), Anycast-Health, DNS – wie schnell sind Services wieder „grün“?

Was Sie messen sollten

• Time to First Packet Loss Recovery: Zeit bis Pakete wieder zuverlässig ankommen (data plane).
• Time to Route/Policy Steady State: Zeit bis Prefix-Counts, Bestpaths und Policies stabil sind.
• Churn Rate: Anzahl IGP LSAs/LSPs, BGP Updates pro Sekunde während Events.
• Scope: Link/Node/Region-Ausfall getrennt messen, weil die Mechanismen unterschiedlich sind.

Typische Trade-offs

• Aggressive Timer: Kann Detection beschleunigen, aber Flapping und CPU-Churn erhöhen.
• Mehr Pfade: ECMP/Mesh kann Protection verbessern, erhöht aber Komplexität und Monitoringbedarf.
• Stateful Services: Können ServiceRecovery dominieren, auch wenn Routing schnell reagiert.

KPI 2: Availability – echte Verfügbarkeit statt „Uptime“

Availability ist in Telco-Netzen eine Servicekennzahl, nicht nur eine Gerätekennzahl. Ein Router kann „up“ sein, während ein Service degradierte Latenz oder Packet Loss hat. Deshalb sollte Availability im Design als SLO definiert werden: Was gilt als „available“? Welche Fehler sind zulässig? Und wie wird gemessen? Carrier-Grade Designs definieren Availability pro Domäne und pro Serviceklasse, inklusive Wartungsfenstern (Planned Maintenance).

Service-Availability als SLO

$\mathrm{Availability}=1–\frac{\mathrm{UnavailableTime}}{\mathrm{TotalTime}}$

• Definition „unavailable“: Nur Total Outage oder auch starke Degradation (z. B. Loss > X, RTT > Y)?
• Messpunkte: Topologisch verteilte Probes (PoPs/Regionen) statt nur NMS-Gerätestatus.
• Planned vs. Unplanned: Wartung separat erfassen; Ziel ist „hitless“ oder „low impact“.
• Failure Domains: Availability pro Region/PoP; ein globaler Wert verschleiert lokale Probleme.

Designhebel für Availability

• Redundanz mit Diversität: Dual-Homing und SRLG-Disziplin reduzieren gemeinsame Ausfallursachen.
• Wartungsdomänen: Rolling Upgrades möglich machen, ohne beide Redundanzseiten zu treffen.
• Guardrails: Leak-Prevention, Max-Prefix, CoPP – verhindern großflächige Incidents durch Control-Plane-Failures.
• Containment: Domänenschnitt (Metro/Region/Core) begrenzt Blast Radius.

Anti-Pattern: Availability ohne Degradation-Kriterien

Wenn „available“ nur „Ping geht“ bedeutet, werden Customer-Impact und QoS-Probleme ignoriert. Carrier-Grade Availability sollte serviceorientiert sein.

KPI 3: Cost/Bit – Kapazität wirtschaftlich bereitstellen

Cost/Bit ist ein zentrales KPI für Telcos, weil Transportnetze massiv CAPEX- und OPEX-getrieben sind. Gleichzeitig ist Cost/Bit oft missverstanden: Es geht nicht nur um „Linkkosten“, sondern um den Gesamtaufwand pro transportierter Nutzlast über einen Zeitraum. Topologisch beeinflussen Redundanz, Pfadwahl, Auslastungsgrad, Technologieentscheidungen (z. B. 100G vs. 400G, Ring vs. Mesh, zentral vs. regional) und Betriebsaufwand die Kennzahl stark.

Ein praktikables Cost/Bit-Modell

$\mathrm{CostPerBit}=\frac{\mathrm{CAPEX}+\mathrm{OPEX}}{\mathrm{DeliveredBits}}$

• CAPEX: Router/Optik/Transponder, Linecards, DC-Footprint, Cross-Connects.
• OPEX: Betrieb, Lizenzen, Energie, Wartung, Incident-Kosten, Transitkosten (am Edge).
• DeliveredBits: Nutzlast über Zeit, idealerweise nach Serviceklasse und Region getrennt.

Topologische Hebel für Cost/Bit

• Auslastung erhöhen: ECMP/Partial Mesh kann Kapazität besser nutzen als „blockierte“ Ring-Reserve – aber nur mit guter Observability.
• Engpässe reduzieren: Richtige Hub-Platzierung und DCI-Design verhindern teure Overprovisioning-Spiralen.
• Peering optimieren: Mehr Peering senkt Transitkosten, verändert aber Policy- und Betriebsaufwand.
• Headroom-Strategie: Zu wenig Headroom führt zu Incidents (teuer), zu viel Headroom verschlechtert Cost/Bit.

Anti-Pattern: Cost/Bit ohne N-1 Betrachtung

Ein Design kann im Normalbetrieb günstig wirken, im Failover aber Engpässe erzeugen, die Servicequalität ruinieren und Incident-Kosten explodieren lassen. Carrier-Grade Cost/Bit braucht N-1/N-2 als Lastfall.

KPI 4: Operational Complexity – der stille Kostentreiber

Operational Complexity ist oft der KPI, der am stärksten unterschätzt wird. Zwei Designs können dieselbe Performance liefern, aber sehr unterschiedliche Betriebsaufwände verursachen: mehr Protokolle, mehr Sonderfälle, mehr manuelle Changes, höhere Fehlerraten, längere MTTR. Operational Complexity sollte deshalb als eigener KPI im Design stehen – mit messbaren Proxy-Metriken.

Komplexität als messbares Konstrukt

$\mathrm{OpsComplexity}\approx \mathrm{State}+\mathrm{Variants}+\mathrm{Changes}+\mathrm{Dependencies}$

• State: Anzahl Protokollzustände (BGP Sessions, IGP Adjacencies, SR Policies, VRFs, EVPN Instances).
• Variants: Wie viele „Profile“ existieren (Timer, QoS, Policy)? Jede Variante erhöht Fehlerwahrscheinlichkeit.
• Changes: Change-Volumen, Automationsgrad, Change-Failure-Rate, Rollback-Häufigkeit.
• Dependencies: Abhängigkeiten zu externen Systemen (Controller, AAA, Logging, DDoS-Plattformen).

Praktische Proxy-KPIs für Operational Complexity

• Change-Failure-Rate: Anteil der Changes, die Incident/Degradation verursachen oder Rollback benötigen.
• MTTR: Zeit bis Wiederherstellung, getrennt nach Domäne (Core/Metro/Edge/Access).
• Config Drift Rate: Abweichungen zwischen Source of Truth und Ist-Konfiguration.
• Exception Count: Anzahl aktiver Sonderfälle/Ausnahmen (idealerweise mit Ablaufdatum).
• Alert Noise Ratio: Anteil Alerts ohne Action vs. Alerts mit echter Maßnahme (Signal/Noise).

Designhebel zur Reduktion von Komplexität

• Blueprints: Rollenbasierte Standardprofile statt individuell gebauter Regionen.
• Intent Validation: Pre-Change Checks für Guardrails (Leaks, Max-Prefix, MTU, QoS, CoPP).
• Domänenschnitt: Kapseln von Spezialfunktionen (Edge, DDoS, CGNAT, BNG) statt „alles überall“.
• Observability-by-Design: High-Signal Alerts reduzieren Noise und verkürzen MTTR.

KPIs zusammen denken: Zielkonflikte und „Pareto-Front“ im Design

Carrier-Grade Design bedeutet, Zielkonflikte aktiv zu managen. Es ist selten möglich, Konvergenz maximal zu beschleunigen, Availability maximal zu erhöhen, Cost/Bit zu minimieren und Komplexität gleichzeitig zu senken. Stattdessen suchen Sie eine stabile Balance. In Reviews hilft es, pro Domäne eine Priorität zu definieren: Internet Edge optimiert stärker auf Policy-Guardrails und DDoS-Resilienz, Core stärker auf Stabilität und schnelle Recovery, Access stärker auf Scale und OPEX.

• Konvergenz vs. Stabilität: Schnellere Detection kann mehr Flaps erzeugen.
• Availability vs. Cost/Bit: Mehr Redundanz erhöht Verfügbarkeit, kostet aber CAPEX/OPEX.
• Cost/Bit vs. Komplexität: Mesh/ECMP kann Cost/Bit verbessern, erhöht aber Monitoring- und TE-Komplexität.
• Komplexität vs. Featureumfang: Jede zusätzliche Technologie (RSVP-TE, spezielle EVPN-Optionen) hat Betriebskosten.

Designregel: KPIs pro Domäne gewichten

Ein einheitlicher KPI-Satz ohne Gewichtung führt zu falschen Entscheidungen. Definieren Sie Gewichte pro Domäne und Serviceklasse.

KPIs als Experten-Gates: Wie aus Zahlen echte Designentscheidungen werden

KPIs werden erst dann zu „Gates“, wenn sie in Review-Prozesse und Rollout-Pipelines integriert sind. Das bedeutet: Designreview verlangt Zielwerte, Evidence, und Stop/Go-Kriterien. Für kritische Changes müssen KPI-Gates vorab in Lab/Simulation/Intent Validation geprüft werden und nach dem Deploy als Post-Checks wieder gemessen werden.

• Pre-Change Gates: Leak-Prevention, Max-Prefix, MTU-Minimum, QoS-Profil, FRR Coverage, CoPP aktiv.
• Canary Gates: SLOs bleiben grün (Loss/RTT/Jitter), Drops im Budget, Routing-Churn akzeptabel.
• Wave Gates: Nach jeder Welle Vergleich „Expected vs. Observed“, sonst Stopp.
• Evidence Archive: Reports, Diffs, Metriken und Entscheidungen versioniert, auditierbar.

Ein einfaches Gate-Modell

$\mathrm{Go}=(\mathrm{Convergence}\le \mathrm{Target})\wedge (\mathrm{Availability}\ge \mathrm{Target})\wedge (\mathrm{CostPerBit}\le \mathrm{Budget})\wedge (\mathrm{OpsComplexity}\le \mathrm{Threshold})$

Die konkrete Parametrisierung hängt von Domäne und Serviceklasse ab – wichtig ist die Struktur: Zielwerte sind explizit und werden geprüft.

Praktische Leitlinien: Design KPIs in Telco-Blueprints verankern

• KPIs pro Domäne definieren: Core, Metro, Access, Internet Edge, DCI, Mobile Backhaul – jeweils mit Zielwerten und Messpunkten.
• Konvergenz zerlegen: Detection/Protection/ControlPlane/ServiceRecovery separat messen, sonst optimieren Sie „blind“.
• Availability serviceorientiert messen: Degradation als Unavailability definieren, nicht nur Geräte-Uptime.
• Cost/Bit ganzheitlich rechnen: CAPEX+OPEX über DeliveredBits, inklusive N-1/N-2 Lastfällen und Incident-Kosten.
• Operational Complexity quantifizieren: Change-Failure-Rate, MTTR, Drift, Exceptions, Signal/Noise als Proxy-KPIs nutzen.
• KPI-Gates in Reviews integrieren: Topology Review Checkliste um KPI-Gates ergänzen, Evidence verlangen.
• Pre-/Post-Checks automatisieren: Intent Validation und Lab-Reproduktion für kritische Änderungen; Post-Checks als Abschlussbedingung.
• Gewichtung festlegen: Nicht alle KPIs sind überall gleich wichtig; definieren Sie Prioritäten pro Serviceklasse.
• Feedbackschleife etablieren: Nach Incidents und großen Rollouts KPI-Ziele und Blueprints nachschärfen, statt ad hoc zu patchen.