Dans cet article, nous aborderons les considérations sur l’architecture Azure concernant l’analyse et l’implémentation d’un ensemble de contrôles de gestion des risques liés à la sécurité des informations (ISRM) pour la classification en niveaux à haut risque courants.
Architecture
L’architecture est présentée dans ce diagramme et suit le principe de zones d’atterrissage à l’échelle de l’entreprise, en particulier l’analyse à l’échelle de l’entreprise et l’architecture de référence de l’intelligence artificielle.
Téléchargez un fichier Visio de cette architecture.
Workflow
L’architecture se compose du flux de travail décrit dans les sections suivantes. Chaque composant de l’architecture possède un nombre correspondant dans le diagramme. Nous décrivons l’objectif principal du composant, son intégration à l’architecture et d’autres considérations importantes que vous devez prendre lors de son adoption :
- Abonnements de plateforme : principaux abonnements Azure qui fournissent la gestion, la connectivité et l’identité via Microsoft Entra ID. Elles ne sont pas décrites ici plus en détail et sont supposées être prêtes et disponibles dans le cadre de la principale configuration à l’échelle de l’entreprise.
Gestion des données
- Zone de gestion des données : la zone de gestion des données est responsable de la gouvernance des données à travers la plateforme et applique des garde-fous qui offrent une plus grande flexibilité en aval des zones d’atterrissage des données. Il possède son propre abonnement et héberge des services centralisés, tels que le catalogage des données, la surveillance, les audits, etc. Cet environnement est hautement contrôlé et soumis à des audits rigoureux. Tous les types de classifications de données sont stockés dans le catalogue de données central (Azure Purview). Selon les métadonnées, des stratégies et des modèles d’accès différents sont appliqués. Il n’existe qu’un seul abonnement de zone de gestion des données pour l’ensemble du locataire. La zone de gestion des données est appairée (par le peering de réseaux virtuels) à toutes les autres zones d’atterrissage de données. Les points de terminaison privés sont utilisés chaque fois que cela est possible pour garantir que les services déployés ne sont pas accessibles via l’internet public.
- Groupe de ressources de mise en réseau : les réseaux virtuels Azure, les groupes de sécurité réseau et toutes les autres ressources liées à la mise en réseau nécessaires à la zone de gestion des données sont approvisionnés dans ce groupe de ressources de mise en réseau.
- Groupe de ressources de déploiement : un groupe de ressources de déploiement héberge les agents privés Azure DevOps CI/CD (machines virtuelles) nécessaires à la zone de gestion des données et un coffre de clés pour le stockage des secrets liés au déploiement.
- Groupe de ressources de gouvernance des données : Azure Purview est utilisé en tant que solution de gestion des données et de catalogue de données. il est utilisé pour appliquer les garde-fous nécessaires aux jeux de données afin de respecter les exigences en matière de données et les réglementations imposées par la loi ou d’autres entités. Purview est hébergé de manière centralisée dans ce groupe de ressources, avec une instance de coffre de clés pour le stockage des secrets.
- Ressources centralisées : Les ressources centralisées hébergent des ressources importantes et précieuses qui sont essentielles à la plateforme, telles que :
- Les registres de conteneurs Azure qui hébergent les images de base utilisées dans les produits de données basés sur Azure Machine Learning (images précédemment analysées et ne présentant aucune vulnérabilité)
- Les modèles AI/Machine Learning qui sont publiés et mis à la disposition des consommateurs sur la plateforme (afin qu’ils puissent être déployés dans une ou plusieurs zones d’atterrissage de données si nécessaire).
- Services supplémentaires : tous les autres services qui doivent être centralisés peuvent être hébergés dans l’un de ces groupes de ressources, qui peut inclure des instances Azure centralisées de Gestion des API, des logiciels tiers, etc.
- Groupe de ressources de visualisation des données : ce groupe de ressource héberge des solutions de visualisation des données partagées entre les zones d’atterrissage des données. Les solutions peuvent être Power BI, Tableau ou toute autre solution de visualisation.
- Contrôles d’infrastructure supplémentaires et gouvernance : Microsoft Defender pour le cloud et Azure Monitor sont utilisés comme des solutions de sécurité de base et de monitoring.
Zones d’atterrissage des données
Zone d'atterrissage de données 001 : une zone d’atterrissage de données est un abonnement qui représente une unité d’échelle au sein de la plateforme de données. Les zones d’atterrissage de données sont déployées en fonction de l’architecture de la zone d’atterrissage de données de base (plan), y compris de toutes les fonctionnalités clés pour héberger une analyse et une plate-forme IA. Il peut y avoir une ou plusieurs zones d’atterrissage de données dans l’environnement. Azure Policy est appliquée pour assurer la sécurité de l’accès et des configurations des différents services Azure. La zone d’atterrissage de données est appairée (par le peering de réseaux virtuels) à toutes les autres zones d’atterrissage de données et à la zone de gestion de données. Les points de terminaison privés sont utilisés chaque fois que cela est possible pour garantir que les services déployés ne sont pas accessibles via l’internet public.
Groupe de ressources de mise en réseau : les réseaux virtuels Azure, les groupes de sécurité réseau et toutes les autres ressources liées à la mise en réseau nécessaires à la zone d’atterrissage de données sont approvisionnés dans ce groupe de ressources.
Groupe de ressources de déploiement : un groupe de ressources de déploiement héberge les agents privés Azure DevOps CI/CD (machines virtuelles) nécessaires à la zone d’atterrissage de données et un coffre de clés pour le stockage des secrets liés au déploiement.
Groupe de ressources de stockage de données : un groupe de ressources de stockage de données contient les principaux comptes de stockage de données de cette zone d’atterrissage de données, déployés comme Azure Data Lake Storage Gen2, avec un espace de noms hiérarchique. Elles sont réparties sur trois domaines principaux :
- Brut : les données sont ingérées depuis la source de données dans leur état d’origine
- Organisé et Enrichi : les données sont nettoyées, validées et agrégées
- Espace de travail : des produits de données spécifiques peuvent stocker leurs jeux de données ou les sorties des modèles de Machine Learning, etc.
Les flèches des diagrammes affichent le flux de données attendu, des données brutes aux données organisées et enrichies (de confiance), et jusqu’à l’espace de travail pour l’exploration, l’analyse et la fourniture d’une valeur supplémentaire à partir du produit de données.
Groupe de ressources d’intégration de données : le groupe de ressources d’intégration de données héberge une plateforme Azure Data Factory qui partage la connectivité avec le runtime d’intégration auto-hébergé local (SHIR). Son objectif principal consiste à établir la connectivité. D’autres instances de Data Factory le réutilisent afin que la connectivité soit maintenue à un seul emplacement. Son autre objectif consiste à héberger le runtime d’intégration auto-hébergé du service Azure Purview afin qu’il puisse accéder aux sources de données de cette zone d’atterrissage de données, à des fins d’analyse.
Groupe de ressources de gestion de métadonnées : le groupe de ressources de gestion de métadonnées héberge les métadonnées d’Azure Databricks (le méta-magasin Hive) et les pipelines d’ingestion et de traitement d’Azure Data Factory. Il héberge également un coffre de clés pour stocker des secrets permettant d’accéder à ces données. Azure SQL Database est utilisé pour héberger les métadonnées.
Groupe de ressources d’ingestion de données : le groupe de ressources d’ingestion de données héberge une instance d’Azure Data Factory dans laquelle tous les pipelines d’ingestion de données spécifiques à un domaine de données sont déployés. Azure Databricks est utilisé en tant que moteur de traitement pour charger et transformer les données et les stocker dans les comptes Data Lake.
Groupe de ressources d’analytique : le groupe de ressources d’analyse inclut deux services partagés pour approfondir l’analytique et l’exploration des données : Azure Synapse et Azure Databricks. Ces deux services fournissent un calcul et une mise à l’échelle étendus à des fins d’exploration et d’analyse massives de données.
Groupe de ressources de produit de données : le groupe de ressources de produit de données est un plan de produit de données, disposant d’un groupe de ressources contenant des ressources Azure de base dont un produit de données pourrait avoir besoin. Le déploiement doit être configurable à l’aide d’un pipeline Azure DevOps en fonction des besoins spécifiques de l’entreprise. Les principaux services Azure déployés ici sont les suivants :
- L’espace de travail Azure Machine Learning comme base pour tout projet de Machine Learning d’entreprise avec des services associés tels qu’un coffre de clés (pour le stockage des secrets)
- Application Insights (pour l’analyse du modèle)
- Stockage Azure (pour le stockage des jeux de données)
- Azure Container Registry pour le stockage des images de modèle pendant le développement
Cognitive Services est déployé en tant qu’offre groupée pour fournir un accès d’API à plusieurs services basés sur l’IA, et une instance de calcul Azure Machine Learning et des clusters de calcul sont utilisés à des fins de développement, de génération de modèles et de test. Azure Data Factory est utilisé pour orchestrer le scoring par lot des modèles, si nécessaire. Azure App Service et Azure Cosmos DB fournissent une couche supplémentaire au déploiement du produit de données, dans laquelle une application personnalisée ou une API peut être hébergée avec son propre magasin de données internes.
Les industries réglementées ont généralement des restrictions d’accès aux données strictes et autorisent généralement l’hébergement des données de production uniquement dans l’environnement de production. Pour cette raison, le cycle de vie du développement des produits de données se produit uniquement dans la zone d’atterrissage des données de production et un environnement distinct, ou groupe de ressources, est approvisionné à des fins de développement, de test et de déploiement.
Produits de données supplémentaires : ces groupes de ressources hébergent d’autres produits de données, car une zone d’atterrissage de données peut héberger un ou plusieurs produits de données.
Groupe de ressources de calcul partagé : tout calcul partagé nécessaire pour l’hébergement et le déploiement des produits de données est approvisionné dans ce groupe de ressources. Un cluster Azure Kubernetes Service est un exemple.
Contrôles d’infrastructure supplémentaires et gouvernance : Microsoft Defender pour le cloud et Azure Monitor sont utilisés comme des solutions de sécurité de base et de monitoring.
Zone d’atterrissage de données 002 : cette zone d’atterrissage est un espace réservé aux abonnements Azure supplémentaires qui seraient utilisés pour héberger de nouvelles zones d’atterrissage de données. Ils sont basés sur des critères mentionnés précédemment, tels que les exigences en matière de résidence des données, ou une unité commerciale différente ayant sa propre équipe fonctionnelle et un ensemble de cas d’usage à remettre.
Composants
- Microsoft Entra ID
- Azure Purview
- Réseau virtuel Azure
- Azure DevOps
- Azure Container Registry
- Azure Machine Learning
- Microsoft Defender pour le cloud
- Azure Monitor
- Azure Policy
- Azure Data Lake Storage
- Azure Data Factory.
- Azure SQL Database
- Azure Databricks
- Azure Synapse Analytics
- Azure Kubernetes Service
Autres solutions
Dans les organisations distribuées, les groupes d’entreprises fonctionnent indépendamment et avec un degré élevé d’autonomie. Par conséquent, ils peuvent envisager une autre conception de solution, avec l’isolation complète des cas d’utilisation dans les zones d’atterrissage Azure, en partageant un ensemble minimal de services communs. Bien que cette conception permette un démarrage rapide, elle nécessite un effort élevé de la part des organisations informatiques et ISRM, car la conception de cas d’usage individuels peut rapidement diverger des conceptions de plan. En outre, elle nécessite des processus et des audits ISRM indépendants pour chacun des produits AI et Machine Learning hébergés dans Azure.
Détails du scénario
La mise à l’échelle des initiatives de l’intelligence artificielle et de Machine Learning dans des environnements réglementés pose des problèmes importants aux organisations, quel que soit leur maturité et leur taille numériques. Dans cet article, nous aborderons les décisions d’architecture clés à prendre en compte lors de l’adoption des services d’ingénierie et de Machine Learning des données d’Azure dans des secteurs réglementés. Ces décisions sont basées sur ce qui a été appris par une implémentation récente dans une société de santé et de sciences de la vie mondiale du classement Fortune 500.
L’architecture présentée dans cet article suit la conception de l’analyse à l’échelle de l’entreprise et de l’architecture de référence de l’intelligence artificielle et était l’une de ses premières implémentations.
Si vous configurez des projets de science des données et développez des modèles Machine Learning dans les environnements des sciences de la vie et des soins de santé, alors dans presque tous les cas, vous avez besoin d’accéder à des sources de données ayant un impact commercial élevé. Par exemple, ces sources peuvent être des informations relatives à un protocole d’essai clinique sans les données du patient, des formules chimiques de molécules ou des secrets de processus de fabrication.
Dans les secteurs réglementés, les systèmes informatiques sont classés en fonction de la classification des sources de données auxquelles ces systèmes accèdent. Les environnements d’IA et de Machine Learning s’exécutant sur Azure sont classés comme ayant un fort impact commercial et sont nécessaires pour respecter un ensemble complet de stratégies et de contrôles ISRM.
Principes de conception
Cette architecture est basée sur les principes suivants :
- L’échelle d’entreprise, une approche architecturale et une implémentation de référence alignée sur la feuille de route Azure, fait partie de Microsoft Cloud Adoption Framework (CAF). Elle permet de construire les zones d’atterrissage sur Azure et de définir les concepts opérationnels correspondants de manière efficace et à grande échelle. Le terme zone d’atterrissage est utilisé comme une limite dans laquelle des applications nouvelles ou migrées atterrissent dans Azure. Dans ce scénario, il fait également référence aux parties de la plateforme de données qui sont utilisées pour héberger les données, les modèles IA et Machine Learning.
- Les architectures de plateforme de données monolithique traditionnelles ont une limitation inhérente qui ralentit la distribution des fonctionnalités et des valeurs. L’architecture décrite ici permet aux entreprises de mettre à l’échelle leur patrimoine de données et de relever les défis d’un lac de données monolithiques centralisé en utilisant une approche décentralisée avec la séparation de la propriété (maillage des données). L’approche permet aux organisations d’évoluer vers des milliers de pipelines d’ingestion et de produits de données, tout en assurant la sécurité et la maintenance de la plateforme de données en dissociant la principale plateforme de données et les services de gestion des données (déployés dans une zone d’atterrissage distincte appelée zone de gestion des données) des domaines de données et des produits de données (déployés sur une ou plusieurs zones d’atterrissage de données).
- Les abonnements sont utilisés en tant qu’unités de gestion et évoluent en fonction des besoins et des priorités de l’entreprise. La mise à l’échelle s’effectue en fournissant de nouveaux abonnements (zones d’atterrissage de données) aux unités commerciales selon des critères tels que les différentes parties prenantes, différents objectifs et exigences commerciaux et des exigences de résidence des données (où les données doivent être hébergées dans une région géographique spécifique).
- Azure Policy est utilisée pour fournir des garde-fous et garantir une conformité continue dans le paysage informatique de l’entreprise.
- Un seul plan de contrôle et de gestion (via le portail Azure) offre une expérience cohérente pour toutes les ressources Azure et les canaux de provisionnement, en fonction de l’accès basé sur les rôles et des contrôles basés sur les stratégies. Les services et fonctionnalités de la plateforme native Azure sont utilisés chaque fois que cela est possible.
- Les équipes qui fonctionnent entre elles prennent possession de la conception, du développement et des opérations pour raccourcir le délai de mise sur le marché et l’agilité au sein de la plate-forme. Les principes de base comme le DevOps, l’Infrastructure en tant que Code (IaC) et les conceptions résilientes sont utilisés pour éviter les erreurs humaines et les points de défaillance uniques.
- Les experts en matière de domaines et de sources de données peuvent utiliser des domaines de données pour extraire des ressources de données d’environnements Azure, tiers ou locaux. Un domaine de données est un groupe de ressources au sein d’une zone d’atterrissage de données que des équipes interfonctionnelles peuvent utiliser pour l’ingestion de données personnalisées. Il peut y avoir un ou plusieurs domaines de données au sein d’une zone d’atterrissage de données. Les domaines de données peuvent être affichés de la même façon que les domaines de la Conception Pilotée par Domaine (DDD) auxquels ils fournissent une limite de contexte et dans lesquels ils sont autonomes et isolés. Un exemple de domaine de données serait les données d’un essai clinique ou d’une chaîne logistique.
Cas d’usage potentiels
Les considérations architecturales abordées dans cet article ont leur source dans les secteurs de la santé et des sciences de la vie. Toutefois, ils sont également pertinents pour les organisations d’autres secteurs réglementés, notamment les suivantes :
- Services financiers
- Prestataires de santé
- Hydrocarbures
L’implémentation de l’analyse à l’échelle de l’entreprise et de l’architecture de référence de l’IA dans des environnements réglementés suit des modèles de conception similaires.
Considérations
Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.
Dans cette section, nous abordons les leçons tirées de l’implémentation de l’architecture décrite précédemment dans l’environnement réglementé des sciences de la vie et des soins de santé. Nous abordons également les considérations de conception de haut niveau pour répondre aux stratégies et contrôles ISRM courants.
Sécurité
La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour plus d’informations, consultez Vue d’ensemble du pilier Sécurité.
Environnements
Dans des environnements réglementés, les systèmes informatiques classés comme ayant un impact commercial élevé doivent disposer de plusieurs environnements distincts, tels que le développement, la qualité et la production, ou similaires. L’accès aux sources de données protégées n’est autorisé que dans les environnements certifiés en production.
Le développement de l’intelligence artificielle et du Machine Learning nécessitant un accès à des jeux de données sensibles, les différentes étapes du processus d’opérations d’apprentissage automatique, telles que la génération de modèle, la formation et l’inférence (ou similaire) sont toutes effectuées en production. Les environnements de développement et de qualité sont généralement limités aux travaux d’infrastructure, d’opérations et d’engineering des données pour garantir des améliorations continues à mesure que de nouveaux services et fonctionnalités Azure sont mis à disposition.
Les activités de développement de l’intelligence artificielle et de la science des données doivent être effectuées dans des environnements de production, à l’exception du bac à sable ou des premiers travaux exploratoires.
Chiffrement
Les systèmes informatiques qui accèdent, stockent et traitent les données sensibles de l’entreprise sont nécessaires pour implémenter des exigences spécifiques en matière de gestion des clés de chiffrement, comme les stratégies FIPS 140-2 de niveau 2 ou de niveau 3, avec intégration des clés Customer-Managed (CMK). Les données protégées doivent toujours être chiffrées au repos et en transit à l’aide de protocoles TLS 1.2 ou plus.
Lors de la conception de l’architecture, une analyse minutieuse de la prise en charge et de l’intégration des services Azure à l’infrastructure CMK d’une organisation est nécessaire. Toutes les exceptions au chiffrement des données doivent être documentées. La prise en charge des fournisseurs de modules de sécurité matériels (HSM) est toujours en cours d’extension et des informations supplémentaires sont disponibles dans le module de sécurité matérielle géré par Azure Key Vault.
Conception du réseau et délimitation des sonneries
Les environnements de l’IA et de l’apprentissage automatique doivent être cloisonnés et une segmentation réseau et des contrôles d’accès réseau implémentés. La communication réseau entre les composants de l’architecture est limitée aux flux de données requis et à l’infrastructure sous-jacente pour fonctionner selon une approche de liste d'autorisation. L’analyse basée sur la signature et l’analyse basée sur le comportement doivent être appliquées.
Appliquer des contrôles d’accès réseau à plusieurs couches de l’architecture, y compris les pare-feux Azure, en inspectant la connectivité réseau entrante et sortante, les groupes de sécurité réseau et l’accès au point de terminaison de l’application Web protégé par le pare-feu d’applications Web (WAF).
Gestion des autorisations
Les environnements IA et Machine Learning s’exécutant sur Azure doivent être intégrés au système de configuration de compte principal d’une organisation, où les demandes d’octroi d’accès aux applications métier critiques sont soumises, approuvées et auditées.
Les systèmes d’approvisionnement de comptes sont censés se connecter aux services Active Directory et Microsoft Entra ID de l’organisation, afin que les rôles d’autorisation métier soient mappés aux groupes de sécurité Active Directory et Microsoft Entra correspondants.
Les environnements d’IA et d’apprentissage automatique suivent un modèle de contrôle d’accès en fonction du rôle. Les autorisations de contrôle de niveau d’accès garantissent que les utilisateurs peuvent uniquement effectuer les tâches et les actions relatives à leur rôle de travail et aux besoins de l’entreprise. Les cas d’utilisation de Machine Learning sont censés être fortement séparés, car les scientifiques de données qui travaillent dans un cas d’usage particulier sont uniquement autorisés à accéder à la partie ressources de ce cas d’usage, à la suite d’un principe de moindre privilège. Ces ressources peuvent inclure les éléments suivants :
- Comptes de stockage
- Espaces de travail Azure Machine Learning
- Calcul des instances
Le contrôle d’accès en fonction du rôle utilise des groupes de sécurité dans Microsoft Entra ID.
Authentification multifacteur
L’authentification multifacteur doit être en place et implémentée pour accéder à tous les environnements s’exécutant sur Azure et classés comme ayant un impact commercial élevé. L’authentification multifacteur peut être appliquée à l’aide des services d’authentification multifacteur de Microsoft Entra. Les points de terminaison d’application, y compris Azure DevOps, le portail de gestion Azure, Azure Machine Learning, Azure Databricks et les services Azure Kubernetes doivent être configurés dans les stratégies de contrôle d’accès par authentification multifacteur.
L’authentification multifacteur doit être appliquée à tous les utilisateurs, y compris les managers de service Azure, les ingénieurs de données et les spécialistes en données.
Excellence opérationnelle
L’excellence opérationnelle couvre les processus d’exploitation qui déploient une application et maintiennent son fonctionnement en production. Pour plus d’informations, consultez Vue d’ensemble du pilier Excellence opérationnelle.
Enregistrement et surveillance
Tous les services Azure doivent recevoir leurs événements de sécurité dans la plateforme du centre d’opérations de sécurité (SOC) d’une organisation, et les événements de sécurité suivants doivent être enregistrés :
- Tentatives d’authentification réussies et ayant échoué
- Accès aux données sensibles
- Modifications apportées à la stratégie de sécurité
- Modifications apportées aux groupes d’utilisateurs administrateur, aux utilisateurs ou aux rôles
- Transferts de données sensibles vers des emplacements externes, le cas échéant
- Activation et désactivation des systèmes de protection, tels que les contrôles ABAC
- Accès mis à jour aux journaux et interruption de la journalisation
Les journaux de sécurité Azure peuvent être ingérés dans le SOC par le biais de différents modèles :
- Espace de travail central Azure Log Analytics
- Event Hub connecté aux systèmes de la plateforme SOC, tels que Splunk
- Machines virtuelles Windows et autres ressources de calcul déployées avec des agents SOC
DevOps
Dans des environnements réglementés, les systèmes informatiques doivent suivre des processus stricts de contrôle de qualité de type cascade, avec des approbations formelles (ou portes) entre les phases de processus, comme les spécifications des besoins des utilisateurs, les spécifications fonctionnelles, les spécifications, la conception et les spécifications de test, ou similaires, avec à l’appui une documentation complète et fastidieuse.
Les environnements Azure et le développement de la science des données suivent les processus itératifs, ancrés dans une culture DevOps. Un effort important dans des initiatives de mise à l’échelle d’IA et de Machine Learning est consacré à la communication des piliers d’une organisation DevOps et à la création d’un mappage de traçabilité automatisé de bout en bout entre les épopées Azure DevOps, les fonctionnalités, les récits utilisateur, les plans de test et les pipelines CI/CD, ainsi qu’aux entités et preuves de contrôle de qualité requises.
Efficacité des performances
L’efficacité des performances est la capacité de votre charge de travail à s’adapter à la demande des utilisateurs de façon efficace. Pour plus d’informations, consultez Vue d’ensemble du pilier d’efficacité des performances.
Pour mettre à l’échelle l’intelligence artificielle et la Machine Learning dans des environnements réglementés, et accélérer l’adoption rapide dans les domaines de l’entreprise, nous vous recommandons de concevoir et de mettre en place une infrastructure d’adoption pour mesurer, surveiller et évaluer la valeur créée par les services Azure. Dans notre exemple de sciences de la vie et du secteur de la santé, les principaux atouts de valeur commerciale et indicateurs de performance clés (KPI) ont été évalués :
Évolutivité : pour s’assurer que l’architecture Azure peut évoluer en même temps que les besoins de l’entreprise, quel que soit le point d’échelle, les indicateurs de performance clés suivants sont suggérés :
- Nombre d’instances de calcul et stockage total et mémoire utilisé
- Nombre d’expériences exécutées
- Nombre de modèles déployés
Accélération du développement de l’IA : pour accélérer le développement de solutions IA et d’apprentissage automatique, les indicateurs de performance clés suivants sont suggérés :
- Nombre d’unités commerciales différentes utilisant les services d’IA et d’apprentissage automatique d’Azure
- Nombre d’utilisateurs intégrés, par catégorie, par exemple, ingénieurs de données, scientifiques des données, scientifiques des données des citoyens et utilisateurs professionnels
- Nombre d’expériences exécutées
- Délai entre l’intégration des utilisateurs et l’utilisation active
- Durée d’approvisionnement des services : de la demande de modification de la configuration à la fin de l’approvisionnement du service
Conformité : pour garantir la conformité continue des solutions d’IA et d’apprentissage automatique déployées, les indicateurs de performance clés suivants sont suggérés :
- Conformité globale avec les contrôles ISRM applicables
- Nombre d’avertissements de vulnérabilité de sécurité
- Nombre d’incidents de sécurité de la dernière période
Expérience utilisateur : pour garantir que les expériences utilisateur de haute qualité et homogènes sont disponibles, les indicateurs de performance clés suivants sont suggérés :
- Nombre de demandes de support technique de l’utilisateur
- Net Promoter Score (NPS)
Fondations sécurisées : pour garantir la sécurité des fondations et sécuriser les fondations, les indicateurs de performance clés suivants sont suggérés :
- Temps d’activité des services critiques
- Nombre d’incidents signalés en rapport avec la disponibilité des performances
Optimisation des coûts
L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d’informations, consultez Vue d’ensemble du pilier d’optimisation des coûts.
La gestion des coûts est une partie importante de la conception de la mise en œuvre des plateformes d’IA et d’apprentissage automatique évolutives car les coûts d’exécution ne suivent pas des modèles simples et prévisibles. Le coût repose essentiellement sur le nombre et la taille des expériences d’IA et d’apprentissage automatique qui sont exécutées dans la plateforme, et plus spécifiquement, sur le nombre et les références SKU des ressources de calcul utilisées dans la formation et l’inférence du modèle.
Voici quelques pratiques que nous recommandons :
- Attribuez à chaque cas d’usage et à chaque produit d’IA et d’apprentissage automatique son propre budget de services Azure, ce qui est une pratique de gestion des coûts correcte.
- Établissez un modèle de coût transparent pour les services partagés de plateforme.
- Utilisez des balises de manière cohérente pour associer les ressources de cas d’usage et de produits aux centres de coûts.
- Utilisez Azure Advisor et le budget Azure pour comprendre où les ressources ne sont pas utilisées de manière optimale et passez en revue les configurations régulièrement.
Contributeurs
Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.
Auteur principal :
- Eran Sagi | Architecte de solutions IA
Étapes suivantes
Découvrez comment entraîner et déployer des modèles, et gérer le cycle de vie du machine learning avec Azure Machine Learning. Des didacticiels, des exemples de code, des référence sur les API, et plus, sont disponibles ici :
Découvrez comment implémenter une zone d’atterrissage à l’échelle de l’entreprise pour l’analytique données et l’intelligence artificielle dans Azure :
Documentation du produit :
Ressources associées
Articles de vue d’ensemble du Centre des architectures Azure :