MLOps auf Azure: Vom Experiment zur Produktion in 8 Wochen

Die meisten Machine-Learning-Modelle erreichen nie die Produktion. Diejenigen, die es schaffen, degradieren oft unbemerkt, weil niemand die Infrastruktur für Monitoring, Retraining und Redeployment aufgebaut hat. MLOps — die Disziplin der ML-Operationalisierung — schließt diese Lücke.

Dieser Leitfaden stellt einen praxiserprobten 8-Wochen-Fahrplan für produktionsreifes MLOps auf Azure vor, basierend auf Mustern, die wir bei mehreren Enterprise-Kunden umgesetzt haben.

Warum 8 Wochen?

Acht Wochen sind nicht willkürlich. Es ist der kürzeste Zeitraum, der solides Fundament ermöglicht, ohne Abkürzungen zu nehmen, die technische Schulden erzeugen. Teams, die auf zwei Wochen komprimieren, enden mit fragilen Pipelines, die beim ersten Modell-Update brechen. Teams, die sechs Monate brauchen, verlieren das organisatorische Momentum.

Der 8-Wochen-Plan setzt ein Team von 2–3 ML-Engineers mit Azure-Erfahrung voraus sowie ein bestehendes Modell, das in Notebooks validiert wurde.

Woche 1–2: Fundament — Azure ML Workspace und Versionskontrolle

Azure ML Workspace einrichten

• Ressourcengruppen-Struktur: Separate Ressourcengruppen für Dev, Staging und Produktion. Jede mit eigenem Azure ML Workspace.
• Compute: Compute Instances für die Entwicklung, Compute Clusters für Training, Managed Online Endpoints für Inferenz.
• Netzwerk: Private Endpoints für Workspace, Storage Account und Container Registry. Kein öffentlicher Internetzugang zu Trainingsdaten oder Modellartefakten.

Versionskontrolle etablieren

Jedes Artefakt muss versioniert und nachvollziehbar sein:

• Code: Git-Repository mit Branching-Strategie (wir empfehlen Trunk-Based Development für ML)
• Daten: Azure ML Data Assets mit Versionierung. Nie direkte Storage-Pfade im Trainingscode referenzieren.
• Umgebungen: Conda- oder pip-Requirements-Dateien, eingecheckt in die Versionskontrolle. Azure ML Curated Environments als Basis verwenden und erweitern.
• Modelle: Azure ML Model Registry ab Tag eins. Jedes trainierte Modell bekommt eine Version, verknüpft mit Trainingsrun, Dataset-Version und Code-Commit.

Entscheidende Praxis: Wenn Sie ein Produktionsmodell nicht bis zu den exakten Daten, dem Code und der Umgebung zurückverfolgen können, die es erzeugt haben, haben Sie kein MLOps — Sie haben organisiertes Chaos.

Woche 3–4: Training-Pipelines

Azure ML Pipelines

Notebook-basiertes Training durch reproduzierbare, parametrisierte Pipelines ersetzen:

• Pipeline-Komponenten: Training in diskrete Schritte zerlegen — Datenvorbereitung, Feature Engineering, Training, Evaluierung, Registrierung. Jeder Schritt ist eine wiederverwendbare Komponente.
• Parametrisierung: Hyperparameter, Dataset-Versionen und Compute-Targets als Pipeline-Parameter definieren, nicht als hartcodierte Werte.
• Compute-Skalierung: Compute Clusters mit Auto-Scaling verwenden (min. Knoten = 0), um Kosten für ungenutztes Compute zu vermeiden. Spot-Instanzen können Trainingskosten um 60–80 % senken.

Pipeline-Struktur

Datenvorbereitung → Feature Engineering → Training → Evaluierung → Registrierung (bei bestandenen Metriken)

Der Evaluierungsschritt ist entscheidend. Go/No-Go-Metriken vor dem Pipeline-Aufbau definieren:

• Mindest-Schwellenwert für Accuracy/F1/AUC zur Modellregistrierung
• Performance-Vergleich gegen das aktuelle Produktionsmodell
• Datenqualitätsprüfungen — Schema-Validierung, Null-Raten, Verteilungsdrift

Automatisierte Trigger

• Zeitplanbasiert: Wöchentlich oder monatlich nach festem Rhythmus neu trainieren
• Datengetrieben: Retraining auslösen, wenn neue Daten in der Bronze-Schicht landen (Azure Event Grid + ML Pipeline Trigger)
• Driftgetrieben: Auslösen, wenn Monitoring Daten- oder Vorhersagedrift über Schwellenwerte hinaus erkennt

Woche 5: Feature Store

Ein Feature Store eliminiert die häufigste Ursache für Training-Serving-Skew: Features, die in Notebooks anders berechnet werden als in der Produktion.

Azure ML Managed Feature Store

• Feature Sets: Features als wiederverwendbare Transformationen definieren und im Feature Store registrieren
• Materialisierung: Features werden vorberechnet und für Training (Offline Store) und Inferenz (Online Store) gespeichert
• Point-in-Time-Korrektheit: Der Feature Store übernimmt temporale Joins automatisch und verhindert Data Leakage im Training

Wann lohnt sich ein Feature Store?

• Sie haben 3+ Modelle, die gemeinsame Features nutzen
• Features erfordern komplexe Transformationen (Aggregationen, Window Functions, Joins über Datenquellen)
• Sie hatten bereits Training-Serving-Skew — das Modell verhält sich in Produktion anders als in der Evaluierung

