Der typische Mandant
Ein KMU aus Deutschland, Österreich oder der Schweiz mit eigener Software oder eigenen Diensten: ein Softwarehaus mit 5 bis 50 Entwicklern, ein Hersteller mit Cloud-Anteil am Produkt oder eine IT-Abteilung, die heute einzelne Server betreibt. Oder ein Unternehmen, das schon einen Cluster hat, aber kein verlässliches Monitoring und keine geregelte Fehlersuche.
Was Sie nach vier Wochen haben
Einen Kubernetes-Cluster auf Talos Linux, einem unveränderlichen Betriebssystem ohne SSH, dessen Konfiguration vollständig in Git liegt. GitOps mit Argo CD: Jede Änderung läuft als Pull Request, jede Abweichung wird erkannt. Metriken und Logs aller Anwendungen, Alarme mit festgelegter Bedeutung in Ihrem Chat, eine Verfügbarkeitsprüfung von aussen und Service-Level-Ziele mit Fehlerbudget. Tägliche Sicherung und eine erprobte Wiederherstellung. Und einen Agenten mit Runbooks für die häufigsten Alarme, ein Betriebshandbuch und eine Schulung Ihres Teams.
Wie der Agent bei der Fehlersuche hilft
Bei einem Alarm fragt Ihr Team den Agenten im Chat. Er untersucht Metriken, Logs und Ereignisse im Cluster, hält sich an das Runbook des Alarms und legt eine Diagnose mit Begründung und einem Lösungsvorschlag vor. Er hat im Cluster nur Leserechte und kann nichts selbst ändern. Die Korrektur läuft immer über Git: Ein Mensch gibt den Pull Request frei, Argo CD rollt die Änderung aus, und der Alarm erlischt. Das Sprachmodell des Agenten bestimmen Sie.
So betreiben wir unsere eigene Plattform
Unsere eigene Plattform betreiben wir genau so: 9 Knoten auf Talos Linux mit Kubernetes 1.35, 107 Anwendungen, die Argo CD aus Git ausrollt, 112 Service-Level-Ziele mit Fehlerbudget und eine Verfügbarkeitsprüfung von aussen für über 30 Dienste. Unsere Agenten für die Fehlersuche haben im Cluster nur Leserechte. Stand: 31. Oktober 2026.
Wo der Cluster läuft
Auf Ihrer eigenen Hardware, bei einem Anbieter Ihrer Wahl in der Schweiz oder der EU oder auf unserer Plattform in der EU. Die Konfiguration gehört Ihnen und liegt in Ihrem Git-Repository, sodass Sie den Betrieb jederzeit selbst übernehmen oder den Anbieter wechseln können.
Vier Wochen, ein geprobter Ernstfall
Woche 1: Bestandsaufnahme
Aufnahme von Anwendungen, Daten und heutigem Betrieb, Wahl des Standorts, Zielbild und Plan. Am Freitag entscheiden Sie, ob es weitergeht oder ob Sie zu einem Viertel des Preises aussteigen.
Woche 2: Cluster und GitOps
Aufbau des Clusters oder Überführung des bestehenden Clusters in Git, Einrichtung von Argo CD, erste Anwendung im Betrieb.
Woche 3: Monitoring und Sicherung
Metriken, Logs, Alarme, Service-Level-Ziele, Verfügbarkeitsprüfung, tägliches Backup, weitere Anwendungen.
Woche 4: Agent und Übergabe
Agent mit Leserechten und Runbooks, erprobte Wiederherstellung, ein Probealarm, den Ihr Team mit dem Agenten löst, Schulung und Betriebshandbuch.
Häufige Fragen
Wir haben schon einen Cluster. Passt das Angebot trotzdem?
Ja. Wir überführen den bestehenden Cluster in Git und ergänzen Monitoring, Sicherung und den Agenten. Was wir dabei finden, steht in der Liste der offenen Punkte.
Kann der Agent Schaden anrichten?
Nein. Er hat im Cluster nur Leserechte. Jede Änderung ist ein Pull Request, den ein Mensch freigibt.
Wer betreibt den Cluster danach?
Das entscheiden Sie. Ihr Team übernimmt mit Betriebshandbuch und Schulung, oder wir betreiben ihn inklusive Bereitschaftsdienst zu einem monatlichen Festpreis.
Müssen wir unsere Anwendungen umbauen?
Nein, solange sie als Container laufen. Anwendungen, die das noch nicht tun, nehmen wir in die Liste der offenen Punkte auf.