En este artículo, trataremos las consideraciones arquitectónicas de Azure relacionadas con el análisis y la implementación de controles de administración de un conjunto común de clasificación de niveles de alto riesgo de controles de administración de riesgos de seguridad (ISRM).
Architecture
La arquitectura se muestra en este diagrama y sigue el principio de las zonas de aterrizaje de escala empresarial, específicamente los análisis de escala empresarial y la arquitectura de referencia de análisis e IA.
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
La arquitectura consta del flujo de trabajo descrito en las secciones siguientes. Cada componente de la arquitectura tiene un número correspondiente en el diagrama. Se describe el propósito principal del componente, cómo encaja en la arquitectura y cualquier otra consideración importante que se deba tener en cuenta al adoptarlo:
- Suscripciones de plataforma: suscripciones principales de Azure que proporcionan administración, conectividad e identidad a través de Microsoft Entra ID. No se describen aquí con más detalle y se supone que están listas y disponibles como parte de la configuración de escala empresarial principal.
Administración de datos
- Zona de administración de datos: responsable de la gobernanza de datos en toda la plataforma y aplica barreras de protección para proporcionar más flexibilidad de bajada en las zonas de aterrizaje de datos. Tiene su propia suscripción y hospeda servicios centralizados, como la catalogación de datos, la supervisión, las auditorías, etc. Este entorno está muy controlado y sujeto a auditorías estrictas. Todos los tipos de clasificación de datos se almacenan en el catálogo de datos central (Azure Purview). En función de los metadatos, se aplican diferentes directivas y patrones de acceso. Solo hay una suscripción de zona de administración de datos para todo el inquilino. La zona de administración de datos está emparejada (a través del emparejamiento de VNET) con todas las demás zonas de aterrizaje de datos. Los puntos de conexión privados se usan siempre que es posible para garantizar que los servicios implementados no son accesibles a través de la red pública de Internet.
- Grupo de recursos de red: las redes virtuales de Azure, los grupos de seguridad de red y todos los demás recursos relacionados con las redes necesarios para la zona administración de datos se aprovisionan dentro de la red de grupos de recursos.
- Grupo de recursos de implementación: hospeda Azure DevOps agentes de CI/CD privados (máquinas virtuales) necesarios para la zona de administración de datos y un Key Vault para almacenar los secretos relacionados con la implementación.
- Grupo de recursos de gobernanza de datos: Azure Purview se usa como una solución de catálogo de datos y gobernanza de datos y se usa para aplicar las barreras de protección necesarias para que los conjuntos de datos sigan los requisitos de datos y las regulaciones de datos impuestas por la ley u otras entidades. Purview se hospeda de forma centralizada en este grupo de recursos, junto con una instancia de Key Vault de almacenamiento de secretos.
- Recursos centralizados: recursos centrados en hospedar recursos importantes y valiosos que son fundamentales para la plataforma, como:
- Instancias de Azure Container Registry que hospedan imágenes base usadas en productos de datos basados en Azure Machine Learning (imágenes que se han examinado previamente y no presentan vulnerabilidades)
- Modelos de IA/Machine Learning publicados y puestos a disposición de los consumidores en la plataforma (por lo que se pueden implementar en una o varias zonas de aterrizaje de datos si es necesario).
- Servicios adicionales: cualquier otro servicio que deba centralizarse se puede hospedar en uno de estos grupos de recursos, que puede incluir instancias de Azure API Management centralizadas, software de terceros, entre otros.
- Grupo de recursos de visualización de datos: este grupo de recursos hospeda soluciones de visualización de datos compartidos entre zonas de aterrizaje de datos. Las soluciones pueden ser Power BI, Tableau o cualquier otra solución de visualización.
- Gobernanza y controles de infraestructura adicionales: Microsoft Defender para la nube y Azure Monitor se usan como soluciones de seguridad y supervisión de línea de base.
Zonas de aterrizaje de datos
Zona de aterrizaje de datos 001: una suscripción que representa una unidad de escalado dentro de la plataforma de datos. Las zonas de aterrizaje de datos se implementan en función de la arquitectura de la zona de aterrizaje de datos principal (plano técnico), incluidas todas las funcionalidades clave para hospedar una plataforma de análisis e inteligencia artificial. Puede haber una o varias zonas de aterrizaje de datos en el entorno. Azure Policy se aplica para proteger el acceso y las configuraciones de los distintos servicios de Azure. La zona de aterrizaje de datos está emparejada (a través del emparejamiento de VNET) con todas las demás zonas de aterrizaje de datos y la zona de administración de datos. Los puntos de conexión privados se usan siempre que es posible para garantizar que los servicios implementados no son accesibles a través de la red pública de Internet.
Grupo de recursos de red: las redes virtuales de Azure, los grupos de seguridad de red y todos los demás recursos relacionados con las redes necesarios para la zona de aterrizaje de datos se aprovisionan dentro de este grupo de recursos.
Grupo de recursos de implementación: hospeda Azure DevOps agentes de CI/CD privados (máquinas virtuales) necesarios para la zona de aterrizaje de datos y un Key Vault para almacenar los secretos relacionados con la implementación.
Grupo de recursos de almacenamiento de datos: un grupo de recursos de almacenamiento de datos contiene las cuentas de almacenamiento de datos principales para esta zona de aterrizaje de datos, implementadas como Azure Data Lake Storage Gen2, con espacio de nombres jerárquico. Se distribuyen en tres áreas principales:
- Sin procesar: datos que se ingieren del origen de datos en su estado original
- Mantenida y enriquecida: datos que se limpian, validan y agregan
- Área de trabajo: determinados productos de datos pueden almacenar sus conjuntos de datos o las salidas de los modelos de Machine Learning, entre otros
Las flechas de los diagramas muestran el flujo de datos esperado, desde los datos sin procesar hasta los datos mantenidos y enriquecidos (de confianza), y hasta el área de trabajo para la exploración, el análisis y el suministro de valor adicional fuera del producto de datos.
Grupo de recursos de integración de datos: el grupo de recursos de integración de datos hospeda una Azure Data Factory para compartir la conectividad con el entorno de ejecución de integración auto-hospedado (SHIR) local. Su propósito principal es establecer la conectividad. Otras instancias de Data Factory la reutilizan para que la conectividad solo se mantenga en un solo lugar. Su otro propósito es hospedar el entorno de ejecución de integración auto-hospedado para el servicio Azure Purview, a fin de que pueda acceder a los orígenes de datos de esta zona de aterrizaje de datos, con fines de análisis.
Grupo de recursos de administración de metadatos: el grupo de recursos de administración de metadatos hospeda metadatos para Azure Databricks (el meta store de Hive) y canalizaciones de ingesta y procesamiento de Azure Data Factory. También hospeda un Key Vault para almacenar secretos para acceder a estos datos. Azure SQL Database se usa para hospedar los metadatos.
Grupo de recursos de ingesta de datos: el grupo de recursos de ingesta de datos hospeda una Azure Data Factory donde se implementan todas las canalizaciones de ingesta de datos específicas para un dominio de datos. Azure Databricks se usa como motor de procesamiento para cargar y transformar los datos, y para almacenar los datos en las cuentas de lago de datos.
Grupo de recursos de Analytics: el grupo de recursos de Analytics incluye dos servicios compartidos para realizar análisis y exploración de datos adicionales: Azure Synapse y Azure Databricks. Ambos servicios proporcionan un amplio proceso y escalado para fines de análisis y exploración de datos masivos.
Grupo de recursos del producto de datos: el grupo de recursos del producto de datos es un plano técnico para un producto de datos, con un grupo de recursos que contiene recursos básicos de Azure que un producto de datos podría necesitar. La implementación debe poder configurarse mediante una canalización de Azure DevOps en función de las necesidades específicas de la empresa. Los servicios principales de Azure implementados aquí son los siguientes:
- Área de trabajo de Azure Machine Learning como base para cualquier proyecto de aprendizaje automático empresarial con servicios relacionados, como Key Vault (para almacenar secretos)
- Application Insights (para la supervisión de modelos)
- Azure Storage (para el almacenamiento de conjuntos de datos)
- Una instancia de Azure Container Registry para almacenar imágenes de modelo durante el desarrollo
Cognitive Services se implementa como un conjunto para proporcionar acceso de API a varios servicios respaldados por IA, y los clústeres de proceso y de instancia de proceso de Azure Machine Learning se usan con fines de desarrollo y creación y prueba de modelos. Azure Data Factory se usa para orquestar la puntuación por lotes de los modelos (si es necesario). Azure App Service y Azure Cosmos DB proporcionan una capa adicional para la implementación del producto de datos, donde una aplicación personalizada o una API se pueden hospedar con su propio almacén de datos interno.
Los sectores regulados suelen tener restricciones estrictas de acceso a datos y normalmente permiten hospedar datos de producción solo dentro del entorno de producción. Por este motivo, el ciclo de vida de desarrollo de los productos de datos solo se produce en la zona de aterrizaje de datos de producción y se aprovisiona un entorno independiente o grupo de recursos con fines de desarrollo, prueba e implementación.
Productos de datos adicionales: estos grupos de recursos hospedan otros productos de datos, ya que una zona de aterrizaje de datos puede hospedar uno o varios productos de datos.
Grupo de recursos de proceso compartido: todos los procesos compartidos necesarios para hospedar e implementar productos de datos se aprovisionan dentro de este grupo de recursos. Un clúster de Azure Kubernetes Service es un ejemplo.
Gobernanza y controles de infraestructura adicionales: Microsoft Defender para la nube y Azure Monitor se usan como soluciones de seguridad y supervisión de línea de base.
Zonas de aterrizaje de datos adicionales 002: este marcador de posición para suscripciones de Azure adicionales que se usarían para hospedar nuevas zonas de aterrizaje de datos. Se basan en los criterios mencionados anteriormente, como los requisitos de residencia de datos o en una unidad de negocio diferente que tiene su propio equipo funcional y un conjunto de casos de uso que se van a entregar.
Componentes
- Microsoft Entra ID
- Azure Purview
- Azure Virtual Network
- Azure DevOps
- Azure Container Registry
- Azure Machine Learning
- Microsoft Defender for Cloud
- Azure Monitor
- Azure Policy
- Almacén de Azure Data Lake
- Azure Data Factory
- Azure SQL Database
- Azure Databricks
- Azure Synapse Analytics
- Azure Kubernetes Service
Alternativas
En las organizaciones distribuidas, los grupos de negocios funcionan de forma independiente y con altos grados de autonomía. Por lo tanto, podrían considerar un diseño de solución alternativo, con aislamiento total de casos de uso en las zonas de aterrizaje de Azure y compartiendo un conjunto mínimo de servicios comunes. Aunque este diseño permite un inicio rápido, requiere un gran esfuerzo por parte de las organizaciones de TI e ISRM, ya que el diseño de casos de uso individuales se pueden desviar rápidamente de los diseños de plano técnico. Además, requiere procesos independientes de ISRM y auditorías para cada uno de los "productos" de IA y Machine Learning hospedados en Azure.
Detalles del escenario
El escalado de iniciativas de IA y aprendizaje automático en entornos regulados plantea importantes desafíos a las organizaciones, independientemente de su madurez y tamaño digitales. En este artículo, analizaremos las decisiones arquitectónicas clave que se deben tener en cuenta al adoptar los servicios de ingeniería de datos y aprendizaje automático de Azure en sectores regulados. Estas decisiones se basan en lo que se ha aprendido de una implementación reciente en una empresa global de ciencias médicas y asistencia sanitaria de Fortune 500.
La arquitectura presentada en este artículo sigue el diseño de arquitectura de referencia de Enterprise Scale Analytics e IA y fue una de sus primeras implementaciones.
Si configura proyectos de ciencia de datos y desarrolla modelos de Machine Learning en ciencias de la vida y entornos sanitarios requerirá, en casi todos los casos, acceso a orígenes de datos de alto impacto empresarial (HBI, por sus siglas en inglés). Por ejemplo, estos orígenes pueden ser información sobre el protocolo de pruebas clínicas sin datos de pacientes, fórmulas químicas de moléculas o secretos de procesos de fabricación.
En los sectores regulados, los sistemas de TI se clasifican en función de la clasificación de los orígenes de datos a los que acceden esos sistemas. Los entornos de IA y aprendizaje automático que se ejecutan en Azure se clasifican como de HBI y deben cumplir con un amplio conjunto de directivas y controles de ISRM.
Principios de diseño
Esta arquitectura se basa en los siguientes principios:
- La escala empresarial es un enfoque arquitectónico y una implementación de referencia alineada con la hoja de ruta de Azure y parte de Microsoft Cloud Adoption Framework (CAF). Esta permite la construcción y la puesta en marcha eficaz de zonas de aterrizaje en Azure, a escala. La zona de aterrizaje de nombre se usa como límite en el que las aplicaciones nuevas o migradas llegan a Azure. En este escenario, también hace referencia a partes de la plataforma de datos que se usan para hospedar los datos y los modelos de IA y Machine Learning.
- Las arquitecturas de plataforma de datos monolíticas tradicionales tienen una limitación inherente que ralentiza la entrega de características y valores. La arquitectura que se describe aquí permite a las organizaciones escalar su patrimonio de datos y abordar los desafíos de un lago de datos monolítico centralizado mediante un enfoque descentralizado con separación de propiedad (malla de datos). El enfoque permite a las organizaciones escalar a miles de canalizaciones de ingesta y productos de datos, a la vez que protege la plataforma de datos y permite su mantenimiento. Para ello, desacopla la plataforma de datos principal y los servicios de administración de datos (implementados en una zona de aterrizaje independiente denominada “zona de administración de datos”) de los dominios de datos y los productos de datos (implementados en una o varias zonas de aterrizaje de datos).
- Las suscripciones se usan como unidades de administración y escala alineadas con las necesidades y prioridades empresariales. El escalado se logra proporcionando nuevas suscripciones (zonas de aterrizaje de datos) a las unidades de negocio, en función de determinados criterios, como las diferentes partes interesadas del negocio, los distintos objetivos y los requisitos empresariales y de residencia de datos (donde los datos deben hospedarse en una región geográfica específica).
- Azure Policy se usa para proporcionar barreras de protección y garantizar el cumplimiento continuo dentro del panorama de TI de la empresa.
- El plano de administración y control único (a través de Azure Portal) proporciona una experiencia coherente en todos los recursos y canales de aprovisionamiento de Azure sujetos a controles controlados por directivas y de acceso basado en roles. Los servicios y funcionalidades de la plataforma nativa de Azure se usan siempre que es posible.
- Los equipos multidisciplinarios se encargan del diseño, el desarrollo y las operaciones para reducir el tiempo de comercialización y la agilidad en la plataforma. Los principios básicos como DevOps, la infraestructura como código (IaC) y los diseños resistentes se usan para evitar errores humanos y puntos únicos de error.
- El identificador de dominio y origen de datos pueden usar expertos en la materia (SME) de orígenes de datos y dominios para extraer recursos de datos de entornos de Azure, de terceros o locales. Un dominio de datos es un grupo de recursos dentro de una zona de aterrizaje de datos que pueden usar los equipos multidisciplinarios para la ingesta de datos personalizados. Puede haber uno o muchos dominios de datos dentro de una zona de aterrizaje de datos. Los dominios de datos se pueden ver de forma similar a los dominios del diseño controlado por dominios, donde proporcionan un límite de contexto y son autosuficientes y aislados. Un ejemplo de un dominio de datos serían los datos de pruebas clínicas o los datos de la cadena de suministro.
Posibles casos de uso
Las consideraciones arquitectónicas que se analizan en este artículo tienen su origen en los sectores de ciencias de la vida y asistencia sanitaria. Sin embargo, también son importantes para las organizaciones de otros sectores regulados, que incluyen los siguientes sectores:
- Servicios financieros
- Proveedores de asistencia sanitaria
- Petróleo y gas
La implementación de arquitectura de referencia de IA y análisis de escala empresarial en entornos regulados sigue patrones de diseño similares.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
En esta sección, se describen las lecciones aprendidas de la implementación de la arquitectura descrita anteriormente en un entorno regulado de ciencias de la vida y asistencia sanitaria. También tratamos las consideraciones de diseño de alto nivel para cumplir las directivas y los controles comunes de ISRM.
Seguridad
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.
Entornos
En entornos regulados, los sistemas de TI clasificados como HBI deben tener varios entornos segregados, como desarrollo, calidad y producción o similares. El acceso a orígenes de datos protegidos solo está autorizado en entornos certificados para producción.
Dado que el desarrollo de inteligencia artificial y aprendizaje automático requiere acceso a conjuntos de datos confidenciales, las distintas fases del proceso de operaciones de aprendizaje automático, como la compilación, el entrenamiento y la inferencia del modelo (o similar), se realizan en producción. Los entornos de desarrollo y calidad normalmente están restringidos al tipo de trabajo de infraestructura, operaciones e ingeniería de datos, para garantizar mejoras continuas a medida que estén disponibles nuevos servicios y características de Azure.
Se espera que las actividades de desarrollo de inteligencia artificial y ciencia de datos se deberían llevar a cabo en entornos de producción, a excepción del espacio aislado o del trabajo exploratorio inicial.
Cifrado
Los sistemas de TI que acceden, almacenan y procesan datos empresariales confidenciales son necesarios para implementar requisitos específicos en la administración de claves de cifrado, como las directivas FIPS 140-2 de nivel 2 o nivel 3, con integración de claves administradas por el cliente (CMK). Los datos protegidos siempre deben cifrarse en reposo y en tránsito, mediante protocolos TLS 1.2 o superiores.
Durante el diseño de la arquitectura, se requiere un análisis cuidadoso de la compatibilidad y la integración de los servicios de Azure con la infraestructura de CMK de una organización. Se deben documentar las excepciones del cifrado de datos. La compatibilidad con los proveedores de módulos de seguridad de hardware (HSM) siempre se expande y se puede encontrar información adicional en Módulo de seguridad de hardware administrado de Azure Key Vault.
Diseño de red y barrera de anillo
Los entornos de IA y aprendizaje automático (Machine Learning) deben tener implementada la barrera de anillo, con controles de segmentación de red y acceso a la red implementados. La comunicación de red entre los componentes de arquitectura se limita a los flujos de datos necesarios y a la infraestructura subyacente para funcionar en un enfoque de adición a la lista de permitidos. Se deben aplicar el análisis basado en firmas y el análisis basado en comportamiento.
Aplique controles de acceso a la red en varias capas de la arquitectura, incluidas las instancias de Azure Firewall, la inspección de la conectividad de red entrante y saliente, los grupos de seguridad de red y el acceso al punto de conexión de la aplicación web protegido con el firewall de aplicaciones web (WAF).
Administración de autorización
Los entornos de inteligencia artificial y aprendizaje automático que se ejecutan en Azure deben integrarse con el sistema de aprovisionamiento de cuentas principal de una organización, donde las solicitudes para conceder acceso a aplicaciones empresariales críticas se envían, aprueban y auditan.
Se espera que los sistemas de aprovisionamiento de cuentas se conecten a las instancias de Active Directory y Microsoft Entra ID de una organización, de modo que los roles de autorización empresarial se asignen a los grupos de seguridad de Active Directory y Microsoft Entra correspondientes.
Los entornos de inteligencia artificial y aprendizaje automático siguen un modelo de control de acceso basado en roles. Las autorizaciones de control de nivel de acceso garantizan que los usuarios solo puedan realizar las tareas y acciones para su rol de trabajo y sus requisitos empresariales. Se espera que los casos de uso de aprendizaje automático estén muy segregados, ya que los científicos de datos que trabajan en un caso de uso determinado solo puedan acceder a los recursos que forman parte de ese caso de uso, siguiendo un principio de privilegios mínimos. Estos recursos pueden incluir:
- Cuentas de almacenamiento
- Áreas de trabajo de Azure Machine Learning
- Instancias de computación
El control de acceso basado en rol usa grupos de seguridad en Microsoft Entra ID.
Autenticación multifactor
La autenticación multifactor debe estar implementada para acceder a todos los entornos que se ejecutan en Azure y clasificarse como de alto impacto empresarial. La autenticación multifactor se puede aplicar mediante los servicios de autenticación multifactor de Microsoft Entra. Se espera que los puntos de conexión de la aplicación, incluidos Azure DevOps, Portal de administración de Azure, Azure Machine Learning, Azure Databricks y Azure Kubernetes Services se deben configurar en las directivas de control de acceso de autentificación multifactor.
Autenticación multifactor debe aplicarse a todos los usuarios, incluidos los administradores, los ingenieros de datos y los científicos de datos de Azure.
Excelencia operativa
La excelencia operativa abarca los procesos de las operaciones que implementan una aplicación y la mantienen en ejecución en producción. Para más información, consulte Introducción al pilar de excelencia operativa.
Registro y supervisión
Todos los servicios de Azure deben ingerir sus eventos de seguridad en la plataforma del centro de operaciones de seguridad (SOC) de una organización y se deben registrar los siguientes eventos de seguridad:
- Intentos de autenticación correctos y con errores
- Acceso a datos confidenciales
- Cambios en la directiva de seguridad
- Cambios en grupos de usuarios administradores, usuarios o roles
- Transferencias de datos confidenciales a ubicaciones externas, si procede
- Activación y desactivación de sistemas de protección, como los controles de ABAC
- Se ha actualizado el acceso a los registros y la interrupción del registro
Los registros de seguridad de Azure se pueden ingerir en SOC mediante diferentes patrones:
- Un área de trabajo de Azure Log Analytics
- Un centro de eventos conectado a sistemas de plataforma SOC, como Splunk
- Una VM Windows y otros recursos de proceso implementados con agentes SOC
DevOps
En entornos regulados, los sistemas de TI deben seguir estrictos procesos de control de calidad de estilo cascada, con aprobaciones formales (o puertas) entre fases de proceso, como las especificaciones de requisitos del usuario, las especificaciones funcionales, el diseño y las especificaciones de prueba o similares, con documentación de soporte extensa y lenta.
Los entornos de Azure y el desarrollo de ciencia de datos siguen procesos iterativos, anclados en una cultura de DevOps. Se dedicará un esfuerzo importante en el escalado de iniciativas de IA y aprendizaje automático para comunicar los pilares de una organización de DevOps y crear una asignación automatizada de rastreabilidad de un extremo a otro entre epopeyas, características, casos de usuario, planes de prueba y canalizaciones de CI/CD, y entidades y evidencias de control de calidad necesarios de Azure DevOps.
Eficiencia del rendimiento
La eficiencia del rendimiento es la capacidad de la carga de trabajo para escalar con el fin de satisfacer de manera eficiente las demandas que los usuarios hayan ejercido sobre ella. Para obtener más información, vea Resumen del pilar de eficiencia del rendimiento.
Para escalar la inteligencia artificial y el aprendizaje automático en entornos regulados, e impulsar la adopción rápida en las áreas de negocio de la organización, se recomienda diseñar e implementar un marco de adopción para medir, supervisar y evaluar el valor creado por los servicios de Azure. A partir de nuestro ejemplo de ciencias de la vida y del sector sanitario, se evaluaron los siguientes indicadores clave de rendimiento (KPI) y aceleradores de los valores empresariales:
Escalabilidad: para asegurarse de que la arquitectura de Azure se puede escalar junto con los requisitos empresariales, independientemente del punto de escala, se sugieren los siguientes KPI:
- Número de instancias de proceso y almacenamiento total y memoria usados
- Número de experimentos ejecutados
- Número de modelos implementados
Aceleración del desarrollo de IA: para acelerar el desarrollo de inteligencia artificial y aprendizaje automático, se sugieren los siguientes KPI:
- Número de unidades de negocio diferentes que consumen servicios de IA y aprendizaje automático de Azure
- Número de usuarios incorporados, por categoría (por ejemplo, ingenieros de datos, científicos de datos, científicos de datos de ciudadanos y usuarios empresariales)
- Número de experimentos ejecutados
- Tiempo entre la incorporación de usuarios y el uso activo
- Tiempo para aprovisionar servicios: desde la solicitud de cambio de configuración hasta la finalización del aprovisionamiento del servicio
Cumplimiento: para garantizar el cumplimiento continuo de las soluciones implementadas de inteligencia artificial y aprendizaje automático, se sugieren los siguientes KPI:
- Conformidad general con los controles ISRM aplicables
- Número de advertencias de vulnerabilidad de seguridad
- Número de incidentes de seguridad del último período
Experiencia del usuario: para asegurarse de que hay disponibles experiencias de usuario coherentes y de alta calidad, se sugieren los siguientes KPI:
- Número de solicitudes del servicio de soporte al usuario
- Net Promoter Score (NPS)
Fundamentos seguros: para asegurarse de que existen bases seguras y seguras, se sugieren los siguientes KPI:
- Tiempo de actividad de los servicios críticos
- Número de incidentes notificados en relación con la disponibilidad del rendimiento
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
La administración de costos es una parte importante del diseño en la implementación de plataformas escalables de IA y aprendizaje automático, ya que los costos de ejecución no siguen patrones sencillos ni predecibles. El costo se basa principalmente en el número y el tamaño de los experimentos de IA y aprendizaje automático que se ejecutan en la plataforma y, más concretamente, en el número y las SKU de los recursos de proceso usados en el entrenamiento y la inferencia del modelo.
Estos son algunos procedimientos que se recomiendan:
- Asigne cada caso de uso y producto de inteligencia artificial y aprendizaje automático su propio presupuesto de servicios de Azure, que es una buena práctica de administración de costos.
- Establezca un modelo de costos transparente para los servicios compartidos de la plataforma.
- Use etiquetas de forma coherente para asociar los casos de uso y los recursos de producto a los centros de costos.
- Use Azure Advisor y el presupuesto de Azure para comprender dónde no se usan los recursos de la manera más óptima y revise las configuraciones con regularidad.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Autor principal:
- Eran Sagi | Arquitecto de soluciones de IA
Pasos siguientes
Aprenda a entrenar e implementar modelos, y a administrar el ciclo de vida del aprendizaje automático con Azure Machine Learning. Tutoriales, ejemplos de código, referencias de API, etc., disponibles aquí:
Aprenda a implementar una zona de aterrizaje de escala empresarial para el análisis de datos y la IA en Azure:
Documentación del producto:
- Azure Machine Learning
- Operaciones de aprendizaje automático
- Azure Databricks
- Azure Data Lake Storage Gen2
Recursos relacionados
Artículos de información general del Centro de arquitectura de Azure: