Legacy-Unterstützung
Wir bringen das Betriebsrisiko einer bestehenden Anwendung unter Kontrolle, bevor eine größere Modernisierung, Migration oder Funktionsentwicklung beginnt.
Eine ältere Anwendung ist nicht allein deshalb ein Problem, weil sie eine frühere PHP- oder Symfony-Version verwendet. In ihr stecken häufig gewachsene Geschäftsregeln, Ausnahmen und Integrationen: Bestellungen, Zahlungen, Rechnungen, Dokumente, Kundenkonten oder interne Freigaben. Kritisch wird es, wenn bei einem Vorfall niemand nachvollziehen kann, was geschehen ist, oder wenn ein Release den laufenden Betrieb gefährdet.
Stabilisierung schafft diese Kontrolle zurück. Sie verspricht keine fehlerfreie Anwendung. Sie senkt Wahrscheinlichkeit und Folgen von Störungen und sorgt dafür, dass sie erkannt, geordnet behandelt und vor der nächsten Änderung ausgewertet werden können.
Vor einem größeren Vorhaben unterscheiden wir drei Arten von Arbeit. Eine dringende Korrektur soll nicht unbemerkt zu einem unvorbereiteten Neubau werden; eine Modernisierung braucht ihrerseits einen verlässlichen Ausgangspunkt.
SOFORTSCHUTZ STABILISIERUNG MODERNISIERUNG
aktuellen Schaden begrenzen Betrieb beherrschbar machen für die Zukunft verändern
fehlerhafte Aktion stoppen Tests kritischer Abläufe PHP/Framework aktualisieren
offengelegtes Secret entfernen Monitoring und Statussicht Modul/Integration ersetzen
Doppelverarbeitung stoppen reproduzierbare Deployments API-Grenze oder Migration
WiederherstellungsverfahrenDie Übergänge sind nicht immer scharf, die Ziele aber verschieden. Sofortschutz begrenzt den Schaden. Stabilisierung macht das bestehende System verlässlich genug für den Betrieb. Danach lässt sich fundiert entscheiden, ob ein Modul aktualisiert, migriert, ersetzt oder unverändert behalten wird.
Zuerst betrachten wir die Abläufe, von denen der Alltag abhängt: Anmeldung und Berechtigungen, Checkout, Zahlungsbestätigung, Rechnungsstellung, Dokumentenprozesse, ERP-Importe, Benachrichtigungen und Hintergrundverarbeitung. Ein langsamer Bericht kann warten. Eine doppelte Belastung oder eine nicht auffindbare Rechnung muss rasch verstanden werden.
Bewertet werden die Auswirkungen auf Kunden und Mitarbeitende, die Häufigkeit, ein möglicher sicherer manueller Weg, die Abhängigkeit von Drittanbietern und die Schwierigkeit, den korrekten fachlichen Zustand wiederherzustellen. So entsteht eine sinnvolle Arbeitsreihenfolge statt einer Liste nach dem Alter des Codes.
Nehmen wir eine hypothetische Symfony-Anwendung, die Bestellungen und Zahlungen entgegennimmt, Rechnungen in einem Buchhaltungssystem auslöst, E-Mails versendet und ein Service-Backend bereitstellt. Dieses Beispiel beschreibt kein GiSoft-Kundenprojekt.
Bestellungen können korrekt angelegt werden, während Rechnungen nach einer Verlangsamung des externen Dienstes in der Queue hängen bleiben. Nach einem Deployment läuft ein Worker möglicherweise noch mit der vorherigen Version. Der Support sieht eine Beschwerde, kann aber nicht unterscheiden, ob die Rechnung nie erstellt wurde oder nur die Bestätigung ausblieb. Eine manuelle Wiederholung ohne Prüfung der Historie kann ein zweites Dokument erzeugen.
Darum klären wir zuerst den maßgeblichen Bestellstatus, das auslösende Ereignis für die Rechnungsstellung und den gespeicherten Verlauf jedes Versuchs. Anschließend wird der Ablauf gegen unbeabsichtigte Doppelverarbeitung geschützt und für das Betriebsteam nachvollziehbar gemacht.
Bestellung → Zahlungsbestätigung → gespeicherter Bestellstatus
│
▼
Hintergrundjob für Rechnung
│
┌───────────────┴───────────────┐
▼ ▼
bestätigtes Ergebnis Fehler oder Timeout
Status aktualisieren Versuch speichern + Monitoring
│
▼
sichere Wiederholung oder manuelle PrüfungEin Timeout beweist nicht, dass das Buchhaltungssystem nichts getan hat. Für eine Wiederholung zählen gespeicherter Zustand, Antwort des Anbieters, die Möglichkeit seinerseits nachzusehen und die Geschäftsregel. Wenn die externe Aktion bereits erfolgt sein kann, sind Prüfung oder Korrektur oft sicherer als ein automatischer Retry.
Eine sichere Wiederholung wiederholt dieselbe fachliche Aktion, ohne einen zweiten Effekt auszulösen. Eine stabile Kennung wie Bestellnummer oder Zahlungsanfrage-ID ist nützlich, garantiert aber noch keine Idempotenz.
Entscheidend sind die konkrete Umsetzung: dauerhaft gespeicherter Zustand, atomisches Prüfen und Anlegen, Umgang mit parallelen Anfragen, eindeutige Datenbankregeln und das Verhalten des externen Anbieters. Eine solide Integration erkennt frühere Versuche, liefert das bekannte Ergebnis oder leitet den Fall zur Prüfung weiter. Sie verdeckt Unsicherheit nicht mit unbegrenzten Wiederholungen.
Ein Server-Log reicht selten für jemanden, der einem Kunden Auskunft geben muss. Technisches Monitoring sollte Worker-Ausfälle, Antwortzeiten von Integrationen, Queues, langsame Abfragen und die ausgerollte Version zeigen. Eine operative Sicht sollte Geschäftsfall, Bearbeitungsstufe, Anzahl der Versuche, eine sichere Fehlerkategorie und den nächsten sinnvollen Schritt sichtbar machen.
Dafür müssen keine vollständigen Dokumente oder Kundennachrichten in Logs landen. Entscheidend ist die Verknüpfung einer Geschäftskennung mit den minimalen Informationen für Diagnose und Audit. Sensible Daten, Secrets und Daten anderer Organisationen gehören nicht ins Log, nur weil sie beim Debugging praktisch wären.
Charakterisierungstests beschreiben zunächst das vorhandene Verhalten, auch wenn der Code schwer zu ändern ist. Ein Stabilisierungsprojekt beginnt nicht mit Tausenden Tests. Zuerst sichern wir Fälle mit großen Folgen ab: Ein wiederholter Callback erzeugt keine zweite Belastung, ein unberechtigter Nutzer sieht keine Daten einer anderen Organisation, und eine fehlgeschlagene Rechnung bleibt sichtbar und wird nach einem festgelegten Verfahren behandelt.
Auch das Deployment ist Teil der Stabilisierung. Wir dokumentieren Konfiguration und Reihenfolge der Migrationen, prüfen Abhängigkeiten, halten die Version fest, bestätigen Worker-Neustarts und kontrollieren kritische Abläufe nach dem Release. Ein Rollback muss lokale Änderungen von externen Folgen trennen. Das Zurücksetzen von Code oder Migrationen holt keine gesendete E-Mail, keine bereits ausgeführte Zahlung und keinen an ein ERP übergebenen Vorgang zurück. Dafür braucht es einen geprüften Endzustand, eine Korrekturprozedur und klare Verantwortung.
Stabilisierung bedeutet nicht automatisch, Datenbank, SQL oder Integrationen auszutauschen. Zuerst wird die Ursache belegt. Eine langsame Kundenliste braucht vielleicht Paginierung, weniger geladene Daten oder nach einer Abfrageanalyse einen Index. Direktes SQL kann angemessen sein, wenn es verständlich, abgesichert und eindeutig verantwortet ist.
Bei Integrationen klären wir Timeouts, Antwortvalidierung, Webhook-Prüfung, Zugangsdaten, Zuständigkeiten und Fehlermeldungen. Sicherheit umfasst Authentifizierung, serverseitige Autorisierung, Rollen, Mandantentrennung, deaktivierte Konten, Administrationswege und die Ablage von Secrets. Einen Button auszublenden ist keine Zugriffskontrolle; der Server muss Berechtigungen selbst durchsetzen.
Wenn nur eine Person deployen, die Queue neu starten oder Daten nach einem Vorfall reparieren kann, hängt das Unternehmen an privatem Wissen statt an einem Verfahren. Runbooks, verantwortliche Personen für Integrationen, Zugriffsverfahren, Vorfallhistorie und kurze Übergaben gehören deshalb zur Stabilisierung.
GiSoft beginnt mit belastbaren Informationen: aktuellen Vorfällen, Support-Meldungen, Produktionsverhalten, Deployments, fehlgeschlagenen Jobs, Code und Abhängigkeiten. Daraus entstehen ein priorisiertes Risikobild, Schutz für die wichtigsten Abläufe, überprüfbare Änderungen und ein nächster Schritt. Das kann ein PHP- oder Framework-Upgrade, eine klarere Integrationsgrenze oder das bewusste Beibehalten eines stabilen Moduls sein.
Stabilisierung bewahrt nicht jede alte technische Entscheidung. Sie gibt dem Unternehmen genug Kontrolle, um die Anwendung sicherer zu betreiben und Modernisierung auf Grundlage von Fakten zu planen.