Hauseigene Betriebsplattform

Wie ayedo ein Systemhaus vom gewachsenen Betrieb zur auditierbaren Betriebsplattform geführt hat

Ein eigenes Rechenzentrum zu betreiben war lange ein Wettbewerbsvorteil – besonders für Systemhäuser, die Kundenanwendungen nicht nur entwickeln, sondern auch verantworten. Wer den Betrieb beherrscht, kann Verfügbarkeit garantieren, Updates kontrollieren, Datenhoheit sichern und Compliance-Fragen souverän beantworten.

In der Praxis kippt dieser Vorteil jedoch oft genau dann, wenn er am wichtigsten wird: wenn das Portfolio wächst, die Anforderungen steigen und Kunden nicht mehr nur „läuft" erwarten, sondern messbare SLAs, nachvollziehbare Betriebsprozesse und auditierbare Nachweise.

In diesem Beitrag zeigen wir anhand eines anonymisierten Kundenprojekts, wie ayedo ein mittelständisches IT-Systemhaus dabei unterstützt hat, eine eigene Kubernetes-basierte Betriebsplattform im Rechenzentrum aufzubauen – nicht als Managed Service, sondern als Enablement: mit Workshops, Architektur- und Implementierungsbegleitung, modularer Automatisierung über Polycrate-Blöcke und einem 24/7-Support-Sicherheitsnetz für kritische Situationen.

Der Kunde bleibt anonym. Die Lösung – und der Ansatz dahinter – ist reproduzierbar.

Ausgangslage: Wenn „gewachsen" zur operativen Schuld wird

Der Kunde ist ein Systemhaus mit rund 90 Mitarbeitenden, eigenem Rechenzentrum und einem Portfolio von über 40 betriebenen Kundenanwendungen. Die Infrastruktur war über Jahre sinnvoll erweitert worden: VMware für Virtualisierung, Ansible für Provisionierung, Nagios für Monitoring, ergänzt durch Skripte und Cronjobs.

Das klingt zunächst nach „Standard". Und das war es auch – bis die Realität des Wachstums die Schwächen dieses Modells offengelegt hat.

Das zentrale Problem war nicht ein einzelnes Tool. Es war die fehlende Plattformlogik. Ansible-Playbooks existierten, aber sie waren individuell gepflegt und nicht konsistent. Damit war Automatisierung nicht reproduzierbar, sondern personenabhängig. Wenn Admin A ein Playbook schrieb, funktionierte es auf dessen Workstation, mit dessen Variablen, mit dessen Annahmen. Admin B stand vor einer leicht anderen Realität – und plötzlich wurde Automatisierung zur Fehlerquelle.

Im Betrieb zeigte sich ein ähnliches Muster. Day-2-Tasks wie Backups, Updates, Zertifikatserneuerungen, Log-Rotation oder Skalierung liefen manuell oder halbautomatisch über Cronjobs. Die Aufgaben wurden nicht systemisch überwacht. Viele Probleme wurden nicht „entdeckt", sondern „gemeldet" – meist durch Kunden. Abgelaufene Zertifikate, volle Disks, Versionen mit bekannten Sicherheitslücken: All das sind nicht primär technische Probleme. Es sind Prozessprobleme.

Das Monitoring war dabei symptomatisch. Nagios lieferte binäre Zustände: Dienst erreichbar oder nicht. Was fehlte, waren Trenddaten und Betriebskennzahlen. Wie entwickeln sich Antwortzeiten? Gibt es schleichende Performance-Degradation? Wo entstehen Engpässe? Wie lassen sich Kapazitäten planen? Ohne Metriken, Logs und korrelierbare Signale bleibt Betrieb reaktiv.

Und dann kam der Punkt, an dem „reaktiv" nicht mehr akzeptabel war: SLA-Nachweise.

Mehrere Kunden forderten monatliche Verfügbarkeitsberichte. Diese wurden per Hand aus Logs zusammengestellt. Das kostete Zeit, war fehleranfällig und – entscheidend – es war keine belastbare Steuerungsgrundlage. Ob SLAs eingehalten wurden, war eher Schätzung als Messung.

