Bericht zum Architektur-Review

1. Management Summary

• Das System trägt die heutige Last. Sobald sich die Zahl der Kunden verdoppelt, werden das Reporting und der Bestellprozess jedoch voraussichtlich zum Engpass.
• Die dringendsten Risiken liegen bei Sicherheit und Betriebskontinuität: Die Datenbank-Backups wurden nie mit einer Wiederherstellung getestet, und das Admin-Panel ist für jeden erreichbar.
• Eine Neuentwicklung ist nicht nötig. Empfohlen wird, den bestehenden Monolithen in Module aufzuteilen und ihn über 6 Monate Schritt für Schritt zu härten.

2. Umfang und Vorgehen

Dauer

5 Arbeitstage

Geprüft

Codebasis der Hauptanwendung (~120.000 Zeilen), Datenbankschema, Server- und Deployment-Infrastruktur

Interviews

4 Gespräche mit dem Tech Lead, zwei Entwicklern und der Betriebsleitung

Werkzeuge

Code-Review, Abfragepläne (EXPLAIN ANALYZE), Abhängigkeits- und Sicherheitsscans, Lastprofiling

3. Befunde

Nach Auswirkung und Dringlichkeit sortiert.

1. #1KritischKontinuitätGeschätzter Aufwand: 1 Tag

   Es werden täglich Backups erstellt, aber nie mit einer Wiederherstellung getestet; die Backups liegen auf demselben Server.

   Auswirkung: Bei einem Plattendefekt gingen die Daten und die Backups gleichzeitig verloren.

   Empfehlung: Backups an einen separaten Ort auslagern und monatlich einen Wiederherstellungstest durchführen.

2. #2KritischSicherheitGeschätzter Aufwand: 2 Tage

   Das Admin-Panel ist aus dem Internet erreichbar, ohne Zwei-Faktor-Authentifizierung und ohne Begrenzung der Anmeldeversuche.

   Auswirkung: Ein Brute-Force-Angriff könnte Zugriff auf sämtliche Kundendaten verschaffen.

   Empfehlung: Das Panel hinter ein VPN oder eine IP-Beschränkung legen und 2FA sowie Rate Limiting ergänzen.

3. #3HochPerformanceGeschätzter Aufwand: 3 Tage

   Die Abfrage für den Monatsbericht durchsucht eine Tabelle ohne Index vollständig (im Schnitt 38 s).

   Auswirkung: Während der Bericht läuft, werden die Bestellmasken langsam.

   Empfehlung: Zwei zusammengesetzte Indizes; der Bericht liest aus einer nachts vorbereiteten Übersichtstabelle.

4. #4HochArchitekturGeschätzter Aufwand: 4–6 Wochen

   Der Code für Bestellung, Lager und Abrechnung schreibt direkt in die Tabellen der jeweils anderen Bereiche.

   Auswirkung: Eine Änderung in einem Modul bricht die anderen; neue Features werden immer langsamer.

   Empfehlung: Modulgrenzen festlegen und die Kommunikation zwischen den Modulen über eine einzige Serviceschicht führen.

5. #5MittelWartungGeschätzter Aufwand: 2 Wochen

   Das Framework liegt zwei Hauptversionen zurück; 14 Abhängigkeiten haben bekannte Sicherheitslücken.

   Auswirkung: Sicherheitsupdates lassen sich nicht einspielen, und das Upgrade wird mit jedem Monat schwieriger.

   Empfehlung: Zuerst die Abhängigkeiten aktualisieren, dann das Framework Version für Version.

6. #6MittelTeamGeschätzter Aufwand: 2–3 Wochen

   Die automatisierte Testabdeckung liegt bei 8 %; das Deployment erfolgt manuell und hängt an einer Person.

   Auswirkung: Ist diese Person nicht da, kann nichts live gehen; Fehler bemerken die Kunden.

   Empfehlung: E2E-Tests für die kritischen Abläufe und eine automatisierte Deployment-Pipeline.

4. Zielarchitektur

• Es bleibt eine einzige Anwendung (modularer Monolith); Bestellung, Lager, Abrechnung und Reporting sind getrennte Module.
• Das Reporting liest aus Übersichtstabellen, die die Hauptdatenbank nicht belasten.
• Das Admin-Panel liegt im internen Netz; das Deployment ist automatisiert und lässt sich zurückrollen.

5. Migrationsplan

1. Erste 30 Tage

   Risiken schließen

   • Backups und Wiederherstellungstest
   • Absicherung des Admin-Panels
   • Beschleunigung der Berichtsabfrage

2. 1–3 Monate

   Fundament härten

   • Upgrade von Abhängigkeiten und Framework
   • Tests für die kritischen Abläufe
   • Automatisierte Deployment-Pipeline

3. 3–6 Monate

   In Module aufteilen

   • Trennung der Module Bestellung und Lager
   • Abrechnung in die Serviceschicht überführen
   • Architekturdokumentation und Übergabe an das Team