Verlängerte Werkbank IT: Platform Team on Demand | cloudpunks

Es gibt eine Situation, die viele IT-Leiter kennen, aber selten laut ansprechen: Die Plattform läuft, das Kubernetes-Cluster steht, Pipelines liefern — und dann geht der DevOps-Engineer, der das alles kennt. Oder das Team ist zu klein für das Projekt, das gerade hochgezogen werden soll. Oder jemand ist in Elternzeit, und niemand sonst hat das nötige Wissen.

Das ist der Moment, in dem eine verlängerte Werkbank Sinn macht: externe Cloud- und DevOps-Expertise, die wie interne Kapazität arbeitet — nicht als Berater von außen, sondern embedded im Team.

Was sonst meistens passiert: Entweder hängt das Team über Monate auf einem Stand, der eigentlich weiterentwickelt werden müsste, oder es wird hektisch nach externer Hilfe gesucht — und man bekommt eine klassische Beratungsfirma, die zwei Wochen assessed, ein Konzept schreibt und dann wieder weg ist.

Dieser Artikel erklärt, wann cloudpunks als verlängerte Werkbank sinnvoll ist, was das konkret bedeutet und — genauso wichtig — wann es nicht passt.

Das eigentliche Problem: Wenn die verlängerte Werkbank fehlt

Die meisten IT-Projekte haben ein Anfang-Ende-Modell. Eine Firma kommt, baut etwas auf, übergibt und geht. Das klingt vernünftig, hat aber einen strukturellen Fehler: Komplexe Cloud-Infrastrukturen brauchen kontinuierliche Aufmerksamkeit. Kubernetes-Cluster brauchen Upgrades. Security-Policies müssen angepasst werden. Neue Services müssen integriert werden. Was mit einer Landing Zone beginnt, wird nach zwölf Monaten zu einer lebenden Infrastruktur, die gepflegt, hinterfragt und weiterentwickelt werden muss.

Wenn dann der Mensch fehlt, der das versteht — weil er gekündigt hat, in Elternzeit ist oder schlicht weil er nie im Haus war — entsteht eine Lücke, die teurer wird, je länger sie offen bleibt.

Drei Situationen, in denen es konkret wird

1. Jemand geht

Kündigung, Elternzeit, Langzeitkrankheit: Wenn der DevOps-Engineer oder die Cloud-Architektin das Team verlässt, ist das Know-how weg. Nicht teilweise — oft vollständig. Kubernetes-Cluster, auf denen keine Doku lebt. Pipelines, die "irgendwie gebaut wurden". Terraform-Code, den nur eine Person wirklich versteht.

In dieser Situation braucht man keine Projektbegleitung. Man braucht jemanden, der übernimmt. Sofort. Cluster-Admin-Zugang bekommt, die Infrastruktur versteht und weiterführt, was der Vorgänger aufgebaut hat.

2. Neues Projekt, aber intern fehlt der Skill

Das Team ist gut — aber für AWS Lambda hat es nie jemand gemacht. Oder für ArgoCD. Oder für Entra ID mit Conditional Access. Das sind keine Defizite, die man in zwei Wochen Googlen schließt. Das sind Spezialthemen, für die man Erfahrung braucht, die aus echten Projekten kommt.

Hier macht es keinen Sinn, sechs Monate auf einen Neueinsteller zu warten, der dann drei Monate braucht um anzukommen. Es macht Sinn, das Wissen einzukaufen — für die Zeit, in der man es wirklich braucht — und dafür zu sorgen, dass das interne Team am Ende selbst weiterarbeiten kann.

3. Die Plattform läuft, aber braucht kontinuierliche Betreuung

Das ist die häufigste und am wenigsten spektakuläre Situation. Der Kubernetes-Cluster läuft seit anderthalb Jahren. Die CI/CD-Pipelines funktionieren. Aber: Niemand macht proaktive Cluster-Upgrades. Security-Patches werden reaktiv eingespielt. Die Observability-Landschaft besteht aus einem Grafana-Dashboard, das niemand versteht, wenn es rot wird.

Das ist keine Krise — aber es ist ein schleichender Rückstand. Eine verlängerte Werkbank in dieser Situation bedeutet: kontinuierliche, planbare Betreuung. Kein Notfall-Einsatz, sondern strukturierte Partnerschaft.

Was cloudpunks in diesem Kontext konkret macht

Wenn ein Kunde cloudpunks als verlängerte Werkbank einbindet, sieht das nicht aus wie ein klassisches Beratungsmandat. Es gibt kein Kickoff-Meeting mit zehn Leuten und einer Präsentation. Es gibt auch kein sechswöchiges Assessment, bevor irgendjemand etwas anfasst.

Was passiert: Cluster-Admin-Zugang wird eingerichtet. Wir lesen uns in die Infrastruktur ein — was läuft, wie es konfiguriert ist, was fehlt. Danach arbeiten wir embedded. Das bedeutet konkret:

Wir sind in eurem Standup. Nicht in einem wöchentlichen Statusmeeting, das für uns eingerichtet wird. Im täglichen oder zweimal wöchentlichen Standup des Teams, das die Infrastruktur betreibt.

