In dit artikel bespreken we azure-architectuuroverwegingen met betrekking tot de analyse en implementatie van algemene classificatiesets voor hoog risicolagen van ISRM-controles (Information Security Risk Management).
Architectuur
De architectuur wordt in dit diagram weergegeven en volgt het principe van landingszones op ondernemingsniveau, met name de analyse- en AI-referentiearchitectuur op ondernemingsniveau.
Een Visio-bestand van deze architectuur downloaden.
Werkstroom
De architectuur bestaat uit de werkstroom die in de volgende secties wordt beschreven. Elk onderdeel van de architectuur heeft een bijbehorend getal in het diagram. We beschrijven het belangrijkste doel van het onderdeel, hoe deze in de architectuur past en eventuele andere belangrijke overwegingen die u moet nemen bij de overstap:
- Platformabonnementen: kernabonnementen van Azure die beheer, connectiviteit en identiteit bieden via Microsoft Entra-id. Ze worden hier niet uitvoeriger beschreven en worden ervan uitgegaan dat ze gereed en beschikbaar zijn als onderdeel van de basisinstallatie op ondernemingsniveau.
Gegevensbeheer
- Gegevensbeheerzone: de gegevensbeheerzone is verantwoordelijk voor gegevensbeheer op het platform en dwingt kaders af om meer flexibiliteit te bieden in de landingszones voor gegevens. Het heeft een eigen abonnement en host gecentraliseerde services, zoals gegevenscatalogus, bewaking, controles, enzovoort. Deze omgeving wordt zeer gecontroleerd en onderworpen aan strenge controles. Alle typen gegevensclassificatie worden opgeslagen in de centrale gegevenscatalogus (Azure Purview). Afhankelijk van metagegevens worden verschillende beleidsregels en toegangspatronen afgedwongen. Er is slechts één abonnement op de gegevensbeheerzone voor de hele tenant. De gegevensbeheerzone is gekoppeld (via VNET-peering) met alle andere landingszones voor gegevens. Privé-eindpunten worden waar mogelijk gebruikt om ervoor te zorgen dat de geïmplementeerde services niet toegankelijk zijn via openbaar internet.
- Netwerkresourcegroep : virtuele Azure-netwerken, netwerkbeveiligingsgroepen en alle andere netwerkresources die nodig zijn voor de gegevensbeheerzone, worden ingericht in de netwerkresourcegroep.
- Implementatieresourcegroep: een implementatieresourcegroep host privé Azure DevOps CI/CD-agents (virtuele machines) die nodig zijn voor de gegevensbeheerzone en een Key Vault voor het opslaan van eventuele implementatiegerelateerde geheimen.
- Resourcegroep voor gegevensbeheer: Azure Purview wordt gebruikt als een oplossing voor gegevensbeheer en gegevenscatalogus en wordt gebruikt om de benodigde kaders af te dwingen voor gegevenssets om te voldoen aan gegevensvereisten en gegevensvoorschriften die door de wet of andere entiteiten worden opgelegd. Purview wordt centraal gehost in deze resourcegroep, samen met een Key Vault-exemplaar voor het opslaan van geheimen.
- Gecentraliseerde assets : gecentraliseerde assets host belangrijke en waardevolle assets die centraal staan bij het platform, zoals:
- Azure Container-registers die basisinstallatiekopieën hosten die worden gebruikt in op Azure Machine Learning gebaseerde gegevensproducten (installatiekopieën die eerder zijn gescand en zonder beveiligingsproblemen)
- AI/Machine Learning-modellen die worden gepubliceerd en beschikbaar worden gesteld aan consumenten op het platform (zodat ze indien nodig kunnen worden geïmplementeerd in een of meer landingszones voor gegevens).
- Aanvullende services : alle andere services die moeten worden gecentraliseerd, kunnen worden gehost in een van deze resourcegroepen, waaronder gecentraliseerde Azure API Management-exemplaren, software van derden, enzovoort.
- Resourcegroep voor gegevensvisualisatie: deze resourcegroep host oplossingen voor gegevensvisualisatie die worden gedeeld in gegevenslandingszones. Oplossingen kunnen Power BI, Tableau of een andere visualisatieoplossing zijn.
- Aanvullende infrastructuurcontroles en -governance: Microsoft Defender voor Cloud en Azure Monitor worden gebruikt als basislijnbeveiligings- en bewakingsoplossingen.
Zones voor gegevenslanding
Gegevenslandingszone 001 : een datalandingszone is een abonnement dat een schaaleenheid binnen het gegevensplatform vertegenwoordigt. Landingszones voor gegevens worden geïmplementeerd op basis van de architectuur van de kerngegevenslandingszone (blauwdruk), inclusief alle belangrijke mogelijkheden voor het hosten van een analyse- en AI-platform. Er kunnen een of veel landingszones voor gegevens binnen de omgeving zijn. Azure Policy wordt toegepast om de toegang en configuraties van verschillende Azure-services veilig te houden. De landingszone voor gegevens wordt gekoppeld (via VNET-peering) met alle andere landingszones en de gegevensbeheerzone. Privé-eindpunten worden waar mogelijk gebruikt om ervoor te zorgen dat de geïmplementeerde services niet toegankelijk zijn via openbaar internet.
Netwerkresourcegroep : virtuele Azure-netwerken, netwerkbeveiligingsgroepen en alle andere netwerkresources die nodig zijn voor de gegevenslandingszone, worden ingericht binnen deze resourcegroep.
Implementatieresourcegroep: een implementatieresourcegroep host privé Azure DevOps CI/CD-agents (virtuele machines) die nodig zijn voor de gegevenslandingszone en een Key Vault voor het opslaan van eventuele implementatiegerelateerde geheimen.
Resourcegroep voor gegevensopslag: een resourcegroep voor gegevensopslag bevat de belangrijkste gegevensopslagaccounts voor deze gegevenslandingszone, geïmplementeerd als Azure Data Lake Storage Gen2, met hiërarchische naamruimte. Ze zijn verspreid over drie hoofdgebieden:
- Onbewerkt : gegevens worden opgenomen uit de gegevensbron in de oorspronkelijke staat
- Gecureerd en verrijkt – Gegevens worden opgeschoond, gevalideerd en geaggregeerd
- Werkruimte : specifieke gegevensproducten kunnen hun gegevenssets of de uitvoer van de Machine Learning-modellen opslaan, enzovoort
De pijlen in de diagrammen tonen de verwachte gegevensstroom, van onbewerkte gegevens tot gecureerde en verrijkte (vertrouwde) gegevens, en tot werkruimte voor verkenning, analyse en het leveren van extra waarde buiten het gegevensproduct.
Resourcegroep voor gegevensintegratie: de resourcegroep voor gegevensintegratie fungeert als host voor een Azure Data Factory die connectiviteit deelt met de on-premises zelf-hostende Integration Runtime (SHIR). Het belangrijkste doel is om connectiviteit tot stand te brengen. Andere Data Factory-exemplaren gebruiken deze opnieuw, zodat de connectiviteit slechts op één plaats wordt onderhouden. Het andere doel is om de zelf-hostende Integration Runtime voor de Azure Purview-service te hosten, zodat deze toegang heeft tot de gegevensbronnen in deze gegevenslandingszone voor scandoeleinden.
Resourcegroep voor metagegevensbeheer: de resourcegroep voor metagegevensbeheer host metagegevens voor Azure Databricks (het Hive-metaarchief) en Azure Data Factory-opname- en verwerkingspijplijnen. Er wordt ook een Key Vault gehost om geheimen op te slaan voor toegang tot deze gegevens. Azure SQL Database wordt gebruikt voor het hosten van de metagegevens.
Resourcegroep voor gegevensopname: de resourcegroep voor gegevensopname fungeert als host voor een Azure Data Factory-exemplaar waarin alle pijplijnen voor gegevensopname die specifiek zijn voor een gegevensdomein worden geïmplementeerd. Azure Databricks wordt gebruikt als verwerkingsengine om de gegevens te laden en te transformeren en op te slaan in de Data Lake-accounts.
Analyseresourcegroep: de analyseresourcegroep bevat twee gedeelde services voor verdere gegevensanalyse en -verkenning: Azure Synapse en Azure Databricks. Beide services bieden uitgebreide rekenkracht en schaal voor grootschalige gegevensverkenning en analysedoeleinden.
Gegevensproductresourcegroep: de gegevensproductresourcegroep is een blauwdruk voor een gegevensproduct, met een resourcegroep die basisresources van Azure bevat die een gegevensproduct mogelijk nodig heeft. De implementatie moet worden geconfigureerd via een Azure DevOps-pijplijn op basis van de specifieke behoeften van het bedrijf. De belangrijkste Azure-services die hier zijn geïmplementeerd, zijn als volgt:
- Azure Machine Learning-werkruimte als basis voor elk machine learning-project voor ondernemingen met gerelateerde services zoals Key Vault (voor het opslaan van geheimen)
- Application Insights (voor modelbewaking)
- Azure Storage (voor het opslaan van gegevenssets)
- Een Azure Container Registry voor het opslaan van modelinstallatiekopieën tijdens de ontwikkeling
Cognitive Services wordt geïmplementeerd als een bundel om API-toegang te bieden tot meerdere door AI ondersteunde services, en Azure Machine Learning-rekeninstanties en rekenclusters worden gebruikt voor ontwikkelings-, modelbouw- en testdoeleinden. Azure Data Factory wordt gebruikt voor het organiseren van batchgewijs scoren van modellen, indien nodig. Azure-app Service en Azure Cosmos DB bieden een extra laag voor de implementatie van het gegevensproduct, waarbij een aangepaste toepassing of API kan worden gehost met een eigen interne gegevensopslag.
Gereguleerde branches hebben meestal strikte beperkingen voor gegevenstoegang en staan meestal toe dat productiegegevens alleen binnen de productieomgeving worden gehost. Daarom vindt de ontwikkelingslevenscyclus van gegevensproducten alleen plaats in de landingszone voor productiegegevens en wordt er een afzonderlijke omgeving, of resourcegroep, ingericht voor ontwikkelings-, test- en implementatiedoeleinden.
Aanvullende gegevensproducten : deze resourcegroepen hosten andere gegevensproducten, omdat één gegevenslandingszone een of meer gegevensproducten kan hosten.
Gedeelde rekenresourcegroep : gedeelde berekeningen die nodig zijn voor het hosten en implementeren van gegevensproducten, worden ingericht binnen deze resourcegroep. Een Azure Kubernetes Service-cluster is een voorbeeld.
Aanvullende infrastructuurcontroles en -governance: Microsoft Defender voor Cloud en Azure Monitor worden gebruikt als basislijnbeveiligings- en bewakingsoplossingen.
Gegevenslandingszone 002 : deze landingszone is een tijdelijke aanduiding voor extra Azure-abonnementen die worden gebruikt voor het hosten van nieuwe landingszones voor gegevens. Ze zijn gebaseerd op criteria die eerder worden vermeld, zoals vereisten voor gegevenslocatie of een andere bedrijfseenheid met een eigen functieteam en een set gebruiksvoorbeelden die moeten worden geleverd.
Onderdelen
- Microsoft Entra ID
- Azure Purview
- Azure Virtual Network
- Azure DevOps
- Azure Container Registry
- Azure Machine Learning
- Microsoft Defender voor Cloud
- Azure Monitor
- Azure Policy
- Azure Data Lake Storage
- Azure Data Factory
- Azure SQL-database
- Azure Databricks
- Azure Synapse Analytics
- Azure Kubernetes Service
Alternatieven
In gedistribueerde organisaties werken bedrijfsgroepen onafhankelijk en met hoge mate van autonomie. Daarom kunnen ze een alternatief oplossingsontwerp overwegen, met volledige isolatie van gebruiksvoorbeelden in Azure-landingszones, waarbij een minimale set algemene services wordt gedeeld. Hoewel dit ontwerp snel aan de slag kan gaan, vergt het veel moeite van IT- en ISRM-organisaties, omdat het ontwerp van afzonderlijke gebruiksvoorbeelden snel kan afwijken van blauwdrukontwerpen. Daarnaast zijn onafhankelijke ISRM-processen en -controles vereist voor elk van de AI- en Machine Learning-producten die worden gehost in Azure.
Scenariodetails
Het schalen van AI- en machine learning-initiatieven in gereguleerde omgevingen vormt belangrijke uitdagingen voor organisaties, ongeacht hun digitale volwassenheid en grootte. In dit artikel bespreken we belangrijke beslissingen over architectuur om rekening mee te houden bij het aannemen van data engineering- en machine learning-services van Azure in gereguleerde branches. Deze beslissingen zijn gebaseerd op wat is geleerd van een recente implementatie in een Fortune 500 global life sciences and healthcare company.
De architectuur die in dit artikel wordt gepresenteerd, volgt het ontwerp van analyse op ondernemingsniveau en ai-referentiearchitectuur en was een van de eerste implementaties.
Als u data science-projecten instelt en machine learning-modellen ontwikkelt in life sciences- en gezondheidszorgomgevingen, hebt u in bijna alle gevallen toegang nodig tot HBI-gegevensbronnen (High Business Impact). Deze bronnen kunnen bijvoorbeeld informatie over het klinische proefprotocol zijn zonder patiëntgegevens, chemische formules van het molecuul of productieprocessengeheimen.
In gereguleerde branches worden IT-systemen geclassificeerd op basis van de classificatie van de gegevensbronnen die toegang hebben tot die systemen. AI- en machine learning-omgevingen die worden uitgevoerd in Azure, worden geclassificeerd als HBI en moeten voldoen aan een uitgebreide set ISRM-beleidsregels en -controles.
Ontwerpbeginselen
Deze architectuur is gebaseerd op de volgende principes:
- Ondernemingsniveau is een architectuurbenadering en een referentie-implementatie die is afgestemd op de Azure-roadmap en een deel van het Microsoft Cloud Adoption Framework (CAF). Het maakt effectieve bouw en operationalisatie van landingszones in Azure mogelijk, op schaal. De naamlandingszone wordt gebruikt als grens waarin nieuwe of gemigreerde toepassingen in Azure terechtkomen. In dit scenario verwijst het ook naar delen van het gegevensplatform die worden gebruikt voor het hosten van de gegevens en de AI- en Machine Learning-modellen.
- Traditionele monolithische gegevensplatformarchitecturen hebben een inherente beperking die de levering van functies en waarden vertraagt. Met de architectuur die hier wordt beschreven, kunnen organisaties hun gegevensdomein schalen en de uitdagingen van een gecentraliseerde monolithische data lake aanpakken met behulp van een gedecentraliseerde benadering met scheiding van eigendom (data mesh). Met deze benadering kunnen organisaties schalen naar duizenden opnamepijplijnen en gegevensproducten, terwijl het gegevensplatform veilig en onderhoudbaar blijft door het kerngegevensplatform en de services voor gegevensbeheer (geïmplementeerd in een afzonderlijke landingszone, gegevensbeheerzone genoemd), te ontkoppelen van gegevensdomeinen en gegevensproducten (geïmplementeerd in een of meer datalandingszones).
- Abonnementen worden gebruikt als beheer- en schaaleenheden die zijn afgestemd op bedrijfsbehoeften en -prioriteiten. Schalen wordt bereikt door nieuwe abonnementen (landingszones voor gegevens) aan bedrijfseenheden te bieden op basis van criteria zoals verschillende zakelijke belanghebbenden, verschillende bedrijfsdoelen en vereisten voor gegevenslocatie (waar gegevens moeten worden gehost in een specifieke geografische regio).
- Azure Policy wordt gebruikt om kaders te bieden en ervoor te zorgen dat het IT-landschap van het bedrijf blijft voldoen.
- Eén besturings- en beheervlak (via Azure Portal) biedt een consistente ervaring voor alle Azure-resources en inrichtingskanalen die onderhevig zijn aan op rollen gebaseerde toegang en beleidsgestuurde besturingselementen. Waar mogelijk worden systeemeigen platformservices en -mogelijkheden van Azure gebruikt.
- Functieoverschrijdende teams nemen het eigendom van het ontwerp, de ontwikkeling en de activiteiten om de markt en de flexibiliteit binnen het platform te verkorten. Kernprincipes zoals DevOps, Infrastructure as Code (IaC) en tolerante ontwerpen worden gebruikt om menselijke fouten en single points of failure te voorkomen.
- Domein- en gegevensbronexperts kunnen gegevensdomeinen gebruiken om gegevensassets op te halen uit Azure, externe of on-premises omgevingen. Een gegevensdomein is een resourcegroep binnen een gegevenslandingszone die functieoverschrijdende teams kunnen gebruiken voor aangepaste gegevensopname. Er kunnen een of veel gegevensdomeinen zijn binnen een gegevenslandingszone. Gegevensdomeinen kunnen op dezelfde manier worden weergegeven als domeinen in Domeingestuurd ontwerp, waar ze een contextgrens bieden en zelfvoorzienend en geïsoleerd zijn. Een voorbeeld van een gegevensdomein zijn klinische proefgegevens of supply chain-gegevens.
Potentiële gebruikscases
De architectuuroverwegingen die in dit artikel worden besproken, hebben hun bron in de levenswetenschappen en gezondheidszorg. Ze zijn echter ook relevant voor organisaties in andere gereglementeerde branches, waaronder deze branches:
- Financiële dienstverlening
- Zorgaanbieders
- Olie en gas
Implementatie van analyse op ondernemingsniveau en AI-referentiearchitectuur in gereguleerde omgevingen volgt vergelijkbare ontwerppatronen.
Overwegingen
Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.
In deze sectie bespreken we lessen die zijn geleerd uit de implementatie van de architectuur die eerder is beschreven in een life sciences and healthcare regulated environment. We hebben ook aandacht voor ontwerpoverwegingen op hoog niveau om te voldoen aan algemene ISRM-besturingselementen en -beleidsregels.
Beveiliging
Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie Overzicht van de beveiligingspijler voor meer informatie.
Omgevingen
In gereguleerde omgevingen zijn IT-systemen die als HBI zijn geclassificeerd, vereist om meerdere gescheiden omgevingen te hebben, zoals ontwikkeling, kwaliteit en productie, of vergelijkbaar. Toegang tot beveiligde gegevensbronnen is alleen geautoriseerd in productie-gecertificeerde omgevingen.
Omdat ai- en machine learning-ontwikkeling toegang nodig heeft tot gevoelige gegevenssets, vinden de verschillende fasen van het machine learning-bewerkingsproces, zoals het bouwen, trainen en deductie (of vergelijkbaar), allemaal in productie plaats. Ontwikkel- en kwaliteitsomgevingen zijn doorgaans beperkt tot infrastructuur-, bewerkings- en data engineering-type werk, om ervoor te zorgen dat er continue verbeteringen worden aangebracht naarmate er nieuwe Azure-services en -functies beschikbaar komen.
Ai- en data science-ontwikkelingsactiviteiten moeten worden uitgevoerd in productieomgevingen, met uitzondering van sandbox- of vroege verkennende werkzaamheden.
Versleuteling
IT-systemen die gevoelige bedrijfsgegevens openen, opslaan en verwerken, zijn vereist voor het implementeren van specifieke vereisten voor het beheer van versleutelingssleutels, zoals FIPS 140-2-beleid op niveau 2 of niveau 3, met CMK-integratie (Customer Managed Keys). Beveiligde gegevens moeten altijd at-rest en in transit worden versleuteld met behulp van TLS 1.2- of hogere protocollen.
Tijdens het ontwerpen van de architectuur is een zorgvuldige analyse van de ondersteuning en integratie van Azure-services met de CMK-infrastructuur van een organisatie vereist. Eventuele uitzonderingen op gegevensversleuteling moeten worden gedocumenteerd. Ondersteuning voor HSM-leveranciers (Hardware Security Module) wordt altijd uitgebreid en aanvullende informatie vindt u in azure Key Vault Managed Hardware Security Module.
Netwerkontwerp en ringafscherming
AI- en machine learning-omgevingen moeten ringafscherming hebben, waarbij netwerksegmentatie en netwerktoegangsbeheer zijn geïmplementeerd. Netwerkcommunicatie tussen architectuuronderdelen is beperkt tot vereiste gegevensstromen en onderliggende infrastructuur om te functioneren in een acceptatielijstbenadering. Analyse op basis van handtekeningen en analyse op basis van gedrag moet worden toegepast.
Netwerktoegangsbeheer afdwingen in verschillende lagen in de architectuur, waaronder Azure Firewalls, het inspecteren van binnenkomende en uitgaande netwerkconnectiviteit, netwerkbeveiligingsgroepen en toegang tot webtoepassingseindpunt dat is beveiligd met Web Application Firewall (WAF).
Autorisatiebeheer
AI- en machine learning-omgevingen die worden uitgevoerd in Azure, moeten worden geïntegreerd met het hoofdaccountinrichtingssysteem van een organisatie, waarbij aanvragen voor het verlenen van toegang tot kritieke bedrijfstoepassingen worden ingediend, goedgekeurd en gecontroleerd.
Accountinrichtingssystemen worden naar verwachting verbonden met de Active Directory- en Microsoft Entra-id van een organisatie, zodat bedrijfsautorisatierollen worden toegewezen aan bijbehorende Active Directory- en Microsoft Entra-beveiligingsgroepen.
AI- en machine learning-omgevingen volgen een op rollen gebaseerd toegangsbeheermodel. Autorisaties voor toegangsniveaubeheer zorgen ervoor dat gebruikers alleen de taken en acties voor hun functie en bedrijfsvereiste kunnen uitvoeren. Machine learning-gebruiksscenario's worden naar verwachting hoog gescheiden, omdat gegevenswetenschappers die in een bepaalde use-case werken alleen toegang hebben tot het resourcesgedeelte van die use case, volgens een principe van minimale bevoegdheden. Deze resources kunnen het volgende omvatten:
- Opslagaccounts
- Azure Machine Learning-werkruimten
- Rekenexemplaren
Op rollen gebaseerd toegangsbeheer maakt gebruik van beveiligingsgroepen in Microsoft Entra ID.
Meervoudige verificatie
Meervoudige verificatie moet aanwezig zijn en geïmplementeerd voor toegang tot alle omgevingen die worden uitgevoerd in Azure en geclassificeerd als een hoge bedrijfsimpact. Meervoudige verificatie kan worden afgedwongen met microsoft Entra-services voor meervoudige verificatie. Toepassingseindpunten, waaronder Azure DevOps, Azure Management Portal, Azure Machine Learning, Azure Databricks en Azure Kubernetes Services, moeten worden geconfigureerd in beleidsregels voor meervoudige verificatietoegangsbeheer.
Meervoudige verificatie moet worden afgedwongen voor alle gebruikers, waaronder Azure-servicemanagers, data engineers en gegevenswetenschappers.
Operationele uitmuntendheid
Operationele uitmuntendheid omvat de operationele processen die een toepassing implementeren en deze in productie houden. Zie Overzicht van de operationele uitmuntendheidpijler voor meer informatie.
Logboekregistratie en controle
Alle Azure-services moeten hun beveiligingsgebeurtenissen opnemen in het SOC-platform (Security Operations Center) van een organisatie en de volgende beveiligingsgebeurtenissen moeten worden vastgelegd:
- Geslaagde en mislukte verificatiepogingen
- Toegang tot gevoelige gegevens
- Wijzigingen in beveiligingsbeleid
- Wijzigingen in gebruikersgroepen, gebruikers of rollen voor beheerders
- Gevoelige gegevensoverdracht naar externe locaties, indien van toepassing
- Activering en deactivering van beveiligingssystemen, zoals ABAC-besturingselementen
- Bijgewerkte toegang tot logboeken en onderbreking van logboekregistratie
Azure-beveiligingslogboeken kunnen worden opgenomen in SOC via verschillende patronen:
- Een centrale Azure Log Analytics-werkruimte
- Event Hub verbonden met SOC-platformsystemen, zoals Splunk
- Windows-VM en andere rekenresources die zijn geïmplementeerd met SOC-agents
DevOps
In gereguleerde omgevingen moeten IT-systemen strikte kwaliteitscontroleprocessen in watervalstijl volgen, met formele goedkeuringen (of poorten) tussen procesfasen, zoals specificaties van gebruikersvereisten, functionele specificaties, ontwerp en testspecificaties, of vergelijkbaar, met uitgebreide en tijdrovende ondersteunende documentatie.
Azure-omgevingen en data science-ontwikkeling volgen iteratieve processen, verankerd in een DevOps-cultuur. Een aanzienlijke inspanning bij het schalen van AI- en machine learning-initiatieven wordt besteed aan het communiceren van de pijlers van een DevOps-organisatie en het maken van geautomatiseerde end-to-end traceringstoewijzing tussen Azure DevOps epics, functies, gebruikersverhalen, testplannen en CI/CD-pijplijnen, en vereiste entiteiten en bewijsmateriaal voor kwaliteitscontrole.
Prestatie-efficiëntie
Prestatie-efficiëntie is de mogelijkheid om op efficiënte wijze uw werkbelasting te schalen om te voldoen aan de vereisten die gebruikers eraan stellen. Zie overzicht van de pijler Prestatie-efficiëntie voor meer informatie.
Voor het schalen van AI en machine learning in gereguleerde omgevingen en het stimuleren van snelle acceptatie binnen de bedrijfsgebieden van de organisatie, raden we u aan een implementatieframework te ontwerpen en in te stellen om de waarde te meten, bewaken en evalueren die door de Azure-services is gemaakt. Uit ons voorbeeld van life sciences en gezondheidszorg zijn de volgende levers voor bedrijfswaarde en key performance indicators (KPI) geëvalueerd:
Schaalbaarheid: om ervoor te zorgen dat Azure-architectuur kan worden geschaald naast zakelijke vereisten, ongeacht het schaalpunt, worden de volgende KPI's voorgesteld:
- Aantal rekeninstanties en totale gebruikte opslag en geheugen
- Aantal uitgevoerde experimenten
- Aantal geïmplementeerde modellen
Versnelling van AI-ontwikkeling : om de ontwikkeling van AI- en machine learning-oplossingen te versnellen, worden de volgende KPI's voorgesteld:
- Aantal verschillende bedrijfseenheden dat de AI- en machine learning-services van Azure gebruikt
- Aantal gebruikers dat is voorbereid, per categorie, bijvoorbeeld data engineers, gegevenswetenschappers, burgergegevenswetenschappers en zakelijke gebruikers
- Aantal uitgevoerde experimenten
- Tijd tussen onboarding van gebruikers en actief gebruik
- Tijd om services in te richten: van wijzigingsconfiguratieaanvraag tot voltooiing van serviceinrichting
Naleving : om continue naleving van geïmplementeerde AI- en machine learning-oplossingen te garanderen, worden de volgende KPI's voorgesteld:
- Algehele compatibiliteit met toepasselijke ISRM-besturingselementen
- Aantal beveiligingswaarschuwingen voor beveiligingsproblemen
- Aantal beveiligingsincidenten voor de afgelopen periode
Gebruikerservaring : om ervoor te zorgen dat hoge kwaliteit en consistente gebruikerservaringen beschikbaar zijn, worden de volgende KPI's voorgesteld:
- Aantal helpdeskaanvragen van gebruikers
- Net Promoter Score (NPS)
Veilige basisbeginselen: om veilige en veilige fundamenten te garanderen, worden de volgende KPI's voorgesteld:
- Uptime van kritieke services
- Aantal incidenten dat is gerapporteerd met betrekking tot de beschikbaarheid van prestaties
Kostenoptimalisatie
Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie Overzicht van de pijler kostenoptimalisatie voor meer informatie.
Kostenbeheer is een belangrijk onderdeel van het ontwerp in de implementatie van schaalbare AI- en machine learning-platformen, omdat lopende kosten geen eenvoudige en voorspelbare patronen volgen. De kosten worden voornamelijk bepaald door het aantal en de grootte van de AI- en machine learning-experimenten die in het platform worden uitgevoerd, en meer specifiek op het aantal en de SKU's van de rekenresources die worden gebruikt in modeltraining en deductie.
Hier volgen enkele procedures die we aanbevelen:
- Wijs elk use-case- en AI- en machine learning-product een eigen Azure-servicesbudget toe. Dit is een goede procedure voor kostenbeheer.
- Stel een transparant kostenmodel in voor gedeelde platformservices.
- Gebruik tags consistent om use-case- en productbronnen te koppelen aan kostenplaatsen.
- Gebruik Azure Advisor en Azure Budget om te begrijpen waar resources niet op de meest optimale manier worden gebruikt en om regelmatig configuraties te controleren.
Bijdragers
Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.
Hoofdauteur:
- Eran Sagi | AI-oplossingsarchitect
Volgende stappen
Meer informatie over het trainen en implementeren van modellen en het beheren van de levenscyclus van machine learning met Azure Machine Learning. Zelfstudies, codevoorbeelden, API-verwijzingen en meer, die hier beschikbaar zijn:
Meer informatie over het implementeren van een landingszone op ondernemingsniveau voor gegevensanalyse en AI in Azure:
Productdocumentatie:
Verwante resources
Overzichtsartikelen van Azure Architecture Center: