Betrieb: Standorte, Sicherung, Auslieferung

Wo was läuft

Die Umgebung ist vollständig als Code beschrieben (Bicep) und wird daraus aufgebaut – je Umgebung dieselbe Beschreibung, andere Parameter. Stand der Beschreibung für die Produktivumgebung:

Kundendaten liegen ausschließlich in Schweden-Mitte. Die Oberfläche ist Programmcode, der im Browser läuft; Daten holt sie von der API in Schweden.

Sicherung

Die Datenbank wird täglich gesichert; innerhalb der Aufbewahrung von 14 Tagen lässt sich jeder Zeitpunkt wiederherstellen (Point-in-Time-Recovery). Dokumente und Archiv sind geografisch repliziert. Die Wiederherstellung ist geübt und dokumentiert: zuletzt am 22.09.2026: Der auf einen Zeitpunkt zurückgesetzte Datenbankserver stand nach rund sieben Minuten bereit, alle Tabellen vollständig bis zum gewählten Wiederherstellungspunkt. Gemessen wurde in der Entwicklungsumgebung; eine Zusage zur Wiederanlaufzeit machen wir daraus erst, wenn dieselbe Übung in der Produktivumgebung gelaufen ist. Ob die Datenbanksicherung zusätzlich geografisch redundant angelegt wird, ist eine offene Entscheidung – wir behaupten es nicht.

Überwachung

Jede Komponente meldet ihren Zustand über einen Prüfpunkt (/health); fällt er auf Rot, startet die Anwendung automatisch neu. Protokolle, Metriken und Aufrufketten laufen per OpenTelemetry in Log Analytics und Application Insights zusammen. Überwacht und alarmiert werden Verfügbarkeit, Fehlerquote, Datenbank und Warteschlange; ein Alarm geht per E-Mail an zwei Personen auf Betreiberseite. Die Alarmierung steht als Vorlage in der Infrastruktur-Beschreibung, nicht von Hand angelegt, und ist mit einem Testalarm erprobt. Bei Störungen informieren wir Ihre benannten Ansprechpartner nach einem festgelegten Verfahren; Fristen und Eskalationswege stehen im Vertrag, nicht hier.

Wartungsfenster

Kurzzeitige Deployments ohne wesentliche Beeinträchtigung können ohne Vorankündigung erfolgen. Geplante Wartungsarbeiten mit erwarteter Beeinträchtigung werden mindestens 48 Stunden vorher angekündigt und grundsätzlich werktags ab 20 Uhr durchgeführt. Ungeplante Störungen und Notfallwartungen sind davon ausgenommen.

Die Ankündigung steht in der Anwendung: ein Hinweisbalken über der Oberfläche, sichtbar bis zum angekündigten Ende. Eine öffentliche Statusseite gibt es nicht.

Vom Commit in den Betrieb

1. Jede Änderung durchläuft einen automatisierten Build. Schon das Auflösen der Abhängigkeiten ist ein Tor: Enthält ein Paket eine bekannte Sicherheitslücke, bricht der Build ab – auf der Serverseite ab mittlerer Schwere (NuGet-Audit), in der Oberfläche für alles, was an den Browser ausgeliefert wird, ab hoher Schwere (npm-Audit); dazu ein wöchentlicher Prüflauf unabhängig von Änderungen.

2. Unit- und Integrationstests laufen gegen echte Datenbanken in Containern, nicht gegen Attrappen.

3. Das Container-Image wird gebaut, in der privaten Registry abgelegt und in die Umgebung ausgerollt.

4. Nach dem Ausrollen wird die Gesundheitsprüfung abgefragt. Fällt sie rot aus, rollt die Pipeline automatisch auf das zuletzt laufende Image zurück; dieses Image bleibt in der Registry, solange es irgendwo läuft.

5. Unabhängig von allen Änderungen wird die Anwendung einmal pro Woche neu gebaut, mit aktuellem Basis-Image, und in die Entwicklungsumgebung ausgerollt. In die Produktivumgebung kommt ein solcher Stand wie jede Auslieferung: mit einer Freigabe (nächster Absatz).

Es gibt keinen Weg, Software an diesem Ablauf vorbei in eine Umgebung zu bringen. Eine Auslieferung in die Produktivumgebung verlangt eine Freigabe durch einen Menschen; ein zweiter Freigeber ist nicht vorgesehen.

Verfügbarkeit

Die Anwendung läuft heute in einer Instanz. Wir nennen keine Verfügbarkeitszahl, solange wir sie nicht messen und nicht zusagen können – eine Zahl, die nicht gemessen ist, ist keine Zusage.

Support und Reaktionszeiten

Reaktionszeiten beziehen sich auf die erste qualifizierte Rückmeldung innerhalb unserer Supportzeiten und nicht auf die abschließende Bearbeitung oder Lösung eines Vorgangs. Gesetzliche Feiertage am Sitz von OpexGuard ausgenommen.

Dedizierte Instanz und On-Premises

Die Plattform besteht aus wenigen Bausteinen, die es überall gibt:

Eine dedizierte Instanz entsteht aus derselben Infrastruktur-Beschreibung mit anderen Parametern – auf Wunsch in Ihrem eigenen Azure-Mandanten. Für On-Premises laufen dieselben Container in Ihrer Umgebung; Mandantentrennung, Selbsttest und Änderungsprotokoll sind Teil der Anwendung und verhalten sich dort genauso. Umfang von Betrieb, Updates und Support legen wir je Vertrag fest; einen Referenzkunden dafür gibt es noch nicht.