Wir kommunizieren direkt. Über Teams, Slack, was auch immer das Team nutzt. Kein Ticket-Portal, kein formales Change-Request-Formular für jede kleine Änderung. Wenn etwas klemmt, schreibt ihr uns — und wir antworten.

Wir schreiben Code, keine Konzepte. Der Output ist ein Pull Request, nicht ein Dokument. Wenn ein Cluster-Upgrade ansteht, machen wir es. Wenn eine neue Pipeline gebaut werden muss, bauen wir sie. Wir zeigen dabei, was wir tun und warum — damit das interne Team am Ende selbst weiterkommt. Mehr dazu, wie wir diese Platform-Team-Betreuung konkret gestalten.

Wir dokumentieren für euch, nicht für uns. Runbooks, die wirklich jemand liest. Architektur-Notizen, die in euer Repo kommen. Keine externe Dokumentation, die nach Projektende niemand mehr findet.

Ein konkretes Szenario

Ein mittelständisches Unternehmen — 400 Mitarbeiter, produzierendes Gewerbe, B2B — betreibt seit zwei Jahren einen Kubernetes-Cluster auf Azure (AKS). Der Cluster läuft, darauf sind acht Workloads deployed, CI/CD läuft über GitHub Actions. Den Cluster kennt im Wesentlichen eine Person: der DevOps-Engineer, der ihn damals mit einer externen Firma aufgebaut hat.

Dieser Engineer kündigt. Kündigungsfrist: drei Monate. Danach ist der IT-Leiter mit einem Cluster allein, den er selbst nicht vollständig überblickt.

Was cloudpunks in dieser Situation macht: In der zweiten Woche nach Vertragsstart haben wir Zugang zum Cluster, zu GitHub, zu Azure. Wir führen ein technisches Review durch — nicht um ein Dokument zu produzieren, sondern um zu verstehen, was wartungsintensiv ist und wo die nächsten drei Monate Aufmerksamkeit brauchen. Ab Woche drei arbeiten wir im Team des Kunden mit. Wir nehmen am Standup teil, übernehmen die Cluster-Verantwortung, und sorgen dafür, dass das anstehende Kubernetes-Upgrade noch in der Überlappungszeit mit dem scheidenden Engineer durchgeführt wird.

Nach drei Monaten ist die Situation stabil. Nach sechs Monaten hat der Kunde entschieden, ob er intern jemanden einstellt, der die Arbeit langfristig übernimmt — oder ob cloudpunks dauerhafter Teil des Teams bleibt. Beides ist ein valider Ausgang.

Der Unterschied zu klassischer Beratung

Wer schon mal eine klassische IT-Beratung engagiert hat, kennt das Muster: Erst gibt es eine Analysephase, dann einen Bericht mit Empfehlungen, dann optionale Umsetzungsbegleitung. Die eigentliche Arbeit bleibt beim Kunden.

Das ist manchmal richtig — wenn man wirklich Orientierung braucht und die interne Kapazität zur Umsetzung vorhanden ist.

Aber in den Situationen, die oben beschrieben sind, braucht man keine Empfehlungen. Man braucht jemanden, der es macht.

Der Unterschied ist nicht die Methode, sondern die Einbindung. Beratung heißt: Wir kommen von außen, geben Ratschläge und gehen wieder. Verlängerte Werkbank heißt: Wir sitzen mit drin, tragen Verantwortung, und das Ergebnis liegt in eurem Repository.

"MIT euch, nicht FÜR euch" ist nicht nur ein Satz — es beschreibt, wie wir tatsächlich arbeiten. Wir haben Cluster-Admin-Rechte, nicht Leserechte. Wir machen Code-Reviews, keine Präsentationsreviews. Wir sind verantwortlich, wenn etwas nicht funktioniert.

Wann es passt — und wann nicht

Es passt, wenn:

• Ihr eine laufende Cloud-Infrastruktur habt, die Betreuung braucht, aber intern fehlt die Person oder das Know-how dafür.
• Ihr schnell reagieren wollt — kein drei-monatiger Onboarding-Prozess, bevor jemand etwas anfasst.
• Ihr direkt kommuniziert. Teams, Slack, Anruf — kein formales Ticketsystem für alltägliche Arbeit.
• Ihr Deployments mehrmals pro Woche macht oder das zumindest anstrebt.
• Ihr Entscheidungen treffen könnt, ohne dass jede Änderung durch ein Change Advisory Board muss.

Es passt nicht, wenn:

Wenn euer Unternehmen jeden Change durch einen formalen Freigabeprozess schickt, wenn Tickets der primäre Kommunikationsweg sind, wenn "schnell" bei euch sechs Wochen bedeutet — dann ist das Modell falsch.

Das ist keine Kritik an solchen Unternehmen. Viele regulierte Branchen brauchen genau diese Prozesse. Aber dann ist cloudpunks nicht der richtige Partner für die operative Betreuung. Für diesen Fall gibt es cloudopserve — ein Schwesternunternehmen, das Managed Services mit klaren SLAs, Ticket-Prozessen und Audit-Trails betreibt.

