Offen betrieben

PaaSbox ist ein Ein-Personen-Unternehmen, und die Person bin ich. Das ist eine Tatsache, die man kennen sollte, bevor man Produktion darauf legt – statt sie zu verstecken, betreibe ich deshalb offen: Aufbau, Zahlen und Regeln sind öffentlich, und die Zahlen misst jemand anderes.

Der Aufbau

• Ich entscheide, nehme die Alarme entgegen und bin der Einzige, der die Live-Landscape anfasst. Geschäftszeiten sind Mo–Fr, 09:00–18:00 Uhr MEZ; die Support-Grenze sagt, was kostenlos ist und was abgerechnet wird.
• Meine Agenten erledigen die Bau- und Validierungsarbeit: Sie aktualisieren den Hetzner-Stack und die Plattform, wenn upstream sich bewegt, fahren die Drills, führen Sicherheitsprüfungen durch, implementieren ausgewählte Verbesserungen und machen den ersten Durchgang der Ursachenanalyse bei Incidents. Ihr Ergebnis ist ein Pull Request oder ein Ticket, nie eine Änderung an einem Live-System. Auch dafür habe ich Gardener gewählt: Jede Änderung ist etwas, das sich proben lässt, bevor es dich erreicht.
• Automatisierung übernimmt die Fehler, die verstanden sind: Ein unhealthy Node wird ersetzt, ein NAT-Gateway binnen sechs Minuten zurückgesetzt oder ersetzt, ein verlorenes etcd aus seinen Backups wiederhergestellt, eine verlorene Control Plane aus dem Object Storage neu aufgebaut. Jedes davon war ein Drill, bevor es ein Feature war.
• Ein Totmannschalter außerhalb meiner Infrastruktur alarmiert mich, wenn das eigene Monitoring der Plattform verstummt.

Die Zahlen

Die Verfügbarkeit misst ein externer Monitor, nicht ich. Er prüft aus drei Regionen:

• einen Kanarien-Produktions-Cluster in der Referenz-Konstellation, der PaaSbox gehört – genau wie der eines Kunden;
• die Konsole und die API;
• eine tägliche Cluster-Erstellung vom Token bis kubectl get nodes.

Die Ergebnisse stehen auf der Status-Seite, mitsamt Incidents und ihren Auswertungen. Kunden-Cluster stehen auf keiner öffentlichen Seite; jeder Kunde bekommt dieselbe Monitor-Definition, um sie gegen seinen eigenen API-Endpunkt laufen zu lassen, und genau diese Probe ist das, woran die Verfügbarkeitszusage in den AGB gemessen wird.

Einmal im Monat veröffentliche ich einen Bericht im Blog mit:

• Verfügbarkeit pro Cluster, aggregiert, gegen die Zusage;
• Incidents, ihre Ursache und die Zeit bis zur Wiederherstellung;
• was sich selbst geheilt hat und was mich gebraucht hat;
• Plattformkosten gegen Umsatz;
• was die Agenten geliefert, geprobt und untersucht haben – gegen das, was ich getan habe.

Der erste Bericht erscheint einen Monat nach dem Start. Bis drei Monate Historie existieren, verlinkt diese Seite auf die Berichte, statt sie zusammenzufassen; eine Zusammenfassung mit zu wenig Historie ist Marketing, und mir ist lieber, du liest die Incidents.

Was ich veröffentliche – und was nicht

Den Betrieb vollständig, die Wirtschaftlichkeit als Verhältnisse und Meilensteine. Das ist eine Charta, keine Laune: Sie bleibt von Monat zu Monat gleich, und sollte sie jemals weiter werden, sage ich das im Bericht.

Veröffentlicht, jeden Monat

