Remedy Trade
Remedy Trade entwirft, testet und betreibt systematische Handelsprozesse, bei denen Forschung, Ausführung, Monitoring und Risiko verbunden bleiben müssen. Die Infrastruktur hinter diesen Prozessen umfasst gewöhnliche Softwarethemen – Dienste, Datenbanken, Zertifikate, Logs und Deployments –, doch die Kosten einer unklaren Änderung sind höher, wenn Systeme auf Live-Märkte reagieren.
Die Ausgangslage
Abschnitt betitelt „Die Ausgangslage“Das Team verfügte bereits über leistungsfähige Ausführungs- und Forschungssysteme. Das Problem war die betriebliche Ebene um sie herum. Deployment von Diensten, Host-Zugriff, TLS, Datenbankkonnektivität, Monitoring und Vorfallreaktion verteilten sich auf verschiedene Werkzeuge und Konventionen. Ein Ingenieur konnte jede einzelne Frage beantworten, doch die vollständige Frage – was hat sich geändert, was hat es beeinflusst, waren Kunden oder Strategien betroffen und wie stellt man wieder her – erforderte manuelle Korrelation.
Remedy hatte zudem eine strenge architektonische Vorgabe: Die Verwaltungsanwendung durfte keine Laufzeitabhängigkeit für bereits laufende Strategien werden. War ein Dienst der Control Plane nicht verfügbar, mussten marktseitige Workloads und etablierte Routen weiter bedienen.
Einführung rund um den Ausführungs-Stack
Abschnitt betitelt „Einführung rund um den Ausführungs-Stack“Opfield wurde um die bestehende Handelsumgebung herum eingeführt, nicht durch sie hindurch. Die ersten verwalteten Ressourcen betrafen die Infrastruktur: Ingress, unterstützende Docker-Hosts, Monitoring-Signale und ausgewählte Dienstrouten. Forschungscode, Ausführungslogik und Marktanbindung blieben unverändert.
Der Rollout folgte vier Grenzen:
- Verwaltung ausgehend halten. Verwaltete Hosts bauten ihre Steuerverbindungen selbst auf. Der Rollout erforderte keine breiten eingehenden Verwaltungsports im Handelsnetz.
- Verfügbarkeit der Steuerung von Verfügbarkeit der Workloads trennen. Routen und laufende Dienste arbeiteten weiter, wenn Opfield selbst vorübergehend nicht verfügbar war. Die Control Plane koordinierte Änderungen, leitete aber gewöhnlichen Anwendungsverkehr nicht durch ihren Webprozess.
- Zustand verbinden, bevor Änderungen automatisiert werden. Das Team nutzte Opfield zuerst, um Inventar, Identitäten, Health-Zustand und Beziehungen herzustellen. Automatisierung kam erst, nachdem der sichtbare Zustand der Realität entsprach.
- Betrieb mit Scope anwenden. Routineaktionen wanderten in berechtigungsbewusste Abläufe. Änderungen mit großen Folgen erforderten weiterhin ausdrückliche Prüfung und Verifizierung durch einen Operator.
Was sich im täglichen Betrieb änderte
Abschnitt betitelt „Was sich im täglichen Betrieb änderte“Die Operatoren von Remedy verfolgen die Infrastruktur rund um einen Handelsdienst in einem Produkt. Sie gehen von einer öffentlichen Route zu ihrem Zertifikat, dem Upstream-Workload, dem Health-Zustand des Nodes, den jüngsten Logs und dem Operationsverlauf, ohne Namen zwischen unzusammenhängenden Dashboards übersetzen zu müssen.
Bei Vorfällen verringerte das die Versuchung, breite Änderungen vorzunehmen, bevor die Auswirkung verstanden war. Das Team konnte ein Problem der Control Plane von einem Ausführungsproblem unterscheiden, fehlerfreie Workloads an ihrem Platz lassen und Wartung oder Rollback nur auf dem betroffenen Pfad einsetzen. Observability wurde Teil des Betriebsablaufs statt eines Dashboards, das man nach dem Deployment prüft.
Dasselbe Modell verbesserte auch die Zugriffskontrolle. Wer an Anwendungen arbeitete, benötigte für routinemäßiges Deployment oder Diagnose keine uneingeschränkte Host-Administration, während die Infrastrukturverantwortlichen den Zugriff auf niedrigerer Ebene behielten, der für die Wiederherstellung nötig ist.
Ergebnis
Abschnitt betitelt „Ergebnis“Forschungscode, Ausführungslogik und Marktanbindung von Remedy blieben, wie sie waren. Deployment, Zugriff, Health-Zustand der Dienste, TLS, Logs und Wiederherstellung laufen jetzt in einem Produkt, und der Ausführungspfad hängt nicht davon ab, dass Opfield läuft.
„In der Handelsinfrastruktur können Deployment und Observability keine getrennten Themen sein. Opfield hält die betriebliche Ebene zusammen, ohne der Ausführung im Weg zu stehen.“
Das in dieser Umgebung verwendete Betriebsmodell finden Sie unter Produktionsreife und Incident-Runbook.