Wir sagen das lieber vorher als nachher.

Was "verlängerte Werkbank" konkret bedeutet

Der Begriff "verlängerte Werkbank" kommt aus der Industrie und meint: externe Kapazität, die wie interne Kapazität arbeitet. Nicht als Unterauftragnehmer auf Distanz, sondern als Teil des operativen Teams.

Für Cloud-Infrastruktur bedeutet das drei Dinge:

Skill: Wir bringen Wissen mit, das intern nicht vorhanden ist. Kubernetes-Upgrades, ArgoCD-Setup, Kyverno-Policies, Entra ID mit Conditional Access — das sind Themen, die man nicht mal eben lernt. Wir haben das in echten Projekten gemacht, nicht nur in Labs.

Kapazität: Manchmal ist das Know-how intern vorhanden, aber das Team ist schlicht zu klein. Drei Leute in der Platform-Verantwortung, aber gerade läuft gleichzeitig ein Migrationsprojekt, ein Cluster-Upgrade und ein Audit. Dann braucht man keine neue Expertise, sondern zusätzliche Hände.

Kontinuität: Das ist der Faktor, der am häufigsten unterschätzt wird. Nicht der einmalige Einsatz, sondern die verlässliche, planbare Präsenz über Monate. Jemand, der nächste Woche noch da ist und sich noch erinnert, was letzte Woche entschieden wurde.

Typische Themen in der Betreuung

Kubernetes-Betreuung: Cluster-Upgrades auf aktuelle Kubernetes-Versionen, Node-Pool-Anpassungen wenn Workloads skalieren, Kyverno- oder OPA-Policies wenn Security-Anforderungen steigen, Observability mit Prometheus, Grafana und Loki. Das ist das Kernthema unseres Platform-Engineering-Ansatzes.

CI/CD: Pipeline-Pflege in GitHub Actions oder GitLab CI. Dependency-Updates in Images, bevor die CVE-Scanner Alarm schlagen. Onboarding neuer Services in bestehende Deployment-Prozesse, ohne dass jede Änderung zu einem Sonderprojekt wird.

Cloud-Plattform (Azure/AWS): Cost-Monitoring, IAM-Reviews, Networking-Anpassungen wenn neue Services hinzukommen oder Anforderungen sich ändern.

Incident-Response: Wenn nachts etwas abstürzt und intern niemand mehr da ist, der den Cluster wirklich kennt, dann ist das ein Problem. Wir sind die erste Anlaufstelle, wenn tagsüber etwas nicht stimmt, und wir sorgen dafür, dass Monitoring und Alerting so konfiguriert sind, dass man nachts ruhig schlafen kann.

Wie ein typischer Einstieg aussieht

Eine der häufigsten Fragen in ersten Gesprächen: "Wie lange dauert es, bis ihr wirklich arbeiten könnt?" Die Antwort hängt von der Komplexität der Infrastruktur ab — aber der Anspruch ist, dass wir in der ersten Woche verstehen was läuft, und in der zweiten Woche anfangen produktiv beizutragen.

Was wir für einen funktionierenden Start brauchen, ist überschaubar: Zugang zu den relevanten Systemen (Cluster, Repository, Cloud-Konsole), ein kurzes technisches Briefing mit der Person, die am meisten weiß — und Bereitschaft, uns direkt in die operative Kommunikation einzubinden.

Was wir nicht brauchen: Ein formales Lastenheft. Ein RFP-Prozess mit sechs Bieterparteien. Eine dreimonatige Vertragsverhandlung, bevor irgendjemand etwas anfasst.

Was am Ende bleibt

Unser Ziel ist nicht, dauerhaft unersetzlich zu sein. Es ist das Gegenteil: Wir arbeiten so, dass ihr nach sechs oder zwölf Monaten selbst entscheiden könnt, ob ihr uns weiter wollt — oder ob ihr so weit seid, intern weiterzumachen.

Das bedeutet: Dokumentation in eurem Repo, nicht bei uns. Wissen, das im Team bleibt, nicht nur bei unseren Engineers. Architekturen, die ein interner Nachfolger verstehen kann, wenn er kommt.

Befähigung ist kein Nebenziel. Es ist der Anspruch, mit dem wir in jedes Engagement gehen.

Für wen das relevant ist — und wie man anfängt

Wenn ihr eine laufende Kubernetes- oder Cloud-Infrastruktur habt und aktuell eine der drei beschriebenen Situationen (Personallücke, fehlendes Spezialwissen, kontinuierlicher Betreuungsbedarf) wiedererkennt, lohnt sich ein kurzes Gespräch.

Kein Assessment-Formular, keine Anforderungsliste die ihr ausfüllen müsst. Ein Gespräch, in dem wir verstehen was ihr habt, was fehlt — und ob wir der richtige Fit sind.

Falls ihr unsicher seid, ob das Modell "verlängerte Werkbank" oder ein klassisches Managed-Service-Modell besser passt, erklärt unsere Übersicht der Continuous-Service-Varianten die Unterschiede. Alles weitere unter cloudpunks DevOps & Platform Engineering.