DevOps in KMU: Warum fehlende Rollen zum echten Risiko werden

In den meisten KMU gibt es keinen DevOps-Engineer. Stattdessen gibt es einen Entwickler, der die Infrastruktur "auch noch macht", zusätzlich zu seinem eigentlichen Job, in den Lücken zwischen Tickets und Releases. Das klingt nach Pragmatismus. In der Praxis ist es eine der häufigsten Quellen für technische Schulden, Ausfälle und Wissensverlust.

Dieser Artikel beschreibt, warum diese Situation entsteht, was sie konkret kostet und welche Ansätze wirklich helfen. Er vertieft eines der häufigsten DevOps-Probleme in KMU.

Wie die Situation entsteht

Die Frage, warum KMU keine dedizierte DevOps-Rolle haben, hat meist keine dramatische Antwort. Es ist meistens einfach so gewachsen.

Am Anfang gibt es zwei Entwickler und einen kleinen Server. Einer setzt ihn auf. Das funktioniert. Als das Team wächst, macht dieselbe Person "das mit der Infrastruktur", weil sie es schon kennt. Niemand stellt ernsthaft in Frage, ob das skaliert.

Dazu kommt: Ein erfahrener DevOps-Engineer ist teuer. Nicht nur im Gehalt, sondern auch in der Erwartung an Prozesse, Tools und Arbeitsbedingungen. Viele KMU gehen davon aus, dass sie das Problem erst lösen müssen, wenn es groß genug ist, um es zu rechtfertigen. Bis dahin läuft es ja irgendwie.

Und genau da liegt das Problem.

Was das konkret bedeutet

Wenn Infrastruktur nebenbei mitgemacht wird, entstehen zuverlässig bestimmte Muster, unabhängig davon, wie kompetent die jeweilige Person ist. Es geht dabei selten um individuelles Können, sondern um Rahmenbedingungen: Wer parallel Features baut, Support macht und Releases verantwortet, kann Infrastruktur nur reaktiv betreiben. Das ist die Realität, die wir im Artikel über die Grenzen des Full-Stack-Entwickler-Rollenmodells beschreiben. Dinge werden „irgendwie" zum Laufen gebracht, aber nicht so aufgebaut, dass sie stabil, nachvollziehbar und wiederholbar sind.

Das zeigt sich meistens zuerst in kleinen Reibungen: Deployments dauern länger als sie sollten, Zugänge sind unklar, Warnungen werden ignoriert, weil es zu viele sind. Mit der Zeit wird daraus ein System, das stark von Gewohnheiten und Bauchgefühl abhängt. Und je mehr Services, Umgebungen und Kunden dazukommen, desto schneller kippt dieses Setup von „funktioniert" zu „ständig unter Spannung".

Die folgenden Punkte sind typische Folgen, die in vielen KMU fast immer auftauchen, sobald Infrastruktur kein eigenes Mandat, keine klare Ownership und keine eingeplante Zeit bekommt.

Deployment hängt an einer Person

Wenn der eine Entwickler, der das Deployment kennt, krank wird, im Urlaub ist oder das Unternehmen verlässt, steht das Team vor einem Problem. Nicht nur, dass niemand deployen kann. In der Praxis fehlt auch die Fähigkeit, schnell zu diagnostizieren und zu entscheiden.

Typische Symptome sind:

• Niemand weiß, welche Umgebungsvariablen wirklich aktiv sind und wo sie gesetzt wurden.
• Cron-Jobs laufen irgendwo, aber nicht dokumentiert und ohne Ownership.
• Der eine „Spezial-Port" oder die eine Sonderroute im Ingress existiert, weil es damals „so am schnellsten ging".
• Das CI/CD ist voller Ausnahmen: ein manueller Schritt hier, ein geheimes Token dort.

Spätestens beim Incident wird daraus ein Business-Risiko: Die MTTR (Mean Time To Recovery) steigt, weil nicht nur das Problem gelöst werden muss, sondern zuerst das System verstanden werden muss. Deployment wird so zum kritischen Engpass im Software-Delivery. Und auch wenn der Ausfall „nur" ein paar Stunden dauert: Es kostet Fokus, Vertrauen und Geld.

Ein Single Point of Failure in der Infrastruktur ist kein theoretisches Risiko. Es ist eine Frage des Zeitpunkts.

Wissen, das niemand aufgeschrieben hat

Infrastruktur, die nebenbei betrieben wird, hat selten gute Dokumentation. Die Person, die sie aufgebaut hat, trägt das Wissen im Kopf. Warum wurde dieser Ansatz gewählt? Wo liegen die Secrets wirklich? Was passiert, wenn dieser Pod crasht? Wo ist der Backup-Prozess beschrieben? Und vor allem: Wie würde man das System neu aufsetzen, wenn man morgen bei null anfangen müsste?

Was dann oft fehlt, sind nicht nur schöne Wikis, sondern ganz konkrete Artefakte:

