ChristophandClaude Opus 5.5
f62541ff13
tests / ci (push) Canceled after 0s
- Fragenliste: erste Antworten von BauIn und ITM eingetragen, übrige Fragen auf „gestellt“ - Anmeldung mit eigenem Passwort, 2FA später Pflicht; keine E-Mails; Mehrfach-Upload ohne ZIP - Nur Produktionsschlüssel: Tests rufen die echte API nie auf - Stellungnahme BÜW und Österreich in Phase 2; „Vor dem Livegang zu klären“ in AP11 - Claude Design Stand 0.3 abgeglichen (AP13), Prüfmaske v4 in AP6 - Gitea von ITM als Push-Mirror eingetragen Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
96 lines
4.2 KiB
Markdown
96 lines
4.2 KiB
Markdown
# AP11 – Betrieb
|
||
|
||
| | |
|
||
|---|---|
|
||
| Status | in Arbeit (11a.1 erledigt); Schritte ab 11a.2 detailliert, warten auf Freigabe |
|
||
| Aufwand | 0,5 PW (wir) + 1–1,5 PW (ITM-Entwickler) |
|
||
| Zeitraum | KW 41–44 (Staging), KW 50–51 (Produktion), KW 3/2027 (Restore-Test) |
|
||
| Meilenstein | M2 (Staging), M3 (Produktion), M4 (abgesichert) |
|
||
| Freigabe | offen |
|
||
|
||
## Ziel
|
||
|
||
Staging und Produktion laufen auf den Servern von ITM, werden reproduzierbar bereitgestellt,
|
||
gesichert und überwacht. Ein Ausfall fällt auf, bevor BauIn ihn bemerkt.
|
||
|
||
## Umfang
|
||
|
||
**Enthalten:**
|
||
- **11a, wir:**
|
||
- Server-Anforderungen
|
||
- Vorlagen für Nginx, systemd und Cron
|
||
- Deploy-Skript
|
||
- Lebenszeichen- und Prüfbefehle
|
||
- Backup-Skript
|
||
- Betriebsdoku
|
||
- **11b, ITM-Entwickler:**
|
||
- Server aufsetzen, Domain und Zertifikat
|
||
- Backup-Ziel, Überwachung
|
||
- Restore-Test gemeinsam mit uns
|
||
|
||
**Nicht enthalten:** Hochverfügbarkeit, mehrere Server.
|
||
|
||
## Voraussetzungen
|
||
|
||
- C10 (05.10.): Ausstattung, Zugang, Verschlüsselung und Sicherung der Server sind Sache von ITM.
|
||
Wir liefern die Server-Anforderungen und die Vorlagen (11a).
|
||
- B3 (05.10.): Die Anwendung verschickt keine E-Mails. Die Adresse wird vor dem Livegang geplant.
|
||
- C12 ist beantwortet, offen blieb: Wer deployt im Betrieb, und wie viel Zeit hat der
|
||
ITM-Entwickler?
|
||
- B2, B5 und B6 werden vor dem Livegang geklärt (Abschnitt unten).
|
||
|
||
## Vor dem Livegang zu klären
|
||
|
||
Für die Entwicklung des Prototyps nicht nötig, vor dem Livegang aber Pflicht. Stand 05.10.:
|
||
|
||
| Thema | Frage | Mit wem |
|
||
|---|---|---|
|
||
| Zugriff (B2) | Aus dem Internet mit Login, oder nur über VPN bzw. feste IP-Adressen? | BauIn IT, ITM |
|
||
| Adresse (B3) | Domain und Zertifikat | BauIn IT, ITM |
|
||
| 2FA (B1) | Pflicht einschalten (Schalter aus AP1, E1.6) und Benutzer vorher informieren | BauIn |
|
||
| Backups (B5) | Speicherort, Aufbewahrung, Zuständigkeit | BauIn IT, ITM |
|
||
| Datenschutz und Informationssicherheit (B6) | Vorgaben von BauIn oder der DB, z. B. Sicherheitsanforderungen an Auftragnehmer der DB, ISO 27001, Geheimhaltung. Wer muss der Verarbeitung über die KI-API zustimmen? | BauIn IT |
|
||
| Datenverarbeitung bei API-Werk (C2) | Standort, Speicherdauer, Auftragsverarbeitung, kein Training. Klärt ITM; wir brauchen nur das Ergebnis für die Doku | ITM |
|
||
| Alarmierung (E11.3) | Ohne E-Mail aus der Anwendung: über die Überwachung von ITM? | ITM |
|
||
|
||
Nach dem Livegang von Phase 1: Aufbewahrung nach Projektende (A27), Nutzung der DB-Richtlinien in
|
||
einem KI-System (A28).
|
||
|
||
## Entscheidungen
|
||
|
||
| Nr. | Frage | Vorschlag | Entschieden |
|
||
|---|---|---|---|
|
||
| E11.1 | Deployment | Skript auf dem Server mit Versionsverzeichnissen (`releases/`, `current`), ausgelöst per SSH | offen |
|
||
| E11.2 | Backup-Werkzeug | restic, verschlüsselt, Ziel von ITM | offen (B5) |
|
||
| E11.3 | Alarmierung | Die Anwendung verschickt keine E-Mails (B3). Vorschlag: Lebenszeichen und Prüfbefehle, die die Überwachung von ITM abfragt | offen (mit ITM) |
|
||
|
||
## Schritte
|
||
|
||
- [x] **11a.1** Server-Anforderungen `docs/server-anforderungen.md`
|
||
- [ ] **11a.2** Vorlagen in `deploy/`:
|
||
- Nginx-Server-Block, systemd-Units (Worker, Meilisearch), Cron-Zeile
|
||
- Beispiel für `.env` ohne Werte
|
||
- [ ] **11a.3** Deploy-Skript nach E11.1 mit Prüfungen (Migration, Caches, Neustart der Worker),
|
||
zuerst gegen eine lokale Test-VM oder direkt auf Staging
|
||
- [ ] **11a.4** Betriebsbefehle:
|
||
- Lebenszeichen für Worker und Scheduler
|
||
- Zählung fehlgeschlagener Jobs
|
||
- Statusprüfung der KI-API (aus AP3)
|
||
- Meldung bei Problemen nach E11.3
|
||
- [ ] **11b.1** Staging aufsetzen (ITM-Entwickler, KW 42–44), erstes Deployment gemeinsam
|
||
- [ ] **11a.5** Backup-Skript nach E11.2 und Betriebsdoku `docs/betrieb.md`:
|
||
- Deployment, Wiederherstellung, `APP_KEY` sicher aufbewahren
|
||
- [ ] **11b.2** Produktion aufsetzen (KW 50–51)
|
||
- [ ] **11a.6 / 11b.3** Restore-Test auf einem Ersatzsystem (KW 3), Protokoll in `docs/betrieb.md`
|
||
|
||
## Abnahmekriterien
|
||
|
||
- Ein Deployment aus dem Gitea auf Staging klappt mit einem Befehl.
|
||
- Ein absichtlich gestoppter Worker löst innerhalb von 10 Minuten einen Alarm aus (Weg nach E11.3).
|
||
- Der Restore-Test war erfolgreich und ist dokumentiert.
|
||
|
||
## Risiken
|
||
|
||
- Antworten von ITM zu Zugang und Ausstattung kommen spät. Dann Staging per Bildschirmfreigabe
|
||
gemeinsam aufsetzen.
|