Sie haben die Plattform gelöst.
Sie haben die Infra abstrahiert.
Ingenieure können sie immer noch nicht debuggen.
Wie OpsWorker begann
Bevor eine Zeile Code geschrieben wurde, verbrachte Ar Kobian Monate damit, die Idee zu validieren. Er führte Interviews mit Ingenieuren und Tech-Leadern in über 20 Unternehmen – von großen Enterprises bis hin zu schnell wachsenden Produkt-Startups – auf allen Ebenen: Individual Contributors, Plattform-Leads, VPs und CTOs.
Das Muster war konsistent. Die Untersuchungslast war real, weit verbreitet und kostspielig, aber bei komplexen Incidents. Und es ging nicht nur um Incidents. Es ging um die tägliche Reibung beim Betrieb komplexer Systeme – verstehen, was sich geändert hat, warum sich ein Workload anders verhält, welche Abhängigkeit Risiken einführt, warum ein Alert erneut feuert, nachdem er letzte Woche angeblich gelöst wurde.
Während dieses Prozesses besprach Ar Kobian das Problem auch mit Nune Isabekyan, Gründerin der Powerdata GmbH und Cloud-Architektur-Expertin mit tiefem, praxisnahem Erfahrungsschatz in genau den Systemen, über die OpsWorker nachdenken musste. Ein paar Sitzungen fokussierten Brainstormings machten die Richtung klar. Nune trat als Co-Gründerin und CTO bei, und OpsWorker wurde geboren.
Das Problem, das wir nicht ignorieren konnten
Das ist kein Versagen des Einsatzes. Plattform-Teams haben jahrelang alles richtig gemacht – standardisieren, abstrahieren, interne Entwicklerplattformen aufbauen, Runbooks schreiben, Observability-Standards durchsetzen. Und dennoch schließt es die Lücke nicht.
Wenn etwas in einer komplexen cloud-nativen Umgebung bricht, oder wenn ein Entwickler verstehen muss, warum sich sein Workload in der Produktion anders verhält, ist das für die Untersuchung erforderliche Wissen tief, kontextuell und schwer zu übertragen. Sie können sich nicht durch Dokumentation herausarbeiten. Sie können sich auch nicht durch Plattform-Engineering herausarbeiten.
Nach einem Jahrzehnt im Aufbau und Betrieb von Multi-Cloud-, Multi-Cluster-Kubernetes-Umgebungen im großen Maßstab – Plattformen mit Zehntausenden von Microservices – hatte Ar Kobian die meisten Ansätze versucht. Als Plattform-Owner und Engineering-Lead bestand seine Arbeit nicht nur im Aufbau der Infrastruktur, sondern darin sicherzustellen, dass Software-Entwicklungsteams sie tatsächlich nutzen konnten: verstehen, debuggen, provisionieren, ohne selbst zu Infrastrukturexperten zu werden.
Die Mauer war nicht die Komplexität. Das ist zu erwarten. Die Mauer war alles, was passiert, wenn etwas in dieser Komplexität schiefgeht – oder wenn ein Ingenieur sie verstehen, erklären oder unter Druck darauf reagieren muss.
Das Problem nach links oder rechts zu verschieben, lässt es nicht verschwinden. Software-Ingenieure im großen Maßstab infrastrukturkompetent zu machen, dauert Jahre und bleibt selten haften. Jede Plattformevolution öffnet die Wissenslücke neu. Und jeder Incident, jeder langsame Workload, jede unerklärliche Degradation endet immer noch gleich: den richtigen Ingenieur finden und ihn es manuell herausfinden lassen.
Als die LLM-Ära begann, sahen wir etwas anderes. Keine weitere Abstraktionsebene. Kein weiteres Runbook oder Self-Service-Portal. Die Möglichkeit einer AI-Schicht, die untersucht, erklärt und führt – Ingenieuren dort begegnet, wo sie sind, in dem Moment, in dem das System bricht, mit der spezifischen Antwort, die sie gerade jetzt brauchen.
Das war die Veränderung, die es wert war, aufgebaut zu werden.
Das Team
Ein Jahrzehnt im Aufbau und Betrieb von Multi-Cloud-, Multi-Cluster-Kubernetes-Umgebungen im großen Maßstab. Ehemaliger Plattform-Owner und Engineering-Lead, der Infrastruktur für Zehntausende von Microservices betrieben hat. Hat OpsWorker entwickelt, um das Problem zu lösen, das er täglich erlebt hat: die Wissenslücke zwischen Plattformkomplexität und Engineering-Realität schließen.
Was wir gebaut haben
OpsWorker ist eine AI-SRE-Produktionsintelligenz-Plattform für Engineering-Teams, die Kubernetes in der Produktion betreiben.
Wenn ein Alert feuert – von Prometheus, Datadog, CloudWatch oder einem beliebigen Webhook-kompatiblen Monitoring-Tool – beginnt OpsWorker sofort mit der Untersuchung, ohne auf einen Ingenieur zu warten, der ein Terminal öffnet. Es untersucht Pods, Services, Deployments, Logs, Events, Konfigurationen und Ressourcenbeziehungen parallel. Es bewertet mehrere Hypothesen. Es korreliert, was in der Infrastruktur passiert ist, mit dem, was sich in letzten Deployments geändert hat.
Dann liefert es eine Grundursachen-Analyse mit spezifischen Behebungsschritten – inklusive kopierfertige kubectl-Befehle – in Slack in unter zwei Minuten.
Keine neuen Agenten am ersten Tag zu deployen. Keine neuen Dashboards zu erlernen. Die Untersuchung kommt dort an, wo Ihr Team bereits arbeitet.
Über Incidents hinaus baut OpsWorker ein lebendes Gedächtnis Ihrer Produktionssysteme auf – sodass jede Untersuchung die nächste beschleunigt und institutionelles Wissen aufhört, das Unternehmen zu verlassen, wenn Ingenieure das Team oder Unternehmen wechseln.
Alert empfangen bis Grundursachen-Analyse in Slack geliefert
Der Untersuchungszeit im Vergleich zu manuellen Workflows
Kein menschlicher Auslöser erforderlich
Warum wir so arbeiten
Wir bauen keine weitere Observability-Plattform. Wir ersetzen nicht Ihren bestehenden Monitoring-Stack. Wir füllen die Lücke, die jedes Tool in diesem Bereich offen gelassen hat: die Untersuchung selbst.
Wir wissen, was es kostet, komplexe Systeme im großen Maßstab zu betreiben – die Alert-Fatigue, die Debugging-Sitzungen, die länger dauern als die Fixes, das Stammwissen, das in den Köpfen von zwei Senior-Ingenieuren lebt und sonst nirgendwo. Diese Erfahrung prägt alles, was wir bauen.
Wir sind ehrlich darüber, was OpsWorker tut und nicht tut. Es untersucht und empfiehlt. Es führt Behebungen ohne Ingenieur-Genehmigung nicht aus – diese Grenze ist absichtlich. Vertrauen wird durch Transparenz aufgebaut, nicht durch Behauptungen, die besser klingen als sie sind.
Was als Nächstes kommt
Aufbau eines Wissensgraphen, der Incidents, Deployments, Konfigurationsänderungen und Untersuchungsergebnisse über die Zeit verbindet. OpsWorker wird nicht nur den heutigen Alert lösen – es wird Muster erkennen, Risiken vorhersagen und Kontext über Wochen und Monate hinweg behalten.
Erweiterung über Grundursachen-Analyse hinaus zu geführten Behebungs-Workflows. Ingenieure genehmigen empfohlene Fixes, und OpsWorker führt sie sicher aus – mit Rollback-Plänen, Validierungsprüfungen und vollständigen Audit-Trails.
Verschiebung nach links von der Incident Response zur Risikoerkennung. OpsWorker wird Konfigurationsdrift, Ressourcenengpässe, Deployment-Anomalien und Abhängigkeitsschwachstellen identifizieren, bevor sie Alerts auslösen – und Teams Zeit geben zu handeln, bevor Systeme brechen.
Vision
Das Ziel ist nicht, Ingenieure zu ersetzen. Es geht darum, ihnen Hebel zu geben.
Wir glauben, dass die Zukunft des Plattform-Engineerings nicht darin besteht, mehr Tools hinzuzufügen oder größere Abstraktionen zu schaffen. Es geht darum, die kognitive Last auf den Betreibern dieser Plattformen zu reduzieren – sie in dem Moment zu treffen, in dem sie Hilfe brauchen, mit dem genauen Kontext und der Antwort, die zum sicheren Handeln erforderlich sind.
OpsWorker existiert, um die Lücke zwischen Plattformkomplexität und menschlichem Verständnis zu schließen. Wochenlange Lernkurven in minutenschnelle Klarheit umzuwandeln. Institutionelles Wissen dauerhaft und zugänglich zu machen. Ingenieuren zu ermöglichen, sich auf Bauen statt auf Feuerlöschen zu konzentrieren.
Das ist die Zukunft, auf die wir hinarbeiten.
Jetzt früh einsteigen
OpsWorker befindet sich in aktiver Entwicklung und arbeitet mit zukunftsorientierten Unternehmen und Teams, die Kubernetes und Microservices in der Produktion betreiben.
Wenn Sie Feuerlöschen reduzieren, die Grundursachen-Analyse beschleunigen und Ihrem Team einen intelligenteren Weg zum Betrieb komplexer cloud-nativer Systeme geben möchten – wir würden gerne sprechen.