Service Catalog fürs Netzwerk: Welche Services gibt es wirklich?

Ein Service Catalog fürs Netzwerk beantwortet eine einfache, aber in vielen Unternehmen überraschend schwer zu klärende Frage: Welche Netzwerk-Services gibt es wirklich – und was bedeutet „Netzwerk“ als Lieferant konkret? Ohne Servicekatalog bleibt der Netzwerkbetrieb oft unscharf: Applikationsteams erwarten „Connectivity“, Security erwartet „Segmentierung“, das Management erwartet „Stabilität“, und im Ticketing landen Anfragen, die von „Bitte VLAN“ bis „Internet ist langsam“ reichen. Das führt zu Reibung, weil weder Umfang noch Zuständigkeiten klar sind. Ein Servicekatalog schafft Ordnung, indem er Netzwerkleistungen als definierte Service-Angebote beschreibt: mit Scope, Voraussetzungen, Lieferzeiten, SLAs/SLOs, Übergabepunkten, Standardchanges, Runbooks, Monitoring und klarer Ownership. Der Nutzen ist unmittelbar: Anfragen werden schneller und sauberer bearbeitet, Outsourcing-Übergaben funktionieren besser, Audits erhalten nachvollziehbare Artefakte, und die Kommunikation zwischen Netzwerk, Plattform, Security und Applikationen wird präziser. Dieser Artikel zeigt, wie Sie einen Servicekatalog für Netzwerktechnik auf Expertenniveau aufbauen: von der Service-Definition über Service-Tiers und Request-Workflows bis zu Messbarkeit (SLIs/SLOs) und der Integration in CMDB/SoT.

Warum ein Netzwerk-Servicekatalog mehr ist als „eine Liste“

Viele Teams starten mit einer Liste: „WAN, LAN, WLAN, Firewall“. Das hilft nur begrenzt, weil es nicht beschreibt, was geliefert wird, wie es angefragt wird und welche Grenzen gelten. Ein Servicekatalog ist in der Praxis ein Vertrag zwischen Lieferant (Netzwerkteam) und Konsumenten (Applikation, Workplace, OT, Security, externe Partner). Er macht implizite Annahmen explizit und reduziert so Ticket-Pingpong.

• Scope-Klarheit: Was gehört zum Service, was nicht?
• Standardisierung: Welche Änderungen sind Standard, welche sind „Normal Change“?
• Messbarkeit: Was wird gemessen (Verfügbarkeit, Latenz, Loss), und wie wird berichtet?
• Ownership: Wer ist accountable, wer ist responsible, wer wird consulted?
• Auditfähigkeit: Nachweise sind an Serviceobjekte geknüpft (Policies, Logs, Rezertifizierung).

Als prozessuale Orientierung ist das ITIL-Konzept von Servicekatalog und Service Management hilfreich, z. B. über ITIL Best Practices.

Begriffe sauber definieren: Service, Service Offering, Request und Standard Change

Damit ein Service Catalog fürs Netzwerk konsistent wird, sollten Sie mit klaren Definitionen arbeiten:

• Service: Eine wiederkehrende Leistung mit definiertem Nutzen (z. B. „Site Connectivity“).
• Service Offering: Konkrete Ausprägung eines Services (z. B. „Site Connectivity – Standard“, „Site Connectivity – High Availability“).
• Service Request: Anfrage zur Bereitstellung/Änderung innerhalb des standardisierten Rahmens (z. B. „neues Subnetz in VRF PROD“).
• Standard Change: vordefinierte, risikoarme Änderung mit festem Ablauf (z. B. „Port aktivieren mit Standardprofil“).

Diese Trennung verhindert, dass alles als „Incident“ oder „Projekt“ behandelt wird.

Der zentrale Schritt: Service Discovery – welche Services existieren faktisch?

