Bauen, ausrollen, betreiben — Murex-MX.3-Umgebungen aus einem CLI, von DEV bis PROD
Environment as Code
für Murex® MX.3™.
Jede MX.3-Umgebung — PROD, DR, UAT, SIT, DEV, on-premises oder in der Cloud — wird in Git beschrieben statt von Hand konfiguriert. Darauf laufen EOD, Batch, Health-Checks und Housekeeping. Dasselbe Kommando, dasselbe Ergebnis, überall.
- Ein Go-Binary, keine Agenten
- Standard-Ansible-Inventory-Format
- Bindet Ihren Vault an
- Ihr Inventory bleibt Ihres — Standard-YAML
$ mxenv matrix PROD UAT --diff-only VARIABLE PROD UAT[Identity]* mx_environment MX3P01 MX3U01[Murex]* mx_version 3.1.69.3 3.1.69.5[Database]* db_financial_host db-prod.example.com db-uat.example.com[Secrets]* mx_secret_provider infisical ansible-vault $ mxenv mxcheck PROD --json{"status":"OK","checks":{"fileserver":{"status":"OK","response_ms":12},"middleware":{"status":"OK","answered":"9/9"}, "usersessions":{"status":"OK","sessions":143,"users":87},"openfiles":{"status":"OK"}},"exit":0}Was Ihr Murex-Team davon hat
Weniger Incidents, kürzere Vorlaufzeiten, Audits, die durchgehen.
Kein stilles Auseinanderdriften mehr
Ein Kommando zeigt jede Einstellung, die sich zwischen PROD und UAT unterscheidet — bevor daraus ein Incident im Batch oder ein gescheitertes Release-Wochenende wird.
Umgebungsarbeit in Minuten statt Tagen
Neue Umgebung, Refresh, Murex-Versionswechsel: ein paar Zeilen im Inventory ändern, rendern, anwenden. Das Wissen liegt im Repository, nicht im Kopf eines einzelnen Engineers.
Nachweise statt Behauptungen
Konfiguration ist in Git versioniert, mit vollständiger Historie. Secrets bleiben in Ihrem Vault (CyberArk, Ansible Vault, Infisical) und werden erst beim Anwenden aufgelöst. Was in Git versioniert ist, lässt sich belegen; was ein Skript zur Laufzeit zusammensetzt, nicht.
Tooling, das Sie nicht erst bauen müssen
Sie starten DevOps und CI/CD für Murex nicht mit einem leeren Playbook. MxENV3 ist eine Basis, die seit 1998 im Bankbetrieb läuft. Ihr Team baut eigene Playbooks und Pipelines darauf — statt Umgebungen, Startreihenfolgen und Checks noch einmal zu erfinden.
Seit 1998
Achtundzwanzig Jahre Murex-Betrieb. 2026 von Grund auf neu geschrieben.
Das Rewrite von 2026 trägt dasselbe Betriebswissen über jede Generation von MxGeneration 2000 bis MX.3 — auf neuem Fundament: ein in Go kompiliertes Binary, Standard-Inventory, Vault-Anbindung, Produktionsschutz. Wo früher ein Perl-Baum mit rund 250 Modulen auf jedem Murex-Host installiert und über Jahre gepflegt werden musste, liegt heute eine einzige Datei. Keine Interpreter-Version, keine Abhängigkeiten, kein Compiler auf dem Server. Kopieren und ausführen. Ein Aufruf kostet Millisekunden CPU-Zeit statt einer halben Sekunde und weniger als die Hälfte des Speichers; das Rendern braucht pro Konfigurationsdatei rund 30× weniger CPU.
Auch die Messwerte sind kein Zusatz von heute: Die Perl-Generation konnte sie pro Kommando nach InfluxDB schreiben — optional, und in Teilen abgeschaltet. Im Rewrite ist der Export Standard und immer an.
Gemessen auf identischer Hardware gegen das Perl-Vorgängertool, zehn Läufe je Fall: Kommandostart 4 bis 5 ms CPU und ~24 MB statt ~520 ms und ~54 MB; applyconfig mit 880 Dateien ~60 ms und ~40 MB statt ~2,2 s und ~89 MB. Die Werte gelten für das ausgelieferte Produktions-Binary. Start und Stop von Services sind nicht Teil der Messung.
- erste Version im Produktivbetrieb
- 1998
- komplettes Rewrite als MxENV3
- 2026
- statt eines Perl-Baums mit ~250 Modulen, der auf jedem Host installiert und gepflegt werden musste
- 1 Go-Binary
- abgedeckte Murex-Generationen
- MxG2000 → MX.3
Der Alltag im Murex-Betrieb
MX.3 ist geschäftskritisch. Das Tooling, das es am Laufen hält, auch — es steht nur in keinem Anwendungskatalog.
Umgebungen driften auseinander
Typisch sind 30 bis 50 Umgebungen, und die DEV- und Testumgebungen werden regelmäßig neu aufgesetzt. Jeder Refresh ist eine Gelegenheit, anders zu konfigurieren als zuvor: Die Unterschiede entstehen in Wochen, nicht in Jahren. Welche JVM-Einstellung oder welcher Datenbank-Host inzwischen von PROD abweicht, weiß niemand sicher — bis es darauf ankommt.
Tausende Jobdefinitionen, von Hand gepflegt
Ein EOD sind tausende Scheduler-Jobs, und jede Umgebung hält ihre eigene Kopie. Host, User, Pfad, Parameter, Wartebedingungen und Fehlerbehandlung stecken in Shell-Skripten und in den Köpfen weniger Schlüsselpersonen. Urlaub und Fluktuation werden damit zum Betriebsrisiko.
Zugangsdaten in Skripten
Datenbank- und Admin-Passwörter in Startskripten und Konfigurationstabellen sind ein wiederkehrender Audit-Befund — und eine reale Sicherheitslücke auf jedem Host, auf den sie kopiert werden.
Warum zuerst das Umgebungsmanagement
Environment as Code ist das Fundament für Continuous Delivery auf Murex.
Eine Murex-Plattform steht nie still: Patches, Releases, neues Geschäft, Upgrades. Jedes davon braucht schnell produktionsnahe Umgebungen — für belastbare QA, für Tester, die testen statt Umgebungen zu reparieren, für die kleinen häufigen Deployments eines DevOps-Modells. Die Umgebungen unter Kontrolle zu bringen ist keine Nebenaufgabe, sondern der erste Schritt.
Die Größenordnung des Problems, aus einer realen MX.3-Installation einer großen europäischen Bank
- Konfigurationsdateien im Anwendungsverzeichnis (~50 GB)
- 4.045
- davon umgebungsspezifisch, in einer Hierarchie mit Querabhängigkeiten
- 306
- Produktion plus PAT-, UAT- und DEV-Umgebungen, die produktionsnah bleiben müssen
- 1 + 36
Ohne MxENV3
- Umgebungen aus Tabellen und Eigenbau-Skripten zusammengesetzt — langsam, teuer, fehleranfällig
- Lange Vorlaufzeiten, häufige Neubauten, wenn etwas vergessen wurde
- Eigenbau-Skripte, die niemand anfassen will; Wissen bei wenigen Externen konzentriert
- Unterschiede zwischen Umgebungen fallen in der Produktion oder am Release-Wochenende auf
- Jede Bank baut ihr Tooling selbst — dieselben Probleme, immer wieder von vorn gelöst
Mit MxENV3
- Umgebungen aus einem zentralen, versionierten Repository erzeugt — reproduzierbar in Minuten
- Anpassbare Templates pro Murex-Version, jedes Mal gleich angewandt
- Standardformat, ein Binary, dokumentierte Kommandos — das Wissen liegt im Repository
- Unterschiede auf Knopfdruck sichtbar — vor dem Release-Wochenende
- Eine erprobte Basis, die Sie mit eigenen Playbooks und Pipelines erweitern — statt Murex-Tooling von Grund auf zu bauen
Die beiden Alternativen, die jede Bank prüft
Selbst bauen?
Praktisch jede Bank mit Murex hat dieses Projekt mindestens einmal begonnen. Dort verschwinden die Jahre an Entwicklungsarbeit: im Murex-spezifischen Teil — Service-Abhängigkeiten und Startreihenfolge, Versionsunterschiede, Batch- und Processing-Skripte, Health-Checks, Housekeeping, Produktionsschutz. Das generische Playbook drum herum ist nicht der Aufwand. MxENV3 liefert genau diesen Teil und bleibt erweiterbar: Standard-Ansible-Inventory, skriptbare Kommandos, Ihre Playbooks und Pipelines setzen darauf auf.
Ihr Integrator behält seine Rolle
Die meisten Banken kommen an diesen Punkt mit einem Partner, der Umgebungs-Tooling auf Tagessatzbasis bauen könnte. Dieses Werkzeug gehört danach Ihnen — als Wartungslast, gepflegt für einen einzigen Kunden, und das Wissen geht mit dem Team. MxENV3 ist ein lizenziertes Produkt, das über alle Installationen hinweg gepflegt wird; Ihr Partner arbeitet darauf. Ihr Budget fließt in Ihre Fachlichkeit statt in Version 1 eines Werkzeugs, das es schon gibt. Beratungshäuser und Systemintegratoren sprechen uns für eine Partnerschaft gern direkt an.
Wie MxENV3 hilft
Gebaut für die Art, wie Banken Murex tatsächlich betreiben.
MxENV3 steht neben Murex MX.3 und verändert die Anwendung nicht. Es beschreibt die Umgebung, hält sie konsistent und orchestriert, was um MX.3 herum läuft.
Klare Grenzen
Was MxENV3 nicht ist.
MxENV3 patcht, installiert und aktualisiert MX.3 nicht selbst, berührt keine Geschäfts- oder Marktdaten und ersetzt weder die herstellerseitigen Installations- und Administrationswerkzeuge noch Ihren Scheduler, Ihr Monitoring oder Ihre CI/CD. Es verwaltet das Drumherum: Umgebungskonfiguration, Service-Orchestrierung, Batch-Ausführung und die Betriebsroutine über 30 bis 50 Umgebungen. Auf einer von uns noch nicht validierten Murex-Version bricht das Anwenden der Konfiguration mit --strict ab, statt zu raten.
Gebaut für den Betrieb, nicht nur fürs Bauen
EOD, Checks und Housekeeping — auf PROD mit denselben Kommandos wie auf UAT.
Zuverlässige Testumgebungen sind die eine Hälfte. Die andere ist der Betrieb: dieselben Kommandos, dasselbe Inventory, dasselbe Error-Handling auf der Produktion wie auf UAT. Der Bereitschaftsdienst sieht nachts kein Skript zum ersten Mal.
Ein Kommando, jede Umgebung
Heute verfügbarOb PROD, DR oder die fünfte UAT: runprocessingscript, mxcheck, housekeeping oder start lesen alles Nötige aus dem Inventory der Umgebung. Keine umgebungsspezifischen Skripte, kein Copy-Paste zwischen Hosts, keine Überraschungen, wenn der DR-Standort wirklich gebraucht wird.
Tausende EOD-Jobs, zuverlässig gesteuert
Heute verfügbarJedes Processing-Skript, jedes Makro und jeder Ant-Task liefert ein konsolidiertes Ergebnis: Status, Laufzeit, aufgefangene Logs und die geparste Murex-Antwort. Der Scheduler verzweigt auf Fakten statt auf einen Shell-Exit-Code. Dieselbe Job-Definition läuft auf jeder Umgebung, weil Host, User, Pfad und Parameter aus dem Inventory kommen.
Scheduler-Jobs aus einer Tabelle erzeugt
Heute verfügbarDie EOD-Kette wird einmal als Tabelle gepflegt. MxENV3 erzeugt daraus die AutoSys-Jobdefinitionen (JIL) mit den richtigen Hosts, Usern, Pfaden und Datumsbedingungen je Umgebung. Dieselbe Kette in PROD und UAT, ohne hunderte Jobdefinitionen einzeln zu pflegen; der Weg zurück von JIL in die Tabelle ist ebenso möglich. Weitere Scheduler richten wir auf Anfrage ein.
EOD-Alarmierung an die eingetragene Bereitschaft
Heute verfügbarBricht ein EOD-Job ab, sammelt MxENV3 den Log-Auszug des Jobs und schickt ein Servicedesk-Ticket per Mail, dazu optional eine SMS über das Mail-Gateway. Wer Bereitschaft hat, trägt sich vorher im Bereitschaftsplan ein; das Ticket geht an diese Person. Transport und Textbausteine kommen aus dem Inventory.
Laufzeitvergleich über Nächte
Roadmap — in MxENV seit den frühen 2000ern bewährtDen heutigen EOD-Lauf gegen die Laufzeiten der Vornächte stellen, Ausreißer je Schritt sichtbar machen und Zeitreihen aus dem Scheduler übernehmen. Diese Auswertungen hat MxENV jahrelang getragen; sie werden auf dem neuen Fundament neu aufgebaut.
Alles mit „Heute verfügbar“ ist im aktuellen MxENV3-Release enthalten. Roadmap-Punkte sind MxENV-Fähigkeiten, die auf dem neuen Fundament neu entstehen; fragen Sie in der Demo nach dem aktuellen Stand.
Day-2-Betriebs-Toolkit
Was Ihr Scheduler nachts aufruft: ein Kommando statt eines Dutzends Eigenbau-Skripte.
Dasselbe Binary trägt die Routinen, die sonst in einem Dutzend Shell-Skripten leben. Jedes Kommando liest das Inventory, holt Secrets aus Ihrem Vault und beherrscht Dry-Run. Für den Scheduler geschrieben: konsistentes Logging, aussagekräftige Exit-Codes, echtes Error-Handling.
Health-Checks
mxcheck prüft Fileserver, Middleware, User-Sessions und offene Dateien; jeder Service muss antworten, verglichen mit einem Soll-Snapshot. Status und Metriken kommen als JSON oder Text, mit Exit-Codes für den Scheduler und Schwellwerten aus dem Inventory.
Oracle-SQL gegen die richtige Datenbank
runsql führt Queries, DML, DDL und PL/SQL per sqlplus gegen financial, datamart, MLC oder VaR aus. Die Verbindung kommt aus dem Inventory, das Passwort aus Ihrem Vault. Dazu Dry-Run, CSV/JSON-Ausgabe und Fail-fast-Batches.
Murex-Jobs mit einem konsolidierten Ergebnis
runant, runmacro und runprocessingscript rufen Murex-Skripte auf und liefern Kommando, Host, Laufzeit, Logs und die geparste Murex-Antwort als ein JSON — für den Scheduler und als Nachweis.
Housekeeping und Archivierung
Altersbasierte Archivierung in verifizierte tar.gz und anschließende Bereinigung, gesteuert über Presets im Inventory: Logs, GC-Logs, Core-Dumps, datierte Exporte. Erst Dry-Run, dann auf einem Host oder allen.
Diagnose
Business-Datum gegen heute prüfen, JVM-Heap pro Host mit Schwellwerten, MXML-Tasks und Middleware-Ping gegen einen git-versionierten Soll-Snapshot. Dazu Purge über eine Node-Allow-List und Ad-hoc-Kommandos auf eine ganze Rolle.
Kennzahlen für Ihr Monitoring
Jeder Lauf kann seine Kennzahlen per OpenTelemetry an Ihr Monitoring schicken: Laufzeit, CPU- und IO-Zeit, Speicher-Spitzenwerte, Fehler- und Warnungszähler, je Umgebung, Skript, Host und Status. Fällt der Empfänger aus, läuft der Job trotzdem weiter.
Ein Kontrakt für jeden Scheduler
Jedes Kommando folgt einem Vertrag: Exit-Code 0/1/2/3 (OK / WARNING / ERROR / UNKNOWN), Ergebnis auf stdout, Status auf stderr, JSON auf Wunsch. Job-Schritte verzweigen darauf. Niemand muss ein Log lesen, um das Ergebnis zu kennen. Die Job-Generierung ist für einige Scheduler implementiert, heute AutoSys (JIL); weitere richten wir jederzeit auf Anfrage ein.
Zentraler Inventory-Server
Ein optionaler Server pro Domäne (TLS und Token) liefert das git-versionierte Inventory an schlanke Clients. Er synchronisiert versionsspezifische Templates per Prüfsumme und kann Jobs stellvertretend ausführen. Clients aktualisieren sich von ihm selbst.
Sichere Abfolgen
wait und waitforfile blockieren mit Timeout und Exit-Code, bis ein Service antwortet oder eine Datei erscheint. Batch-Ketten raten nicht mehr mit sleep.
So funktioniert es
Drei Schritte, kein neues proprietäres Format.
- 01
Umgebungen beschreiben
Jede Umgebung ist ein kleines Inventory im Standard-Ansible-Format. Server sind nach Murex-Rolle gruppiert (Session, Processing, XML-Server …), dazu die Einstellungen, die von den bankweiten Defaults abweichen. Das Format kennt Ihr Team bereits.
- 02
Werte auflösen und vergleichen
Defaults, Umgebungs-, Rollen- und Host-Einstellungen werden zur wirksamen Konfiguration zusammengeführt. Einen Wert abfragen, zwei Umgebungen vergleichen, die volle Matrix rendern — immer mit klarer Antwort, welcher Wert wo gilt.
- 03
Planen, anwenden, betreiben
Konfigurationsdateien werden für die Murex-Version der Umgebung gerendert und ins Anwendungsverzeichnis übernommen. EOD-Schritte, Checks, Housekeeping und Service-Orchestrierung laufen aus demselben Inventory. Standardmäßig Dry-Run, Ausführung auf Wunsch, mit Exit-Codes, auf die Ihr Scheduler verzweigt.
inventory/
group_vars/all.yaml # global defaults
PROD/
hosts.yaml # servers grouped by Murex role
group_vars/all.yaml # PROD overrides only
UAT/
services/
fs.yaml
xmls.yaml # after: [fs]
mxsession.yaml # after: [mandatory, rtbs]
templates/
3.1.69.3/start.sh.tmpl
3.1.69.5/start.sh.tmpl
3.1.69.5-frtb/start.sh.tmpl # project go-live = a version tooIn der Praxis
Für Operatoren gebaut: skriptbar, erst Dry-Run.
Ausgabe als Text, CSV oder HTML — dieselbe auf dem Jump-Host, im Change-Ticket und im Audit-Nachweis.
$ mxenv listPROD prod PROD ProductionUAT uat SAMPLE UAT $ mxenv get PROD db_financial_hostdb-prod.example.com $ mxenv compare PROD UAT db_financial_hostdb_financial_host db-prod.example.com db-uat.example.com * $ eval "$(mxenv export PROD --shell)"# MX_ENVIRONMENT, MX_HOME, DB_FINANCIAL_HOST … now in your shellMurex MX.3 in der Private oder Public Cloud
Der Cloud-Business-Case trägt erst, wenn Umgebungen Code sind.
MxENV3 arbeitet in der Cloud genau wie auf klassischen Hosts — die Maschinen stehen nur woanders. Private Cloud im eigenen Rechenzentrum oder Public Cloud: dasselbe Inventory, dieselben Kommandos. In der Cloud zahlt sich das doppelt aus, weil Vorlaufzeit und Rechnung an der Nutzung hängen.
Umgebungen auf Abruf
Heute verfügbarEine neue SIT- oder Projektumgebung ist ein Inventory-Eintrag plus applyconfig und start — reproduzierbar, in Minuten statt Tagen, identisch zur letzten. Kein wochenlanges Warten auf eine handgebaute Umgebung mehr.
Non-Production abschalten — und wieder an
Heute verfügbarAbhängigkeitsbewusstes Starten und Stoppen macht es gefahrlos, UAT, SIT und DEV über Nacht und am Wochenende herunterzufahren und vor Tagesbeginn wieder hochzuziehen. Cloud-Kosten folgen der Nutzung, nicht dem Kalender.
Dasselbe Inventory für Infrastructure as Code
Heute verfügbarDas Inventory-Format ist Standard-Ansible und fügt sich in die IaC-Toolchain ein, die Ihr Cloud-Team ohnehin betreibt: Playbooks, Pipelines, Review in Git. MxENV3 ersetzt Ihr Plattform-Tooling nicht. Es bringt das Murex-Wissen hinein.
Inventory aus Ihrer Cloud erzeugt
RoadmapNächstes Modul: das Umgebungs-Inventory aus Cloud-Tags und Terraform-State ableiten, damit eine frisch provisionierte MX.3-Topologie MxENV3 bekannt ist, ohne dass jemand Hostnamen tippt.
Nicht der Zielfall: Wird MX.3 für Sie als Managed Service betrieben, liegt der Umgebungsbetrieb dort. MxENV3 ist für Banken, die MX.3 selbst betreiben — on-premises, in einer Private Cloud oder in ihrer eigenen Public Cloud.
Observability
Ihr Monitoring, nicht noch eines.
mxenv schickt seine Messwerte als Standard-OTLP/HTTP an den Empfänger, den Sie schon haben. Läuft bei Ihnen Datadog, Splunk, Dynatrace, Grafana Alloy oder ein OpenTelemetry-Collector, ist nichts zu installieren — eine Zeile Konfiguration, und die Daten landen dort, wo Ihr Betrieb ohnehin hinschaut.
Jeder Aufruf misst sich selbst
Es gibt nichts zu instrumentieren. Jedes mxenv-Kommando erfasst seine Laufzeiten und Ergebnisse selbst und gibt sie beim Beenden ab — die EOD-Kette, die ein Scheduler um zwei Uhr nachts startet, ein Housekeeping-Lauf, ein Health-Check, ein Konfigurations-Rollout. Keine Wrapper-Skripte, kein separater Monitoring-Job, der nachgezogen werden muss, und keine Umgebung, die still dunkel bleibt, weil jemand vergessen hat, sie einzutragen.
Und weil das seit dem ersten Tag für jeden Aufruf gilt, sehen Sie nicht die Momentaufnahme von heute, sondern Monate: welche Umgebung langsamer wird, welcher Job wächst, was sich nach dem letzten Release verändert hat. Langfristige Trends sind der Teil, den niemand von Hand aufbaut — und der Teil, der zeigt, woher das nächste Problem kommt.
Was gemessen wird
Pro Lauf: Dauer, die Elapsed-, CPU- und IO-Zeiten aus der Murex-Antwort, Spitzen- und Arbeitsspeicher, Fehler- und Warnungszähler.
Jedes Health-Kommando exportiert dauerhaft, ohne dass man an einen Schalter denken muss: seinen Status auf der gewohnten Nagios-Skala und die Messwerte darunter — JVM-Heap, Fileserver-Antwortzeit, Murex-Sessions und angemeldete Nutzer, offene Dateien, MXML-Warteschlangen.
Hostnamen stehen in den Labels, nicht in den Metriknamen. Das ist der Unterschied zwischen Zeitreihen, die man über dreißig Umgebungen aggregieren kann, und zehntausend Einzelmetriken, die man nur noch anschaut.
Nicht nur, wie der Prozess lief — was Murex getan hat
Laufzeiten und Health-Checks beschreiben die Maschine. Die Zahlen, die im Morgenmeeting eines Handelsbereichs zählen, kommen aus Murex selbst, und mxenv erhebt sie als eigene Kommandos: Handelsvolumen (live, dead, heute gebucht), Tiefe der MxML-Workflow-Queues, live und validierte MLC-Limit-Engines pro Pattern, Purge- und Archiv-Statistiken als Entscheidungsgrundlage fürs Housekeeping, Core-Dumps über alle Hosts mit klassifizierter Absturzart, und die Antwortzeiten des Client-Performance-Robots für Login, Trade Query, eTradePad und MLC-Preview.
Ein Beispiel dafür, was das Rewrite verändert hat: Queue-Tiefen brauchten früher einen Aufruf pro Queue, und jeder Aufruf bedeutete einen vollen Durchlauf des schweren Workflow-Joins. Heute liefert eine einzige Abfrage alle Queues.
Das gesamte Murex-SQL steckt im eingebauten Schema-Adapter — Schemaunterschiede eines Kunden sind damit Inventory-Konfiguration und kein neues Release. Und `mxenv adapter verify` beweist jede Abfrage und jede schreibende Anweisung gegen Ihre Datenbank, bevor sie in die Produktion geht: SELECTs laufen lesend und enden mit einem Rollback, schreibende werden per EXPLAIN PLAN übersetzt und nie ausgeführt.
Zusammen gelesen sind diese beiden der eigentliche Punkt: die Kurve steigt tagelang, bevor etwas ausfällt. Das ist der Unterschied zwischen einem Wartungsfenster, das Sie planen, und einer Nacht am Telefon.
Telemetrie bricht keinen Lauf ab
Ein nicht erreichbarer Empfänger ist eine Warnung auf stderr, nie ein fehlgeschlagener Job — der Export ist ausdrücklich fail-open. Und ohne konfigurierten Endpunkt findet überhaupt kein Netzwerkverkehr statt: kein Phone-Home, keine Voreinstellung, die nach außen zeigt.
Optional, für Demos und Bewertungen
Wer es sehen will, bevor ein Endpunkt steht, bekommt einen fertigen Prometheus-und-Grafana-Stack mitgeliefert: eigenes Playbook, eigene Dienste und Ports, auf localhost gebunden, restlos entfernbar. Er ersetzt Ihr bestehendes Monitoring nicht und rührt es nicht an. Für abgeschottete Netze lassen sich die Artefakte vorab bereitstellen, mit verankerten Prüfsummen.
Sicherheit & Compliance
Entworfen für Banken, die jede Änderung belegen müssen.
Läuft vollständig auf Ihrer Infrastruktur
MxENV3 ist ein einzelnes, statisch in Go kompiliertes Binary. Keine Agenten auf den Murex-Hosts, kein Cloud-Dienst, keine Verbindung zu uns. Es läuft auf Ihrem Jump-Host oder direkt auf den Murex-Hosts und führt über Ansible und SSH aus, was Ihr Plattform-Team ohnehin einsetzt. Ein optionaler zentraler Inventory-Server (TLS, Token) bleibt in Ihrem Netz.
Pro Institut lizenziert — kein Lizenzserver, kein Phone-Home
Jedes ausgelieferte Binary wird für Ihr Institut gebaut, mit einkompilierter Lizenzlaufzeit und Version. Sie wissen jederzeit, was Sie betreiben und bis wann. Nichts telefoniert aus Ihrem Netz hinaus.
Secrets verlassen Ihren Vault nie
MxENV3 speichert keine Secrets. Passwörter werden per Name referenziert und beim Anwenden aus Ihrem Vault aufgelöst — Repository, Inventory und gerenderte Dateien enthalten sie konstruktionsbedingt nie im Klartext.
Nachweisbar, nicht nur nachvollziehbar
Konfiguration liegt in Git: wer hat was, wann und warum geändert. Auf Knopfdruck vergleicht MxENV3 die gerenderte Konfiguration mit den tatsächlich ausgelieferten Dateien auf den Hosts und meldet Abweichungen und fehlende Dateien. Damit belegen Sie einem Prüfer, dass die Umgebung dem Repository entspricht, statt es zu behaupten.
Sollten wir verschwinden, laufen Ihre Umgebungen weiter
MxENV3 hat keine Laufzeitabhängigkeit von uns: kein Lizenzserver, kein Phone-Home, keine Cloud-Komponente. Ihr Inventory ist einfaches YAML in Ihrem Git, die gerenderte Konfiguration sind einfache Dateien auf Ihren Hosts — beides bleibt ohne das Binary lesbar und nutzbar. Source-Code-Escrow bei einem europäischen Treuhänder und eine Fallback-Lizenz vereinbaren wir auf Wunsch; Unterlagen für Ihre Drittparteien-Risikoprüfung stellen wir bereit.
Wirtschaftlichkeit
Der Business Case, den Sie selbst rechnen können.
Vier Zahlen entscheiden: Personentage je Umgebungsaufbau und Refresh, multipliziert mit den Rebuilds pro Jahr; verlorene Stunden je Incident aus einer unentdeckten Abweichung zwischen PROD und UAT; Testtage, die verloren gehen, während eine Umgebung repariert statt genutzt wird; und in der Cloud die Non-Production-Rechenleistung, die nachts und an Wochenenden bezahlt wird. Das Rechenblatt bringen wir in die Fachsession mit und füllen es mit Ihren Zahlen. Die Lizenz ist jährlich, pro Institut, und skaliert mit der Zahl der gleichzeitig laufenden Umgebungen.
FAQ
Was Murex-Teams zuerst fragen
MxENV3 auf Ihren eigenen Umgebungen sehen.
Schicken Sie uns einen anonymisierten Überblick Ihrer Murex-Umgebungen, oder auch nur Anzahl und Versionen. In 45 Minuten zeigen wir Ihnen das resultierende Inventory, die Konfigurationsmatrix und einen Startplan. Kein Zugriff auf Ihre Systeme nötig.
Danach können Sie auf einer Nicht-Produktionsumgebung selbst testen: Die Evaluierung beginnt mit ausschließlich lesenden Kommandos — Konfigurationsmatrix, Umgebungsvergleich, Drift-Abgleich gegen die ausgelieferten Dateien. Geschrieben wird erst, wenn Sie es freigeben.
Beides ohne Formular herunterladbar — zum Weiterleiten an Fachbereich, Sicherheit und Einkauf.