Vous avez résolu la plateforme.
Vous avez abstrait l'infra.
Les ingénieurs ne peuvent toujours pas la déboguer.
Comment OpsWorker a commencé
Avant d'écrire une ligne de code, Ar Kobian a passé des mois à valider l'idée. Il a interviewé des ingénieurs et des leaders techniques dans plus de 20 entreprises — de grandes entreprises aux startups produit en croissance rapide — à tous les niveaux : contributeurs individuels, responsables de plateforme, VP et CTO.
Le pattern était cohérent. Le fardeau de l'investigation était réel, répandu et coûteux, mais pour les incidents complexes. Et ce n'était pas seulement une question d'incidents. C'était à propos de la friction quotidienne de l'exploitation de systèmes complexes — comprendre ce qui a changé, pourquoi un workload se comporte différemment, quelle dépendance introduit un risque, pourquoi une alerte se déclenche à nouveau après avoir été supposément résolue la semaine dernière.
Au cours de ce processus, Ar Kobian a également discuté du problème avec Nune Isabekyan, fondatrice de Powerdata GmbH et experte en architecture cloud avec une expérience pratique approfondie dans les systèmes mêmes sur lesquels OpsWorker devait raisonner. Quelques sessions de brainstorming ciblé ont clarifié la direction. Nune a rejoint l'aventure en tant que cofondatrice et CTO, et OpsWorker est né.
Le problème que nous ne pouvions ignorer
Ce n'est pas un manque d'effort. Les équipes de plateforme ont passé des années à tout faire correctement — standardiser, abstraire, construire des plateformes développeurs internes, rédiger des runbooks, appliquer les standards d'observabilité. Et ça ne comble toujours pas l'écart.
Quand quelque chose se casse dans un environnement cloud-native complexe, ou quand un développeur a besoin de comprendre pourquoi son workload se comporte différemment en production, la connaissance nécessaire pour investiguer est profonde, contextuelle et difficile à transférer. On ne peut pas s'en sortir par la documentation. On ne peut pas s'en sortir par l'ingénierie de plateforme non plus.
Après une décennie à construire et exploiter des environnements Kubernetes multi-cloud et multi-cluster à grande échelle — des plateformes avec des dizaines de milliers de microservices — Ar Kobian avait essayé la plupart des approches. En tant que propriétaire de plateforme et responsable d'ingénierie, son travail n'était pas seulement de construire l'infrastructure mais de s'assurer que les équipes de développement logiciel pouvaient réellement l'utiliser : la comprendre, la déboguer, provisionner contre elle sans devenir des experts en infrastructure.
Le mur n'était pas la complexité. C'est attendu. Le mur était tout ce qui se passe quand quelque chose se casse dans cette complexité — ou quand un ingénieur a besoin de la comprendre, ou de l'expliquer, ou d'agir dessus sous pression.
Déplacer le problème vers la gauche ou vers la droite ne le fait pas disparaître. Rendre les ingénieurs logiciels alphabétisés en infrastructure à grande échelle prend des années et fonctionne rarement durablement. Chaque évolution de plateforme rouvre l'écart de connaissance. Et chaque incident, chaque workload lent, chaque dégradation inexpliquée se termine toujours de la même façon : trouver le bon ingénieur et lui demander de comprendre manuellement.
Quand l'ère des LLMs a commencé, nous avons vu quelque chose de différent. Pas une autre couche d'abstraction. Pas un autre runbook ou portail libre-service. La possibilité d'une couche AI qui pourrait investiguer, expliquer et guider — rejoignant les ingénieurs là où ils sont, au moment où le système se casse, avec la réponse spécifique dont ils ont besoin maintenant.
C'était le changement qui valait la peine d'être construit.
L'équipe
Une décennie à construire et exploiter des environnements Kubernetes multi-cloud et multi-cluster à grande échelle. Ancien propriétaire de plateforme et responsable d'ingénierie gérant l'infrastructure pour des dizaines de milliers de microservices. A construit OpsWorker pour résoudre le problème qu'il vivait au quotidien : combler l'écart de connaissance entre la complexité de la plateforme et la réalité de l'ingénierie.
Fondatrice de Powerdata GmbH avec une expérience pratique approfondie dans les architectures cloud-natives et les systèmes exacts sur lesquels OpsWorker doit raisonner. Apporte des années d'expertise dans la construction et le scaling d'infrastructures distribuées complexes.
Ce que nous avons construit
OpsWorker est une plateforme d'intelligence de production AI SRE pour les équipes d'ingénierie exploitant Kubernetes en production.
Lorsqu'une alerte se déclenche — depuis Prometheus, Datadog, CloudWatch ou tout outil de monitoring compatible webhook — OpsWorker commence à investiguer immédiatement, sans attendre qu'un ingénieur ouvre un terminal. Il examine les pods, services, déploiements, logs, événements, configurations et relations de ressources en parallèle. Il évalue plusieurs hypothèses. Il corrèle ce qui s'est passé dans l'infrastructure avec ce qui a changé dans les déploiements récents.
Puis il livre une analyse de cause racine avec des étapes de remédiation spécifiques — incluant des commandes kubectl prêtes à coller — dans Slack en moins de deux minutes.
Aucun nouvel agent à déployer dès le premier jour. Aucun nouveau dashboard à apprendre. L'investigation arrive là où votre équipe travaille déjà.
Au-delà des incidents, OpsWorker construit une mémoire vivante de vos systèmes de production — pour que chaque investigation accélère la suivante, et que la connaissance institutionnelle cesse de partir quand les ingénieurs changent d'équipe ou d'entreprise.
De la réception de l'alerte à la livraison de l'analyse de cause racine dans Slack
Du temps d'investigation comparé aux workflows manuels
Aucun déclenchement humain requis
Pourquoi nous travaillons ainsi
Nous ne construisons pas une autre plateforme d'observabilité. Nous ne remplaçons pas votre stack de monitoring existant. Nous comblons l'écart que chaque outil dans cet espace a laissé ouvert : l'investigation elle-même.
Nous savons ce que coûte l'exploitation de systèmes complexes à grande échelle — la fatigue des alertes, les sessions de débogage qui durent plus longtemps que les correctifs, la connaissance tribale qui vit dans la tête de deux ingénieurs seniors et nulle part ailleurs. Cette expérience façonne tout ce que nous construisons.
Nous sommes honnêtes sur ce qu'OpsWorker fait et ne fait pas. Il investigue et recommande. Il n'exécute pas de remédiations sans approbation de l'ingénieur — cette limite est intentionnelle. La confiance se construit par la transparence, pas par des affirmations qui semblent meilleures qu'elles ne le sont.
Ce qui vient ensuite
Construction d'un graphe de connaissance qui connecte incidents, déploiements, changements de configuration et résultats d'investigation dans le temps. OpsWorker ne résoudra pas seulement l'alerte d'aujourd'hui — il reconnaîtra les patterns, prévoira les risques et retiendra le contexte sur des semaines et des mois.
Expansion au-delà de l'analyse de cause racine vers des workflows de remédiation guidée. Les ingénieurs approuveront les correctifs recommandés, et OpsWorker les exécutera en toute sécurité — avec des plans de rollback, des vérifications de validation et des pistes d'audit complètes.
Déplacement de la réponse aux incidents vers la détection des risques. OpsWorker identifiera la dérive de configuration, la contention de ressources, les anomalies de déploiement et les vulnérabilités de dépendances avant qu'elles ne déclenchent des alertes — donnant aux équipes le temps d'agir avant que les systèmes ne tombent en panne.
Vision
L'objectif n'est pas de remplacer les ingénieurs. C'est de leur donner du levier.
Nous croyons que l'avenir de l'ingénierie de plateforme ne consiste pas à ajouter plus d'outils ou à construire de plus grandes abstractions. Il s'agit de réduire la charge cognitive des personnes qui exploitent ces plateformes — les rejoindre au moment où elles ont besoin d'aide, avec le contexte exact et la réponse nécessaires pour agir avec confiance.
OpsWorker existe pour combler l'écart entre la complexité de la plateforme et la compréhension humaine. Pour transformer des semaines d'apprentissage en minutes de clarté. Pour rendre la connaissance institutionnelle durable et accessible. Pour laisser les ingénieurs se concentrer sur la construction plutôt que le firefighting.
C'est l'avenir vers lequel nous construisons.
Rejoignez-nous tôt
OpsWorker est en développement actif, travaillant avec des entreprises et équipes de pointe qui exploitent Kubernetes et des microservices en production.
Si vous souhaitez réduire le firefighting, accélérer l'analyse de cause racine et donner à votre équipe un moyen plus intelligent d'exploiter des systèmes cloud-natifs complexes — nous aimerions vous parler.