Für Banken, die Murex Mx.3 betreiben

Jede Murex-Umgebung.
Konsistent. Prüfbar. Unter Kontrolle.

MxENV3 verwaltet die Konfiguration aller Ihrer Mx.3-Umgebungen — Produktion, DR, UAT, SIT, DEV — als Code: ein Ort für jede Einstellung, Abweichungen auf einen Blick, Start und Stop jedes Mal in der richtigen Reihenfolge, und kein Passwort mehr in einer Konfigurationsdatei.

Demo anfragenSo funktioniert es
  • Läuft auf Ihren Hosts, ohne Agenten
  • Standard-Ansible-Inventory-Format
  • Bindet Ihren Vault an
mxenv matrix PROD UAT --diff-only
$ mxenv matrix PROD UAT --diff-only   VARIABLE            PROD                       UAT* db_financial_host   db-prod.example.com        db-uat.example.com* mx_app_dir          /appl/murex/mx3P01/mxenv   /appl/murex/mx3U01/mxenv* mx_domain           prod                       uat* mx_environment      MX3P01                     MX3U01* mx_secret_provider  infisical                  ansible-vault* mx_version          3.1.35r3l                  3.1.26 $ mxenv applyconfig PRODmxenv: refusing to applyconfig the PRODUCTION environment "PROD" without --iknowwhatimdoing

Was Ihr Murex-Team davon hat

Weniger Umgebungs-Incidents. Schnellere Umgebungsarbeit. Saubere Audits.

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 Stunden 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.

Audit-fähig von Haus aus

Konfiguration ist in Git versioniert, mit vollständiger Historie. Zugangsdaten bleiben in Ihrem Vault (CyberArk, Ansible Vault, Infisical) und werden erst beim Anwenden aufgelöst — nichts, was ein Prüfer in einem Skript finden könnte.

Der Alltag im Murex-Betrieb

Murex Mx.3 ist geschäftskritisch. Das Tooling um seine Umgebungen herum meist nicht.

Umgebungen driften auseinander

Zehn, zwanzig Umgebungen, über Jahre von Hand konfiguriert. Niemand kann sicher sagen, welche JVM-Einstellung oder welcher Datenbank-Host sich zwischen UAT und PROD unterscheidet — bis es darauf ankommt.

Start/Stop steckt in Köpfen

Welcher Service nach welchem kommt, worauf gewartet wird, welcher Host was fährt — kodiert in Shell-Skripten und der Erfahrung weniger Schlüsselpersonen. Urlaub und Fluktuation werden 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.

Wie MxENV3 hilft

Gebaut für die Art, wie Banken Murex tatsächlich betreiben.

MxENV3 steht neben Murex Mx.3 — es verändert die Anwendung nicht. Es übernimmt die Umgebungskonfiguration, ihre Konsistenz und die Orchestrierung drum herum.

Eine Quelle der Wahrheit für jede Umgebung

Bankweite Defaults einmal definiert, jede Umgebung überschreibt nur, was wirklich abweicht — Hosts, Datenbank, JVM-Optionen, Pfade. Eine neue Umgebung sind ein paar Zeilen, keine kopierte Tabellenspalte.

Start und Stop jedes Mal in der richtigen Reihenfolge

Services werden mit ihren Abhängigkeiten beschrieben; MxENV3 leitet die Startreihenfolge ab, fährt unabhängige Services parallel hoch und in umgekehrter Reihenfolge wieder herunter. Erst Dry-Run, dann Ausführung per SSH.

Murex-Upgrades ohne Konfigurations-Fork

Konfigurations-Templates und Service-Kataloge werden pro Murex-Version geführt. 3.1.26 in PROD und 3.1.35 in UAT ist Normalbetrieb, kein Sonderfall.

Ihr Vault bleibt der einzige Ort für Secrets

Templates referenzieren ein Secret per Name; der Wert wird beim Anwenden der Konfiguration aus Ihrem Vault geholt. Ansible Vault und Infisical heute, CyberArk auf der Roadmap — der Wechsel ist Konfiguration.

Produktion ist geschützt

Jedes Kommando, das eine Produktionsumgebung verändert, verweigert die Ausführung ohne ausdrückliche Bestätigung. Lesende Kommandos und Dry-Runs sind immer gefahrlos — auch für den Bereitschaftsdienst um 3 Uhr nachts.

Alle Umgebungen auf einen Blick

Eine Konfigurationsmatrix — jede Einstellung über jede Umgebung — als Tabelle, CSV oder hervorgehobener HTML-Report. Nur die Abweichungen zeigen, ans Change Management oder den Prüfer weitergeben.

So funktioniert es

Drei Schritte, kein neues proprietäres Format.

  1. 01

    Umgebungen beschreiben

    Jede Umgebung ist ein kleines Inventory im Standard-Ansible-Format: Server nach Murex-Rolle gruppiert (Session, Processing, XML-Server …) plus die Einstellungen, die von den bankweiten Defaults abweichen. Das Format kennt Ihr Team bereits.

  2. 02

    MxENV3 löst auf und vergleicht

    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.

  3. 03

    Planen, anwenden, starten, stoppen

    Konfigurationsdateien werden für die Murex-Version der Umgebung gerendert und ins Anwendungsverzeichnis übernommen. Services werden geplant und in Abhängigkeitsreihenfolge gestartet oder gestoppt — standardmäßig als Dry-Run, Ausführung auf Wunsch.

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.26/start.sh.tmpl
    3.1.35r3l/start.sh.tmpl

In der Praxis

Für Operatoren gemacht, nicht für Foliensätze.

Ein Kommandozeilenwerkzeug, skriptbar, Dry-Run zuerst. Ausgabe als Text, CSV oder HTML — dieselbe auf dem Jump-Host, im Change-Ticket und im Audit-Nachweis.

mxenv compare
$ 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 shell

Sicherheit & Compliance

Für regulierte Umgebungen entworfen.

Läuft vollständig auf Ihrer Infrastruktur

MxENV3 ist ein einzelnes, statisch kompiliertes Binary. Keine Agenten, kein Cloud-Dienst, keine ausgehenden Verbindungen — es läuft auf Ihrem Jump-Host oder direkt auf den Murex-Hosts, innerhalb Ihres Netzwerkperimeters.

Pro Bank lizenziert, transparent

Jedes ausgelieferte Binary wird für Ihr Institut gebaut, mit einkompilierter Lizenz und Laufzeit. Sie wissen jederzeit, was Sie betreiben und bis wann — kein Lizenzserver, kein Phone-Home.

Zugangsdaten 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.

Nachvollziehbar und prüfbar

Konfiguration liegt in Git: wer hat was, wann und warum geändert. Jedes Anwenden ist aus dem Repository reproduzierbar, jeder Umgebungsvergleich ein Report, den Sie an einen Change oder eine Prüfungsanfrage hängen können.

FAQ

Was Murex-Teams zuerst fragen

MxENV3 auf Ihren eigenen Umgebungen sehen.

Schicken Sie uns einen anonymisierten Überblick Ihrer Murex-Umgebungen — oder nur Anzahl und Versionen — und wir zeigen Ihnen in einer 45-Minuten-Session das resultierende Inventory, die Konfigurationsmatrix und einen Startplan.

Demo anfragen