I den här artikeln diskuterar vi arkitekturöverväganden i Azure som rör analys och implementering av vanliga ISRM-kontroller (high-risk tier classification set of information security risk management).
Arkitektur
Arkitekturen visas i det här diagrammet och följer principen för landningszoner i företagsskala, särskilt analys i företagsskala och AI-referensarkitektur.
Ladda ned en Visio-fil med den här arkitekturen.
Arbetsflöde
Arkitekturen består av arbetsflödet som beskrivs i följande avsnitt. Varje komponent i arkitekturen har ett motsvarande tal i diagrammet. Vi beskriver huvudsyftet med komponenten, hur den passar in i arkitekturen och andra viktiga överväganden som du bör tänka på när du antar den:
- Plattformsprenumerationer – Grundläggande Azure-prenumerationer som tillhandahåller hantering, anslutning och identitet via Microsoft Entra-ID. De beskrivs inte här mer detaljerat och antas vara redo och tillgängliga som en del av konfigurationen i företagsskala.
Datahantering
- Datahanteringszon – Datahanteringszonen ansvarar för datastyrning över hela plattformen och framtvingar skyddsräcken för att ge mer flexibilitet nedströms i datalandningszonerna. Den har en egen prenumeration och är värd för centraliserade tjänster som datakatalogering, övervakning, granskningar och så vidare. Den här miljön är mycket kontrollerad och föremål för stränga granskningar. Alla dataklassificeringstyper lagras i den centrala datakatalogen (Azure Purview). Beroende på metadata tillämpas olika principer och åtkomstmönster. Det finns bara en prenumeration på datahanteringszonen för hela klientorganisationen. Datahanteringszonen peerkopplas (via VNET-peering) med alla andra datalandningszoner. Privata slutpunkter används när det är möjligt för att säkerställa att de distribuerade tjänsterna inte är tillgängliga via offentligt Internet.
- Nätverksresursgrupp – Azure Virtual Networks, nätverkssäkerhetsgrupper och alla andra nätverksrelaterade resurser som behövs för datahanteringszonen etableras i nätverksresursgruppen.
- Distributionsresursgrupp – En distributionsresursgrupp är värd för privata Azure DevOps CI/CD-agenter (virtuella datorer) som behövs för datahanteringszonen och ett Nyckelvalv för lagring av eventuella distributionsrelaterade hemligheter.
- Resursgrupp för datastyrning – Azure Purview används som en datastyrnings- och datakataloglösning och används för att framtvinga nödvändiga skyddsmekanismer för datauppsättningar för att följa datakrav och dataregler som införs av lag eller andra entiteter. Purview finns centralt i den här resursgruppen, tillsammans med en Key Vault-instans för lagring av hemligheter.
- Centraliserade tillgångar – Centraliserade tillgångar är värdar för viktiga och värdefulla tillgångar som är centrala för plattformen, till exempel:
- Azure Container Registries som är värd för basavbildningar som används i Azure Machine Learning-baserade dataprodukter (bilder som tidigare genomsökts och är sårbarhetsfria)
- AI/Machine Learning-modeller som publiceras och görs tillgängliga för konsumenter på plattformen (så att de kan distribueras till en eller flera datalandningszoner om det behövs).
- Ytterligare tjänster – alla andra tjänster som ska centraliseras kan finnas i någon av dessa resursgrupper, som kan innehålla centraliserade Azure API Management-instanser, programvara från tredje part och så vidare.
- Resursgrupp för datavisualisering – Den här resursgruppen är värd för datavisualiseringslösningar som delas mellan datalandningszoner. Lösningar kan vara Power BI, Tableau eller någon annan visualiseringslösning.
- Ytterligare infrastrukturkontroller och styrning – Microsoft Defender för molnet och Azure Monitor används som säkerhets- och övervakningslösningar för baslinjen.
Datalandningszoner
Datalandningszon 001 – En datalandningszon är en prenumeration som representerar en skalningsenhet inom dataplattformen. Datalandningszoner distribueras baserat på kärnarkitekturen för datalandningszoner (skiss), inklusive alla viktiga funktioner som värd för en analys- och AI-plattform. Det kan finnas en eller flera datalandningszoner i miljön. Azure Policy används för att skydda åtkomst och konfigurationer av olika Azure-tjänster. Datalandningszonen peerkopplas (via VNET-peering) med alla andra datalandningszoner och datahanteringszonen. Privata slutpunkter används när det är möjligt för att säkerställa att de distribuerade tjänsterna inte är tillgängliga via offentligt Internet.
Nätverksresursgrupp – Azure Virtual Networks, nätverkssäkerhetsgrupper och alla andra nätverksrelaterade resurser som behövs för datalandningszonen etableras i den här resursgruppen.
Distributionsresursgrupp – En distributionsresursgrupp är värd för privata Azure DevOps CI/CD-agenter (virtuella datorer) som behövs för datalandningszonen och ett Nyckelvalv för lagring av eventuella distributionsrelaterade hemligheter.
Datalagringsresursgrupp – En datalagringsresursgrupp innehåller de viktigaste datalagringskontona för den här datalandningszonen, distribuerad som Azure Data Lake Storage Gen2, med hierarkiskt namnområde. De är spridda över tre huvudområden:
- Rådata – Data matas in från datakällan i sitt ursprungliga tillstånd
- Kuraterad och berikad – Data rensas, verifieras och aggregeras
- Arbetsyta – Specifika dataprodukter kan lagra sina datamängder eller utdata från Machine Learning-modellerna och så vidare
Pilarna i diagrammen visar det förväntade dataflödet, från rådata till kuraterade och berikade (betrodda) data och över till arbetsytan för utforskning, analys och extra värde från dataprodukten.
Resursgrupp för dataintegrering – Resursgruppen för dataintegrering är värd för en Azure Data Factory som delar anslutningen med den lokala lokalt lokalt installerade integrationskörningen (SHIR). Dess huvudsakliga syfte är att upprätta anslutningar. Andra Data Factory-instanser återanvänder den så att anslutningen endast underhålls på ett ställe. Det andra syftet är att vara värd för den lokalt installerade integrationskörningen för Azure Purview-tjänsten så att den kan komma åt datakällorna i den här datalandningszonen i genomsökningssyfte.
Resursgrupp för metadatahantering – Resursgruppen för metadatahantering är värd för metadata för Azure Databricks (Hive-metaarkivet) och Azure Data Factory-inmatnings- och bearbetningspipelines. Det är också värd för ett Key Vault för att lagra hemligheter för åtkomst till dessa data. Azure SQL Database används som värd för metadata.
Datainmatningsresursgrupp – Resursgruppen för datainmatning är värd för en Azure Data Factory-instans där alla pipelines för datainmatning som är specifika för en datadomän distribueras. Azure Databricks används som en bearbetningsmotor för att läsa in och transformera data och lagra dem i datasjökontona.
Resursgrupp för analys – Analysresursgruppen innehåller två delade tjänster för ytterligare dataanalys och utforskning: Azure Synapse och Azure Databricks. Båda dessa tjänster tillhandahåller omfattande beräkning och skalning för massiv datautforskning och analys.
Resursgrupp för dataprodukt – Dataproduktresursgruppen är en skiss för en dataprodukt, med en resursgrupp som innehåller grundläggande Azure-resurser som en dataprodukt kan behöva. Distributionen bör konfigureras via en Azure DevOps-pipeline baserat på verksamhetens specifika behov. De grundläggande Azure-tjänster som distribueras här är följande:
- Azure Machine Learning-arbetsyta som grund för alla företagsprojekt för maskininlärning med relaterade tjänster, till exempel Key Vault (för lagring av hemligheter)
- Application Insights (för modellövervakning)
- Azure Storage (för att lagra datauppsättningar)
- Ett Azure Container Registry för lagring av modellavbildningar under utveckling
Cognitive Services distribueras som ett paket för att ge API-åtkomst till flera AI-backade tjänster, och Azure Machine Learning-beräkningsinstanser och beräkningskluster används för utveckling, modellskapande och testning. Azure Data Factory används för att samordna batchbedömning av modeller om det behövs. Azure App Service och Azure Cosmos DB ger ett extra lager för distribution av dataprodukten, där ett anpassat program eller API kan hanteras med ett eget internt datalager.
Reglerade branscher har vanligtvis strikta dataåtkomstbegränsningar och tillåter vanligtvis att produktionsdata endast hanteras i produktionsmiljön. Därför sker utvecklingslivscykeln för dataprodukter endast i landningszonen för produktionsdata, och en separat miljö, eller resursgrupp, etableras för utvecklings-, testnings- och distributionsändamål.
Ytterligare dataprodukter – Dessa resursgrupper är värdar för andra dataprodukter, eftersom en datalandningszon kan vara värd för en eller flera dataprodukter.
Resursgrupp för delad beräkning – All delad beräkning som behövs för att vara värd för och distribuera dataprodukter etableras i den här resursgruppen. Ett Azure Kubernetes Service-kluster är ett exempel.
Ytterligare infrastrukturkontroller och styrning – Microsoft Defender för molnet och Azure Monitor används som säkerhets- och övervakningslösningar för baslinjen.
Datalandningszon 002 – Den här landningszonen är en platshållare för extra Azure-prenumerationer som skulle användas som värd för nya datalandningszoner. De baseras på kriterier som nämnts tidigare, till exempel krav på datahemvist eller en annan affärsenhet som har ett eget tvärfunktionellt team och en uppsättning användningsfall som ska levereras.
Komponenter
- Microsoft Entra ID
- Azure Purview
- Azure Virtual Network
- Azure DevOps
- Azure Container Registry
- Azure Machine Learning
- Microsoft Defender för molnet
- Azure Monitor
- Azure Policy
- Azure Data Lake Storage
- Azure Data Factory
- Azure SQL Database
- Azure Databricks
- Azure Synapse Analytics
- Azure Kubernetes Service
Alternativ
I distribuerade organisationer arbetar företagsgrupper självständigt och med hög grad av autonomi. Därför kan de överväga en alternativ lösningsdesign med fullständig isolering av användningsfall i Azure-landningszoner och dela en minimal uppsättning vanliga tjänster. Även om den här designen ger en snabb start kräver den stor ansträngning från IT- och ISRM-organisationer, eftersom designen av enskilda användningsfall snabbt kan skilja sig från skissdesign. Dessutom krävs oberoende ISRM-processer och granskningar för var och en av AI- och Machine Learning-produkterna som finns i Azure.
Information om scenario
Att skala AI- och maskininlärningsinitiativ i reglerade miljöer innebär stora utmaningar för organisationer, oavsett digital mognad och storlek. I den här artikeln diskuterar vi viktiga arkitektoniska beslut att tänka på när du antar Azures datateknik- och maskininlärningstjänster i reglerade branscher. Dessa beslut baseras på vad som lärdes från en nyligen genomförd implementering i ett globalt biovetenskaps- och hälsovårdsföretag på Fortune 500.
Arkitekturen som presenteras i den här artikeln följer designen för analys och AI-referensarkitektur i företagsskala och var en av de första implementeringarna.
Om du konfigurerar datavetenskapsprojekt och utvecklar maskininlärningsmodeller i life science- och sjukvårdsmiljöer behöver du i nästan alla fall tillgång till HBI-datakällor (high business impact). Dessa källor kan till exempel vara information om protokoll för kliniska prövningar utan patientdata, molekylens kemiska formler eller tillverkningsprocesshemligheter.
I reglerade branscher klassificeras IT-system baserat på klassificeringen av de datakällor som dessa system har åtkomst till. AI- och maskininlärningsmiljöer som körs i Azure klassificeras som HBI och måste följa en omfattande uppsättning ISRM-principer och kontroller.
Designprinciper
Den här arkitekturen baseras på följande principer:
- Företagsskala är en arkitekturmetod och en referensimplementering i linje med Azure-översikten och en del av Microsoft Cloud Adoption Framework (CAF). Det möjliggör effektiv konstruktion och driftsättning av landningszoner i Azure i stor skala. Namnlandningszonen används som en gräns där nya eller migrerade program hamnar i Azure. I det här scenariot refererar det också till delar av dataplattformen som används som värd för data och AI- och Machine Learning-modellerna.
- Traditionella monolitiska dataplattformsarkitekturer har en inbyggd begränsning som saktar ned leveransen av funktioner och värden. Arkitekturen som beskrivs här låter organisationer skala sin dataegendom och hantera utmaningarna med en centraliserad monolitisk datasjö med hjälp av en decentraliserad metod med uppdelning av ägarskap (datanät). Metoden gör att organisationer kan skala till tusentals inmatningspipelines och dataprodukter, samtidigt som dataplattformen hålls säker och underhållsbar genom att frikoppla kärndataplattformen och datahanteringstjänster (distribuerade i en separat landningszon som kallas datahanteringszon) från datadomäner och dataprodukter (distribuerade till en eller flera datalandningszoner).
- Prenumerationer används som hanteringsenheter och skalas i enlighet med affärsbehov och prioriteringar. Skalning uppnås genom att tillhandahålla nya prenumerationer (datalandningszoner) till affärsenheter baserat på kriterier som olika affärsintressenter, olika affärsmål och krav och krav på datahemvist (där data måste finnas i en specifik geo-region).
- Azure Policy används för att tillhandahålla skyddsräcken och säkerställa fortsatt efterlevnad i företagets IT-landskap.
- Ett enda kontroll- och hanteringsplan (via Azure-portalen) ger en konsekvent upplevelse för alla Azure-resurser och etableringskanaler som omfattas av rollbaserad åtkomst och principdrivna kontroller. Azure-inbyggda plattformstjänster och funktioner används när det är möjligt.
- Tvärfunktionella team tar ansvar för design, utveckling och drift för att förkorta tiden till marknaden och flexibiliteten inom plattformen. Grundläggande principer som DevOps, Infrastruktur som kod (IaC) och elastiska design används för att undvika mänskliga fel och enskilda felpunkter.
- Experter på ämnesämnen för domäner och datakällor kan använda datadomäner för att hämta datatillgångar från Azure, tredje part eller lokala miljöer. En datadomän är en resursgrupp inom en datalandningszon som korsfunktionella team kan använda för anpassad datainmatning. Det kan finnas en eller flera datadomäner i en datalandningszon. Datadomäner kan visas på samma sätt som domäner i domändriven design där de tillhandahåller en kontextgräns och är självförsörjande och isolerade. Ett exempel på en datadomän skulle vara data från kliniska prövningar eller leveranskedjedata.
Potentiella användningsfall
De arkitekturöverväganden som beskrivs i den här artikeln har sin källa inom life science- och hälsovårdsindustrin. De är dock också relevanta för organisationer i andra reglerade branscher, inklusive dessa branscher:
- Financial services
- Vårdgivare
- Olja och gas
Implementeringen av analys i företagsskala och AI-referensarkitektur i reglerade miljöer följer liknande designmönster.
Att tänka på
Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.
I det här avsnittet diskuterar vi lärdomar från implementeringen av arkitekturen som beskrevs tidigare i en biovetenskaplig och hälso- och sjukvårdsreglerad miljö. Vi tar även upp designöverväganden på hög nivå för att uppfylla vanliga ISRM-kontroller och principer.
Säkerhet
Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.
Miljöer
I reglerade miljöer måste IT-system som klassificeras som HBI ha flera åtskilda miljöer, till exempel utveckling, kvalitet och produktion eller liknande. Åtkomst till skyddade datakällor är endast auktoriserad i produktionscertifierade miljöer.
Eftersom AI- och maskininlärningsutveckling kräver åtkomst till känsliga datauppsättningar sker de olika stegen i processen för maskininlärningsåtgärder, till exempel modellbygge, utbildning och slutsatsdragning (eller liknande), i produktion. Utvecklings- och kvalitetsmiljöer är vanligtvis begränsade till infrastruktur, drift och datateknik för att säkerställa kontinuerliga förbättringar när nya Azure-tjänster och funktioner blir tillgängliga.
AI- och datavetenskapsutvecklingsaktiviteter bör utföras i produktionsmiljöer, med undantag för sandbox-miljö eller tidigt utforskande arbete.
Kryptering
IT-system som kommer åt, lagrar och bearbetar känsliga affärsdata krävs för att implementera specifika krav för hantering av krypteringsnycklar, till exempel FIPS 140-2-principer på nivå 2 eller nivå 3, med integrering av kundhanterade nycklar (CMK). Skyddade data måste alltid krypteras i vila och under överföring med TLS 1.2 eller senare protokoll.
Under arkitekturdesignen krävs en noggrann analys av stöd och integrering av Azure-tjänster till en organisations CMK-infrastruktur. Eventuella undantag från datakryptering måste dokumenteras. Stöd för leverantörer av maskinvarusäkerhetsmoduler (HSM) utökas alltid och ytterligare information finns i Azure Key Vault Managed Hardware Security Module.
Nätverksdesign och ringstängsel
AI- och maskininlärningsmiljöer måste ha ringstängsel på plats, med nätverkssegmentering och nätverksåtkomstkontroller implementerade. Nätverkskommunikation mellan arkitekturkomponenter är begränsad till nödvändiga dataflöden och underliggande infrastruktur för att fungera i en allowlisting-metod. Signaturbaserad analys och beteendebaserad analys bör tillämpas.
Framtvinga nätverksåtkomstkontroller över flera lager i arkitekturen, inklusive Azure Firewalls, inspektera inkommande och utgående nätverksanslutningar, nätverkssäkerhetsgrupper och åtkomst till webbprogramslutpunkten som skyddas med brandväggen för webbprogram (WAF).
Auktoriseringshantering
AI- och maskininlärningsmiljöer som körs i Azure måste integreras med organisationens huvudsakliga kontoetableringssystem, där begäranden om att bevilja åtkomst till kritiska affärsprogram skickas, godkänns och granskas.
Kontoetableringssystem förväntas ansluta till en organisations Active Directory- och Microsoft Entra-ID, så att företagsauktoriseringsroller mappas till motsvarande Active Directory- och Microsoft Entra-säkerhetsgrupper.
AI- och maskininlärningsmiljöer följer en rollbaserad åtkomstkontrollmodell. Åtkomstnivåkontrollauktoriseringar säkerställer att användarna endast kan utföra uppgifter och åtgärder för sin jobbroll och sina affärskrav. Användningsfall för maskininlärning förväntas vara högsegregerade, eftersom dataforskare som arbetar i ett visst användningsfall endast tillåts komma åt resurserna som en del av det användningsfallet, enligt en princip med minsta möjliga behörighet. Dessa resurser kan vara:
- Lagringskonton
- Azure Machine Learning-arbetsytor
- Beräkningsinstanser
Rollbaserad åtkomstkontroll använder säkerhetsgrupper i Microsoft Entra-ID.
Multifaktorautentisering
Multifaktorautentisering måste finnas på plats och implementeras för åtkomst till alla miljöer som körs i Azure och klassificeras som hög affärspåverkan. Multifaktorautentisering kan tillämpas med hjälp av Microsoft Entra multifaktorautentiseringstjänster. Programslutpunkter – inklusive Azure DevOps, Azure Management Portal, Azure Machine Learning, Azure Databricks och Azure Kubernetes Services – bör konfigureras i principer för åtkomstkontroll för multifaktorautentisering.
Multifaktorautentisering måste tillämpas på alla användare, inklusive Azure-tjänstchefer, datatekniker och dataforskare.
Driftsäkerhet
Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.
Loggning och övervakning
Alla Azure-tjänster måste mata in sina säkerhetshändelser i en organisations SOC-plattform (Security Operations Center) och följande säkerhetshändelser ska registreras:
- Lyckade och misslyckade autentiseringsförsök
- Åtkomst till känsliga data
- Ändringar i säkerhetsprincipen
- Ändringar i administratörsanvändargrupper, användare eller roller
- Känsliga dataöverföringar till externa platser, om tillämpligt
- Aktivering och inaktivering av skyddssystem, till exempel ABAC-kontroller
- Uppdaterad åtkomst till loggar och avbrott i loggning
Azure-säkerhetsloggar kan matas in i SOC via olika mönster:
- En central Azure Log Analytics-arbetsyta
- Händelsehubb ansluten till SOC-plattformssystem, till exempel Splunk
- Virtuell Windows-dator och andra beräkningsresurser som distribuerats med SOC-agenter
DevOps
I reglerade miljöer måste IT-system följa strikta kvalitetskontrollprocesser i vattenfallsstil, med formella godkännanden (eller grindar) mellan processfaser – till exempel specifikationer för användarkrav, funktionella specifikationer, design och testningsspecifikationer, eller liknande – med omfattande och tidskrävande stöddokumentation.
Azure-miljöer och datavetenskapsutveckling följer iterativa processer som är förankrade i en DevOps-kultur. En betydande ansträngning för att skala AI- och maskininlärningsinitiativ är att kommunicera grundpelarna i en DevOps-organisation och skapa automatiserad spårningsmappning från slutpunkt till slutpunkt mellan Azure DevOps-epos, funktioner, användarberättelser, testplaner och CI/CD-pipelines samt nödvändiga kvalitetskontrollentiteter och bevis.
Prestandaeffektivitet
Prestandaeffektivitet handlar om att effektivt skala arbetsbelastningen baserat på användarnas behov. Mer information finns i Översikt över grundpelare för prestandaeffektivitet.
För att skala AI och maskininlärning i reglerade miljöer och driva snabb implementering inom organisationens affärsområden rekommenderar vi att du utformar och inför ett implementeringsramverk för att mäta, övervaka och utvärdera värdet som skapas av Azure-tjänsterna. Från vårt exempel på biovetenskap och hälsovårdsbranschen utvärderades följande affärsvärdesspakar och nyckeltal (KPI):
Skalbarhet – För att säkerställa att Azure-arkitekturen kan skalas tillsammans med affärskrav föreslås följande KPI:er oavsett skalningspunkt:
- Antal beräkningsinstanser och totalt lagringsutrymme och minne som används
- Antal experiment som har körts
- Antal distribuerade modeller
Acceleration av AI-utveckling – För att påskynda utvecklingen av AI- och maskininlärningslösningar föreslås följande KPI:er:
- Antal olika affärsenheter som använder Azures AI- och maskininlärningstjänster
- Antal registrerade användare per kategori – till exempel datatekniker, dataforskare, medborgardataforskare och företagsanvändare
- Antal experiment som har körts
- Tid mellan registrering av användare och aktiv användning
- Tid att etablera tjänster – från ändringskonfigurationsbegäran till slutförande av tjänstetablering
Efterlevnad – För att säkerställa kontinuerlig efterlevnad av distribuerade AI- och maskininlärningslösningar föreslås följande KPI:er:
- Övergripande tillförlitlighet med tillämpliga ISRM-kontroller
- Antal varningar om säkerhetsrisker
- Antal säkerhetsincidenter för den senaste perioden
Användarupplevelse – För att säkerställa att hög kvalitet och konsekventa användarupplevelser är tillgängliga föreslås följande KPI:er:
- Antal supportbegäranden för användare
- Net Promoter Score (NPS)
Secure Foundations – För att säkerställa att säkra och säkra grunder finns på plats föreslås följande KPI:er:
- Drifttid för kritiska tjänster
- Antal incidenter som rapporterats relaterade till prestandatillgänglighet
Kostnadsoptimering
Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.
Kostnadshantering är en viktig del av designen i implementeringen av skalbara AI- och maskininlärningsplattformar, eftersom driftskostnaderna inte följer enkla och förutsägbara mönster. Kostnaden drivs främst av antalet och storleken på de AI- och maskininlärningsexperiment som körs på plattformen, och mer specifikt på antalet och SKU:erna för de beräkningsresurser som används i modellträning och slutsatsdragning.
Här följer några metoder som vi rekommenderar:
- Tilldela varje användningsfall och AI- och maskininlärningsprodukt sin egen Budget för Azure-tjänster, vilket är en bra metod för kostnadshantering.
- Upprätta en transparent kostnadsmodell för plattformsdelade tjänster.
- Använd taggar konsekvent för att associera användningsfall och produktresurser med kostnadsställen.
- Använd Azure Advisor och Azure Budget för att förstå var resurser inte används på det mest optimala sättet och granska konfigurationer regelbundet.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Eran Sagi | AI-lösningsarkitekt
Nästa steg
Lär dig hur du tränar och distribuerar modeller och hanterar maskininlärningslivscykeln med Azure Machine Learning. Självstudier, kodexempel, API-referenser med mera, finns här:
Lär dig hur du implementerar en landningszon i företagsskala för dataanalys och AI i Azure:
Produktdokumentation:
Relaterade resurser
Översiktsartiklar för Azure Architecture Center: