DevOps funktioniert immer noch nicht

Warum Ego, Verantwortung und Realität den Traum von „gemeinsamer Ownership" immer noch scheitern lassen.

Vor über einem Jahrzehnt wurde DevOps als Befreiung gefeiert. Ein Kulturwandel, der die alten Mauern zwischen Entwicklung und Betrieb einreißen sollte. Ein gemeinsames Verständnis: Entwickler und Operations arbeiten in einem Team, teilen Verantwortung, Tools, Prozesse und Ziele. Heute, mehr als zehn Jahre später, ist das Versprechen in vielen Organisationen gebrochen. Die Trennung besteht weiterhin – nur subtiler. Und in vielen Fällen ist die Kluft sogar größer als zuvor.

Die Theorie war schön

In der Theorie klang es so einfach: Crossfunktionale Teams, gemeinsame Ownership, Continuous Delivery, Shared On-Call, Infrastructure as Code. „You build it, you run it." Ein Satz, der mehr als nur Verantwortung ausdrücken sollte – er stand für Haltung. Doch was in der Praxis passiert, ist oft das Gegenteil. Entwickler entwickeln. Operations betreibt. Und sobald etwas in Produktion steht, kehrt die alte Realität zurück:

“Worked fine in dev. Ops problem now.”

Ein Satz, der sich als Running Gag in die IT-Kultur eingebrannt hat – aber einer, der ernster ist, als er klingt.

Der Alltag im Betrieb

Wer im Betrieb arbeitet, kennt das Muster:

Ein neuer Release, alles läuft gut – bis nicht es nicht mehr gut läuft. Die Anwendung hängt, die Datenbank überlastet, CPU-Spitzen, Speicherauslastung, Timeouts, Anomalien. Und dann? Das Ops-Team triagiert, beobachtet, sammelt Metriken, loggt, isoliert, analysiert.

Die Ursache? Oft nicht das Netzwerk, nicht die Hardware, nicht die Plattform – sondern die Anwendung selbst.

Software-induzierte Probleme sind die Hauptursache für Instabilität in modernen SaaS- und Cloud-Systemen.

Und trotzdem: Wenn der Pager klingelt, geht der erste Blick immer zur Infrastruktur.

Wo DevOps wirklich scheitert: Kultur vs. Realität

Das Grundproblem liegt selten in Tools oder Prozessen, sondern im Verhalten. DevOps ist kein Toolset, sondern ein Mindset, das aber häufig nie wirklich angekommen ist.

Entwicklerteams agieren weiterhin weitgehend isoliert. Operations wird als Service-Funktion verstanden, nicht als gleichberechtigter Partner. Und Verantwortung wird – trotz schöner PowerPoint-Folien – immer noch verteilt, nicht geteilt. Man kann es pointiert sagen: DevOps ist vielerorts nur ein Rebranding von “Wir deployen jetzt öfter.”

Technische Symptome einer kulturellen Schieflage

Diese kulturelle Trennung zeigt sich in konkreten technischen Mustern, die in nahezu jedem Betrieb sichtbar sind:

1. Ineffizientes Datenbank-Handling

Unkoordinierte Abfragen, N+1 Queries, ineffiziente Joins oder ungetestete Migrationsskripte, die produktive Systeme zum Stillstand bringen.

Warum? Weil Datenbankverhalten in der Entwicklung oft nicht realistisch simuliert wird – lokale SQLite oder Test-Datenbanken verhalten sich einfach nicht wie produktive PostgreSQL-Cluster mit 10.000 gleichzeitigen Verbindungen. Oder man hofft einfach das Framework, bzw. das ORM wird schon alles auf Performance optimieren.

2. Memory Leaks und Ressourcenverbrauch

In vielen Teams wird Speicherverbrauch nicht gemessen, nur Funktion getestet. Ein lokaler Debugger zeigt keine Heap-Fragmentierung, keine OOM-Killer, keine kumulative Speicherakkumulation über Stunden. Das Resultat: Anwendungen, die auf Testsystemen solide laufen, brechen im Dauerbetrieb ein.

3. Fehlendes Verständnis verteilter Systeme

„Lokal funktioniert’s doch" – aber in der Realität laufen Services verteilt über Regionen, Latenzen, Netzwerke, Queues. Asynchrone Kommunikation, Event Ordering, idempotente Operationen – für viele Entwickler nach wie vor Neuland. Aber genau das ist die Betriebsrealität.

4. Ignorierte Observability

„Ich brauche kein Monitoring, ich habe einen Debugger." Ein Satz, der im produktiven Umfeld nur Kopfschütteln auslöst. Doch genau diese Haltung verhindert, dass Entwickler ihre Systeme verstehen, wenn sie nicht direkt vor ihnen laufen.

5. Fehlendes Wissen über die Internals der eigenen Software

In vielen Organisationen fehlt tiefes Verständnis dafür, was unter der Oberfläche passiert – Garbage Collection, Thread Scheduling, Connection Pools, File Descriptors, IO Blocking. All das entscheidet über Stabilität – und all das ist in der Entwicklungsrealität oft ausgeblendet. Das Ergebnis: Software, die in Dev funktioniert, aber in Produktion aus dem Tritt gerät.