• die Verfügbarkeit des Kanarien-Clusters und der Flotte insgesamt; jeder Vorfall mit Ursache und Zeit bis zur Wiederherstellung; was sich selbst geheilt hat und was mich gebraucht hat;
• was die Agenten ausgeliefert, gedrillt und untersucht haben, gegenüber dem, was ich getan habe, und die Stunden, die ich aufgewendet habe;
• die Kostendeckung als Meilenstein: ob der Umsatz die Kosten der Plattform deckt, und seit wann – nie die Euro-Beträge, nie die Kostenaufstellung;
• wie viele Kunden, als Spanne: „unter zehn“, „zehn bis fünfundzwanzig“, exakt erst über fünfundzwanzig;
• jede Vorfall-Auswertung, anonymisiert; jedes Drill-Protokoll; jede Roadmap- und Preisänderung, mit Begründung.

Nicht veröffentlicht

• exakter Umsatz und Margen, Cluster-Zahlen (Cluster mal Listenpreis ist der Umsatz), und was die eigenen Server der Plattform kosten;
• irgendetwas über einen einzelnen Kunden; Kundennamen, außer sie bitten darum;
• Sicherheitsdetails, die einem Angreifer helfen würden: Adressen, interne Namen, eine Schwachstelle, bevor ihr Fix ausgeliefert ist;
• Termine als Versprechen. Ich sage, was ausgeliefert ist, nicht, was kommen wird.

Warum die Linie hier liegt: Wer diese Seite liest, entscheidet, ob es den Dienst in einem Jahr noch gibt, und eine Monatsumsatzzahl bei zehn Clustern sagt darüber weniger als die Drills, die Vorfälle und die Stunden. Und bei weniger als zwanzig Kunden ist alles, was einen einzelnen Kunden betrifft, identifizierend.

Die Agenten-Charta

Was meine Agenten dürfen – und was nur ich tue:

Agenten tun	Nur ich tue
Pull Requests gegen die Plattform und den Hetzner-Stack öffnen	in den Live-Branch mergen, was deployt
den Drill-Katalog auf einer Wegwerf-Landschaft fahren und die Ergebnisse protokollieren	eine Änderung für Kunden freigeben
Abhängigkeiten, Images und Konfiguration auf bekannte Schwachstellen prüfen	die Live-Landscape anfassen
die Ursachenanalyse eines Incidents aus Logs und Metriken entwerfen	über die Behebung entscheiden und sie anwenden
alles, was Geld kostet oder Daten löscht, als Ticket vorschlagen	es ausführen
internes Tooling, Dashboards und das Lab-Harness bauen	sie in Produktion betreiben

Ambient Agents – solche, die beobachten und ohne Auftrag handeln – kommen einen Bereich nach dem anderen dazu, sobald der Bereich es sich verdient hat, und ich kündige jede Erweiterung im Monatsbericht an, samt dem, was sie darf.

Die Drills

Jede Änderung an der Plattform läuft gegen eine Wegwerf-Landschaft, bevor sie einen Kunden erreicht. Der Katalog, Stand 2026-09-06: etcd-Verlust und Restore aus dem Object Storage, Verlust der gesamten Plattform und ihr Wiederaufbau, ein hängendes oder ausgeschaltetes NAT-Gateway, Node-Ersatz und In-place-Rebuild adoptierter Server durch ein Kubernetes-Upgrade hindurch, Ruhezustand und Aufwecken, Mandanten-Isolation, privater Egress mit einem dedizierten Server hinter dem Gateway – und das Exit-Kit. Die Protokolle veröffentliche ich mit den monatlichen Zahlen, samt dem, was gemessen und was behoben wurde.

Was ich verspreche, nicht zu behaupten

• Keine Verfügbarkeitsprozente, die ich nicht mindestens drei Monate lang gemessen habe.
• Keine „kostenlose Testphase“ – es gibt ein Startguthaben von 5 € mit hinterlegter Karte.
• Kein „Zero Data Loss“ – der Wiederherstellungspunkt liegt auf einem Test-Cluster bei bis zu fünf Minuten und ist nur beim Verlust eines einzelnen Plattform-Nodes auf einem Produktions-Cluster null.
• Keine Zertifizierung, die ich nicht habe. Die Plattform läuft in nach ISO 27001 zertifizierten Hetzner-Rechenzentren; PaaSbox selbst ist nicht zertifiziert.
• Kein Feature, das als verfügbar beschrieben wird, bevor es das ist.