ankn
a5f8fb49ab
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
202 lines
7.5 KiB
Markdown
202 lines
7.5 KiB
Markdown
# Runbook-Analyse — pathOS Architekturdokumentation
|
|
|
|
> Quelle: Runbook (arc42-Format), ~346KB, Stand April 2026
|
|
> Analyse: 2026-04-22
|
|
|
|
---
|
|
|
|
## 1. Qualitaetsziele (Priorisiert)
|
|
|
|
| Prio | Ziel | Beschreibung |
|
|
|------|------|-------------|
|
|
| 1 | Diskriminierungsverbot | Gleichbehandlung DB-eigener und externer EVU (Performance, Verfuegbarkeit, Funktionalitaet) |
|
|
| 2 | 24/7 Verfuegbarkeit | Unternehmenskritische Anwendung (UKA) mit SL1 (Gold), auch ausserhalb Geschaeftszeiten |
|
|
| 3 | Interoperabilitaet | Kompatibel mit TAF/TAP TSI Standard und RNE Common Interface |
|
|
| 4 | Mandantenfaehigkeit | Strikte Datentrennung nach Kundennummern |
|
|
| 5 | Unveraenderbarkeit | Kundenauftraege nachvollziehbar und unveraenderbar |
|
|
| 6 | Fehlertoleranz | Automatische Reaktion auf HW/SW-Fehler |
|
|
| 7 | Kapazitaet | Genuegend Kapazitaet fuer Netzfahrplan-Deadlines |
|
|
| 8 | Ressourcenverbrauch | Effiziente Nutzung, dynamische Skalierung |
|
|
| 9 | Bedienbarkeit | Effizient fuer Power-User |
|
|
| 10 | Erlernbarkeit | Leicht fuer Gelegenheitsnutzer |
|
|
|
|
## 2. Service Levels
|
|
|
|
| Umgebung | Service Level | Verfuegbarkeit | RTO |
|
|
|----------|--------------|----------------|-----|
|
|
| Produktion | DB Silber (ab 03/2026), Silber Plus (ab 08/2026) | 99.38% / 99.73% | 6h |
|
|
| WGK-Ausweich | DB Bronze Plus | 98.90% | 24h |
|
|
| Sonstige | DB Bronze | 98.75% | 24h |
|
|
|
|
## 3. Subdomaenen-Architektur
|
|
|
|
Das System ist in 4 Subdomaenen zerlegt:
|
|
|
|
### TAF/TAP Schnittstellen (Team Zero)
|
|
- Common Interface (SOAP/XML, Mutual SSL)
|
|
- TAF/TAP TDM Konverter
|
|
- Partnerverwaltung, Zertifikatsverwaltung
|
|
|
|
### Bestellportal (Team 404)
|
|
- Portal UI (Angular)
|
|
- Portal Middleware (Spring Boot)
|
|
- Entwuerfe und Vorlagen
|
|
|
|
### Prozesse (Team CIB)
|
|
- Steuerung Vertrieb (Camunda 8, BPMN)
|
|
- IFP Connector
|
|
- Archivierungsservice
|
|
|
|
### Backend (Team CIB/Zero)
|
|
- Auftrags-Verwaltung-Trasse
|
|
- Kundendaten-Bereitstellung
|
|
- Stammdaten-Bereitstellung
|
|
- Rabattnummern-Bereitstellung
|
|
- Vertragsdaten-Verteiler
|
|
|
|
## 4. Teams (aus Runbook bestaetigt)
|
|
|
|
| Team | Verantwortung | Schwerpunkt |
|
|
|------|--------------|-------------|
|
|
| Team Zero | TAF/TAP Schnittstellen, Stammdaten | Common Interface, Stammdaten-Bereitstellung |
|
|
| Team 404 | Bestellportal | Portal UI, Portal Middleware |
|
|
| Team CIB | Prozesse, Backend | Steuerung Vertrieb, Auftrags-Verwaltung |
|
|
| Team STeam | Infrastruktur, DevOps, Security | CI/CD, Deployment, Keycloak, Monitoring |
|
|
| Team BSSUPPORT | Support | 2nd Level Support |
|
|
|
|
## 5. Umgebungslandschaft (17+ Umgebungen!)
|
|
|
|
### DEV Stage
|
|
- BU (Build-Umgebungen) — temporaer, pro MR
|
|
- EU/BASE-* (Review) — temporaer, pro MR
|
|
- Demo — dauerhaft, manuelle Tests
|
|
- BASE-AT (Integrationstest) — temporaer, pro MR
|
|
- LUP (Last & Performance) — temporaer
|
|
- IEU (Integrierte Entwicklung) — dauerhaft, auto-deploy bei Master-Merge
|
|
- SIT (Systemintegration) — dauerhaft, manuelles Deployment
|
|
- SIT2 — dauerhaft, automatisiert
|
|
|
|
### ABN Stage
|
|
- E2E (TTT-ITU1) — dauerhaft, TTT-abgestimmt
|
|
- SAT1 (Alarm ITU) — dauerhaft, Hotfix-Tests
|
|
- SAT2 (Release ITU) — dauerhaft, Feature-Release-Tests
|
|
- SAT3 — dauerhaft, LuP/Pentest/DRT
|
|
- ABN1 (TTT-KTU) — dauerhaft, Kundentests mit EVUs
|
|
- ABN2 (Release ABN) — dauerhaft, TTT-E2E
|
|
- ABN4 — dauerhaft, Alarm-Patches
|
|
- ABN8 — dauerhaft, EVU-Integrationstests
|
|
- PREPROD — dauerhaft, Sondertests mit Fahrplan-IT
|
|
|
|
### PROD Stage
|
|
- PROD — Produktionsumgebung
|
|
|
|
**Erkenntnis**: 17+ Umgebungen erklaeren die Deployment-Komplexitaet!
|
|
|
|
## 6. Externe Schnittstellen (detailliert)
|
|
|
|
| Name | Technologie | Auth | SLA |
|
|
|------|------------|------|-----|
|
|
| EVU-Eingang | SOAP/XML | Mutual SSL (RNE-Zertifikate) | SL1 |
|
|
| EVU-Ausgang | SOAP/XML | Mutual SSL | SL1 |
|
|
| Portal-App | HTML5/REST | JWT (OIDC) | SL1 |
|
|
| IM Stammdaten | REST/JSON | JWT, Client-ID/Secret | SL3+ |
|
|
| Benutzer-Auth | OpenID Connect | Benutzername/Passwort | SL1 |
|
|
| NuR-Service | REST/JSON | Entra ID Client-Credential | SL3 |
|
|
| KDV (CRM) | REST/JSON | Basic-Auth | SL3 |
|
|
| NVN-Tool | REST/JSON | Basic-Auth + JSON Token | SL3 |
|
|
| TPN Produktionsauftraege | AWS MSK (Kafka) | IAM:Role | SL1 |
|
|
| TPN Vertriebsauftraege | AWS MSK (Kafka) | IAM:Role | SL1 |
|
|
| AC Trasse Archiv | REST/JSON | BizHub ClientID/Secret | SL3 |
|
|
| Stammdaten extern | REST/JSON | Keine Auth | SL1 |
|
|
| BEP | REST/JSON | BizHub ClientID/Secret | SL3 |
|
|
| Stationsportal | AWS MSK (Kafka) | IAM:Role | SL1 |
|
|
| TBV | AWS MSK (Kafka) | IAM:Role | SL1 |
|
|
|
|
## 7. Kafka-Topologie
|
|
|
|
### Interne Topics (25+)
|
|
Wichtigste Datenfluesse:
|
|
- eingangsnachricht: TTK/PMW → SV, Archivierungsservice
|
|
- versandauftrag: SV → TTK, PMW
|
|
- versandergebnis: CI/TTK → SV
|
|
- auftragsverwaltung: SV → AV, TBV-Konverter, Archivierungsservice
|
|
- produktionsauftrag-to-connector: SV → IFP-Connector
|
|
- vertriebsauftrag-to-sv: IFP-Connector → SV
|
|
- process-eingangsnachricht: SV → SV (Camunda)
|
|
- camunda-events: Camunda Zeebe → SV
|
|
- vertragsdaten-to-stationsportal: VDV → Stationsportal
|
|
|
|
### Kafka-Cluster (12+)
|
|
- bsz-dev (IEU, SIT, Demo)
|
|
- bsz-dev-e2e (E2E)
|
|
- bsz-dev-2 (SIT, SIT2)
|
|
- bsz-abn-abn1, abn2, sat1, sat2, sat3, abn8, preprod
|
|
- bsz-prod
|
|
|
|
## 8. Datenbank-Architektur
|
|
|
|
### Produktions-Setup (3 separate Cluster!)
|
|
- bsz-prod-production: Alle ausser SV, IFP, AV, PMW (db.m6gd.large, 200GB)
|
|
- bsz-prod-production-avt: AV + PMW (db.m6gd.large, 200GB)
|
|
- bsz-prod-production-sv: SV + IFP-Connector (db.m6gd.large, 200GB)
|
|
|
|
**Erkenntnis**: DB-Split nach Performance-Anforderungen (SV und AV sind die lastintensivsten)
|
|
|
|
### Persistenz-Strategie
|
|
- Shared-Nothing: Jede Anwendung eigene DB
|
|
- TAF/TAP-Daten als JSON/XML BLOBs (nicht relationales Modell!)
|
|
- Flyway fuer Migrationen
|
|
- Append-Only fuer Kundenauftraege (Unveraenderbarkeit)
|
|
|
|
## 9. Sicherheitsarchitektur
|
|
|
|
### Authentifizierung
|
|
- Portal: DB WebSSO (OIDC) via SIPS Access Proxy + NuR
|
|
- Common Interface: Mutual SSL mit RNE-Zertifikaten
|
|
- Intern: Keycloak (Test), Entra ID (Prod)
|
|
- Kafka: AWS IAM Roles
|
|
- DB: Technische User pro Anwendung (DML only)
|
|
|
|
### Verschluesselung
|
|
- TLS ueberall (ISGW → ALB → App)
|
|
- Data-at-Rest: AWS-managed Encryption
|
|
- Secrets: age + sops + Helm Secrets Plugin
|
|
|
|
### Mandantentrennung
|
|
- Basierend auf Kundennummern
|
|
- Alle Zugriffe gefiltert nach Berechtigungen
|
|
- Backend-seitige Validierung (Browser nicht vertrauenswuerdig)
|
|
|
|
## 10. Bekannte Technische Schulden (aus Runbook)
|
|
|
|
| Kategorie | Problem | Massnahme |
|
|
|-----------|---------|-----------|
|
|
| TAF/TAP TSI | Veraltete Technologie (SOAP, unvollstaendige Specs) | CI als Adapter |
|
|
| AppMesh | AWS EOL, CNP arbeitet an Alternative | O2CBS-555 |
|
|
| CI/CD Pipelines | Zu komplex (pipeship + CNB) | Vereinfachungen |
|
|
|
|
## 11. Offene Punkte / Risiken (aus Runbook)
|
|
|
|
- Common Interface: SOAP als Altlast, bidirektionale async Kommunikation fragil
|
|
- Stammdaten: Performance-Probleme beim Strecken-Import (zu viele kleinteilige API-Calls)
|
|
- Portal-Middleware: Haeufige Schnittstellenaenderungen von SV und AV
|
|
- Kundendaten/Rabattdaten: Koennen kurzzeitig veraltet sein (akzeptiert)
|
|
- Performance: Keine systematische Performance-Messung bei mehreren Services
|
|
- Click&Ride: Anbindungsdetails noch nicht geklaert
|
|
- BEP: Anbindung noch in Arbeit
|
|
|
|
## 12. Architecture Decision Records (75 ADRs!)
|
|
|
|
Wichtigste aktive ADRs:
|
|
- ADR-29: Internes Datenmodell TDM
|
|
- ADR-35: Zugriffskontrolle interne Schnittstellen
|
|
- ADR-36: Trennung Build/Deployment Pipelines
|
|
- ADR-53: Hybride Anbindung Eingangskaenaele
|
|
- ADR-56: CI an Backend ueber Kafka (In Arbeit)
|
|
- ADR-58: Deployment und Release
|
|
- ADR-61: Signieren von Nachrichten
|
|
- ADR-63: Camunda 8 als Workflow Engine
|
|
- ADR-70: Weiterentwicklung Testvorgehen (In Arbeit)
|
|
- ADR-72: Click&Ride Anbindung (In Arbeit)
|
|
- ADR-74: TrassenPortal Anbindung (In Arbeit)
|