Parallel stiegen Compliance-Fragen, insbesondere in Richtung NIS-2, Zugriffskontrollen, Backup-Strategien und Nachweisführung. Maßnahmen waren teilweise vorhanden – aber nicht auditierbar. Was nicht dokumentiert, versioniert und exportierbar ist, existiert in Audits faktisch nicht.

Der Auslöser: „Nachvollziehbare Betriebsplattform oder Vertragsrisiko"

Der Wendepunkt kam, als ein strategisch wichtiger Kunde klar machte: Der Betriebsvertrag wird nur verlängert, wenn innerhalb eines Jahres eine moderne, nachvollziehbare Betriebsplattform nachgewiesen werden kann – inklusive automatisiertem Monitoring, SLA-Tracking und dokumentiertem Incident-Response-Prozess.

Für viele Unternehmen ist das der Moment, in dem Outsourcing oder Public Cloud als „schnelle Lösung" erscheint. Für dieses Systemhaus war das keine Option. Betrieb war Kernkompetenz und Teil des Wertversprechens. Kunden erwarteten Kontrolle über Infrastruktur – und genau das sollte erhalten bleiben.

Die Frage war also nicht „Wie geben wir Betrieb ab?", sondern: Wie bauen wir Betrieb so, dass er skalierbar, standardisiert, messbar und auditierbar wird?

Hier sind wir als ayedo eingestiegen.

ayedos Ansatz: Enablement + Plattformengineering statt Tool-Feuerwerk

In solchen Projekten entscheidet nicht das Toolset über den Erfolg, sondern die Reihenfolge: Wissen, Architektur, Standardisierung, Automatisierung, Betriebssicherheit.

Kubernetes spielte eine zentrale Rolle – aber nicht als Trend. Sondern als deklaratives Betriebsmodell, das Plattformlogik ermöglicht: gewünschter Zustand, reproduzierbare Deployments, standardisierte Workloads, klare Schnittstellen zwischen Teams.

Gleichzeitig war klar: Das Team hatte kein Kubernetes-Know-how. Wer On-Premises Kubernetes ohne Kompetenzaufbau einführt, baut eine Plattform, die zwar modern aussieht, aber operativ nicht beherrscht wird. Genau das wollten wir vermeiden.

Darum bestand unser Vorgehen aus fünf Phasen, die aufeinander aufbauen.

Phase 1: Know-how in Production aufbauen – nicht in der Sandbox

Wir haben mit einer strukturierten Workshop-Reihe begonnen, die explizit auf produktiven Betrieb ausgelegt ist. Wichtig war dabei nicht nur das Curriculum, sondern die Umgebung: Die Workshops fanden vor Ort statt und arbeiteten direkt auf der realen Infrastruktur, den Netzwerken und Servern, die später produktiv laufen sollten.

Das Team musste nicht abstrakt „Kubernetes verstehen", sondern es musste lernen, wie man einen Cluster installiert, betreibt, absichert und beobachtbar macht – im eigenen Rechenzentrum, mit eigenen Randbedingungen.

Ein Schwerpunkt lag auf den typischen On-Premises-Klippen: Cluster-Topologie, Hochverfügbarkeit der Control Plane, Netzwerkdesign (CNI) im Bestand, Storage-Integration (CSI) für persistente Workloads, sowie GitOps als Betriebsstandard statt „kubectl auf Zuruf".

Am Ende dieser Phase stand kein Zertifikat, sondern ein produktionsreifer Cluster, den das Team selbst aufgebaut hatte. Das ist der Unterschied zwischen Schulung und Enablement.

Phase 2: Zielarchitektur gemeinsam entwerfen – passend zu Hardware, Kunden und Skill-Level

Technische Tiefe entsteht nicht durch „mehr Komponenten", sondern durch passende Entscheidungen.

In der Architekturplanung haben wir gemeinsam mit dem Kunden eine Zielarchitektur entwickelt, die die vorhandene Hardware berücksichtigt, aber gleichzeitig klare Prinzipien einführt:

