48 Ports, 48-mal Handarbeit, und der Admin-Tag ist weg?
Einen neuen Switch konfigurieren Sie heute Port für Port, Zeile für Zeile. Jede getippte Zeile ist ein möglicher Zahlendreher. COD erzeugt aus vielen Einzelschritten einen einzigen Rollout-Befehl und spielt ihn per Ansible direkt aus der Plattform aus, mit lesbaren Logs, mandantenfähig und on-premise.
Wartungskalender in der Wochenansicht: geplante Wartungen zentral terminieren.
Kennen Sie das?
48 Ports, 48-mal Handarbeit: Switch-Konfiguration frisst den Admin-Tag
Der Schmerz: Ein neuer Access-Switch kommt ins Rack, dann beginnt die Fleißarbeit: Port für Port konfigurieren, Zeile für Zeile in der CLI oder Klick für Klick im Webinterface. Bei mehreren Switches zieht sich das über Stunden.
Die Folge: Rollouts dauern unnötig lange und binden qualifizierte Admins mit stumpfer Wiederholarbeit. Tippfehler fallen oft erst auf, wenn ein Anwender kein Netz hat. Dann beginnt die Fehlersuche von vorn.
So löst COD das: COD erzeugt statt 48 Einzelschritten einen einzigen Rollout-Befehl für den gesamten Port-Bereich (z. B. Ports 1/0/1 bis 1/0/48 in einem Zug) und rollt die Konfiguration per Ansible direkt aus der Plattform aus, ganz ohne Werkzeugwechsel. Das spart Klicks, vermeidet Tippfehler und beschleunigt Deployments spürbar.
Jede geplante Wartung wird zum Fehlalarm, und das Team stumpft ab
Der Schmerz: Das Wartungsfenster ist seit Wochen geplant, trotzdem schlägt das Monitoring Alarm, sobald der erste Host neu startet. Das Team quittiert die erwartbaren Meldungen weg. Oder es gewöhnt sich an, Alarme während Wartungen pauschal zu ignorieren.
Die Folge: Fehlalarme kosten Zeit und untergraben das Vertrauen in jedes Monitoring-Signal. Wer Alarme routinemäßig wegklickt, übersieht irgendwann den einen, der zählt.
So löst COD das: Geplante Wartungen terminieren Sie zentral im COD-Kalender. Während des Wartungsfensters alarmiert das Monitoring nicht grundlos. Sie unterscheiden geplante Arbeiten zuverlässig von echten Störungen, und das Vertrauen in jeden Alarm bleibt erhalten.
Automatisierungsläufe ohne Nachweis: „Wer hat das ausgerollt?"
Der Schmerz: Nach einem Rollout stimmt etwas nicht. Aber welcher Lauf war es, wer hat ihn gestartet, was kam heraus? Die Antwort steckt, wenn überhaupt, in rohen JSON-Ausgaben, die niemand freiwillig liest.
Die Folge: Ohne saubere Nachvollziehbarkeit zieht sich jede Fehlersuche unnötig. Im KRITIS-Audit droht zudem ein Finding, weil sich Änderungen an der Infrastruktur nicht lückenlos belegen lassen.
So löst COD das: COD zeigt Ansible-Ausgaben formatiert und gut lesbar statt als rohes JSON. Jeder Log-Eintrag trägt seine Runner-ID, damit bleibt jeder Lauf eindeutig nachvollziehbar: Wer hat wann was ausgerollt, mit welchem Ergebnis. Das ist Nachvollziehbarkeit, die zu KRITIS und Audit passt.
Warum COD, nicht nur ein Feature
Automatisierung läuft in COD auf derselben Plattform wie Ihr Betrieb: Rollouts starten Sie neben den Assets, die sie betreffen, und teilen sich den Wartungskalender mit dem Monitoring. Deshalb weiß die Plattform, wann eine Arbeit geplant ist und wann eine echte Störung vorliegt. Ansible ohne Werkzeugwechsel, lesbare Logs mit Runner-ID, mandantenfähig und on-premise.
Häufige Fragen
Rollouts in Sekunden statt Stunden.
In einer Live-Demo zeigen wir Ihnen Bulk-Rollout, Zonen-Resync und Wartungskalender praxisnah in Ihrer Umgebung, oder Sie laden das Automatisierungs-Datenblatt mit allen Funktionen kompakt herunter.