Viele Organisationen haben einen „gefühlten“ Katalog, aber keinen realen. Deshalb beginnt ein guter Servicekatalog nicht mit Idealen, sondern mit Discovery: Welche Leistungen liefert das Netzwerkteam heute tatsächlich?

• Ticket-Analyse: Welche Anfrage-/Incident-Typen dominieren? (Top 20 Kategorien)
• Change-Historie: Welche wiederkehrenden Changes passieren? (z. B. VLAN, BGP Peer, Firewall Rule, VPN)
• Monitoring-Scope: Was wird aktiv überwacht? Das sind meist echte Services oder Servicebestandteile.
• CMDB/SoT: Welche CIs/Objekte sind dem Netzwerkteam zugeordnet (Sites, Circuits, Firewalls, Load Balancer)?
• Stakeholder-Interviews: Was erwarten Applikation, Security und Workplace konkret?

Aus dieser Discovery entsteht ein „Ist-Katalog“, der anschließend standardisiert und bereinigt wird.

Service-Taxonomie: So strukturieren Experten einen Netzwerk-Servicekatalog

Ein Servicekatalog wird erst nutzbar, wenn er klar strukturiert ist. Für Netzwerkteams hat sich eine Taxonomie nach Domänen plus Querschnittsservices bewährt.

• Connectivity Services: LAN/Campus, WAN/SD-WAN, DC-Fabric, Cloud Connectivity
• Segmentation & Security Services: VRFs/Zonen, Firewall-Policy, Remote Access, SASE/Proxy
• Core Network Services: DNS/NTP, IPAM, AAA (TACACS/RADIUS), Routing Services
• Wireless Services: SSIDs, RF Profiles, Guest Access, Roaming Policies
• Observability Services: Monitoring, Logging, Flow Visibility, Incident Tooling
• Physical & DCIM Services: Rack/Port/Cable Management, Circuits, Cross-Connects, Remote Hands

Querschnitt: Change Enablement, Standards, Dokumentation, Evidence-Pakete, Service Reports.

Beispielhafte Service-Angebote, die „Netzwerk“ oft wirklich liefert

Viele Organisationen sind überrascht, wie konkret Netzwerkleistungen sind, wenn man sie als Offerings formuliert. Typische, realistische Service Offerings:

• Site Connectivity: Anbindung eines Standorts an WAN/SD-WAN (Standard oder HA)
• VLAN/Segment Bereitstellung: neues Subnetz inkl. Gateway, DHCP-Relay, ACL-Baseline
• VRF/Zone Bereitstellung: neue Routing-Domäne inkl. Standardpolicies und Logging
• Firewall Rule Change: Standardflow, Ausnahmeflow mit Ablaufdatum/Rezertifizierung
• VPN/IPsec Tunnel: Site-to-Site oder Partner-Tunnel inkl. Crypto Suite, Rekey, Monitoring
• Public Exposure: NAT/Load Balancer/WAF-Fronting (je nach Organisationsschnitt)
• Wireless SSID: Corporate/Guest/IoT inkl. VLAN Mapping, Auth, Roaming Policy
• IPAM Allocation: Prefix- und Reservierungsmanagement nach Template
• Network Observability: Standarddashboards, Alerts, Flow-Reports, Runbook-Verlinkung

Der Katalog wird dadurch „requestbar“: Statt „könnt ihr mal…“ gibt es definierte Bestellungen.

Service-Blueprint: Welche Felder jedes Netzwerk-Service-Offering haben sollte

Ein Service Offering sollte so beschrieben sein, dass Konsumenten es ohne Rückfragen verstehen und bestellen können.