Deklarativ statt imperativ, Git als Single Source of Truth, standardisierte Observability und ein Backup-/DR-Konzept, das nicht nur existiert, sondern regelmäßig getestet wird.

Gerade im On-Premises-Kontext war uns wichtig, dass die Plattform nicht von Einzelpersonen abhängt. Das bedeutet: klare Cluster-Topologie, nachvollziehbare Netz- und Storage-Entscheidungen, Standardpfade für Deployments und eine Plattform-„Definition", die versioniert ist.

Phase 3: Plattform modular aufbauen – mit Polycrate-Blöcken statt Bastel-Integration

Viele Teams verlieren Monate, weil sie jeden Helm-Chart selbst evaluieren, jede Grafana-Version selbst testen und jede Integrationskante selbst lösen. Am Ende entsteht ein individueller Stack, der nur mit großem Aufwand wartbar ist.

Unser Ansatz war modular: Die Plattform wurde aus Polycrate-Blöcken aufgebaut – versionierten, getesteten Infrastrukturbausteinen vom PolyHub, die wir kontinuierlich pflegen und aktualisieren.

Der Observability-Stack basierte auf VictoriaMetrics, VictoriaLogs und Grafana. Das war kein „Monitoring-Tool-Wechsel", sondern eine Verschiebung des Betriebsparadigmas: weg vom binären Alarm, hin zu Metriken, Logs und Dashboards, die Trends sichtbar machen. Damit werden Kapazitätsplanung, Performance-Analysen und Anomalie-Erkennung überhaupt erst möglich.

ArgoCD wurde als GitOps-Deployer eingeführt. Damit ist jede Änderung ein Commit, jede Änderung nachvollziehbar, jede Ausbringung reproduzierbar. Kein SSH auf Server, keine „Fixes" in der Nacht, die niemand dokumentiert.

Für Backup und Disaster Recovery wurde Velero integriert – inklusive konfigurierbarer Retention und automatisierbaren Restore-Tests. Das ist entscheidend: Backups sind wertlos, wenn Restore nie geprobt wird.

cert-manager hat die TLS-Zertifikatsverwaltung automatisiert. Das klingt banal, ist aber operativ ein riesiger Hebel: Zertifikate laufen nicht „versehentlich" ab, sondern werden als Teil der Plattformlogik erneuert.

Authentik wurde als zentrales Identity Management eingeführt, um Zugriffe auf interne Tools und Plattformkomponenten konsistent über SSO zu steuern – ein wesentlicher Baustein für Auditierbarkeit und Zugriffsnachweise.

Wichtig ist dabei: Polycrate-Blöcke bringen nicht nur Installation, sondern Betriebsstandardisierung. Updates werden über polycrate pull gezogen und via ArgoCD ausgerollt. Eigene Anpassungen bleiben erhalten, weil Polycrate Vererbung unterstützt. Das reduziert Wartungsaufwand massiv, ohne Flexibilität zu verlieren.

Phase 4: Day-2-Automatisierung und SLA-Tracking mit Polycrate API

Der größte Qualitätsgewinn im Betrieb entsteht nicht durch „Cluster läuft", sondern durch Day-2-Automation: Monitoring-Integration, Discovery, Health Checks, Compliance-Nachweise, SLA-Reporting.

Hier kam Polycrate API ins Spiel.

Die Plattform erkennt automatisch neu deployte Anwendungen, Ingresses, Zertifikate und Backup-Jobs. Neue Kundenanwendungen werden ohne manuelle Zusatzkonfiguration in das Monitoring aufgenommen – ein entscheidender Unterschied zu klassischen Toolchains, in denen Monitoring immer „nachgezogen" werden muss.

Endpoints werden kontinuierlich geprüft, inklusive TLS-Konfiguration und Zertifikatslaufzeiten. Damit bekommt das Team nicht nur „Uptime", sondern ein echtes Service-Signal.

