DFK Algotrade

DFK Algotrade entwickelt Finanzsoftware und betreibt Systeme rund um Portfoliomanagement, Handel, Daten und Risiko. In diesem Umfeld zählt die Geschwindigkeit von Deployments, doch vorhersehbare Änderungen zählen mehr. Ein Update der Control Plane kann Zugriff, Routing, Anwendungsauslieferung, Datenbanken und die Fähigkeit des Teams beeinträchtigen, alles andere zu diagnostizieren.
Der Vorfall, der die Anforderung veränderte
Abschnitt betitelt „Der Vorfall, der die Anforderung veränderte“Das Team hatte zuvor eine Umgebung betrieben, in der ein automatisches Update von Coolify einen Produktionsausfall verursachte. Die Lehre daraus: Verfügbarkeit eines Releases, Freigabe eines Releases, Zeitpunkt des Rollouts, Datenkompatibilität und Belege für die Wiederherstellung sind unterschiedliche Entscheidungen.
Der Ausfall legte eine grundsätzlichere Schwäche im Betriebsmodell offen. Das Team konnte den Dienst wiederherstellen, doch der Release-Prozess begann nicht mit einer gemeinsamen Antwort auf mehrere Fragen: Welche genaue Version ist freigegeben? Welcher Zustand muss gesichert werden? Was würde ein Rollback auslösen? Welche kundenseitigen Pfade beweisen, dass das Update erfolgreich war? Welche Teile können unabhängig geändert werden?
DFK wollte die Kontrolle über jede Änderung an seiner Infrastruktur, nicht nur einen Update-Knopf.
Einführung rund um Release-Disziplin
Abschnitt betitelt „Einführung rund um Release-Disziplin“DFK wechselte zu Opfield zusammen mit einem Release-Verfahren, auf das sich Entwicklung und Betrieb geeinigt hatten.
- Erkennung von Freigabe trennen. Der gewählte Update-Kanal konnte eine verfügbare Version melden, ohne die laufende Installation zu ändern. Ein Operator wählte Ziel und Wartungsfenster.
- Die Eingaben für die Wiederherstellung festhalten. Vor der Änderung hielt das Team laufende Versionen und Image-Digests fest, prüfte Backups von PostgreSQL und persistentem Zustand und bewahrte Verschlüsselungs- und Identitätsmaterial.
- Nach Fehlerdomäne aktualisieren. Opfield, Relay-Mitglieder und verwaltete Nodes wurden nicht als ein gleichzeitiges Ereignis behandelt. Komponenten konnten geleert, aktualisiert, geprüft und wieder in Betrieb genommen werden, bevor es weiterging.
- Das echte System prüfen. Ein laufender Container galt nicht als Erfolg. Anmeldung, Entschlüsselung, erneute Verbindung der Nodes, Routen, Datenbank-Bindings, Logs, Automatisierung und externer Datenverkehr bildeten die Abschlusskriterien.
Signierte Releases und Daemon-Artefakte lassen keinen Zweifel daran, was installiert ist, und Tasks und Audit-Datensätze halten jede Entscheidung auch nach dem Ende des Wartungsfensters sichtbar.
Was sich über Updates hinaus änderte
Abschnitt betitelt „Was sich über Updates hinaus änderte“Dieselbe Disziplin verbesserte die gewöhnliche Anwendungsauslieferung. DFK konnte ein bekanntermaßen fehlerfreies Deployment behalten, wo sinnvoll Rollout-Wege mit Health Checks nutzen und Anwendungs-Rollback von Datenwiederherstellung unterscheiden. Operatoren neigten weniger dazu, Infrastruktur zu löschen oder neu zu erstellen, nur weil ein Deployment fehlgeschlagen war.
Auch die Beziehungen in der Infrastruktur wurden leichter nachvollziehbar. Finanzdienste, private Datenbankverbindungen, Routen, Zertifikate und der Health-Zustand der Hosts waren in der Release-Besprechung keine getrennten Fragmente mehr. Das Team konnte bestimmen, welche Ebene sich geändert hatte, und vermeiden, einen lokalen Fehler zu einem plattformweiten Vorfall zu eskalieren.
Ergebnis
Abschnitt betitelt „Ergebnis“Updates wurden zu geplanten betrieblichen Entscheidungen mit ausdrücklicher Zuständigkeit, Eingaben für die Wiederherstellung und Prüfung. DFK behielt die Kontrolle über den Zeitpunkt von Releases und erhielt zugleich einen klareren Weg, neue Opfield-Funktionen einzuführen, ohne dass der Release-Rhythmus des Herstellers Änderungen in der Produktion diktiert.
„Nachdem ein Update von Coolify eine Produktionsumgebung lahmgelegt hatte, haben wir aufgehört, automatische Updates als Bequemlichkeit zu betrachten. Opfield gibt uns einen Release-Prozess, den wir prüfen, planen und verifizieren können, bevor wir weitermachen.“
Die Verfahren hinter diesem Fall finden Sie unter Updates und Backups und Lebenszyklus und Sicherheit.