• Runbooks („Wenn X passiert, dann prüfe Y, dann tue Z")
• Architektur-Übersichten (Netzwerk, Ingress, Datenflüsse, Abhängigkeiten)
• Access- und Rollenmodelle (wer darf was, wo liegen die Credentials)
• Entscheidungsdokumente („Warum haben wir dieses Tool gewählt und nicht das andere?")

Wenn diese Person geht, geht das Wissen mit. Was bleibt, sind Konfigurationen ohne Kontext und Kolleginnen und Kollegen, die sich vorsichtig vorarbeiten müssen, um nichts zu brechen. Wie sich Wissensdokumentation und Bus-Faktor konkret senken lässt, zeigen wir in einem eigenen Artikel. Oft endet das in einer Mischung aus Angst vor Änderungen und einem „Hands-off"-Bereich, den niemand mehr anfassen will.

Das ist kein Vorwurf an die betroffene Person. Es ist das natürliche Ergebnis einer Rolle, für die keine Zeit eingeplant ist.

Infrastruktur, die "irgendwie läuft"

Der dritte Effekt ist subtiler, aber teurer. Wenn jemand Infrastruktur nur nebenbei betreut, werden Probleme gelöst, aber nicht nachhaltig behoben. Der Workaround, der einmal funktioniert hat, bleibt. Das Skript, das refactored werden sollte, bleibt. Das Monitoring, das sauber aufgesetzt werden müsste, bleibt auf der Todo-Liste.

Das führt zu typischen „Stillstands-Kosten":

• Security drift: Patches, Kubernetes-Versionen, Container-Base-Images werden zu spät aktualisiert.
• Fehlende Observability: Kein klares Bild über Latenzen, Fehlerquoten, Ressourcenauslastung. Alerts sind noisy oder fehlen komplett.
• Unsaubere Kapazitätsplanung: Zu große Nodes „für Sicherheit" oder zu enge Limits, die sporadische OOM-Kills verursachen.
• Fragiles Deployment: Releases funktionieren nur, wenn „alles genau so ist wie immer", weil es keine klaren Standards und Checks gibt.

Technische Schulden in der Infrastruktur sind besonders gefährlich, weil sie lange unsichtbar bleiben. Sie zeigen sich oft erst dann, wenn es sowieso schon brennt: beim Wachstum, beim ersten echten Incident, beim Audit oder beim Onboarding neuer Teammitglieder.

Warum das mit wachsender Infrastruktur nicht besser wird

Man könnte annehmen, dass sich das Problem von selbst löst, wenn das Unternehmen wächst. In der Praxis passiert das Gegenteil.

Mit mehr Diensten, mehr Deployments und mehr Komplexität wächst auch die Last auf der einen Person, die "das mit der Infrastruktur macht". Gleichzeitig steigt der Druck, schnell zu liefern, was bedeutet, dass noch weniger Zeit für saubere Infrastrukturarbeit bleibt.

Kubernetes macht das nicht einfacher. Die Plattform ist mächtig, aber sie ist kein Self-Service für jemanden ohne Erfahrung. Cluster-Networking, Resource-Limits, RBAC, Storage-Klassen, Ingress-Konfiguration. Das sind keine Themen, die man "schnell mal" löst. Und wenn man sie "schnell mal" löst, sieht man die Konsequenzen später.

Was DevOps KMU-tauglich macht

Es gibt keine einfache Lösung, die für alle KMU passt. Aber es gibt Ansätze, die systematisch helfen:

Infrastruktur als Code ist der erste Schritt. Wenn Konfigurationen in Git liegen, ist das implizite Wissen zumindest teilweise explizit gemacht. Änderungen sind nachvollziehbar, Rollbacks möglich.

Standardisierte Plattformen reduzieren Komplexität. Statt jedes Mal neu zu entscheiden, wie etwas aufgesetzt wird, gibt es eine Vorlage, die funktioniert. Das senkt den Einstiegsaufwand und die Fehlerquote.

Managed Services und DevOps as a Service gehen einen Schritt weiter. Statt Infrastruktur selbst zu betreiben, wird sie als Service bezogen. Das bedeutet nicht Kontrollverlust – es bedeutet, dass jemand anderes für Betrieb, Updates und Incident-Response zuständig ist, während das eigene Team sich auf die Anwendung konzentriert.

Wie lowcloud das Problem löst

lowcloud ist eine Kubernetes-DevOps-as-a-Service-Plattform, die genau für dieses Szenario gebaut wurde. Nicht für Konzerne mit einem Platform-Engineering-Team, sondern für KMU und Start-ups, die Kubernetes-Workloads betreiben wollen, ohne selbst Infrastruktur-Expertise aufzubauen.

Die Plattform übernimmt Cluster-Management, Updates, Monitoring und Security-Hardening. Entwicklerteams deployen ihre Anwendungen über standardisierte Workflows – ohne sich um das darunter liegende Kubernetes kümmern zu müssen. Das Wissen über den Betrieb liegt nicht mehr bei einer einzelnen Person, sondern in der Plattform.

Das löst das Kernproblem: Die Abhängigkeit von einer einzelnen Person, die nebenbei die Infrastruktur kennt, wird durch eine Plattform ersetzt, die von Anfang an für genau diese Situation konzipiert ist.

Wenn du in einem KMU arbeitest, das gerade in dieser Situation steckt oder ihr euch fragt, wie ihr Kubernetes vernünftig betreiben könnt ohne eine dedizierte DevOps-Rolle – schau dir an, was lowcloud konkret anbietet.