Das Betriebsmodell: ein verantwortlicher Betreiber, mit schriftlicher Abgrenzung
Bevor eine regulierte Organisation eine Plattform bewertet, zählt sie. Wie viele Verträge, wie viele SLA, wie viele Parteien um drei Uhr morgens in der Leitung, solange noch niemand weiss, ob die Datenbank, der Cluster oder der Hypervisor schuld ist. Ein Stack aus vier Lieferanten verliert gegen einen einfacheren mit einem Betreiber, und dieser Vergleich ist meist entschieden, bevor jemand das Architekturdiagramm öffnet.
Diese Seite nennt darum zuerst die Zahl und danach die Abgrenzung, die sie belastbar macht.
Ein Vertrag, und die Infrastruktur ist drin
Ein Vertrag deckt die Dienste ab, die du aus dem Application Catalog wählst, die Plattform, auf der sie laufen, und Rechenleistung, Speicher und Netzwerk darunter. Ein SLA, bis zu 99,99 %, nach Schweizer Recht. Eine Rechnung.
Die Infrastruktur ist deshalb Teil davon, weil VSHN sie beschafft. Cloudscale, Exoscale oder ein anderer Anbieter, den du freigibst, liefert die Kapazität auf dem Vertrag von VSHN. Du verhandelst, überwachst und mahnst keinen zweiten Lieferanten.
Willst du lieber dein eigenes Cloud-Abo behalten, behalte es. Viele Unternehmen haben zugesagte Volumen, einen bestehenden Rahmenvertrag oder eine interne Regel, dass der Tenant ihnen gehört. VSHN betreibt dann in deinem Abo, und der Anbieter verrechnet dir die Kapazität. Am Rest ändert sich nichts: dieselben Dienste, dasselbe SLA, dieselben Pikett-Engineers. Das ist eine Beschaffungsfrage, keine Frage der Betriebsverantwortung.
Ein Eskalationsweg
Du eröffnest ein Ticket, bei VSHN, rund um die Uhr, besetzt aus der Schweiz.
Im Standardfall gehört die Anbieterbeziehung uns. Das Ticket beim Infrastrukturanbieter eröffnen und verfolgen also wir, und du hast einen Strang statt drei. Das zählt genau in dem Fall, gegen den du dich eigentlich absicherst: eine Störung, bei der noch offen ist, welche Schicht sie ausgelöst hat. Niemand verlangt von dir, das zuerst zu diagnostizieren, um zu wissen, wen du anrufen musst.
Die Abgrenzung, schriftlich
Ein Betriebsmodell, das nur "wir kümmern uns" sagt, macht aus jeder Störung eine Diskussion über den Umfang. Hier ist die Aufteilung, und sie steht in der Leistungsbeschreibung, statt im Störungsfall ausgehandelt zu werden.
| VSHN betreibt | Bei dir bleibt |
|---|---|
| Die Kubernetes- oder OpenShift-Plattform: Control Plane, Cluster-Komponenten, Upgrades | Dein Applikationscode und die Container-Images, die du baust |
| Die Katalogdienste darauf: Datenbanken, Identity, Secrets, Messaging | Deine Schemas, deine Realms, deine Policies, deine Daten |
| Patching, Versions-Upgrades und Change Management für alles in den zwei Zeilen darüber | Der Entscheid, wann dein eigenes Release rausgeht |
| Backups, Restore-Tests und der Nachweis, dass sie gelaufen sind | Deine Aufbewahrungs- und Klassifizierungsvorgaben |
| Monitoring, Alerting und 24/7-Pikett für Plattform und Dienste | Alerting auf der Fachlogik deiner Applikation, ausser du buchst es dazu |
| Kapazitätsplanung, und die Anbieterbeziehung, wenn VSHN die Infrastruktur beschafft | Die Freigabe von Anbieter und Region |
Hinter der Tabelle steht Zuständigkeit, nicht Technik. Eine Plattformänderung, die etwas kaputt macht, müssen wir reparieren, also spielen wir sie ohne Rückfrage ein. Ob dein Produkt eine angehobene Abhängigkeit im eigenen Image überlebt, weiss nur deine Testsuite, also bleibt das bei dir.
Wo die Grenze liegt
Die Aussage dieser Seite gilt für die Applikationsplattform, und sie endet dort, wo unsere Zuständigkeit endet.
VSHN besitzt kein Rechenzentrum. Gebäude, Strom, Racks und das physische Netz sind Sache eines Anbieters, und in einem Umfang, der sie einschliesst, steckt eine Partei in der Kette, die nicht wir sind. VSHN betreibt keine Windows- und MS-SQL-Landschaften. Das WAN zwischen deinen Standorten gehört uns ebenfalls nicht.
Deckt eine Ausschreibung solche Teile ab, ist die ehrliche Form ein Generalunternehmer, der sie hält, mit VSHN benannt für die Plattform. Das sagen wir dann auch, statt einem Angebot mit bereits drei Logos ein viertes hinzuzufügen. Wer Schnittstellen zählt, zählt unsere zu Recht mit.
Was das für eine Ausschreibung heisst
Verlangt dein Zielbetriebsmodell eine durchgängige Betriebsverantwortung mit möglichst wenigen Schnittstellen, dann beschreibt dieser Satz genau, was auf dieser Seite steht: ein verantwortlicher Betreiber ab der Infrastrukturschnittstelle aufwärts, mit dokumentierter statt entdeckter Aufteilung.
Was er nicht beschreibt, ist ein Generalunternehmer für eine ganze IT-Landschaft. Wer einen Lieferanten bittet, Rechenzentrum, Windows-Landschaft, Netz und Applikationsplattform gleichzeitig zu tragen, bekommt entweder ein Konsortium, also wieder das Schnittstellenproblem, oder einen Generalunternehmer, der das meiste weitervergibt, also dasselbe Problem mit einem schöneren Deckblatt. Kaufenswert ist die kleine Zahl von Parteien, die je etwas Ganzes halten. Für die Applikationsplattform sind das wir.
Weiterlesen: Souveränität behandelt Gerichtsstand, Eigentümerschaft und den CLOUD Act, Compliance die Nachweise, nach denen ein Prüfer fragt, darunter ISO 27001 und der ISAE-3402-Typ-II-Bericht.