Der Kern war jedoch das SLO-/SLA-Management. Für jede Anwendung wurden interne SLOs (z. B. 99,95 %/30 Tage) und vertragliche SLAs (z. B. 99,9 %/365 Tage) definiert. Polycrate API misst die tatsächliche Verfügbarkeit, berechnet Error Budgets und warnt automatisiert, bevor ein Breach eintritt.

Das ist wichtig: SLA-Management ist nicht Reporting. Es ist Steuerung. Error Budgets machen Verfügbarkeit planbar und erlauben Priorisierung im Betrieb.

Auch Downtime-Tracking wurde systemisch: geplante Wartungsfenster können als nicht SLA-relevant markiert werden; ungeplante Ausfälle werden sauber erfasst. Damit sind Berichte nicht nur „schön", sondern belastbar.

Zusätzlich liefen regelmäßige Reconciliation-Checks: Backup-Status, Zertifikatslaufzeiten, Ressourcenauslastung, Replication Lag, ausstehende Updates. Das verschiebt den Betrieb von „wir reagieren" zu „wir verhindern".

Und schließlich: Audit-Logs. Sämtliche Aktionen auf der Plattform werden protokolliert – wer hat wann was deployt, wer hat Zugriffe geändert, wann wurde ein Backup durchgeführt. Das ist die Grundlage, um Compliance nicht nur zu behaupten, sondern nachzuweisen.

Phase 5: 24/7 Priority Support als Sicherheitsnetz – ohne Abhängigkeit

Ein typisches Dilemma bei On-Premises Kubernetes: Man möchte Eigenständigkeit, aber man will nicht nachts um drei allein sein, wenn die Control Plane wackelt oder Storage sich merkwürdig verhält.

Darum war der ayedo Priority Support bewusst als Sicherheitsnetz positioniert, nicht als Ersatz für das Team. Im Incident-Fall steht eine Eskalationsstufe bereit – mit definierter Reaktionszeit und 24/7-Erreichbarkeit. Für viele Organisationen ist genau das der Unterschied, ob sie sich den Schritt in Richtung Kubernetes-Plattform zutrauen oder nicht.

Ergebnis: Standardisiert, messbar, auditierbar – ohne Kontrolle abzugeben

Nach der Transformation war die wichtigste Veränderung sichtbar im Alltag des Teams.

Der Betrieb war nicht mehr personenabhängig. Deployments liefen über GitOps. Observability lieferte Trends statt binärer Zustände. Zertifikate liefen nicht mehr ab. Backups wurden nicht nur erstellt, sondern überprüfbar wiederhergestellt. SLA-Reports wurden automatisiert generiert – in Sekunden statt Stunden.

Ein strategischer Kunde verlängerte den Vertrag – weil die Plattform nicht nur existierte, sondern nachvollziehbar, messbar und auditierbar war.

Und genauso entscheidend: Das Systemhaus blieb souverän. Es betreibt die Plattform selbst, besitzt das Know-how und bleibt Herr der Infrastruktur. Gleichzeitig profitiert es von kontinuierlich gepflegten Bausteinen und einem Support-Sicherheitsnetz für den Ernstfall.

Warum dieser Ansatz funktioniert

Kubernetes On-Premises scheitert selten an Kubernetes. Es scheitert an fehlender Betriebslogik.

Unser Ansatz kombiniert deshalb drei Dinge, die zusammengehören:

Erstens: Kompetenzaufbau. Wer die Plattform nicht versteht, wird sie nicht sicher betreiben. Zweitens: Standardisierte, modulare Bausteine. Wer alles selbst integriert, wird in Wartung ertrinken. Drittens: Day-2-Automation und Messbarkeit. Wer SLAs nicht messen kann, kann sie nicht steuern.

Genau daraus entsteht Plattformengineering – und damit ein Betrieb, der skalieren kann, ohne die Kontrolle abzugeben.

Call to Action

Wenn ihr ein eigenes Rechenzentrum betreibt und merkt, dass euer Betrieb mit dem Wachstum nicht mehr Schritt hält, ist das kein individuelles Versagen.