Second-Level-Support – L2-Support oder Technical Support – ist die zweite Eskalationsstufe im Supportmodell, die Anfragen übernimmt, die L1 nicht mit standardisierten Mitteln lösen konnte. L2 verfügt über tiefergehende technische Expertise, direkten Zugriff auf Systeme, Logs und Konfigurationen und kann Ursachenanalysen durchführen, die über das Playbook von L1 hinausgehen. L2 analysiert, diagnostiziert und behebt komplexere Probleme – und eskaliert nur jene Fälle an L3, die strukturelle Lösungen oder Expertenwissen erfordern, das L2 nicht hat.
In Automatisierungsorganisationen ist L2 typischerweise durch erfahrene Operations- oder Workflow-Engineers besetzt, die sowohl das System als auch die Kundenprozesse gut kennen. L2 ist teurer als L1 – daher ist es wirtschaftlich sinnvoll, so viel wie möglich auf L1 zu halten und L2 nur für Anfragen zu nutzen, die seine tiefere Expertise tatsächlich erfordern.
Typische L2-Aufgaben in Automatisierungsinfrastrukturen
Log-Analyse
Fehlerursache aus Workflow-Logs, Cloud-Logs und Systemlogs identifizieren. Korrelation von Ereignissen über verschiedene Systeme hinweg – was hat wann was ausgelöst?
Konfigurationsänderungen
Workflow-Parameter, API-Verbindungen, Authentifizierungskonfigurationen anpassen. Nur mit vollständigem Systemverständnis, da jede Änderung andere Workflows beeinflussen kann.
Daten-Debugging
Fehler in Datenformaten, Mapping-Problemen oder Transformationslogik identifizieren und beheben. Direkte Datenbankabfragen, Payload-Analyse, Datenqualitätsprüfungen.
Performance-Analyse
Warum ist ein Workflow plötzlich langsamer? Datenbankindizes, API-Latenzen, Ressourcenauslastung, Cloud-Bottlenecks diagnostizieren und beheben.
Security-Incidents
Ungewöhnliche Zugriffsmuster, fehlgeschlagene Authentifizierungen, verdächtige API-Nutzung analysieren und initial eindämmen. Eskalation zu L3 wenn strukturelle Sicherheitslücke vermutet.
Integrations-Fehler
API-Antwort-Fehler von Drittanbietern analysieren, Webhook-Probleme debuggen, Datenfluss zwischen Systemen nachverfolgen wenn Daten „verschwinden“.
Praxisbeispiel
L1 eskaliert ein Ticket an L2: „Rechnungsworkflow läuft seit 2 Stunden nicht, Neustart hat nicht geholfen.“ L2-Diagnose (35 Minuten): Log-Analyse zeigt 403-Fehler von der ERP-API. Zeitpunkt des ersten Fehlers: gestern 23:17 Uhr. Correliertes Ereignis: ERP-System hat gestern Abend ein Update eingespielt. Überprüfung der API-Dokumentation des ERP-Systems: Ein neues Pflichtfeld wurde im Update hinzugefügt. Der Workflow sendet dieses Feld nicht. Lösung: Workflow-Konfiguration um das neue Feld ergänzt (bestehende Rechnungen erhalten einen Default-Wert). Test in Staging erfolgreich. Deployment in Produktion. Workflow läuft wieder. Nacharbeiten: Kunde informiert über Ursache und Behebung. Maßnahme für die Zukunft: API-Versionspinning prüfen, sodass Breaking Changes im ERP-Update früher erkannt werden. Dieser Fall war klar L2 – L1 hatte keine Möglichkeit, die Log-Analyse oder ERP-API-Änderung zu erkennen.