Das Blame Game lebt

Wenn ein System ausfällt, beginnt meist dasselbe Ritual: Ein Ticket, ein Chat-Channel, eine lange Nacht.

Ops analysiert Logs, checkt Ressourcen, testet Infrastruktur. Irgendwann zeigt sich: Ursache war ein Code-Change. Aber statt Ursachenanalyse folgt das alte Reflexverhalten – Schuldzuweisung. Das Resultat:

Weniger Vertrauen, weniger Zusammenarbeit, weniger Kommunikation.

Das Ironische daran: DevOps wollte genau das Gegenteil.

Warum das so bleibt

Man kann viele Ursachen nennen:

• Strukturelle Trennung in Organisationen.
• Unterschiedliche Zielsysteme (Velocity vs. Stability).
• Fehlende geteilte KPIs.
• Historisch gewachsene Zuständigkeiten.

Aber ein Faktor ist besonders entscheidend: Ego. Nicht im negativen Sinne von Arroganz, sondern im psychologischen Sinne. Menschen identifizieren sich mit „ihrem" Code, „ihrem" System, „ihrem" Bereich.

Fehler in Produktion werden dadurch nicht als gemeinsames Lernfeld gesehen, sondern als Bedrohung der eigenen Kompetenz. Das Ergebnis: Verteidigung statt Kooperation.

Die Realität im Jahr 2025: Dev und Ops leben getrennt – nur moderner

Heute tragen Entwickler Hoodies mit „DevOps" und betreiben Kubernetes-Cluster. Aber die Muster sind oft dieselben. Die Tools sind anders, die Haltung bleibt.

Man spricht von „SRE", „Platform Teams" und „Shift Left", aber die operative Realität sieht aus wie immer: Entwickler liefern Container, Ops sorgt dafür, dass sie laufen. Nur dass der Zaun zwischen beiden jetzt aus YAML besteht.

Was sich ändern muss

DevOps ist nicht gescheitert – es wurde nur nie konsequent umgesetzt. Die Lösung ist keine neue Rolle, kein weiteres Tool und kein weiterer Slack-Channel, sondern ein radikales Umdenken:

1. Verantwortung gehört geteilt, nicht weitergereicht.

   Fehler sind systemisch, nicht individuell.

2. Entwickler müssen den Betrieb verstehen.

   Nicht im Detail, aber im Prinzip.

   Kein Code ohne Verständnis für Ressourcen, Netzwerk, Laufzeitverhalten und Skalierung.

3. Operations muss Feedback geben dürfen.

   Nicht nur „Fehler aufnehmen", sondern Architektur mitgestalten.

4. Observability ist Pflicht, kein Bonus.

   Wer Systeme baut, muss sie sehen, messen und verstehen können – jenseits des Debuggers.

5. Fehlerkultur statt Schuldzuweisung.

   Incidents sind Lernchancen, keine Karrierefallen.

Kollaboration statt Konfrontation

Das Ziel ist nicht, Entwickler zu Betriebsleuten zu machen – oder umgekehrt. Das Ziel ist, geteilte Realität zu schaffen. Wenn beide Seiten dasselbe Monitoring sehen, dieselben Logs lesen und dieselben Metriken interpretieren können, entsteht Vertrauen. Wenn beide gemeinsam Postmortems durchführen, lernen sie voneinander. Wenn beide dieselben KPIs haben (Uptime, Performance, Deployment Success Rate), entsteht gemeinsames Ownership. DevOps funktioniert nur, wenn beide Seiten dieselbe Sprache sprechen.

Wie wir bei ayedo das angehen

In unseren Workshops zu Docker, Kubernetes und Betriebssouveränität sehen wir genau diese Dynamik immer wieder. Entwickler mit starkem Framework-Fokus treffen auf Betriebsteams, die mit Infrastrukturproblemen kämpfen – beide reden über dieselben Systeme, aber in unterschiedlichen Sprachen.

Wir bringen beide zusammen – in einem praktischen Rahmen, wo Theorie und Realität sich treffen. Wir zeigen, wie Container, Observability und CI/CD zusammenhängen, und warum gute Software sich erst im Betrieb beweist.

Denn das ist der Kern von DevOps, den viele vergessen haben: Der Betrieb ist kein Gegner, sondern die Verlängerung der Entwicklung.

DevOps sollte die Brücke zwischen Entwicklung und Betrieb schlagen. Doch in der Praxis wurde sie nie fertig gebaut – und manchmal steht auf beiden Seiten wieder jemand mit dem Eimer Benzin. Was wir brauchen, ist kein neues Buzzword, sondern ein neues Bewusstsein. Software ist kein abgeschlossenes Produkt, sondern ein lebender, atmender Organismus, der im Betrieb reift. Die Verantwortung dafür liegt nicht in einer Abteilung, sondern bei allen, die an diesem System arbeiten. Solange Ego, Misstrauen und Schuldzuweisung den Ton angeben, wird DevOps weiter scheitern – ganz egal, wie viele CI/CD-Pipelines man aufsetzt.

Die Zukunft gehört Teams, die gelernt haben, Verantwortung gemeinsam zu tragen – in Erfolg und in Ausfall. Alles andere ist nur Dev und Ops in neuem Gewand.