• Beschreibung: Nutzen und Ziel
• Scope: was enthalten ist (und was explizit nicht)
• Voraussetzungen: Inputdaten, Abhängigkeiten, notwendige Freigaben
• Request Inputs: Pflichtfelder im Ticket (z. B. Site, VRF, Ports, 5-Tuple)
• Lieferzeit: Standard Lead Time (z. B. 2 Tage, 10 Tage, projektabhängig)
• Risiko/Change-Klasse: Standard Change vs. Normal Change vs. Emergency
• Qualitätskriterien: Verifikation/Post-Checks, Dokumentations-DoD
• Monitoring: welche SLIs/Alerts gelten, welche Dashboards sind relevant
• Ownership: accountable Owner, responsible Team, escalation path
• Security/Compliance: Logging, Rezertifizierung, Evidence-Links (wo nötig)

SLIs/SLOs im Netzwerk-Servicekatalog: Was wirklich messbar ist

Ein Servicekatalog wirkt deutlich besser, wenn er messbar ist. Dafür eignen sich SLIs (Indicators) und SLOs (Objectives). Wichtig ist, dass Sie pro Service nur wenige, aber aussagekräftige SLIs definieren.

• Connectivity: Verfügbarkeit, Packet Loss, Latenz (z. B. zwischen Sites oder zu Hubs)
• Internet Egress: Availability, RTT zu Referenzzielen, Throughput/Capacity, Failover-Zeit
• DNS: Query Success Rate, Response Time, Resolver Reachability
• VPN: Tunnel Uptime, Rekey-Failures, SLA-Metriken bei SD-WAN
• Firewall: Policy Change Lead Time, Exception Aging, Logging Coverage (indirekte Indikatoren)

Für SLO-Grundkonzepte ist der SRE-Ansatz eine gute Referenz: Google SRE – Service Level Objectives.

Request-Design: Wie ein Servicekatalog Tickets „intelligent“ macht

Ein häufiges Ziel des Servicekatalogs ist, dass Tickets mit den richtigen Informationen starten. Das gelingt, wenn jedes Offering definierte Request-Inputs besitzt. Beispiele:

• VLAN/Subnetz: Site, VRF/Zone, Segmentklasse, benötigte Größe, Gateway-Policy, DHCP ja/nein
• Firewall Flow: Source/Destination (inkl. NAT?), Ports/Protokoll, Zweck, Owner, Ablaufdatum, Logging-Anforderung
• VPN: Peer-Endpunkte, Crypto Suite, Rekey, Routing (static/BGP), Monitoring, Ownership
• WLAN SSID: Auth-Methode (802.1X/PSK), VLAN Mapping, Roaming, Band-Steering, Guest Captive Portal

Wenn diese Inputs im Ticketing als Pflichtfelder modelliert sind, sinkt die Rückfragequote drastisch.

Servicekatalog und Source of Truth: Services an echte Objekte koppeln

Ein Servicekatalog wird belastbar, wenn er nicht nur Text ist, sondern an reale Objekte gekoppelt ist: Sites, Circuits, Devices, VRFs, VLANs, Firewall-Zonen. Viele Netzwerkteams nutzen NetBox als IPAM/DCIM-Source-of-Truth und verlinken Service-Offerings auf diese Objekte. Einstieg: NetBox Dokumentation.

• Service → Scope-Objekte: „Site Connectivity“ referenziert Circuits und Site-Blocks.
• Service → Ownership: Owner ist als Tag/Custom Field am Objekt sichtbar.
• Service → Doku-Artefakte: Diagramme, Runbooks, SOPs sind über stabile Links verbunden.

Damit wird der Katalog nicht zur statischen Seite, sondern zum Navigationssystem in den Betrieb.

Service-Tiers: Standard, Premium, High Availability

In Expertenumgebungen ist es hilfreich, Services in Tiers anzubieten. Nicht jeder Bereich braucht maximalen Aufwand. Tiers schaffen Erwartungsmanagement.

• Standard: definierte Basisverfügbarkeit, Standardmonitoring, Standardchange-Prozess
• Business Critical: strengere SLOs, engere Change-Fenster, erweitertes Monitoring, schnellere Eskalation
• High Availability: redundante Circuits/Devices, definierte Failover-Ziele, regelmäßige Failover-Tests

