Migrate all repos into monorepo context folders
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.
This commit is contained in:
@@ -0,0 +1,201 @@
|
||||
# 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)
|
||||
Reference in New Issue
Block a user