Bei einem einzelnen Modell mit einfachen Features fügt ein Feature Store Komplexität ohne proportionalen Nutzen hinzu. Starten Sie mit gut strukturierten Pipeline-Komponenten und migrieren Sie zum Feature Store, wenn der Bedarf offensichtlich wird.

Woche 6: Modell-Deployment und A/B-Testing

Managed Online Endpoints

Azure MLs Managed Online Endpoints übernehmen die Infrastruktur für Echtzeit-Inferenz:

• Blue/Green Deployment: Eine neue Modellversion neben der bestehenden deployen. Einen Prozentsatz des Traffics auf die neue Version leiten.
• Traffic-Splitting: Mit 10 % Traffic auf das neue Modell starten. Fehlerraten, Latenz und Business-Metriken überwachen. Bei gesunden Metriken schrittweise auf 100 % erhöhen.
• Auto-Scaling: Skalierungsregeln basierend auf CPU-Auslastung oder Request-Anzahl konfigurieren. Minimum-Replicas setzen, um Baseline-Traffic ohne Cold Starts abzufangen.

Deployment-Checkliste

Bevor ein Modell in Produktion geht:

• Modell im Azure ML Registry registriert mit verlinktem Trainingsrun
• Inferenz-Code mit repräsentativen Eingaben getestet
• Endpoint Health Probe konfiguriert
• Skalierungsregeln unter Last validiert
• Rollback-Verfahren dokumentiert und getestet
• Logging erfasst Input-Features, Vorhersagen und Latenz

Batch-Deployment

Für nicht-echtzeitkritische Workloads (Millionen Datensätze über Nacht scoren) Batch Endpoints verwenden:

• Kosteneffizient: Low-Priority Compute nutzen
• Parallelisiert: Azure ML übernimmt die Verteilung auf Knoten
• Ausgabe in Storage: Ergebnisse direkt in Blob Storage oder Data Lake schreiben

Woche 7: Monitoring und Drift-Erkennung

Deployment ohne Monitoring ist ein Risiko. Modelle degradieren — die Frage ist, ob man es vor oder nach der geschäftlichen Auswirkung erkennt.

Was überwachen?

Azure ML Monitoring einrichten

• Data Collection auf Managed Endpoints aktivieren, um Input-Features und Vorhersagen zu erfassen
• Data Drift Monitors konfigurieren, die Produktions-Input-Verteilungen mit Trainingsdaten vergleichen
• Azure Monitor Alerts für Endpoint-Health-Metriken einrichten
• Monitoring-Dashboard in Azure Dashboards oder Grafana erstellen, das ML- und Betriebsmetriken kombiniert

Praxistipp: Nicht auf alles alertieren. Mit drei Signalen beginnen, die direkt mit geschäftlicher Auswirkung korrelieren. Monitoring-Breite ausbauen, nachdem das Team operationelle Routine aufgebaut hat.

Woche 8: CI/CD und Betriebsbereitschaft

CI/CD für ML

ML-Pipelines in den bestehenden DevOps-Workflow integrieren:

• CI (bei Pull Request): Code linten, Unit Tests für Pipeline-Komponenten ausführen, Umgebungsabhängigkeiten validieren, schnelle Trainings-Pipeline auf Daten-Sample laufen lassen
• CD (bei Merge auf main): Vollständige Trainings-Pipeline ausführen, auf Staging deployen, Integrationstests durchführen, mit Traffic-Splitting in Produktion überführen

Azure DevOps oder GitHub Actions mit Azure ML CLI v2 Extension verwenden. Pipelines als YAML definieren, nicht über die UI — das stellt Reproduzierbarkeit und Code Review sicher.

Betriebshandbücher

Diese Verfahren vor dem Go-live dokumentieren:

• Modell-Rollback: Wie in unter 5 Minuten auf die vorherige Modellversion zurückgesetzt wird
• Notfall-Modell-Deaktivierung: Wie ML-basierte Features deaktiviert und auf regelbasierte Logik zurückgefallen wird
• Retraining-Fehler: Was passiert, wenn eine geplante Retraining-Pipeline fehlschlägt? Wer wird benachrichtigt? Wie sieht das SLA für die Untersuchung aus?
• Drift-Reaktion: Wenn Drift erkannt wird, wie sieht der Eskalationspfad aus?

Team-Verantwortlichkeiten

Wie Erfolg aussieht

Nach 8 Wochen sollten Sie haben:

• Automatisierte Trainings-Pipelines, ausgelöst durch Zeitplan oder Datenänderungen
• Ein Model Registry mit vollständiger Lineage von Daten bis Produktion
• Managed Endpoints mit Blue/Green Deployment und Auto-Scaling
• Monitoring-Dashboards mit Drift-Erkennung und Alerting
• CI/CD-Pipelines, die Modelländerungen wie jede andere Software testen und deployen

Das ist nicht das Ende — es ist das Fundament. Von hier aus können Sie fortgeschrittene Funktionen hinzufügen: Online-Experimentation-Frameworks, Champion/Challenger-Testing und Multi-Modell-Orchestrierung.

Bereit, Ihr MLOps-Fundament aufzubauen? Kontaktieren Sie uns — wir beschleunigen Ihr Team strukturiert und risikoarm von Notebooks zur produktionsreifen ML-Plattform.