Tiers sind auch intern nützlich, weil sie Prioritäten im Betrieb und bei Budgetentscheidungen strukturieren.

Governance: Ownership, RACI und Freigaben im Servicekatalog

Ein Katalog ohne Ownership verrottet. Deshalb sollte jedes Offering einen accountable Owner besitzen (RACI) und einen Review-Rhythmus. Zusätzlich sollten Freigaben risikobasiert modelliert sein.

• Accountable: Domain Owner (WAN, Campus, DC, Security)
• Responsible: Operations/Engineering Teams, ggf. Automation Jobs
• Consulted: Security, Service Owner, Compliance (je nach Offering)
• Informed: Stakeholder/Management (bei High-Risk Änderungen)

Für die prozessorientierte Einbettung in Change- und Knowledge-Management ist ITIL eine geeignete Referenz.

„Living Catalog“: Wie der Servicekatalog aktuell bleibt

Ein Servicekatalog muss „leben“, sonst wird er schnell eine schöne, falsche Seite. Bewährte Mechanismen:

• Definition of Done: Jede relevante Change-Klasse aktualisiert Katalog/Offerings, wenn sich Scope oder Inputs ändern.
• PR/MR-Workflow: Änderungen am Katalog laufen über Reviews und sind nachvollziehbar.
• CI Checks: Broken Links, Metadatenpflicht, veraltete Artefakte, Diagramm-Rendering (wenn genutzt).
• Quarterly Review: top Services prüfen (Top 20 Tickets), veraltete Offerings deprecaten.

Für PR/MR-Konzepte sind die Plattformdokumentationen hilfreich: GitHub Pull Requests und GitLab Merge Requests.

Typische Anti-Pattern beim Netzwerk-Servicekatalog

• Zu abstrakt: „Connectivity“ ohne Request-Inputs; Lösung: konkrete Offerings mit Pflichtfeldern.
• Zu technisch: nur Protokolle und Geräte; Lösung: Nutzen, Scope, Lieferzeiten, Qualitätskriterien.
• Alles ist „projekt“: keine Standardchanges; Lösung: Standard Offerings und Standard Changes definieren.
• Keine Ownership: niemand pflegt; Lösung: accountable Owner + Review-Datum als Pflicht.
• Kein Monitoring-Bezug: Service ist nicht messbar; Lösung: SLIs/SLOs und Dashboard-Links pro Service.
• Copy-Paste Stammdaten: Drift; Lösung: SoT/CMDB verlinken statt replizieren.

Checkliste: Service Catalog fürs Netzwerk professionell aufsetzen

• Der Service Catalog fürs Netzwerk ist aus Discovery entstanden (Tickets, Changes, Monitoring, SoT/CMDB) und beschreibt reale Leistungen
• Services sind in Offerings aufgeteilt (Standard/Business Critical/HA) und haben klare Scope-Grenzen
• Jedes Offering hat Pflichtfelder: Beschreibung, Voraussetzungen, Request Inputs, Lieferzeiten, Change-Klasse, Verifikation, Monitoring, Ownership
• SLIs/SLOs sind pro Service minimal, aber aussagekräftig definiert (Verfügbarkeit, Loss, Latenz, Tunnel-Health, DNS-Response)
• Request-Workflows sind so gestaltet, dass Tickets mit den richtigen Informationen starten (weniger Rückfragen)
• SoT/CMDB ist angebunden (Services verlinken auf Sites, Circuits, VRFs/VLANs, Devices), z. B. über NetBox
• Governance ist klar (RACI, Freigaben risikobasiert, Rezertifizierungen für Ausnahmen)
• Der Katalog ist „living“ (DoD, PR/MR-Reviews, CI Checks, regelmäßige Reviews, Deprecation-Regeln)
• Outbound-Links führen zu relevanten Grundlagen: ITIL, SRE SLOs, NetBox, GitHub Pull Requests

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.