Kontaktieren Sie uns
Wir von accompio helfen Ihnen gerne.
06.10.2026
Kubernetes, CI/CD-Pipelines, Cloud-native Plattformen: Wenn Unternehmen über DevOps sprechen, stehen meist die Tools im Mittelpunkt. Doch ein moderner Technologie-Stack allein macht noch keine DevOps-Organisation. Es gibt Unternehmen mit den besten Pipelines, die trotzdem drei Monate für ein Release brauchen – und andere, die mit virtuellen Maschinen und einem Monolithen deutlich schneller liefern.
Der Unterschied liegt nicht in der Technologie, sondern in der Arbeitsweise. DevOps ist in erster Linie eine Kultur der Zusammenarbeit, des schnellen Feedbacks und der kontinuierlichen Verbesserung. Die Tools sind das Ergebnis dieser Arbeitsweise – nicht ihr Ausgangspunkt.
Im aktuellen Video spricht Bastien Reinhardt, Senior IT-Consultant bei accompio, darüber, warum erfolgreiche DevOps-Strategien weit über Tools und Technologien hinausgehen.
DevOps wird häufig gleichgesetzt mit Kubernetes, CI/CD und Cloud-native Technologien. Aus Sicht von Bastien Reinhardt greift das zu kurz. DevOps ist entstanden, weil Teams anders zusammenarbeiten wollten: schneller, enger abgestimmt und mit gemeinsamer Verantwortung für das Ergebnis. Aus diesem Gedanken heraus sind die bekannten Tools erst entwickelt worden.
Heute ist die Reihenfolge oft umgekehrt. Unternehmen führen zuerst die Tools ein und erwarten, dass sich die Arbeitsweise dadurch automatisch ändert. Im schlimmsten Fall wird den Teams eine neue Arbeitsweise über die Tools aufgedrückt, ohne dass sie verstanden oder gewollt ist.
„Diese Tools sind im Endeffekt nur das Ergebnis einer Arbeitsweise.“
Bastien Reinhardt, Senior IT-Consultant bei accompio
Das „DevOps Handbuch“ (The DevOps Handbook von Gene Kim, Jez Humble, Patrick Debois und John Willis) beschreibt drei zentrale Prinzipien: den Arbeitsfluss (Flow), schnelles Feedback und kontinuierliches Lernen und Verbessern. Trotzdem stehen in vielen Unternehmen vor allem die Tools im Fokus.
Der Grund ist einfach: Tools sind sichtbar. Wer Kubernetes einführt, hat klare Verantwortlichkeiten, sieht, dass die Plattform betrieben und genutzt wird, und kann sogar messen, wie viele Workloads bereits darauf laufen. Eine veränderte Arbeitsweise lässt sich dagegen nicht so einfach vorzeigen.
Wie sich das konkret auswirkt, zeigt ein Vergleich aus der Praxis:
Die Release-Dauer ist dabei eine messbare Kennzahl, die mehr über die DevOps-Reife eines Unternehmens aussagt als die Liste der eingesetzten Tools.
Viele Unternehmen arbeiten noch mit klassisch getrennten Entwicklungs-, Betriebs- und Infrastrukturteams. Gerade große Organisationen sind auf Verlässlichkeit optimiert und in ihrer bestehenden Arbeitsweise stark. Eine Veränderung fühlt sich für viele Mitarbeitende deshalb wie ein Kontrollverlust über ihren eigenen Fachbereich an.
„Die Hürden sind eigentlich fast nie technisch.“
Bastien Reinhardt, Senior IT-Consultant bei accompio
Die Silos sind jeweils auf ihr eigenes Ziel optimiert: Entwicklungsteams darauf, möglichst schnell Features zu liefern. Der Betrieb darauf, die Verfügbarkeit hochzuhalten. Beide Ziele sind berechtigt, stehen aber häufig im Widerspruch. DevOps verlangt, bereichsübergreifend zu arbeiten – und genau diese Umstellung fällt anfangs schwer.
Dieser Satz steht einem erfolgreichen DevOps direkt im Weg. Denn bei DevOps geht es darum, Silos aufzubrechen. Wer im DevOps-Team arbeitet, ist nicht nur für die Entwicklung zuständig, sondern für das gesamte Produkt. Dazu gehört auch, gemeinsam mit dem Betrieb Probleme zu finden und zu lösen.
Wichtig ist dabei: Meist steckt hinter diesem Satz keine Bequemlichkeit, sondern jahrelang gelebte Praxis. Hinzu kommen in manchen Organisationen Compliance-Vorgaben, die bestimmte Tätigkeiten formal einschränken. Deshalb ist DevOps ein ganzheitliches Thema, das alle betrifft – Teams, Führungskräfte und die Organisation als Ganzes.
Veränderung wirkt am nachhaltigsten, wenn sie von unten kommt. Entwicklerinnen und Entwickler können DevOps deshalb aktiv vorantreiben – auch ohne Auftrag von oben. Bastien Reinhardt nennt drei konkrete Ansatzpunkte:
Technische Spezialisierung bleibt wichtig. Doch daneben gewinnen Fähigkeiten an Bedeutung, die über das eigene Fachgebiet hinausgehen.
Wo sitze ich in der Wertschöpfungskette meines Unternehmens? Was machen die anderen Teams? Und wie kann ich ihnen die Arbeit erleichtern? Wer diese Fragen stellt, optimiert nicht mehr nur den eigenen Bereich, sondern das Gesamtsystem.
Früher wurden vor allem Spezialistinnen und Spezialisten gesucht. Heute sind sogenannte T-Shaped Profile gefragt: breites Wissen über angrenzende Bereiche (der horizontale Balken des „T“) kombiniert mit tiefer Expertise im eigenen Fachgebiet (der vertikale Balken).
DevOps bedeutet mehr Abstimmung. Dazu gehört auch, Grenzen zu akzeptieren: Eine Optimierung im eigenen Bereich ist nicht sinnvoll, wenn sie im Betrieb deutlich größere Auswirkungen hätte. Dann gilt es, einen gemeinsamen Punkt zu finden, bis zu dem man geht – und nicht weiter.
Nahezu jedes Unternehmen betreibt heute bereits eine eigene interne Plattform. Auch der DORA-Report 2025 von Google Cloud zeigt, dass rund 90 Prozent der befragten Organisationen mindestens eine interne Plattform einsetzen. Die entscheidende Frage ist daher nicht mehr, ob es eine Plattform gibt, sondern wie gut sie ist: Nutzen die Teams sie freiwillig, weil sie ihnen hilft? Oder werden sie organisatorisch gezwungen, sie zu verwenden? Die Antwort darauf spricht Bände über die Qualität des Platform Engineering.
An KI kommt niemand vorbei. Aktuell wird sie vor allem für die Code-Generierung eingesetzt. Für DevOps gilt jedoch dasselbe wie für jedes andere Tool: KI ist ein Multiplikator.
„Gute Teams werden besser, schlechten Teams wird deutlich schneller und häufiger gezeigt, wo sie Probleme haben.“
Bastien Reinhardt, Senior IT-Consultant bei accompio
Teams, die ihren Arbeitsfluss kennen und schnelle, kurze Feedback-Loops haben, werden KI schneller und in allen Bereichen wirksam einsetzen können. Die Folge: Die Schere zwischen Teams, die DevOps leben, und Teams, die es noch nicht tun, wird größer.
accompio begleitet Unternehmen bei der Einführung von Kubernetes, CI/CD und Infrastructure as Code – Themen, die im Kern auf Site Reliability Engineering (SRE) aufbauen.
Bastien Reinhardts wichtigster Rat für Unternehmen: klein anfangen und ein messbares Problem lösen.
Erfolgreiches DevOps beginnt nicht mit Kubernetes oder einer neuen CI/CD-Pipeline, sondern mit der Frage, wie Teams zusammenarbeiten. Tools, Automatisierung und KI verstärken das, was bereits da ist – gute Praktiken genauso wie schwache Prozesse. Unternehmen, die DevOps nachhaltig etablieren wollen, sollten deshalb Technologie und Kultur gemeinsam weiterentwickeln: Silos aufbrechen, Teams entlang von Produkten zuschneiden, ihnen Zeit für Betrieb und Verbesserung geben und Feedback sichtbar machen.
Der Einstieg muss dabei nicht groß sein. Ein einziges, messbares Problem – etwa ein zu langer Release-Zyklus – reicht aus, um den Wandel anzustoßen.
Bastien unterstützt Unternehmen bei der Einführung von Kubernetes, CI/CD und Infrastructure as Code. Sein Schwerpunkt liegt im Site Reliability Engineering und in der Frage, wie Teams Technologie und Arbeitsweise gemeinsam weiterentwickeln.
DevOps ist eine Arbeitsweise, bei der Entwicklung (Development) und Betrieb (Operations) eng zusammenarbeiten und gemeinsam Verantwortung für ein Produkt übernehmen. Zentrale Prinzipien sind ein schneller Arbeitsfluss, kurze Feedback-Schleifen und kontinuierliche Verbesserung. Tools wie Kubernetes oder CI/CD unterstützen diese Arbeitsweise, ersetzen sie aber nicht.
Nein. Tools sind das Ergebnis einer DevOps-Arbeitsweise, nicht ihre Voraussetzung. Unternehmen mit modernem Cloud-native Stack können trotzdem lange Release-Zyklen haben, wenn Teams weiterhin in Silos arbeiten.
Die Hürden sind meist organisatorisch statt technisch: Silodenken, unterschiedlich optimierte Ziele von Entwicklung und Betrieb, Angst vor Kontrollverlust sowie Compliance-Vorgaben. DevOps verlangt bereichsübergreifende Zusammenarbeit, die erst gelernt werden muss.
T-Shaped beschreibt ein Kompetenzprofil mit breitem Wissen über angrenzende Bereiche wie Betrieb oder Security und gleichzeitig tiefer Spezialisierung im eigenen Fachgebiet. Solche Profile erleichtern die Zusammenarbeit in Produktteams.
An einer lernorientierten Fehlerkultur, in der Post-Mortems nach Ursachen statt nach Schuldigen fragen, und daran, dass Deployments unspektakulär sind – ein Nicht-Ereignis am Dienstagvormittag statt eines Großereignisses mit Bereitschaftsplänen.
KI ist im DevOps-Kontext ein Werkzeug und wirkt als Multiplikator. Teams mit gutem Arbeitsfluss und schnellen Feedback-Loops profitieren stark, während bei schwächeren Teams Probleme schneller sichtbar werden.
Am besten mit einem kleinen, messbaren Problem, etwa der Dauer eines Releases. DevOps sollte nicht als zeitlich begrenztes Projekt aufgesetzt werden, da die Kultur dauerhaft im Unternehmen verankert bleiben soll.
