Machine Learning-Vorgänge
In diesem Artikel werden drei Azure-Architekturen für Machine Learning- Operations beschrieben, die durchgängige fortlaufende Integration und CI/CD-Pipelines (Continuous Delivery) und Umschulungspipelinen aufweisen. Die Architekturen sind für diese KI-Anwendungen:
- Klassisches maschinelles Lernen
- Maschinelles Sehen (CV)
- Verarbeitung natürlicher Sprache
Diese Architekturen sind das Produkt des MLOps v2-Projekts. Sie beinhalten bewährte Methoden, die Lösungsarchitekten im Entwicklungsprozess verschiedener Lösungen für maschinelles Lernen identifiziert haben. Das Ergebnis ist verfügbar, wiederholbar und wartbares Muster. Alle drei Architekturen verwenden den Azure Machine Learning-Dienst.
Eine Implementierung mit Beispielbereitstellungsvorlagen für MLOps v2 finden Sie unter Azure MLOps v2 GitHub-Repository.
Mögliche Anwendungsfälle
Klassisches maschinelles Lernen: Zeitreihenprognose, Regression und Klassifizierung in tabellarischen strukturierten Daten sind die häufigsten Anwendungsfälle in dieser Kategorie. Beispiele:
Binäre und Multibeschriftungsklassifizierung
Linear, Polynomial, Ridge, Lasso, Quantile und Bayesian-Regression
ARIMA, autoregressive, SARIMA, VAR, SES, LSTM
CV: Das in diesem Artikel vorgestellte MLOps-Framework konzentriert sich hauptsächlich auf die CV-Anwendungsfälle der Segmentierung und Bildklassifizierung.
Verarbeitung natürlicher Sprachen: Sie können dieses MLOps-Framework verwenden, um Folgendes zu implementieren:
Erkennung benannter Entitäten:
Textklassifizierung
Textgenerierung
Stimmungsanalyse
Sprachübersetzung
Fragen und Antworten
Zusammenfassung
Satzerkennung
Spracherkennung
Satzteilmarkierung
KI-Simulationen, Deep Reinforcement Learning und andere Formen der KI werden in diesem Artikel nicht beschrieben.
Aufbau
Das Architekturmuster MLOps v2 verfügt über vier hauptmodulare Komponenten oder Phasen des MLOps-Lebenszyklus:
- Datenbestand
- Verwaltung und Einrichtung
- Modellentwicklung oder die innere Schleifenphase
- Modellimplementierung oder die Phase der äußeren Schleife
Die vorhergehenden Komponenten, die Verbindungen zwischen ihnen und die typischen beteiligten Personas sind in allen MLOps v2-Szenarioarchitekturen Standard. Abweichungen in den Details der einzelnen Komponenten können je nach Szenario unterschiedlich sein.
Die Basisarchitektur für MLOps v2 für Machine Learning ist das klassische Machine Learning-Szenario für tabellarische Daten. Die CV- und NLP-Architekturen basieren auf dieser Basisarchitektur und ändern diese Basisarchitektur.
MLOps v2 behandelt die folgenden Architekturen, die in diesem Artikel beschrieben werden:
- Klassische Azure Machine Learning-Architektur
- CV-Architektur für Machine Learning
- Architektur der logistischen Datenverarbeitung für maschinelles Lernen
Klassische Machine Learning-Architektur
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow für die klassische Machine Learning-Architektur
Datenbestand
Diese Komponente veranschaulicht den Datenbestand der Organisation und potenzielle Datenquellen und -ziele für ein Data Science-Projekt. Datentechniker sind die primären Besitzer dieser Komponente des MLOps v2-Lebenszyklus. Die Azure-Datenplattformen in diesem Diagramm sind weder vollständig noch präskriptiv. Ein grünes Häkchen kennzeichnet die Datenquellen und -ziele, die empfohlene Best Practices darstellen, die auf dem Anwendungsfall des Kunden basieren.
Verwaltung und Einrichtung
Diese Komponente ist der erste Schritt in der MLOps v2-Lösungsbereitstellung. Es besteht aus allen Aufgaben im Zusammenhang mit der Erstellung und Verwaltung von Ressourcen und Rollen, die dem Projekt zugeordnet sind. Beispielsweise kann das Infrastrukturteam:
- Projekt-Quellcode-Repositorys erstellen.
- Verwenden Sie Bicep oder Terraform, um Machine Learning-Arbeitsbereiche zu erstellen.
- Erstellen oder Ändern von Datasets und Computeressourcen für die Modellentwicklung und -bereitstellung.
- Definieren von Projektteambenutzern, deren Rollen und Zugriffssteuerelementen für andere Ressourcen
- Erstellen von CI/CD-Pipelines.
- Erstellen Sie Überwachungskomponenten zum Sammeln und Erstellen von Warnungen für Modell- und Infrastrukturmetriken.
Die primäre Person, die mit dieser Phase in Verbindung steht, ist das Infrastrukturteam, aber eine Organisation kann auch Dateningenieure, Ingenieure für maschinelles Lernen oder Datenwissenschaftler haben.
Modellentwicklung (innere Schleifenphase)
Die innere Schleifenphase besteht aus seinem iterativen Data Science-Workflow, der innerhalb eines dedizierten und sicheren Machine Learning-Arbeitsbereichs fungiert. Das vorangehende Diagramm zeigt einen typischen Workflow. Der Prozess beginnt mit der Datenaufnahme, geht über explorative Datenanalyse, Experimente, Modellentwicklung und -bewertung und registriert dann ein Modell für den Produktionseinsatz. Diese modulare Komponente ist agnostisch und kann an den Prozess angepasst werden, den Ihr Data Science-Team zur Entwicklung von Modellen verwendet.
Personas, die dieser Phase zugeordnet sind, umfassen Datenwissenschaftler und Machine Learning-Techniker.
Machine Learning-Registrierungen
Nachdem das Data Science-Team ein Modell entwickelt hat, das es in der Produktion einsetzen kann, registriert es das Modell im Machine Learning-Arbeitsbereichsregister. CI-Pipelines, die entweder automatisch durch die Modellregistrierung oder durch die Genehmigung von Menschen in der Schleife ausgelöst werden, fördern das Modell und alle anderen Modellabhängigkeiten an die Modellbereitstellungsphase.
Personas, die dieser Phase zugeordnet sind, sind in der Regel Machine Learning-Techniker.
Modellimplementierung (äußere Schleifenphase)
Die Modellimplementierung oder äußere Schleifenphase besteht aus vorproduktivem Staging und Tests, der Produktionsbereitstellung und der Überwachung von Modell, Daten und Infrastruktur. Wenn das Modell die Kriterien der Organisation und des Anwendungsfalls erfüllt, fördern CD-Pipelines das Modell und die zugehörigen Assets durch Produktion, Überwachung und mögliche Neuschulung.
Personas, die dieser Phase zugeordnet sind, sind in erster Linie Machine Learning-Techniker.
Staging und Test
Die Staging- und Testphase variiert je nach Kundenpraxis. Diese Staging- und Testphase kann sich je nach Kundenpraktiken unterscheiden, umfasst in der Regel Vorgänge wie die Umschulung und Prüfung des Modellkandidaten auf Produktionsdaten, Testbereitstellungen für Endpunktleistung, Datenqualitätsprüfungen, Komponententests und verantwortungsvolle KI-Prüfungen für Modell- und Datenverzerrungen. Diese Phase erfolgt in einem oder mehreren dedizierten und sicheren Machine Learning-Arbeitsbereichen.
Produktionsbereitstellung
Nachdem ein Modell die Staging- und Testphase durchlaufen hat, können Machine-Learning-Ingenieure es mithilfe einer „Human-in-the-Loop“-Genehmigung in die Produktion überführen. Zu den Optionen für die Modellbereitstellung gehören ein verwalteter Batchendpunkt für Batchszenarien oder ein verwalteter Onlineendpunkt oder eine Kubernetes-Bereitstellung, die Azure Arc für Onlineszenarien nahezu in Echtzeit verwendet. Die Produktion erfolgt normalerweise in einem oder mehreren dedizierten und sicheren Machine-Learning-Arbeitsbereichen.
Überwachung
Ingenieure für maschinelles Lernen überwachen Komponenten in der Bereitstellung, beim Testen und in der Produktion, um Metriken im Zusammenhang mit Leistungsänderungen des Modells, der Daten und der Infrastruktur zu sammeln. Sie können diese Metriken verwenden, um Maßnahmen zu ergreifen. Modell- und Datenüberwachung können die Überprüfung auf Modell- und Datendrift, die Modellleistung für neue Daten und verantwortungsvolle KI-Probleme umfassen. Durch die Überwachung der Infrastruktur können langsame Endpunktreaktionen, unzureichende Rechenkapazität oder Netzwerkprobleme identifiziert werden.
Daten- und Modellüberwachung: Ereignisse und Aktionen
Basierend auf Modell- und Datenkriterien wie Metrikschwellenwerten oder Zeitplänen können automatisierte Auslöser und Benachrichtigungen entsprechende Maßnahmen implementieren. Ein Trigger kann z. B. ein Modell neu trainieren, um neue Produktionsdaten zu verwenden, und dann das Modell zum Staging und Testen für eine Vorproduktionsauswertung zurückführen und testen. Oder ein Modell- oder Datenproblem könnte eine Aktion auslösen, die einen Loopback zur Modellentwicklungsphase erfordert, wo Datenwissenschaftler das Problem untersuchen und möglicherweise ein neues Modell entwickeln können.
Infrastrukturüberwachung: Ereignisse und Aktionen
Automatisierte Auslöser und Benachrichtigungen können entsprechende Maßnahmen basierend auf Infrastrukturkriterien implementieren, wie z. B. einer Verzögerung der Endpunktantwort oder unzureichender Rechenleistung für die Bereitstellung. Automatische Auslöser und Benachrichtigungen können einen Loopback zur Einrichtungs- und Verwaltungsphase auslösen, wo das Infrastrukturteam das Problem untersuchen und ggf. die Rechen- und Netzwerkressourcen neu konfigurieren kann.
CV-Architektur für Machine Learning
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow für die CV-Architektur
Die CV-Architektur für Machine Learning basiert auf der klassischen Machine Learning-Architektur, beinhaltet jedoch Änderungen, die insbesondere für überwachte CV-Szenarien gelten.
Datenbestand
Diese Komponente demonstriert den Datenbestand der Organisation und potenzielle Datenquellen und -ziele für ein Data Science-Projekt. Datentechniker sind die primären Besitzer dieser Komponente im MLOps v2-Lebenszyklus. Die Azure-Datenplattformen in diesem Diagramm sind weder vollständig noch präskriptiv. Bilder für CV-Szenarien können aus verschiedenen Datenquellen stammen. Zur Steigerung der Effizienz bei der Entwicklung und Bereitstellung von CV-Modellen mit Machine Learning empfehlen wir Azure Blob Storage und Azure Data Lake Storage.
Verwaltung und Einrichtung
Diese Komponente ist der erste Schritt in der MLOps v2-Bereitstellung. Es besteht aus allen Aufgaben im Zusammenhang mit der Erstellung und Verwaltung von Ressourcen und Rollen, die dem Projekt zugeordnet sind. Für CV-Szenarien ist die Verwaltung und Einrichtung der MLOps v2-Umgebung weitgehend identisch mit klassischem maschinellem Lernen, umfasst aber einen zusätzlichen Schritt. Das Infrastrukturteam verwendet das Bezeichnungsfeature von Machine Learning oder ein anderes Tool zum Erstellen von Bildbezeichnungen und Anmerkungsprojekten.
Modellentwicklung (innere Schleifenphase)
Das innere Schleifenphase besteht aus seinem iterativen Data Science-Workflow, der innerhalb eines dedizierten und sicheren Machine Learning-Arbeitsbereichs ausgeführt wird. Der Hauptunterschied zwischen diesem Workflow und dem klassischen Machine Learning-Szenario besteht darin, dass die Bildbezeichnung und Anmerkung eine wichtige Komponente dieser Entwicklungsschleife ist.
Machine Learning-Registrierungen
Nachdem das Data Science-Team ein Modell entwickelt hat, das es in der Produktion einsetzen kann, registriert es das Modell im Machine Learning-Arbeitsbereichsregister. CI-Pipelines, die automatisch durch die Modellregistrierung oder durch die Genehmigung von Menschen in der Schleife ausgelöst werden, fördern das Modell und alle anderen Modellabhängigkeiten an die Modellbereitstellungsphase.
Modellimplementierung (äußere Schleifenphase)
Die Modellimplementierung oder äußere Schleifenphase besteht aus vorproduktivem Staging und Tests, der Produktionsbereitstellung und der Überwachung von Modell, Daten und Infrastruktur. Wenn das Modell die Kriterien der Organisation und des Anwendungsfalls erfüllt, fördern CD-Pipelines das Modell und die zugehörigen Assets durch Produktion, Überwachung und mögliche Neuschulung.
Staging und Test
Die Staging- und Testphase variiert je nach Kundenpraxis. Diese Staging- und Testphase kann sich je nach Kundenpraktiken unterscheiden, umfasst in der Regel Vorgänge wie Testbereitstellungen, Datenqualitätsprüfungen, Komponententests und verantwortungsvolle KI-Prüfungen für Modell- und Datenverzerrungen. Bei CV-Szenarien müssen Machine Learning-Ingenieure den Modellkandidaten aufgrund von Ressourcen- und Zeitbeschränkungen nicht mit Produktionsdaten neu trainieren. Das Data Science-Team kann stattdessen Produktionsdaten für die Modellentwicklung verwenden. Das aus der Entwicklungsschleife registrierte Kandidatenmodell wird für die Produktion ausgewertet. Diese Phase erfolgt in einem oder mehreren dedizierten und sicheren Machine Learning-Arbeitsbereichen.
Produktionsbereitstellung
Nachdem ein Modell die Staging- und Testphase durchlaufen hat, können Machine-Learning-Ingenieure es mithilfe einer „Human-in-the-Loop“-Genehmigung in die Produktion überführen. Zu den Optionen für die Modellbereitstellung gehören ein verwalteter Batchendpunkt für Batchszenarien oder ein verwalteter Onlineendpunkt oder eine Kubernetes-Bereitstellung, die Azure Arc für Onlineszenarien nahezu in Echtzeit verwendet. Die Produktion erfolgt normalerweise in einem oder mehreren dedizierten und sicheren Machine-Learning-Arbeitsbereichen.
Überwachung
Ingenieure für maschinelles Lernen überwachen Komponenten in der Bereitstellung, beim Testen und in der Produktion, um Metriken im Zusammenhang mit Leistungsänderungen des Modells, der Daten und der Infrastruktur zu sammeln. Sie können diese Metriken verwenden, um Maßnahmen zu ergreifen. Modell- und Datenüberwachung kann die Überprüfung der Modellleistung auf neuen Bildern umfassen. Durch die Überwachung der Infrastruktur können langsame Endpunktreaktionen, unzureichende Rechenkapazität oder Netzwerkprobleme identifiziert werden.
Daten- und Modellüberwachung: Ereignisse und Aktionen
Die Daten- und Modellüberwachung und Ereignis- und Aktionsphasen von MLOps für linguistische Datenverarbeitung sind die wichtigsten Unterschiede zum klassischen maschinellen Lernen. Die automatisierte Neuschulung erfolgt in der Regel nicht in CV-Szenarien, wenn die Leistungsverschlechterung der Modellleistung bei neuen Bildern erkannt wird. In diesem Fall ist ein Human-in-the-Loop-Prozess erforderlich, um neue Textdaten für das Modell mit schlechter Leistung zu überprüfen und zu kommentieren. Die nächste Aktion geht häufig zurück zur Modellentwicklungsschleife, um das Modell mit den neuen Bildern zu aktualisieren.
Infrastrukturüberwachung: Ereignisse und Aktionen
Automatisierte Auslöser und Benachrichtigungen können entsprechende Maßnahmen basierend auf Infrastrukturkriterien implementieren, wie z. B. einer Verzögerung der Endpunktantwort oder unzureichender Rechenleistung für die Bereitstellung. Automatische Auslöser und Benachrichtigungen können einen Loopback zur Setup- und Administrationsphase auslösen, wo das Infrastrukturteam das Problem untersuchen und ggf. die Umgebung sowie die Rechen- und Netzwerkressourcen neu konfigurieren kann.
Architektur der logistischen Datenverarbeitung für maschinelles Lernen
Laden Sie eine Visio-Datei dieser Architektur herunter.
Workflow für die Architektur der linguistischen Datenverarbeitung.
Die Architektur der linguistischen Datenverarbeitung beim maschinellen Lernen basiert auf der klassischen Architektur des maschinellen Lernens, weist jedoch einige für NLP-Szenarien spezifische Modifikationen auf.
Datenbestand
Diese Komponente demonstriert den Datenbestand der Organisation und potenzielle Datenquellen und -ziele für ein Data Science-Projekt. Datentechniker sind die primären Besitzer dieser Komponente im MLOps v2-Lebenszyklus. Die Azure-Datenplattformen in diesem Diagramm sind weder vollständig noch präskriptiv. Ein grünes Häkchen kennzeichnet Quellen und Ziele, die empfohlene Best Practices darstellen, die auf dem Anwendungsfall des Kunden basieren.
Verwaltung und Einrichtung
Diese Komponente ist der erste Schritt in der MLOps v2-Bereitstellung. Es besteht aus allen Aufgaben im Zusammenhang mit der Erstellung und Verwaltung von Ressourcen und Rollen, die dem Projekt zugeordnet sind. Für Szenarien zur Verarbeitung natürlicher Sprache sind Verwaltung und Einrichtung der MLOps v2-Umgebung weitgehend identisch mit denen für klassisches maschinelles Lernen, allerdings mit einem zusätzlichen Schritt: Erstellen Sie Bildbeschriftungs- und Annotationsprojekte, indem Sie die Beschriftungsfunktion von Machine Learning oder einem anderen Tool verwenden.
Modellentwicklung (innere Schleifenphase)
Das innere Schleifenphase besteht aus seinem iterativen Data Science-Workflow, der innerhalb eines dedizierten und sicheren Machine Learning-Arbeitsbereichs ausgeführt wird. Die typische NLP-Modellentwicklungsschleife unterscheidet sich vom klassischen Szenario des maschinellen Lernens darin, dass die typischen Entwicklungsschritte für dieses Szenario Annotatoren für Sätze sowie Tokenisierung, Normalisierung und Einbettungen für Textdaten umfassen.
Machine Learning-Registrierungen
Nachdem das Data Science-Team ein Modell entwickelt hat, das es in der Produktion einsetzen kann, registriert es das Modell im Machine Learning-Arbeitsbereichsregister. CI-Pipelines, die automatisch durch die Modellregistrierung oder durch die Genehmigung von Menschen in der Schleife ausgelöst werden, fördern das Modell und alle anderen Modellabhängigkeiten an die Modellbereitstellungsphase.
Modellimplementierung (äußere Schleifenphase)
Die Modellimplementierung oder äußere Schleifenphase besteht aus vorproduktivem Staging und Tests, der Produktionsbereitstellung und der Überwachung von Modell, Daten und Infrastruktur. Wenn das Modell die Kriterien der Organisation und des Anwendungsfalls erfüllt, fördern CD-Pipelines das Modell und die zugehörigen Assets durch Produktion, Überwachung und mögliche Neuschulung.
Staging und Test
Die Staging- und Testphase variiert je nach Kundenpraxis. Diese Staging- und Testphase kann sich je nach Kundenpraktiken unterscheiden, umfasst in der Regel Vorgänge wie die Umschulung und Prüfung des Modellkandidaten auf Produktionsdaten, Testbereitstellungen für Endpunktleistung, Datenqualitätsprüfungen, Komponententests und verantwortungsvolle KI-Prüfungen für Modell- und Datenverzerrungen. Diese Phase erfolgt in einem oder mehreren dedizierten und sicheren Machine Learning-Arbeitsbereichen.
Produktionsbereitstellung
Nachdem ein Modell die Staging- und Testphase durchlaufen hat, können Machine-Learning-Ingenieure es mithilfe einer „Human-in-the-Loop“-Genehmigung in die Produktion überführen. Zu den Optionen für die Modellbereitstellung gehören ein verwalteter Batchendpunkt für Batchszenarien oder ein verwalteter Onlineendpunkt oder eine Kubernetes-Bereitstellung, die Azure Arc für Onlineszenarien nahezu in Echtzeit verwendet. Die Produktion erfolgt normalerweise in einem oder mehreren dedizierten und sicheren Machine-Learning-Arbeitsbereichen.
Überwachung
Ingenieure für maschinelles Lernen überwachen Komponenten in der Bereitstellung, beim Testen und in der Produktion, um Metriken im Zusammenhang mit Leistungsänderungen des Modells, der Daten und der Infrastruktur zu sammeln. Sie können diese Metriken verwenden, um Maßnahmen zu ergreifen. Modell- und Datenüberwachung können die Überprüfung auf Modell- und Datendrift, die Modellleistung für neue Daten und verantwortungsvolle KI-Probleme umfassen. Die Infrastrukturüberwachung kann Probleme wie langsame Endpunktantworten, unzureichende Berechnungskapazität oder Netzwerkprobleme identifizieren.
Daten- und Modellüberwachung: Ereignisse und Aktionen
Wie in der CV-Architektur sind die Daten- und Modellüberwachung und Ereignis- und Aktionsphasen von MLOps für linguistische Datenverarbeitung die wichtigsten Unterschiede zum klassischem maschinellem Lernen. Die automatisierte Neuschulung erfolgt in der Regel nicht in Szenarien für linguistische Datenverarbeitung, wenn die Leistungsverschlechterung der Modellleistung bei neuen Bildern erkannt wird. In diesem Fall ist ein Human-in-the-Loop-Prozess erforderlich, um neue Textdaten für das Modell mit schlechter Leistung zu überprüfen und zu kommentieren. Häufig besteht die nächste Aktion darin, zur Modellentwicklungsschleife zurückzukehren, um das Modell mit den neuen Textdaten zu aktualisieren.
Infrastrukturüberwachung: Ereignisse und Aktionen
Automatisierte Auslöser und Benachrichtigungen können entsprechende Maßnahmen basierend auf Infrastrukturkriterien implementieren, wie z. B. einer Verzögerung der Endpunktantwort oder unzureichender Rechenleistung für die Bereitstellung. Automatische Auslöser und Benachrichtigungen können einen Loopback zur Einrichtungs- und Verwaltungsphase auslösen, wo das Infrastrukturteam das Problem untersuchen und ggf. die Rechen- und Netzwerkressourcen neu konfigurieren kann.
Komponenten
Machine Learning ist ein Cloud-Dienst, mit dem Sie Machine-Learning-Modelle im großen Maßstab trainieren, bewerten, bereitstellen und verwalten können.
Azure Pipelines ist ein Build- und Testsystem, das auf Azure DevOps basiert und für die Erstellung und Freigabe von Pipelines verwendet wird. Azure Pipelines unterteilt diese Pipelines in logische Schritte, die als Aufgaben bezeichnet werden.
GitHub ist eine Codehostingplattform für Versionsverwaltung, Zusammenarbeit und CI/CD-Workflows.
Azure Arc ist eine Plattform, die Azure Resource Manager zum Verwalten von Azure-Ressourcen und lokalen Ressourcen verwendet. Die Ressourcen können virtuelle Computer, Kubernetes-Cluster und Datenbanken enthalten.
Kubernetes ist ein Open-Source-System, mit dem Sie die Bereitstellung, Skalierung und Verwaltung von Containeranwendungen automatisieren können.
Azure Data Lake Storage ist ein Hadoop-kompatibles Dateisystem. Es verfügt über einen integrierten hierarchischen Namespace und die enorme Staffelung und Wirtschaftlichkeit von Azure Blob Storage.
Azure Synapse Analytics ist ein unbegrenzter Analysedienst, der Datenintegration, Data Warehousing für Unternehmen und Big Data-Analysen vereint.
Azure Event Hubs ist ein Dienst, der von Clientanwendungen generierte Datenströme aufnimmt. Anschließend erfassen und speichern sie Streamingdaten, die die Abfolge der empfangenen Ereignisse beibehalten. Consumer können eine Verbindung mit den Hubendpunkten herstellen, um Nachrichten zur Verarbeitung abzurufen. Diese Architektur verwendet die Data Lake Storage-Integration.
Andere Aspekte
Das vorangehende MLOps v2-Architekturmuster verfügt über mehrere wichtige Komponenten, einschließlich rollenbasierter Zugriffssteuerung (RBAC), die sich an die Geschäftsbeteiligten, die effiziente Paketverwaltung und robuste Überwachungsmechanismen richtet. Diese Komponenten tragen gemeinsam zur erfolgreichen Implementierung und Verwaltung von Machine Learning-Workflows bei.
Persona-basiertes RBAC
Es ist entscheidend, dass Sie den Zugriff auf Machine Learning-Daten und -Ressourcen verwalten. RBAC bietet ein robustes Framework, mit dem Sie verwalten können, wer bestimmte Aktionen ausführen und auf bestimmte Bereiche in Ihrer Lösung zugreifen kann. Entwerfen Sie Ihre Identitätssegmentierungsstrategie so, dass sie mit dem Lebenszyklus von Machine Learning-Modellen in Machine Learning und den im Prozess enthaltenen Personas übereinstimmt. Jede Persona verfügt über einen bestimmten Satz von Zuständigkeiten, die in ihren RBAC-Rollen und der Gruppenmitgliedschaft widerspiegelt werden.
Beispielpersonas
Um die entsprechende Segmentierung in einer Machine Learning-Workload zu unterstützen, berücksichtigen Sie die folgenden allgemeinen Personas, die den identitätsbasierten RBAC-Gruppenentwurf informieren.
Data Scientist und Ingenieur für maschinelles Lernen
Data Scientists und Machine Learning Ingenieure führen verschiedene Machine Learning- und Data Science-Aktivitäten im gesamten Softwareentwicklungslebenszyklus eines Projekts durch. Zu ihren Aufgaben gehören explorative Datenanalyse und Datenvorverarbeitung. Data Scientists und Machine Learning Ingenieure sind für Schulungen, Auswertungen und Bereitstellungsmodelle verantwortlich. Die Zuständigkeiten dieser Rollen umfassen auch Break-Fix-Aktivitäten für Machine Learning-Modelle, Pakete und Daten. Diese Aufgaben liegen außerhalb des Umfangs des technischen Supportteams der Plattform.
Typ: Person
Projektspezifisch: Ja
Data Analyst
Datenanalysten liefern die erforderliche Eingabe für Data Science-Aktivitäten, z. B. das Ausführen von SQL-Abfragen für Business Intelligence. Die Zuständigkeiten dieser Rolle umfassen das Arbeiten mit Daten, das Ausführen von Datenanalysen und die Unterstützung der Modellentwicklung und Modellbereitstellung.
Typ: Person
Projektspezifisch: Ja
Modelltester
Modelltester führen Tests in Test- und Stagingumgebungen durch. Diese Rolle bietet eine funktionale Trennung von den CI/CD-Prozessen.
Typ: Person
Projektspezifisch: Ja
Beteiligte im Unternehmen
Geschäftsbeteiligte werden dem Projekt zugeordnet, z. B. einem Marketingmanager.
Typ: Person
Projektspezifisch: Ja
Projektleiter oder Data Science-Lead
Der Data Science-Lead ist eine Projektverwaltungsrolle für den Machine Learning-Arbeitsbereich. Diese Rolle führt auch Break-Fix-Aktivitäten für die Machine Learning-Modelle und -Pakete durch.
Typ: Person
Projektspezifisch: Ja
Projekt- oder Produktbesitzer (Geschäftsbesitzer)
Geschäftsbeteiligte sind gemäß Datenbesitz für den Maschinellen Lerning-Arbeitsbereich verantwortlich.
Typ: Person
Projektspezifisch: Ja
Technischer Plattformsupport
Der technische Support der Plattform ist der technische Supportmitarbeiter, der für Break-Fix-Aktivitäten auf der gesamten Plattform verantwortlich ist. Diese Rolle umfasst Infrastruktur oder Dienst, aber nicht die Machine Learning-Modelle, Pakete oder Daten. Diese Komponenten verbleiben unter der Rolle des Data Scientists oder Machine Learning Engineerings und sind die Verantwortung des Projektleiters.
Typ: Person
Projektspezifisch: Nein
Modell-Endbenutzer
Modell-Endbenutzer sind die Endbenutzer des Machine Learning-Modells.
Typ: Person oder Prozess
Projektspezifisch: Ja
CI/CD-Prozesse
CI/CD verarbeitet Release- oder Rollbackänderungen in plattformübergreifenden Umgebungen.
Typ: Prozess
Projektspezifisch: Nein
Machine Learning-Arbeitsbereich
Machine Learning-Arbeitsbereiche verwenden verwaltete Identitäten , um mit anderen Teilen von Azure zu interagieren. Diese Persona stellt die verschiedenen Dienste dar, aus denen eine Machine Learning-Implementierung besteht. Diese Dienste interagieren mit anderen Teilen der Plattform, z. B. dem Entwicklungsarbeitsbereich, der eine Verbindung mit dem Entwicklungsdatenspeicher herstellt.
Typ: Prozess
Projektspezifisch: Nein
Überwachungsprozesse
Überwachungsprozesse sind Computeprozesse, die basierend auf Plattformaktivitäten überwachen und warnen.
Typ: Prozess
Projektspezifisch: Nein
Datengovernanceprozesse
Datengovernanceprozesse scannen das Machine Learning-Projekt und Datenspeicher für Die Datengovernance.
Typ: Prozess
Projektspezifisch: Nein
Mitgliedschaft in der Microsoft Entra Gruppe
Wenn Sie RBAC implementieren, bieten Microsoft Entra-Gruppen eine flexible und skalierbare Möglichkeit zum Verwalten von Zugriffsberechtigungen über verschiedene Personas hinweg. Sie können Microsoft Entra-Gruppen verwenden, um Benutzer zu verwalten, die den gleichen Zugriff und die gleichen Berechtigungen für Ressourcen benötigen, z. B. potenziell eingeschränkte Apps und Dienste. Anstatt einzelnen Benutzern spezielle Berechtigungen hinzuzufügen, erstellen Sie eine Gruppe, in der die speziellen Berechtigungen für jedes Mitglied dieser Gruppe angewendet werden.
In diesem Architekturmuster können Sie diese Gruppen mit einer Einrichtung eines Machine Learning-Arbeitsbereichs verknüpfen, z. B. ein Projekt, ein Team oder eine Abteilung. Sie können Benutzer bestimmten Gruppen zuordnen, um differenzierte Zugriffsrichtlinien zu definieren. Die Richtlinien gewähren oder einschränken Berechtigungen für verschiedene Machine Learning-Arbeitsbereiche basierend auf Auftragsfunktionen, Projektanforderungen oder anderen Kriterien. Beispielsweise können Sie eine Gruppe haben, die allen Datenwissenschaftlern Zugriff auf einen Entwicklungsarbeitsbereich für einen bestimmten Anwendungsfall gewährt.
Identitäts-RBAC
Überlegen Sie, wie Sie die folgenden integrierten Azure RBAC-Rollen verwenden können, um RBAC auf Produktions- und Vorproduktionsumgebungen anzuwenden. Für die Architektur in diesem Artikel umfassen die Produktionsumgebungen Staging-, Test- und Produktionsumgebungen. Zu den Vorproduktionsumgebungen gehören Entwicklungsumgebungen. Die folgenden RBAC-Rollen basieren auf den weiter oben in diesem Artikel beschriebenen Personas.
Standardrollen
- R = Reader
- C = Contributor
- O = Besitzer
Komponentenspezifische Rollen
AcrPush = Azure Container Registry Push
LAR = Log Analytics-Leser
MR = Überwachungsleser
KVA = Key Vault-Administrator
KVR = Key Vault Reader
Diese Azure RBAC-Rollenkürzel entsprechen den folgenden Tabellen.
Produktionsumgebung
Persona | Machine Learning-Arbeitsbereich | Azure Key Vault | Container Registry | Azure Storage-Konto | Azure DevOps | Azure Artifacts | Log Analytics-Arbeitsbereich | Azure Monitor |
---|---|---|---|---|---|---|---|---|
Datenwissenschaftler | R | LAR | MR | |||||
Data Analyst | ||||||||
Modelltester | ||||||||
Beteiligte im Unternehmen | MR | |||||||
Projektleiter (Data Science-Lead) | R | R, KVR | R | LAR | MR | |||
Projekt-/Produktbesitzer | MR | |||||||
Technischer Plattformsupport | O | O, KVA | DOPCA | O | O | O | ||
Modell-Endbenutzer | ||||||||
CI/CD-Prozesse | O | O, KVA | AcrPush | DOPCA | O | O | O | |
Machine Learning-Arbeitsbereich | R | K | K | |||||
Überwachungsprozesse | R | LAR | MR | |||||
Datengovernanceprozesse | R | R | R | R | R |
Umgebung vor der Produktion:
Persona | Machine Learning-Arbeitsbereich | Schlüsseltresor | Container Registry | Speicherkonto | Azure DevOps | Azure Artifacts | Log Analytics-Arbeitsbereich | Azure Monitor |
---|---|---|---|---|---|---|---|---|
Datenwissenschaftler | ADS | R, KVA | K | K | K | K | LAC | MC |
Data Analyst | R | K | LAR | MC | ||||
Modelltester | R | R, KVR | R | R | R | R | LAR | MR |
Beteiligte im Unternehmen | R | R | R | R | R | |||
Projektleiter (Data Science-Lead) | K | C, KVA | K | K | K | K | LAC | MC |
Projekt-/Produktbesitzer | R | R | MR | |||||
Technischer Plattformsupport | O | O, KVA | O | O | DOPCA | O | O | O |
Modell-Endbenutzer | ||||||||
CI/CD-Prozesse | O | O, KVA | AcrPush | O | DOPCA | O | O | O |
Machine Learning-Arbeitsbereich | R, KVR | K | K | |||||
Überwachungsprozesse | R | R | R | R | R | R | LAC | |
Datengovernanceprozesse | R | R | R |
Hinweis
Jede Persona behält zugriff auf die Dauer des Projekts mit Ausnahme des technischen Supports der Plattform, der temporären oder just-in-time Microsoft Entra Privileged Identity Management (PIM)-Zugriff hat.
RBAC spielt eine wichtige Rolle bei der Sicherung und Optimierung von MLOps-Workflows. RBAC schränkt den Zugriff basierend auf zugewiesenen Rollen ein und verhindert, dass nicht autorisierte Benutzer auf vertrauliche Daten zugreifen, wodurch Sicherheitsrisiken verringert werden. Vertrauliche Daten umfassen Schulungsdaten oder Modelle und kritische Infrastruktur, z. B. Produktionspipelinen. Sie können die RBAC verwenden, um die Einhaltung der Datenschutzbestimmungen sicherzustellen. RBAC bietet auch eine klare Aufzeichnung von Zugriff und Berechtigungen, die die Überwachung vereinfacht, erleichtert die Identifizierung von Sicherheitslücken und die Verfolgung von Benutzeraktivitäten.
Paketverwaltung
Abhängigkeiten von verschiedenen Paketen, Bibliotheken und Binärdateien sind während des gesamten MLOps-Lebenszyklus üblich. Diese Abhängigkeiten, oft von der Community entwickelt und sich schnell entwickeln, erfordern Fachwissen zur richtigen Verwendung und zum richtigen Verständnis. Sie müssen sicherstellen, dass die entsprechenden Personen sicheren Zugriff auf verschiedene Objekte haben, z. B. Pakete und Bibliotheken, aber Sie müssen auch Sicherheitsrisiken verhindern. Datenwissenschaftler stoßen auf dieses Problem, wenn sie spezielle Bausteine für Machine Learning-Lösungen zusammenstellen. Herkömmliche Softwaremanagementansätze sind kostspielig und ineffizient. Andere Ansätze bieten mehr Wert.
Um diese Abhängigkeiten zu verwalten, können Sie einen sicheren, Self-Serve-Paketverwaltungsprozess basierend auf dem Quarantänemuster verwenden. Sie können diesen Prozess entwerfen, damit Datenwissenschaftler aus einer kuratierten Liste von Paketen selbst bedient werden können, und sicherstellen, dass die Pakete sicher und den Organisationsstandards entsprechen.
Zu diesem Ansatz gehört die Aufnahme von drei branchenüblichen Paket-Repositorys für maschinelles Lernen in die Safelist: Microsoft Artifact Registry, Python Package Index (PyPI) und Conda. Safe-Listing ermöglicht die Selbstbedienung von einzelnen Machine Learning-Arbeitsbereichen. Verwenden Sie dann während der Bereitstellung einen automatisierten Testprozess, um die resultierenden Lösungscontainer zu scannen. Fehler beenden den Bereitstellungsprozess elegant und entfernen den Container. Das folgende Diagramm und der Prozessablauf veranschaulicht diesen Prozess:
Prozessablauf
Data Scientists, die in einem Machine Learning-Arbeitsbereich arbeiten, der über eine Netzwerkkonfiguration verfügt, kann Machine Learning-Pakete bei Bedarf aus den Repositorys des Machine Learning-Pakets selbst bedienen. Ein Ausnahmeprozess ist für alles andere erforderlich, indem das private Speichermuster verwendet wird, das mit einer zentralen Funktion seediert und verwaltet wird.
Machine Learning liefert Machine Learning-Lösungen als Docker-Container. Da diese Lösungen entwickelt werden, werden sie in die Containerregistrierung hochgeladen. Microsoft Defender für Container generiert Sicherheitsrisikobewertungen für das Containerimage.
Die Lösungsbereitstellung erfolgt über einen CI/CD-Prozess. Microsoft Defender für DevOps wird im gesamten Stapel verwendet, um die Verwaltung von Sicherheitsstatus und Bedrohungsschutz bereitzustellen.
Der Lösungscontainer wird nur bereitgestellt, wenn er jeden der Sicherheitsprozesse übergibt. Wenn der Lösungscontainer einen Sicherheitsvorgang fehlschlägt, schlägt die Bereitstellung mit Fehlerbenachrichtigungen und vollständigen Überwachungspfaden fehl. Der Lösungscontainer wird verworfen.
Der vorherige Prozessfluss bietet einen sicheren, selbstbedienungsbasierten Paketverwaltungsprozess für Data Scientists und stellt sicher, dass die Pakete sicher und mit organisatorischen Standards konform sind. Um Innovation und Sicherheit auszugleichen, können Sie Data Scientists Self-Service-Zugriff auf allgemeine Machine Learning-Pakete, Bibliotheken und Binärdateien in Präproduktionsumgebungen gewähren. Ausnahmen für weniger häufige Pakete erforderlich. Diese Strategie stellt sicher, dass Data Scientists während der Entwicklung produktiv bleiben können, was einen großen Engpass während der Lieferung verhindert.
Um Ihre Veröffentlichungsprozesse zu optimieren, containerisieren Sie Umgebungen für die Verwendung in Produktionsumgebungen. Containerisierte Umgebungen reduzieren die Gefährdung und sorgen für eine kontinuierliche Sicherheit durch sicherheitsrelevante Überprüfungen. Dieser Prozessfluss bietet einen wiederholbaren Ansatz, den Sie in allen Anwendungsfällen zum Zeitpunkt der Übermittlung verwenden können. Dadurch werden die Gesamtkosten reduziert, um Machine Learning-Lösungen in Ihrem Unternehmen zu erstellen und bereitzustellen.
Überwachung
In MLOps ist die Überwachung entscheidend für die Aufrechterhaltung der Integrität und Leistung von Maschinellen Lernsystemen und die Sicherstellung, dass Modelle effektiv bleiben und mit den Geschäftszielen in Einklang stehen. Die Überwachung unterstützt Governance, Sicherheit und Kostenkontrolle während der inneren Schleifenphase. Außerdem bietet es einen Einblick in den Leistungs-, Modellbeeinträchtigungen und die Verwendung bei der Bereitstellung von Lösungen während der äußeren Schleifenphase. Überwachungsaktivitäten sind für Personen wie Wissenschaftliche Fachkraft für Daten s, Geschäftsbeteiligte, Projektleiter, Projektbesitzer, plattformtechnischer Support, CI/CD-Prozesse und Überwachungsprozesse relevant.
Wählen Sie Ihre Überwachungs- und Überprüfungsplattform abhängig von Ihrer Einrichtung des Machine Learning-Arbeitsbereichs aus, z. B. ein Projekt, ein Team oder eine Abteilung.
Modellleistung
Überwachen Sie die Modellleistung, um Modellprobleme und Leistungsbeeinträchtigungen frühzeitig zu erkennen. Verfolgen Sie die Leistung, um sicherzustellen, dass Modelle exakt, zuverlässig und an geschäftsziele ausgerichtet bleiben.
Datendrift
Datendrift verfolgt Änderungen in der Verteilung der Eingabedaten eines Modells, indem sie mit den Trainingsdaten des Modells oder den Produktionsdaten der letzten Vergangenheit verglichen werden. Diese Änderungen ergeben sich aus Änderungen der Marktdynamik, Funktionstransformationsänderungen oder vorgelagerten Datenänderungen. Solche Änderungen können die Modellleistung beeinträchtigen, daher ist es wichtig, die Drift zu überwachen, um eine rechtzeitige Wartung sicherzustellen. Um einen Vergleich durchzuführen, erfordert die Umgestaltung von Datenabweichungen aktuelle Produktionsdatensätze und -ausgaben.
Umgebung: Produktion
Azure-Erleichterung: Machine Learning – Modellüberwachung
Vorhersagedrift
Mit der Vorhersageabweichung werden Änderungen in der Verteilung der Vorhersageausgaben eines Modells verfolgt, indem sie mit Validierungs-, Test-Labeling- oder aktuellen Produktionsdaten verglichen werden. Um einen Vergleich durchzuführen, erfordert die Umgestaltung von Datenabweichungen aktuelle Produktionsdatensätze und -ausgaben.
Umgebung: Produktion
Azure-Erleichterung: Machine Learning – Modellüberwachung
Resource
Verwenden Sie mehrere Modell für Endpunktmetriken, um Qualität und Leistung anzugeben, z. B. CPU- oder Arbeitsspeicherauslastung. Dieser Ansatz hilft Ihnen, aus der Produktion zu lernen, um zukünftige Investitionen oder Änderungen voranzutreiben.
Umgebung: Alle
Azure-Erleichterung: Überwachen – Metriken für Onlineendpunkte
Nutzungsmetriken
Überwachen Sie die Verwendung von Endpunkten, um sicherzustellen, dass Sie organisationsspezifische oder workloadspezifische Leistungsindikatoren erfüllen, Nutzungsmuster nachverfolgen und Probleme diagnostizieren und beheben können, die Ihre Benutzer erleben.
Clientanforderungen
Verfolgen Sie die Anzahl der Clientanforderungen an den Modellendpunkt, um das aktive Nutzungsprofil der Endpunkte zu verstehen, was sich auf die Skalierung oder Kostenoptimierung auswirken kann.
Umgebung: Produktion
Azure-Erleichterung: Überwachen – Metriken für Onlineendpunkte, z. B. RequestsPerMinute.
Hinweise:
- Sie können akzeptable Schwellenwerte an T-Shirt-Größenanpassungen oder Anomalien ausrichten, die auf die Anforderungen Ihrer Workload zugeschnitten sind.
- Eingestellte Modelle, die nicht mehr aus der Produktion verwendet werden.
Drosselungsverzögerungen
Drosselungsverzögerungen sind Verlangsamungen bei der Anforderung und Reaktion auf Datenübertragungen. Die Drosselung erfolgt auf Ressourcen-Manager-Ebene und auf Dienstebene. Verfolgen Sie Metriken auf beiden Ebenen.
Umgebung: Produktion
Azure-Erleichterung:
- Monitor – Ressourcen-Manager, Summe von RequestThrottlingDelayMs, ResponseThrottlingDelayMs.
- Maschinelles Lernen – Um Informationen zu den Anforderungen Ihrer Endpunkte zu überprüfen, können Sie Online-Endpunktdatenverkehrsprotokolle aktivieren. Sie können einen Log Analytics-Arbeitsbereich verwenden, um Protokolle zu verarbeiten.
Hinweis: Richten Sie akzeptable Schwellenwerte an die Ziele ihrer Workload (Service Level Objectives, SLOs) oder Vereinbarungen auf Servicelevel (Service Level Agreements, SLAs) und die nicht funktionsfreien Anforderungen (NFRs) der Lösung aus.
Generierte Fehler
Verfolgen Sie Antwortcodefehler, um die Zuverlässigkeit des Diensts zu messen und eine frühzeitige Erkennung von Dienstproblemen zu gewährleisten. Beispielsweise könnte eine plötzliche Zunahme von 500 Serverfehlerantworten auf ein kritisches Problem hinweisen, das sofortige Aufmerksamkeit erfordert.
Umgebung: Produktion
Azure-Erleichterung: Maschinelles Lernen – Aktivieren Sie Online-Endpunktdatenverkehrsprotokolle , um Informationen zu Ihrer Anforderung zu überprüfen. Beispielsweise können Sie die Anzahl der XRequestId mithilfe von ModelStatusCode oder ModelStatusReason überprüfen. Sie können einen Log Analytics-Arbeitsbereich verwenden, um Protokolle zu verarbeiten.
Hinweise:
- Alle HTTP-Antwortcodes im Bereich 400 und 500 werden als Fehler klassifiziert.
Kostenoptimierung
Kostenmanagement und Optimierung in einer Cloudumgebung sind von entscheidender Bedeutung, da sie Arbeitslasten dabei helfen, Ausgaben zu steuern, Ressourcen effizient zuzuweisen und den Nutzen aus ihren Clouddiensten zu maximieren.
Arbeitsbereich Compute
Wenn monatliche Betriebskosten einen vordefinierten Betrag erreichen oder überschreiten, generieren Sie Warnungen, um relevante Projektbeteiligte, z. B. Projektleiter oder Projektbesitzer, basierend auf den Arbeitsbereichseinrichtungsgrenzen zu benachrichtigen. Sie können die Arbeitsbereichseinrichtung basierend auf Projekt-, Team- oder Abteilungsgrenzen ermitteln.
Umgebung: Alle
Azure-Erleichterung: Microsoft Cost Management – Budgetwarnungen
Hinweise:
- Legen Sie Die Budgetschwellenwerte basierend auf den ursprünglichen NSP- und Kostenschätzungen fest.
- Verwenden Sie mehrere Schwellenwertebenen. Mehrere Schwellenwerte stellen sicher, dass die Beteiligten vor dem Überschreiten des Budgets eine entsprechende Warnung erhalten. Diese Projektbeteiligten können Geschäftskontakte, Projektbesitzer oder Projektkontakte abhängig von der Organisation oder Arbeitsauslastung umfassen.
- Konsistente Budgetwarnungen könnten auch ein Auslöser für die Umgestaltung sein, um eine größere Nachfrage zu unterstützen.
Veraltetheit des Arbeitsbereichs
Wenn ein Machine Learning-Arbeitsbereich keine Anzeichen für die aktive Verwendung basierend auf der zugeordneten Computeverwendung für den vorgesehenen Anwendungsfall anzeigt, kann ein Projektbesitzer den Arbeitsbereich außer Betrieb setzen, wenn er für ein bestimmtes Projekt nicht mehr benötigt wird.
Umgebung: Vorproduktion
Azure-Erleichterung:
- Monitor - Machine Learning Metriken
- Machine Learning – Arbeitsbereichsmetriken, z. B. die Anzahl der aktiven Kerne über einen bestimmten Zeitraum
Hinweise:
- Aktive Kerne sollten gleich Null mit der Aggregation der Anzahl sein.
- Ausrichten von Datumsschwellenwerten an den Projektzeitplan.
Sicherheit
Überwachen Sie, um Abweichungen von geeigneten Sicherheitskontrollen und -baselines zu erkennen, um sicherzustellen, dass Machine Learning-Arbeitsbereiche den Sicherheitsrichtlinien Ihrer Organisation entsprechen. Sie können eine Kombination aus vordefinierten und benutzerdefinierten Richtlinien verwenden.
Umgebung: Alle
Azure-Erleichterung: Azure-Richtlinie für maschinelles Lernen
Endpunktsicherheit
Um Einblicke in unternehmenskritische APIs zu erhalten, implementieren Sie eine gezielte Sicherheitsüberwachung aller Machine Learning-Endpunkte. Sie können den API-Sicherheitsstatus untersuchen und verbessern, Sicherheitskorrekturen priorisieren und aktive Echtzeitbedrohungen schnell erkennen.
Umgebung: Produktion
Azure-Erleichterung: Microsoft Defender für APIs bietet umfassenden Lebenszyklusschutz, Erkennung und Reaktionsabdeckung für APIs.
Hinweis: Defender für APIs bietet Sicherheit für APIs, die in Azure API Management veröffentlicht werden. Sie können Defender für APIs im Microsoft Defender für Cloud-Portal oder innerhalb der API Management-Instanz im Azure-Portal integrieren. Sie müssen Machine Learning-Onlineendpunkte in die API-Verwaltung integrieren.
Bereitstellung Überwachung
Die Bereitstellungsüberwachung stellt sicher, dass alle Endpunkte, die Sie erstellen, Ihren Workload- oder Organisationsrichtlinien entsprechen und frei von Sicherheitsrisiken sind. Dieser Prozess erfordert, dass Sie Compliancerichtlinien für Ihre Azure-Ressourcen vor und nach der Bereitstellung erzwingen, durch Sicherheitsrisikoüberprüfungen fortgesetzte Sicherheit bereitstellen und sicherstellen, dass der Dienst SLOs während des Betriebs erfüllt.
Standards und Governance
Überwachen Sie, um Abweichungen von geeigneten Standards zu erkennen und sicherzustellen, dass Ihre Arbeitsauslastung den Schutzschienen entspricht.
Umgebung: Alle
Azure-Erleichterung:
- Verwaltete Richtlinienzuweisung und -lebenszyklus über Azure Pipelines zum Behandeln von Richtlinien als Code.
- PSRule für Azure bietet ein Testframework für die Azure-Infrastruktur als Code.
- Sie können Enterprise Azure-Richtlinie in CI/CD-basierten Systembereitstellungsrichtlinien, Richtliniensätzen, Zuweisungen, Richtlinienfreistellungen und Rollenzuweisungen verwenden.
Hinweise: Weitere Informationen finden Sie unter Azure-Leitfaden für die Einhaltung gesetzlicher Vorschriften in Machine Learning.
Sicherheitsüberprüfung
Implementieren Sie automatisierte Sicherheitsüberprüfungen als Teil der automatisierten Integrations- und Bereitstellungsprozesse.
Umgebung: Alle
Azure-Erleichterung: Defender for DevOps
Hinweis: Sie können Apps in Azure Marketplace verwenden, um diesen Prozess für Nicht-Microsoft-Sicherheitstests zu erweitern.
Laufende Wartung
Überwachen Sie den laufenden Dienst einer API auf Leistungsoptimierung, Sicherheit und Ressourcennutzung. Stellen Sie eine zeitnahe Fehlererkennung, effiziente Problembehandlung und Einhaltung von Standards sicher.
Umgebung: Produktion
Azure-Erleichterung:
- Monitor - Machine Learning Metriken
- Machine Learning - Sie können Online-Endpunktverkehrsprotokolle aktivieren, um Informationen zu Ihrem Dienst zu überprüfen.
Beitragende
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Scott Donohoo | Senior Cloud Solution Architect
- Moritz Steller | Senior Cloud Solution Architect
Andere Mitwirkende:
- Scott Mckinnon | Cloud Solution Architect
- Nicholas Moore | Cloud Solution Architect
- Darren Turchiarelli | Cloud Solution Architect
- Leo Kozhushnik | Cloud Solution Architect
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
Nächste Schritte
- Was ist Azure Pipelines?
- Übersicht über Azure Arc
- Was ist Machine Learning?
- Daten in Machine Learning
- Azure MLOps v2 GitHub-Repository
- Umfassende Machine Learning-Vorgänge (MLOps) mit Machine Learning
- Einführung in Azure Data Lake Storage Gen2
- Dokumentation zu Azure DevOps
- GitHub-Dokumentation
- Dokumentation für Synapse Analytics
- Event Hubs-Dokumentation
- Funktionsweise von Machine Learning: Ressourcen und Objekte (v2)
- Was sind Machine Learning-Pipelines?