AIOps in der Industrie:
vier Praxisbeispiele
und ihre Kennzahlen.
AIOps wertet die Monitoring-Daten aus IT und Anlage gemeinsam aus und sagt, welche Alarme zusammengehören und woher die Störung kommt. Hier steht, wie das funktioniert, was vier Projekte gemessen haben und woran eine Einführung in der Praxis hängt.
AI
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
DevOps, CI/CD und Industrial Automation seit 2006.
Was ist
AIOps?
AIOps steht für „Artificial Intelligence for IT Operations“. Gemeint ist Machine Learning, das Logs, Metriken und Alarme automatisch auswertet. Es fasst zusammengehörige Meldungen zu einem Vorfall zusammen, erkennt Abweichungen vom Normalverhalten und nennt die wahrscheinliche Ursache. In der Industrie kommen zu den IT-Daten die Signale der Anlage hinzu, also SPS-Statusmeldungen, SCADA-Alarme und Sensorwerte.
Der Unterschied zum klassischen Monitoring zeigt sich nachts. Fällt in einer Halle ein Switch aus, melden sich zweihundert Systeme gleichzeitig, vom Server bis zur Steuerung. Ohne AIOps sucht die Rufbereitschaft in zwei getrennten Monitoringwelten nach dem Zusammenhang. Mit AIOps bekommt sie einen Vorfall mit einer Ursachenvermutung.
Beim Betrieb bleibt dieser Artikel nicht stehen. KI setzt inzwischen an jeder Stufe der Pipeline an, vom Build über den Test bis zum Deployment, und 76 % der DevOps-Teams hatten sie 2025 bereits in ihre Abläufe integriert (RealVNC 2026). Messbar wird das an fünf Betriebskennzahlen: MTTD, MTTA, MTTR, MTBF und MTTF. In der Software-Delivery kommen die DORA-Metriken dazu.
Ob Ihre Organisation die Voraussetzungen schon mitbringt, zeigt das 4-Stufen-Reifegradmodell in unserem Leitfaden KI in der Produktion und Fertigung: Automatisierung zuerst. Die Kurzfassung der Definition steht im Glossar-Eintrag zu AIOps.
AI
Ist KI im Industrial DevOps bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
Wie funktioniert
AIOps?
AIOps sammelt Logs, Metriken und Events aller Systeme zentral ein und legt vier ML-gestützte Funktionen darüber: Rauschunterdrückung, Anomalieerkennung, Ursachenanalyse und automatisierte Behebung. In der Industrie kommt eine Signalklasse hinzu, die klassische IT-Plattformen nicht kennen, nämlich SPS-Statusmeldungen, SCADA-Alarme und Sensorwerte aus der Anlage. Die Umsetzung im Betrieb begleiten wir als Dienstleister für DevOps- und Monitoring-Automatisierung.
Rauschunterdrückung
Aus tausenden Einzelalarmen werden wenige Vorfälle. Das Modell gruppiert Ereignisse nach Ähnlichkeit und filtert das Rauschen heraus, bevor es die Rufbereitschaft erreicht. Hier beginnen die meisten Projekte, weil Alert Fatigue das Problem ist, das jeder im Team kennt.
Anomalieerkennung
Das System lernt das Normalverhalten von Netzwerk, Applikationen und Anlage und meldet Abweichungen, die in keinem Schwellwert stehen. Das passiert oft Stunden, bevor eine Linie tatsächlich stillsteht.
Ursachenanalyse
Statt einer Alarmliste liefert AIOps eine wahrscheinliche Ursache (Root Cause), also Netzwerk, Deployment oder Steuerung. In getrennten IT- und OT-Monitoringwelten kostet diese Frage sonst Stunden manuellen Abgleich.
Automatisierte Behebung
Routinefälle löst die Plattform selbst. Sie startet einen Dienst neu, zieht Kapazität nach oder leert den Build-Cache. Alles darüber landet als vorbereiteter Vorschlag mit Confidence-Score beim Team.
- /01
Was AIOps-Überwachung von Monitoring und Observability unterscheidet
Klassisches Monitoring prüft Schwellwerte und meldet, dass ein Wert überschritten wurde. Observability geht einen Schritt weiter und macht über Logs, Metriken und Traces nachvollziehbar, warum sich ein System so verhält. AIOps-Überwachung setzt auf diesen Daten auf. Sie lernt das Normalverhalten von Netzwerk, Applikationen und Anlage, gruppiert zusammengehörige Alarme zu einem Vorfall und benennt die wahrscheinliche Ursache. Ohne brauchbare Observability-Daten hat das Modell nichts, woraus es lernen könnte.
- /02
Welche Technologie hinter AIOps steckt
Vier Bausteine tragen eine AIOps-Plattform. Eine Datenschicht führt Logs, Metriken, Events und Traces zusammen. Zeitreihen-Modelle erkennen Anomalien. Die Korrelation über Topologie und Zeitfenster gruppiert die Alarme, und Sprachmodelle klassifizieren Fehlertexte und führen Runbooks aus. In der Industrie kommt die Anbindung der OT-Quellen über OPC UA oder MQTT dazu. Das ist technisch der aufwendigste Teil, weil SPS und SCADA nie für Observability gebaut wurden.
Was bringt AIOps
in der Industrie?
Vier AIOps-Erfolgsgeschichten aus der Praxis zeigen den Effekt: korrelierte IT- und OT-Alarme in der Fertigung, selbstheilende SPS-Builds im Maschinenbau, ML-basierte Test-Selektion im Automotive-Umfeld und risikobewertete Deployments in der Logistik. Bei jedem Beispiel steht die Zahl, die dabei herauskam. Den Branchenkontext zum ersten Beispiel liefert der Anwendungsfall Fertigungsindustrie.
- /01
Fertigungsindustrie
AusgangslageIT- und OT-Monitoring laufen in getrennten Systemen. Bei einer Produktionsstörung dauert die Ursachenanalyse Stunden, weil jemand die Daten von Hand abgleichen muss.
KI-LösungEine AIOps-Plattform korreliert automatisch IT-Metriken (Netzwerk, Server, Applikationen) mit OT-Daten (SPS-Statusmeldungen, Sensorwerte, SCADA-Alarme) und zeigt, welche Ereignisse ursächlich zusammenhängen.
ErgebnisMTTD von 47 auf 3 Minuten gesunken. MTTR um 65 % niedriger. 40 % weniger ungeplante Stillstände.
- /02
Maschinenbau
AusgangslageSPS-Builds im TIA Portal schlagen regelmäßig fehl. Unterschiedliche Toolchain-Versionen, fehlende Bibliotheken und Probleme in der Build-Umgebung verursachen 30 % der Pipeline-Fehler.
KI-LösungEine Self-Healing Pipeline liest die Fehlerlogs mit NLP, ordnet sie einer Ursache zu und korrigiert selbst: Bibliotheken nachinstallieren, Toolchain-Version anpassen, Build-Cache leeren.
ErgebnisFehlerrate der Pipeline von 30 % auf 8 % gesunken. Die Pipeline behebt 70 % der bekannten Fehler selbst. Entwickler sparen im Schnitt 45 Minuten Fehlersuche pro Tag.
- /03
Automotive
AusgangslageEin Tier-1-Zulieferer muss bei jeder Code-Änderung an Steuergeräte-Software Tausende Tests gegen ISO 26262 fahren. Die vollständige Testsuite läuft 14 Stunden.
KI-LösungTest Impact Analysis ermittelt die relevanten Tests pro Code-Änderung. Ein ML-Modell, trainiert auf 18 Monaten Build-Historie, wählt nur die betroffenen Testfälle aus.
ErgebnisTestlaufzeit von 14 auf 2,5 Stunden gesunken. 82 % weniger Rechenressourcen bei gleicher Fehlererkennungsrate. Safety-Updates sind 60 % schneller ausgeliefert.
- /04
Logistik
AusgangslageEin Logistikdienstleister betreibt Sortieranlagen rund um die Uhr. Software-Updates müssen ohne Produktionsunterbrechung ausgerollt werden, und das Risiko schätzt bisher ein Mensch von Hand ab.
KI-LösungEin Modell wertet Durchsatz, Schichtpläne, frühere Fehlerraten und saisonale Schwankungen aus. Jedes Deployment bekommt vor der Ausführung einen Risiko-Score.
ErgebnisAusfälle durch Deployments um 90 % gesunken. Das System schlägt die passenden Fenster selbst vor. Releases erscheinen wöchentlich statt monatlich.
In den Ergebnissen stehen Abkürzungen wie MTTD und MTTR. Was sie genau messen und warum Instandhaltung und IT darunter Verschiedenes verstehen, klärt der nächste Abschnitt.
Woran misst man
AIOps?
AIOps wirkt auf fünf Betriebskennzahlen: MTTD (Zeit bis zur Erkennung), MTTA (Zeit bis zur Übernahme), MTTR (Zeit bis zur Wiederherstellung), MTBF (Zeit zwischen zwei Ausfällen) und MTTF (Lebensdauer bis zum Ausfall). Die ersten drei senkt AIOps direkt, weil Korrelation und Ursachenanalyse die Handarbeit ersetzen. MTBF und MTTF steigen indirekt über Predictive Maintenance.
Mit diesen fünf Zahlen lässt sich der Aufwand begründen. Alles andere an einer AIOps-Plattform ist Mittel zum Zweck.
Warum MTTR in der Instandhaltung etwas anderes misst als in der IT
In gemischten Projekten fällt irgendwann der Satz „unsere MTTR liegt bei vier Stunden“, und dann reden zwei Abteilungen aneinander vorbei. Die Instandhaltung rechnet die reine Reparaturzeit an der Maschine, ab dem Moment, in dem der Techniker davorsteht. Die IT rechnet von der ersten Alarmmeldung bis zum wiederhergestellten Normalbetrieb, also inklusive Diagnose, Fix und Test.
Dieselbe Störung, zwei Zahlen, die um den Faktor drei auseinanderliegen können. Wer AIOps über beide Welten legt, muss vorher festlegen, welche Definition gilt. Sonst zeigt ein Dashboard zwei verschiedene Dinge in derselben Spalte, und es fällt monatelang niemandem auf.
AIWas eine halbierte MTTR an der Anlage wert ist
Die Instandhaltung schaut auf MTBF und MTTR zugleich, denn aus beiden ergibt sich die Anlagenverfügbarkeit: MTBF geteilt durch die Summe von MTBF und MTTR. Eine Linie, die alle 200 Betriebsstunden ausfällt und dann zwei Stunden steht, kommt auf 99,0 %.
Senkt AIOps die MTTR auf eine Stunde, sind es 99,5 %. Ein halber Prozentpunkt klingt nach nichts. Bei durchgehendem Betrieb sind das gut 43 Stunden Produktionszeit im Jahr, die vorher als Stillstand verbucht wurden.
Die MTTR als DORA-Metrik der Software-Delivery ist eine andere Betrachtung. Sie steht im Glossar-Eintrag zur Mean Time to Recovery, die vollständige Erhebung aller vier Kennzahlen in DORA-Metriken richtig messen. Hier geht es um die Betriebssicht.
Was braucht AIOps,
bevor es funktioniert?
AIOps braucht eine gemeinsame Datengrundlage aus IT und OT, und die entsteht erst durch IT/OT-Konvergenz. Solange SPS-Meldungen, SCADA-Alarme und Sensorwerte in eigenen Systemen liegen, ohne gemeinsame Zeitbasis und in jedem Format anders, kann kein Modell sie mit Netzwerk- und Serverdaten in Beziehung setzen. Die International Federation of Robotics (IFR) führt IT/OT-Konvergenz unter den fünf wichtigsten Automatisierungstrends 2026.
AI- /01
Datenqualität ist der Engpass
OT-Systeme liefern Daten in vielen Formaten, vom SPS-Fehlerprotokoll über den SCADA-Alarm bis zum rohen Sensorwert. Bevor ein Modell daraus lernt, brauchen diese Daten ein einheitliches Format, einen Zeitstempel und ihren Kontext: welche Linie, welche Station, welcher Softwarestand.
- /02
Edge Computing und IIoT
Viele Modelle laufen direkt auf dem Edge-Gateway, weil die Anlage keine Latenz verträgt und auch ohne Verbindung zur Cloud weiterarbeiten muss. Die Pipeline dafür verwaltet Container, OTA-Updates und Modellversionen auf Geräten mit wenig Rechenleistung.
- /03
Sicherheitsnormen: IEC 62443 und VDMA 66412-40
Wer IT und OT verbindet, öffnet Wege zwischen zwei Netzen und muss sie absichern. IEC 62443 regelt die Security industrieller Automatisierungssysteme, VDMA 66412-40 die Schnittstellen von MES und Industrie 4.0. In der Pipeline werden daraus automatisierte Quality Gates. Wie Comquent das umsetzt, beschreibt die Seite zu DevSecOps & Compliance.
Bevor Sie KI in Ihre Pipelines holen, sollte diese Datenbrücke stehen: normalisierte Daten, Rechenleistung am Edge und eine gemeinsame Observability-Plattform für IT- und OT-Metriken. Dazu kommt ein neuer Prüfmaßstab. Seit dem 7. Juli 2026 liegt der Community Draft des BSI-Prüfkatalogs A5 für vertrauenswürdige KI-Systeme vor. KI-Agenten, die Deployments freigeben oder Compliance prüfen, werden künftig selbst gegen solche Kriterien auditiert. Was der Entwurf verlangt, steht in BSI A5 Prüfkatalog: Was der Entwurf von KI-Systemen verlangt, die Pflichten aus dem AI Act im Leitfaden zur EU-AI-Act-Umsetzung in der Industrie.
AIOps, MLOps, DevOps:
Wo liegt der Unterschied?
DevOps automatisiert Auslieferung und Betrieb von Software, AIOps wertet den laufenden Betrieb mit KI aus, und MLOps betreibt den Lebenszyklus der ML-Modelle selbst. In der Industrie greifen die drei ineinander. DevOps liefert die Pipeline, MLOps die Modelle, etwa für Predictive Maintenance, und AIOps überwacht IT und Anlage gemeinsam.
Dieser Artikel bleibt auf der AIOps-Seite des Diagramms, also bei den Kennzahlen des Betriebs. Wie die MLOps-Seite in der Industrie aussieht, welche sieben Praktiken ein Modell braucht, das neben der Anlage läuft, und warum ein Modellstand ohne Freigabekette in der Fertigung nichts verloren hat, steht in Industrial MLOps: das Fundament für KI in der Produktion.
Was sich zwischen IT-Betrieb und Anlage ändert
Dieselben Verfahren treffen in der OT auf andere Daten, andere Tests und andere Risiken. Die Tabelle stellt sechs Bereiche gegenüber.
Wo hilft KI
entlang der Pipeline?
AIOps ist die Betriebsseite. Dieselben Verfahren setzen aber schon früher an, beim Bauen, Testen und Ausliefern der Software. In diesen fünf Feldern sehen wir in Projekten den schnellsten Effekt, geordnet nach den Stufen der Pipeline vom Build bis zum Betrieb.
- /01
Self-Healing Pipelines
Diagnose und Korrektur ohne Ticket.
Bei SPS-Builds und Embedded-Kompilierungen wiederholen sich die Fehler: fehlende Abhängigkeiten, unpassende Toolchain-Versionen, Probleme in der Build-Umgebung. Ein Modell lernt aus den bisherigen Korrekturen und wendet bekannte Lösungen selbst an. Wie das in sechs Stufen abläuft, zeigt der nächste Abschnitt.
Harness AI · GitHub Actions + ML · Jenkins Plugins · ArgoCD Self-Heal
- /02
KI-optimiertes Testing
Nur die Tests, die die Änderung betrifft.
Embedded-Tests kosten Zeit und teure Prüfstände. Test Impact Analysis ermittelt, welche Tests nach einer Code-Änderung relevant sind, und lässt nur diese laufen. Der Hersteller CloudBees (früher Launchable) gibt für seine Test-Selektion bis zu 80 % kürzere Testlaufzeiten an.
Launchable · Diffblue Cover · Applitools · Test Impact Analysis
- /03
KI-gestütztes Deployment
Das Fenster mit dem geringsten Risiko.
In einer Fertigung, die rund um die Uhr läuft, entscheidet der Zeitpunkt über das Risiko. Ein Modell wertet Produktionszyklen, Schichtpläne und frühere Ausfälle aus und schlägt das Fenster vor, in dem ein Update am wenigsten stört.
Harness AI Verification · Argo Rollouts · Flagger · Custom Scoring
- /04
Log-Analyse und Anomalieerkennung
Millionen Log-Zeilen, in Echtzeit gelesen.
Steuerungen, Sensoren und Edge-Gateways schreiben mehr Log-Zeilen, als ein Mensch lesen kann. Ein Modell erkennt Abweichungen vom Normalverhalten und warnt, bevor ein Fehler die Produktion stoppt.
Elastic AI Assistant · Dynatrace Davis AI · Splunk ITSI · Custom ML
- /05
AIOps und IT/OT-Observability
Netzwerk, SPS und Sensorik in einer Sicht.
Sobald IT- und OT-Monitoring zusammenlaufen, wächst die Datenmenge über das hinaus, was ein Team von Hand abgleichen kann. AIOps korreliert Netzwerk-Anomalien mit SPS-Fehlerprotokollen und Sensorwerten zu einem gemeinsamen Lagebild.
Dynatrace Davis AI · Datadog AI · Grafana ML · PagerDuty AIOps
Wie funktioniert eine
Self-Healing Pipeline?
Eine Self-Healing Pipeline erkennt einen Fehler, analysiert die Ursache, schlägt eine Korrektur vor, wendet sie bei hoher Konfidenz selbst an, prüft das Ergebnis und lernt aus dem Ausgang. Der Ausgangspunkt ist vertraut. Montagmorgen, die Nightly-Builds vom Wochenende sind rot, und die erste Arbeitsstunde geht für die Frage drauf, welcher der dreißig Commits schuld war. Diese Stunde fehlt dem Sprint.
AI- /01
Fehler-Erkennung
Die Pipeline erkennt einen Fehler: Build schlägt fehl, Test bricht ab, Deployment scheitert.
KI-RolleKI unterscheidet zwischen echten Fehlern und transienten Problemen. Falsch-positive Rate um 60 % reduziert.
- /02
Ursachen-Analyse
Die Pipeline wertet Fehlerlogs, Stack-Traces und Umgebungsvariablen aus und grenzt die Ursache ein.
KI-RolleNLP-Modelle klassifizieren Fehlermeldungen und vergleichen sie mit einer Wissensdatenbank aus vergangenen Incidents.
- /03
Lösungsvorschlag
Aus der Ursache leitet die Pipeline Lösungsvorschläge ab und ordnet sie nach Erfolgswahrscheinlichkeit.
KI-RolleEin Empfehlungssystem schlägt Fixes vor, die bei ähnlichen Fehlern erfolgreich waren. Confidence-Score bestimmt Auto- vs. Manuell-Fix.
- /04
Automatische Korrektur
Bei hoher Konfidenz wendet die Pipeline die Korrektur selbst an: Dependency Update, Cache-Bereinigung, Toolchain-Fix oder Retry.
KI-RolleNur Korrekturen mit einem Confidence-Score über 85 % laufen automatisch. Alle anderen landen als vorbereiteter Pull Request beim Team.
- /05
Validierung
Nach der Korrektur läuft die Pipeline erneut. Alle Tests müssen grün sein, bevor der Fix als erfolgreich gilt.
KI-RolleKI überwacht, ob der Fix keine neuen Probleme verursacht hat (Regression Detection). A/B-Vergleich zwischen fehlerhaftem und korrigiertem Build.
- /06
Lern-Feedback-Loop
Jeder gelöste und jeder nicht gelöste Fehler fließt zurück in das ML-Modell. Mit jedem Vorfall erkennt die Pipeline mehr Fehlerbilder.
KI-RolleReinforcement Learning hebt die Erkennungsrate von Lauf zu Lauf. Neue Fehlermuster wandern automatisch in die Wissensdatenbank.
In Stufe 04 handelt die Pipeline zum ersten Mal selbst, statt nur vorzuschlagen. Von dort ist es ein kleiner Schritt zum KI-Agenten, und was der in einer Produktionsumgebung darf, klärt der nächste Abschnitt.
Was können KI-Agenten,
und wo ist Schluss?
KI-Agenten sind Softwarekomponenten, die innerhalb festgelegter Grenzen selbst entscheiden und handeln. Sie lesen Kontext, wählen eine Aktion und führen sie aus, ohne dass ein Mensch jeden Schritt anstößt. Das unterscheidet sie von regelbasierter Automatisierung, die nur abarbeitet, was jemand vorher festgelegt hat.
Der Markt bewegt sich schnell. GitHub hat „Agentic Workflows“ vorgestellt, und laut den Deloitte Tech Trends 2026 erproben rund 25 % der Unternehmen KI-Agenten in ihren Entwicklungsprozessen. Einen Engineer ersetzt das nicht. Die Agenten nehmen ihm die Fehlersuche im Log ab, damit er Zeit für die Entscheidung hat, die ein Urteil braucht.
- /01
Agent für SPS-Build-Fehleranalyse
Analysiert fehlgeschlagene TIA-Portal-Builds, identifiziert die Root Cause aus Fehlerlogs und historischen Patterns, erstellt automatisch einen Fix-Vorschlag als Pull Request, inklusive Begründung und Confidence-Score.
- /02
Agent für das Deployment-Fenster
Analysiert Produktionszyklen, Schichtpläne, historische Ausfallmuster und aktuelle Maschinenauslastung, um den risikoärmsten Deployment-Zeitpunkt für OT-Updates zu bestimmen.
- /03
Agent für Security-Compliance-Prüfung
Prüft Code-Änderungen automatisch gegen Normen wie IEC 62443 (Industrial Cybersecurity) und ISO/SAE 21434 (Automotive Cybersecurity) und markiert Compliance-Verstöße vor dem Merge.
Wo Schluss ist
Gartner erwartet, dass über 40 % aller Agentic-AI-Projekte bis Ende 2027 abgebrochen werden, und nennt steigende Kosten, unklaren Geschäftswert und unzureichende Risikokontrollen als Gründe. In der OT kommt ein vierter Grund dazu. Ein Agent, der sich irrt, hält im Zweifel eine Linie an.
Für sicherheitskritische Umgebungen empfehlen wir deshalb drei Regeln. Agenten arbeiten zuerst in Pipeline-Stufen, die die Produktion nicht berühren. Sie bekommen enge Guardrails und nur die Tool-Rechte, die sie für ihre Aufgabe brauchen. Und jede Deployment-Entscheidung gibt ein Mensch frei. Dass sich ein Agent irgendwann irrt, ist sicher. Es zählt, ob es jemand bemerkt, bevor die Anlage es tut.
AIWie ein Multi-Agent-Setup mit Guardrails aussieht, lässt sich an einem konkreten Szenario am besten lernen. Im ArgoCD & GitOps Workshop mit KI orchestrieren Sie Manifest-, Policy-, Test- und Doku-Agents parallel an einem Workload-Onboarding, mit klaren Tool-Erlaubnissen, Audit-Trail über Git und Human-in-the-Loop am Pull Request.
Welche AIOps-Tools
passen in die Industrie?
Sechs Werkzeuge aus sechs Kategorien, jeweils mit der Stelle, an der sie die OT berühren. Eine Marktübersicht ist das nicht. Die Tabelle ordnet jeder Kategorie das Problem zu, das sie löst.
Womit fängt
man an?
Eine fertige KI-Strategie brauchen Sie dafür nicht. In den meisten Build-Teams liest niemand die Logs systematisch, und rote Builds landen am Ende auf demselben Schreibtisch. Diese fünf Schritte setzen dort an, ohne dass Sie vorher eine Plattform bauen.
- /01
GitHub Copilot für Pipeline-Code einsetzen
Aufwand: NiedrigNutzen Sie GitHub Copilot in der IDE für Jenkinsfiles, GitLab-CI-Konfigurationen und Terraform-Module. Bei wiederkehrenden Pipeline-Mustern sparen Sie vom ersten Tag an Zeit.
- /02
Log-Anomalieerkennung mit Elastic aktivieren
Aufwand: NiedrigSchalten Sie die ML-basierte Anomalieerkennung in Elasticsearch für Build-Logs und OT-Protokolle ein. Elastic meldet ungewöhnliche Log-Muster, bevor daraus ein Ausfall wird. Voraussetzung ist eine Platinum-Subskription.
- /03
Test Impact Analysis einführen
Aufwand: MittelBinden Sie Launchable (heute Teil von CloudBees) oder ein vergleichbares Werkzeug zur Test-Selektion in die Pipeline ein. Starten Sie mit einem Pilotprojekt und messen Sie vier Wochen lang, wie stark die Testlaufzeit sinkt.
- /04
KI-basierte Code Reviews starten
Aufwand: NiedrigSetzen Sie ein Review-Werkzeug wie CodeRabbit oder Sourcery als zusätzliche Instanz in Pull Requests ein. Es markiert Security-Probleme, Performance-Fallen und Code-Smells, bevor ein Kollege den Diff öffnet.
- /05
Deployment-Risiko bewerten
Aufwand: MittelBauen Sie ein einfaches Scoring, das vor jedem Deployment vier Faktoren bewertet: Zahl der geänderten Dateien, betroffene Komponenten, Tageszeit und letzte Fehlerrate. Starten Sie regelbasiert und ergänzen Sie ML, sobald genug Historie vorliegt.
Rechnet
sich das?
Der Einstieg kostet wenig, und größere Investitionen wie eigene ML-Modelle oder eine AIOps-Plattform rechnen sich typischerweise innerhalb von 6 bis 12 Monaten. GitHub Copilot Business kostet 19 USD pro Nutzer und Monat. Die Anomalieerkennung von Elastic gehört zur Platinum-Subskription. Wer sie schon hat, zahlt dafür nichts zusätzlich.
Auf der Nutzenseite stehen drei Herstellerangaben und Analystenwerte: bis zu 50 % kürzere MTTR (Gartner Market Guide for AIOps 2025), bis zu 80 % kürzere Testlaufzeit (Launchable 2025) und bis zu 90 % weniger Ausfälle durch Deployments (Harness 2025). Was eine halbierte MTTR an Ihrer Anlage wert ist, lässt sich mit der Verfügbarkeitsrechnung aus Abschnitt 04 überschlagen. Die eigene Zahl liefert der ROI-Rechner.
Der erste Ertrag ist meist unspektakulär. Oft markiert das Modell als Erstes einen flaky Test, den das Team seit Monaten stillschweigend neu startet.
Was leistet eine
AIOps-Beratung?
Eine AIOps-Beratung bewertet zuerst die Datengrundlage, wählt dann die Plattform aus, bindet die OT-Quellen an und übergibt am Ende den laufenden Betrieb der Modelle. Der Aufwand steckt dabei selten im Algorithmus. Er steckt in der Naht zwischen IT und OT, denn SPS-Statusmeldungen, SCADA-Alarme und Sensorwerte erreichen die Plattform in vielen Projekten ohne gemeinsame Zeitbasis oder gar nicht. An dieser Stelle scheitern AIOps-Einführungen, nicht am Modell.
- /01
Wie eine AIOps-Einführung abläuft
Am Anfang steht eine Bestandsaufnahme. Welche Quellen gibt es, welche liefern Zeitstempel, welche Alarme kommen heute bei wem an? Danach folgt ein Pilot an einer Linie oder einem Dienst, meist mit der Rauschunterdrückung, weil die Rufbereitschaft ihren Effekt als Erste bemerkt. Erst wenn die Korrelation dort trägt, kommen Ursachenanalyse und automatisierte Behebung dazu.
- /02
Woran Sie einen passenden AIOps-Dienstleister erkennen
Ein Dienstleistungsunternehmen für AIOps muss beide Seiten beherrschen, die IT mit Monitoring, CI/CD und Datenpipelines und die OT mit SPS, SCADA und Edge-Gateways. Fragen Sie nach der Anbindung der OT-Quellen, nach dem Umgang mit fehlenden Zeitstempeln und danach, wer die Modelle nach dem Projekt betreibt. Comquent begleitet diesen Weg als Dienstleister für AIOps- und Monitoring-Automatisierung und ordnet ihn in die Industrial-DevOps-Beratung ein, von der Bewertung der Datengrundlage bis zum Betrieb.
- /03
Wer Comquent ist
Die Comquent GmbH mit Sitz in Puchheim bei München berät seit 2006 Industrieunternehmen in DevOps, CI/CD-Automatisierung und Industrial DevOps. Die Comquent Academy ergänzt das um Trainings zu Self-Healing Pipelines, Jenkins-Automatisierung und KI-gestützten DevOps-Abläufen.
Wie solche Einführungen ausgehen, zeigen die vier AIOps-Erfolgsgeschichten weiter oben. Wo Ihr eigenes Team steht, ordnet der Reifegrad-Check in 3 Minuten ein. Danach klärt ein fachliches Erstgespräch, an welcher Linie ein Pilot Sinn ergibt.
30 Minuten · unverbindlich · kein Vertriebsgespräch
Was Kunden
wirklich fragen.
- Q.01
- Wofür steht AIOps?
- AIOps steht für „Artificial Intelligence for IT Operations“, also Künstliche Intelligenz für den IT-Betrieb. Gartner hat den Begriff 2016 geprägt. Er bezeichnet Plattformen, die mit Machine Learning und Big-Data-Analysen Monitoring-Daten korrelieren, Alarmrauschen filtern und Störungen automatisiert beheben.
- Q.02
- Was sind Beispiele für AIOps?
- Typische AIOps-Beispiele sind die Korrelation von IT- und OT-Alarmen zu einem einzigen Vorfall, die Vorhersage von Maschinenausfällen aus Sensordaten (Predictive Maintenance) und die automatische Ursachenanalyse fehlgeschlagener Builds. In einem Fertigungsprojekt sank die mittlere Erkennungszeit (MTTD) von 47 auf 3 Minuten, weil niemand mehr SPS-Statusmeldungen, SCADA-Alarme und Netzwerk-Metriken von Hand abgleichen musste. Im Maschinenbau behebt eine Self-Healing Pipeline 70 % der bekannten Build-Fehler selbst, etwa fehlende Bibliotheken, eine falsche Toolchain-Version oder einen verschmutzten Build-Cache.
- Q.03
- Wie hilft AIOps in der Industrie?
- In der Industrie wertet AIOps IT-Metriken und OT-Daten gemeinsam aus und erkennt dadurch, ob ein SPS-Fehler aus dem Netzwerk, aus einem Deployment oder aus der Steuerung selbst kommt. Ohne diese Korrelation sucht die Rufbereitschaft in zwei getrennten Monitoringwelten. Voraussetzung ist eine gemeinsame Datengrundlage mit einheitlichen Zeitstempeln, die erst durch IT/OT-Konvergenz entsteht.
- Q.04
- Ist AIOps noch relevant?
- Ja. AIOps entwickelt sich gerade vom Dashboard-Werkzeug zur agentischen Disziplin, in der Agenten Störungen zunehmend selbst beheben, statt nur Alarme zu korrelieren. Der Markt wächst von 24,24 Mrd. USD (2025) auf prognostizierte 259 Mrd. USD bis 2035 (Global Growth Insights). In industriellen Umgebungen wird AIOps durch die IT/OT-Konvergenz wichtiger, weil kein Team Millionen von IT- und OT-Events von Hand korrelieren kann.
- Q.05
- Was ist KI-gestütztes DevOps?
- KI-gestütztes DevOps bezeichnet den Einsatz von Machine Learning, AIOps und KI-Agenten in DevOps-Prozessen, von der automatischen Log-Analyse über die Test-Selektion bis zur Bewertung von Deployments. In der Industrie verbindet es IT-Systeme mit OT-Umgebungen wie SPS-Steuerungen, SCADA-Systemen und Edge-Gateways.
- Q.06
- Was ist MTBF und MTTR?
- MTBF (Mean Time Between Failures) misst die mittlere Betriebszeit zwischen zwei Ausfällen, MTTR (Mean Time to Repair oder Recovery) die mittlere Dauer bis zur Wiederherstellung. MTBF beantwortet, wie zuverlässig ein System läuft, MTTR, wie schnell man es zurückholt. Zusammen ergeben sie die Verfügbarkeit, nämlich MTBF geteilt durch die Summe aus MTBF und MTTR. Eine Anlage mit 200 Stunden MTBF und 2 Stunden MTTR erreicht damit 99,0 %.
- Q.07
- Wie lautet die Formel für MTTR und MTBF?
- Die MTTR ist die gesamte Ausfallzeit geteilt durch die Anzahl der Vorfälle im Betrachtungszeitraum. Die MTBF ist die gesamte Betriebszeit geteilt durch die Anzahl der Ausfälle. Fällt eine Anlage im Monat fünfmal aus und summiert sich die Reparaturzeit auf zehn Stunden, liegt die MTTR bei zwei Stunden. Beide Seiten müssen dieselbe Startzeit verwenden. In der Instandhaltung beginnt die Messung meist, wenn der Techniker an der Maschine steht, in der IT schon mit der ersten Alarmmeldung.
- Q.08
- Was bedeutet MTTF?
- MTTF (Mean Time To Failure) ist die mittlere Lebensdauer bis zum Ausfall bei Bauteilen, die nicht repariert, sondern getauscht werden, etwa Lager, Sensoren oder Speichermedien. Der Unterschied zur MTBF liegt genau darin: Die MTBF gilt für reparierbare Systeme, die MTTF für Teile, die nach dem Ausfall ersetzt werden. Wer beide Kennzahlen in einem Dashboard mischt, vergleicht Lebensdauern mit Ausfallabständen.
- Q.09
- Was ist der Unterschied zwischen MTTD, MTTA und MTTR?
- Die drei Kennzahlen messen aufeinanderfolgende Abschnitte desselben Vorfalls: MTTD die Zeit bis zur Erkennung, MTTA die Zeit, bis ein Mensch den Alarm übernimmt, MTTR die Zeit bis zum wiederhergestellten Normalbetrieb. AIOps setzt zuerst an der MTTD an, denn eine Störung, die niemand bemerkt, behebt auch niemand. In einem Fertigungsprojekt sank die MTTD von 47 auf 3 Minuten, nachdem SPS-Statusmeldungen, SCADA-Alarme und Netzwerk-Metriken nicht mehr von Hand abgeglichen werden mussten.
- Q.10
- Was ist Alert Fatigue und was hilft dagegen?
- Alert Fatigue (Alarmmüdigkeit) beschreibt den Zustand, in dem ein Team so viele Alarme bekommt, dass es sie nicht mehr ernst nimmt. Messbar wird sie an einer steigenden MTTA. Dagegen hilft Rauschunterdrückung, also die Gruppierung zusammengehöriger Alarme zu einem Vorfall mit Ursachenvermutung. Wer nachts 200 Einzelmeldungen aus IT- und OT-Monitoring bekommt, quittiert irgendwann pauschal, und dann geht die eine Meldung unter, auf die es ankam.
- Q.11
- Was ist Predictive Maintenance und wie hängt sie mit DevOps zusammen?
- Predictive Maintenance (vorausschauende Wartung) sagt mit Machine-Learning-Modellen aus Sensor- und Maschinendaten Ausfälle vorher, bevor sie eintreten. Im Industrial DevOps trainiert, prüft und verteilt eine CI/CD-Pipeline diese Modelle bis auf die Edge-Geräte an der Anlage. Der Nutzen zeigt sich an weniger ungeplanten Stillständen und einer höheren MTBF.
- Q.12
- Kann KI manuelle Tests in der SPS-Entwicklung ersetzen?
- Nein, KI ersetzt manuelle Tests nicht vollständig, sie verkürzt aber den Testlauf. Test Impact Analysis ermittelt die relevanten Tests pro Code-Änderung und spart so Laufzeit, nach Angabe des Herstellers CloudBees (früher Launchable) bis zu 80 %. Sicherheitskritische Tests nach ISO 26262 und IEC 62443 laufen weiterhin vollständig.
- Q.13
- Was kostet die Einführung von KI in DevOps-Prozesse?
- Der Einstieg kostet wenig. GitHub Copilot Business liegt bei 19 USD pro Nutzer und Monat, und die Anomalieerkennung von Elastic gehört zur Platinum-Subskription und kostet dort nichts zusätzlich. Größere Investitionen wie eigene ML-Modelle oder eine AIOps-Plattform rechnen sich typischerweise innerhalb von 6 bis 12 Monaten. Als Richtwerte für den Nutzen gelten bis zu 50 % kürzere MTTR (Gartner), bis zu 80 % kürzere Testlaufzeit (Launchable) und bis zu 90 % weniger Ausfälle durch Deployments (Harness).
- Q.14
- Wer unterstützt bei der Einführung von AIOps?
- Die Einführung begleiten spezialisierte DevOps-Dienstleister, die beide Seiten kennen: die IT mit Monitoring, CI/CD und Datenpipelines und die OT mit SPS, SCADA und Edge-Gateways. An dieser Naht scheitern die meisten AIOps-Projekte, weil die OT-Daten entweder gar nicht oder ohne Zeitbezug ankommen. Comquent übernimmt die Bewertung der Datengrundlage, die Auswahl der Plattform, die Anbindung der OT-Quellen und den Betrieb der Modelle. Der Einstieg ist ein fachliches Erstgespräch von 30 Minuten.
Wie geht es bei Ihnen mit KI im Industrial DevOps weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
Industrial MLOps: das Fundament für KI in der Produktion
Wo KI in Produktion und Fertigung heute wirkt, warum die Automatisierung vor der KI kommt und welche sieben MLOps-Praktiken ein Modell neben der Anlage braucht.
DORA-Metriken: DevOps-Performance messen und verbessern
Deployment Frequency, Lead Time, Change Failure Rate und MTTR verstehen, messen und verbessern.
Corporate LLMs in Industrial DevOps
Lokales LLM mit RAG im eigenen Netz: Vorteile, Herausforderungen und vier Anwendungsbeispiele von der Jenkins-Log-Triage bis zur Wissensbasis.
Jenkins mit KI steuern: MCP, Vibe Coding & Log-Analyse
Jenkins per Model Context Protocol steuern, Pipelines vibecoden und Build-Logs KI-gestützt analysieren.
Erstgespräch.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance