Compartir a través de

Confiabilidad de Azure Functions

Azure Functions es un servicio de proceso controlado por eventos que permite ejecutar pequeños bloques de código (funciones) sin tener que aprovisionar o administrar explícitamente la infraestructura. Las funciones pueden responder a eventos como solicitudes HTTP, temporizadores, mensajes de cola y cambios en otros servicios de Azure, lo que hace que sea adecuado para procesar datos, integrar sistemas y ejecutar tareas en segundo plano.

Cuando se usa Azure, la confiabilidad es una responsabilidad compartida. Microsoft proporciona una variedad de funcionalidades para admitir resistencia y recuperación. Es responsable de comprender cómo funcionan esas funcionalidades dentro de todos los servicios que usa y de seleccionar las funcionalidades que necesita para cumplir los objetivos empresariales y los objetivos de tiempo de actividad.

En este artículo se describe cómo hacer que Azure Functions sea resistente a varias posibles interrupciones y problemas, incluidos errores transitorios, errores de zona de disponibilidad y errores en toda la región. También resalta información clave sobre el acuerdo de nivel de servicio (SLA) de Azure Functions.

Recomendaciones de implementación de producción

Azure Well-Architected Framework proporciona recomendaciones sobre confiabilidad, rendimiento, seguridad, costo y operaciones. Para comprender cómo estas áreas influyen entre sí y contribuyen a una solución confiable de Azure Functions, consulte Procedimientos recomendados de arquitectura para Azure Functions.

Introducción a la arquitectura de confiabilidad

Al implementar Azure Functions, es importante familiarizarse con varios conceptos:

  • Planes de hospedaje: Los planes representan el entorno de hospedaje de las aplicaciones de funciones. El plan determina los recursos de proceso disponibles, el modelo de precios y el comportamiento de escalado.

  • Cuentas de almacenamiento: Al crear una aplicación de funciones, debe especificar una cuenta de almacenamiento de host. La cuenta de almacenamiento se usa para administrar aspectos de las operaciones internas de la aplicación de funciones, incluido el almacenamiento de código de función, el registro y la administración de simultaneidad (como concesiones de blobs para determinados tipos de desencadenadores).

    También puede usar una cuenta de almacenamiento para la implementación. Esta cuenta de almacenamiento puede ser la misma que la cuenta de almacenamiento de host o una cuenta de almacenamiento diferente.

    Importante

    Las cuentas de almacenamiento son partes críticas de la arquitectura de confiabilidad de Azure Functions y debe configurarlas para cumplir los requisitos de resistencia de la aplicación de funciones.

  • Desencadenadores y enlaces: permiten a la función responder a eventos, recibir y escribir datos de otros servicios.

  • Durable Functions: Durable Functions son funciones con estado, incluidas orquestaciones de larga duración y entidades con estado.

    Cuando se usa Durable Functions, se configura un proveedor de almacenamiento, que almacena el estado. Debe evaluar las características de confiabilidad del almacén de estado que elija y configurarlo para cumplir los requisitos de resiliencia.

Resistencia a errores transitorios

Los errores transitorios son errores breves e intermitentes en los componentes. Se producen con frecuencia en un entorno distribuido como la nube y son una parte normal de las operaciones. Los errores transitorios se corrigen después de un breve período de tiempo. Es importante que las aplicaciones puedan controlar errores transitorios, normalmente mediante el reintento de solicitudes afectadas.

Todas las aplicaciones hospedadas en la nube deben seguir las instrucciones de control de errores transitorios de Azure cuando se comunican con cualquier API, bases de datos y otros componentes hospedados en la nube. Para obtener más información, consulte Recomendaciones para controlar errores transitorios.

Tenga en cuenta las siguientes recomendaciones para controlar errores transitorios en las aplicaciones de funciones:

  • Desencadenadores y enlaces: La plataforma Azure Functions incluye el control de errores transitorios integrado para muchos desencadenadores y enlaces. Cuando se produce un error transitorio mientras se activa un desencadenador compatible o un enlace admitido lee o escribe datos, la plataforma puede reintentar automáticamente la operación. Este comportamiento de reintento integrado ayuda a garantizar que los problemas de conectividad temporal o los fallos de servicio no impidan que la función se ejecute. Para más información, consulte Control de errores y reintentos de Azure Functions.

    Sin embargo, esta protección solo cubre errores transitorios. Los errores persistentes, como una cadena de conexión mal configurada o un recurso eliminado, no se reintentan.

    Los errores persistentes y los errores transitorios repetidos se tratan como errores y puede configurar el registro para capturar información sobre los errores de ejecución de funciones. Para obtener más información, consulte Cómo configurar la supervisión para Azure Functions.

  • Tu código de función: Dentro del cuerpo de tu función, eres responsable de manejar errores transitorios al realizar llamadas a servicios externos. Debe implementar patrones de lógica de reintento, tiempos de espera y disyuntor, según corresponda, para las llamadas de servicio externas realizadas en el código de su función. Diseñe las funciones para que sean idempotentes siempre que sea posible, de modo que los reintentos no causen efectos secundarios duplicados.

  • Clientes: Las aplicaciones cliente que se conectan a funciones de forma sincrónica, como mediante una conexión HTTP, deben ser resistentes a errores transitorios.

Resistencia a errores de zona de disponibilidad

Las zonas de disponibilidad son grupos físicamente independientes de centros de datos dentro de una región de Azure. Cuando una zona falla, los servicios pueden transferirse a una de las zonas restantes.

Los planes de consumo no admiten zonas de disponibilidad. Si la redundancia de zona es un requisito para su carga de trabajo, considere usar los tipos de plan Consumo Flexible, Premium o Dedicado (App Service).

Los planes Flex Consumption admiten implementaciones con redundancia de zona.

Los planes Premium admiten implementaciones con redundancia de zona.

Cuando se habilita la redundancia de zona, la plataforma distribuye automáticamente las instancias del plan en todas las zonas de disponibilidad de la región seleccionada. Si alguna zona de disponibilidad de la región tiene un problema, las funciones continúan ejecutándose mediante instancias en zonas saludables.

Debe habilitar también el almacenamiento con redundancia de zona (ZRS) en la cuenta de almacenamiento del host, lo que garantiza que sea resistente a las interrupciones de zona.

Diagrama que muestra el plan de Azure Functions con redundancia de zona con tres instancias distribuidas entre tres zonas y una cuenta de almacenamiento con redundancia de zona.

El plan Dedicado (App Service) admite implementaciones con redundancia de zona. Cuando se habilita la redundancia de zona, la plataforma distribuye automáticamente las instancias en todas las zonas de disponibilidad de la región seleccionada. Configuras la redundancia de zona en el plan. Para más información sobre cómo App Service controla la redundancia de zona, consulte Confiabilidad en Azure App Service.

Si no habilita la redundancia de zona, el plan es no zonal o regional, lo que significa que las instancias de plan se pueden colocar en cualquier zona de disponibilidad dentro de la región o dentro de la misma zona, y no son resistentes a errores de zona de disponibilidad. Es posible que su plan experimente tiempo de inactividad durante una interrupción en cualquier zona de la región.

Requisitos

  • Compatibilidad con regiones: Los planes de consumo flexible con redundancia de zona se pueden implementar en un conjunto específico de regiones. Puede recuperar la lista actual de regiones admitidas mediante la CLI de Azure. Para más información, consulte Visualización de regiones que admiten zonas de disponibilidad.

  • Compatibilidad con regiones: Los planes Premium con redundancia de zona se pueden implementar en las siguientes regiones:

    Americas Europa Oriente Medio África Asia Pacífico
    Sur de Brasil Centro de Francia Israel Central Norte de Sudáfrica Australia East
    Canada Central Centro-oeste de Alemania Qatar Central Centro de la India
    Central US Norte de Italia Norte de Emiratos Árabes Unidos Norte de China 3
    East US Norte de Europa Este de Asia
    Este de EE. UU. 2 Norway East Japón Oriental
    Centro-sur de EE. UU. Centro de Suecia Sudeste Asiático
    Oeste de EE. UU. 2 Norte de Suiza
    Oeste de EE. UU. 3 UK South
    West Europe

  • Sistemas operativos: Se admiten los planes de Windows y Linux.

  • Recuento mínimo de instancias: Se requiere un mínimo de dos instancias listas para siempre cuando la redundancia de zona está habilitada para los planes Premium.

  • Cuenta de almacenamiento de host: Debe configurar la cuenta de almacenamiento de host predeterminada de la aplicación de funciones para usar el almacenamiento con redundancia de zona (ZRS). Si usa una cuenta de almacenamiento de host que no está configurada para ZRS, es posible que la aplicación se comporte inesperadamente durante una interrupción de zona.
  • Cuenta de almacenamiento de contenedor de implementación: Si usa una cuenta de almacenamiento independiente para el contenedor de implementación de la aplicación, también debe actualizarla para que sea redundante de zona.

Consideraciones

La redundancia de zona solo garantiza un tiempo de actividad continuado para las aplicaciones implementadas. Una interrupción de la zona de disponibilidad puede afectar a algunos aspectos de Azure Functions, aunque la aplicación sigue atendiendo el tráfico. Estos comportamientos incluyen el escalado del plan, la creación de aplicaciones, la configuración de la aplicación y la publicación de aplicaciones.

Distribución de instancias a través de zonas

Al configurar las aplicaciones del Plan de Consumo Flex como redundante en la zona, la plataforma distribuye automáticamente las instancias del plan entre varias zonas de la región seleccionada, con reglas diferentes para instancias siempre disponibles frente a las instancias bajo demanda.

  • Las instancias siempre listas se distribuyen entre al menos dos zonas de forma circular.

    Para garantizar la resistencia de zona, la plataforma mantiene automáticamente al menos dos instancias listas para siempre para cada función o grupo de escalado por función, independientemente de la configuración siempre lista para la aplicación. Las instancias creadas por la plataforma son administradas por la plataforma, se facturan como instancias listas para siempre y no cambian las opciones de configuración siempre preparadas.

  • Las instancias en función de la demanda se crean como resultado de los volúmenes de origen del evento a medida que la aplicación escala más allá del recuento de instancias siempre preparadas. Las instancias a petición se distribuyen entre zonas de disponibilidad de la mejor manera posible. La priorización del escalado horizontal rápido sobre la distribución uniforme entre zonas. La plataforma intenta equilibrar la distribución a lo largo del tiempo.

Al configurar planes de aplicación de funciones de Elastic Premium como con redundancia de zona, la plataforma propaga automáticamente las instancias del plan entre varias zonas de la región seleccionada. La propagación de instancias sigue estas reglas, incluso cuando la aplicación se expande y se contrae:

  • El número mínimo de instancias de la aplicación de funciones es dos.
  • Cuando se especifica una capacidad mayor que el número de zonas, las instancias solo se distribuyen uniformemente cuando la capacidad es un múltiplo del número de zonas.
  • Para un valor de capacidad mayor que Número de zonas * Número de instancias, las instancias adicionales se distribuyen entre las zonas restantes.

Cuando Functions asigna instancias a un plan Premium con redundancia de zona, usa el equilibrio de zona de mejor esfuerzo, que ofrece los conjuntos de escalado de máquinas virtuales de Azure subyacentes. Un plan Premium se considera equilibrado cuando cada zona tiene el mismo número de máquinas virtuales en todas las demás zonas usadas por el plan Premium, más o menos una máquina virtual.

Costo

No hay ningún costo adicional asociado a la habilitación de la redundancia de zona. Los precios de un plan con redundancia de zona son los mismos que los de un plan de zona única.

Sin embargo, cuando se habilitan zonas de disponibilidad en una aplicación con una configuración de instancia siempre lista para menos de dos instancias para cada función o grupo de escalado por función, la plataforma crea automáticamente dos instancias del tipo siempre listo para cada función o grupo de escalado por función. Estas nuevas instancias también se facturan como instancias siempre listas.

Sin embargo, si habilita zonas de disponibilidad en un plan con menos de dos instancias, la plataforma aplica un número mínimo de instancias de dos para ese plan y se le cobra por ambas instancias.

Para más información sobre los precios completos, consulte Precios de Azure Functions.

Configurar soporte de zonas de disponibilidad

  • Cree un nuevo plan de Azure Functions con redundancia de zona. Puede habilitar la redundancia de zona al crear un nuevo plan. Para obtener pasos detallados, consulte Creación de una aplicación de funciones con redundancia de zona.

  • Habilite la redundancia de zona en un plan existente: En el caso de los planes Premium, solo puede habilitar la redundancia de zona durante la creación del plan. No se puede convertir un plan de nivel Premium existente para que sea redundante en zonas. En su lugar, debe migrar la aplicación mediante la creación de una implementación en paralelo en una nueva aplicación de plan Premium. Para obtener más información, consulte Habilitación de la redundancia de zona en un plan existente.

Planeamiento y administración de capacidad

Las aplicaciones de funciones con redundancia de zona siguen ejecutándose incluso cuando las zonas de la región sufren una interrupción.

Durante una interrupción de zona, Azure Functions detecta instancias perdidas e intenta buscar o crear instancias de reemplazo automáticamente en las zonas correctas. Este proceso se realiza de la mejor manera posible y no está garantizado. Si la carga de trabajo debe tener un número determinado de instancias para mantener el nivel de servicio esperado, considere la posibilidad de sobreaprovisionar el número de instancias siempre listas. Este enfoque permite que la solución tolere cierta pérdida de capacidad y siga funcionando sin que se vea afectado su rendimiento. Para obtener más información, consulte Administración de la capacidad mediante el aprovisionamiento excesivo.

Comportamiento cuando todas las zonas están en buen estado

En esta sección se describe qué esperar cuando un plan tiene redundancia de zona, la cuenta de almacenamiento del host utiliza ZRS (Redundancia de Zona de Almacenamiento), y todas las zonas de disponibilidad están operativas.

  • Operación entre zonas: Al configurar la redundancia de zona en Azure Functions, las solicitudes se distribuyen automáticamente entre las instancias de cada zona de disponibilidad. Una solicitud puede ir a cualquier instancia de cualquier zona de disponibilidad.

  • Replicación de datos entre zonas: Azure Functions es un servicio de proceso sin estado, por lo que no hay datos de cliente para replicar entre zonas. La plataforma replica la configuración entre zonas automáticamente.

    Si la cuenta de almacenamiento de host usa ZRS, Azure Storage replica sincrónicamente sus datos en varias zonas de disponibilidad.

    Para Durable Functions, revise el proveedor de almacenamiento para comprender cómo replica datos entre zonas.

Comportamiento durante un fallo de zona

En esta sección se describe qué esperar cuando un plan tiene redundancia de zona, la cuenta de almacenamiento de host usa ZRS y hay una interrupción de zona de disponibilidad.

  • Detección y respuesta: La plataforma Azure Functions es responsable de detectar un error en una zona de disponibilidad. No es necesario hacer nada para iniciar una conmutación por error de la zona.
  • Notificación: Microsoft no le notifica automáticamente cuando una zona está inactiva. Sin embargo, puede usar Azure Resource Health para supervisar el estado de un recurso individual y puede configurar alertas de Resource Health para notificarle problemas. También puede usar Azure Service Health para comprender el estado general del servicio, incluidos los errores de zona, y puede configurar alertas de Service Health para notificarle problemas.

  • Solicitudes activas: Cuando una zona de disponibilidad no está disponible, las solicitudes en curso que están conectadas a una instancia de la zona de disponibilidad errónea se finalizan y deben reintentarse. Asegúrese de que las aplicaciones están preparadas siguiendo las instrucciones de control de errores transitorios.

  • Pérdida de datos esperada: No se espera que los errores de zona causen pérdida de datos porque Azure Functions es un servicio sin estado.

    Si la cuenta de almacenamiento de host usa ZRS, Azure Storage garantiza que no se pierdan datos de un error de zona.

    Para Durable Functions, revise el proveedor de almacenamiento para comprender si la pérdida de datos es posible durante un error de zona.

  • Tiempo de inactividad esperado: Durante las interrupciones de zona, las conexiones pueden experimentar interrupciones breves que suelen durar unos segundos a medida que se redistribuye el tráfico. Asegúrese de que las aplicaciones están preparadas siguiendo las instrucciones de control de errores transitorios.

  • Reenrutamiento del tráfico: Azure Functions detecta las instancias perdidas de esa zona e intenta buscar nuevas instancias de reemplazo. Después de que Azure Functions encuentre reemplazos, distribuye el tráfico entre las nuevas instancias según sea necesario.

    Importante

    Azure no garantiza que las solicitudes de más instancias se realicen correctamente en un escenario de zona descendente. La plataforma intenta reponer instancias perdidas de forma óptima. Si necesita capacidad garantizada durante un error de zona de disponibilidad, cree y configure los planes para tener en cuenta la pérdida de zona mediante el aprovisionamiento excesivo de la capacidad.

  • Comportamientos no en tiempo de ejecución: Las aplicaciones de un plan de aplicación de funciones con redundancia de zona siguen ejecutándose y atendiendo el tráfico incluso si una zona de disponibilidad experimenta una interrupción. Sin embargo, los comportamientos que no son de ejecución pueden verse afectados durante una interrupción de la zona de disponibilidad. Estos comportamientos incluyen el escalado de aplicaciones de funciones, la creación de aplicaciones, la configuración de la aplicación y la publicación de aplicaciones.

Recuperación de zona

Cuando se recupera la zona de disponibilidad, Azure Functions restaura automáticamente las instancias de la zona de disponibilidad, quita las instancias temporales creadas en las otras zonas de disponibilidad y vuelve a enrutar el tráfico entre las instancias como normal.

Prueba de fallos de zona

La plataforma Azure Functions administra el enrutamiento del tráfico, la conmutación por error y la recuperación por zona para los recursos con redundancia de zona. No es necesario iniciar nada. Dado que esta característica está totalmente administrada, no es necesario validar los procesos de error de zona de disponibilidad.

Resistencia a errores en toda la región

Azure Functions es un servicio de una sola región. Si la región deja de estar disponible, el recurso de Azure Functions tampoco está disponible.

Soluciones personalizadas de varias regiones para la resistencia

Para evitar que se pierdan los datos de la ejecución durante las interrupciones, puede implementar de forma redundante las mismas funciones en aplicaciones de funciones en varias regiones.

Usted es responsable de:

  • Implementación de aplicaciones de funciones en varias regiones
  • Administración de la distribución del tráfico entre regiones
  • Implementación de mecanismos de conmutación por error
  • Garantizar la coherencia de los datos entre regiones (si procede)
  • Supervisión y administración de implementaciones entre regiones

Al ejecutar el mismo código de función en varias regiones, hay dos patrones que se pueden usar habitualmente: activo-activo y activo-pasivo. En las secciones siguientes se proporciona una breve introducción a estos patrones, pero no se proporcionan instrucciones detalladas ni pasos de configuración.

Patrón activo-activo para funciones de desencadenador HTTP

Las funciones de ambas regiones están ejecutando y procesando eventos de forma activa, ya sea de manera duplicada o en rotación. Debe usar un patrón activo-activo en combinación con Azure Front Door para las funciones críticas desencadenadas por HTTP, que pueden enrutar y redondear solicitudes HTTP entre funciones que se ejecutan en varias regiones. Azure Front Door también puede comprobar periódicamente el estado de cada punto de conexión. Si una función en una región deja de responder a las verificaciones de estado, Azure Front Door la elimina de la rotación y solo reenvía el tráfico a las funciones restantes en buen estado.

Diagrama que muestra una arquitectura activa-activa de ejemplo, con enrutamiento de Azure Front Door entre aplicaciones de Azure Functions en distintas regiones, cada una con su propia base de datos.

Patrón activo-pasivo para funciones de desencadenador que no son HTTP

En el caso de las funciones desencadenadas por eventos y no desencadenadas por HTTP (como Las funciones desencadenadas por Service Bus y Event Hubs), use un patrón activo-pasivo. Con un patrón activo-pasivo, las funciones se ejecutan activamente en la región que recibe eventos, mientras que las mismas funciones de una segunda región permanecen inactivas. El patrón activo-pasivo proporciona una manera de que solo una función procese cada mensaje, lo que es importante para mantener la coherencia de los datos, al tiempo que proporciona un mecanismo para hacer failover a la región secundaria en caso de un desastre como una caída de la región.

La conmutación por error de la aplicación de función debe tenerse en cuenta junto con los comportamientos de conmutación por error de otros servicios, como:

Considere un ejemplo de topología con un desencadenador de Azure Event Hubs, donde el espacio de nombres de Event Hubs está configurado para la recuperación geográfica ante desastres. En este caso, el patrón activo-pasivo requiere los siguientes componentes:

  • Azure Event Hubs implementado en una región primaria y una secundaria.
  • Se habilitó la recuperación ante desastres geográfica para vincular los centros de eventos principales y secundarios. Esto también crea un alias que puede usar para conectarse al espacio de nombres de Event Hubs y cambiar de principal a secundario sin cambiar la información de conexión.
  • Las aplicaciones de funciones se implementaron en la región principal y la secundaria (conmutación por error), quedando la aplicación en la región secundaria prácticamente inactiva porque no se envían mensajes allí.
  • La aplicación de funciones se activa a partir de la cadena de conexión directa (sin alias) de su respectivo espacio de nombres de Event Hubs.
  • Los publicadores en el espacio de nombres de Event Hubs deben publicar en la cadena de conexión del alias.

Diagrama que muestra un ejemplo de arquitectura activa-pasiva, con recuperación geográfica ante desastres de Event Hubs que se extiende por varias regiones y funciones y bases de datos independientes en cada región.

Antes de conmutar por error, los publicadores que envían contenido al alias compartido se enrutarán al centro de eventos principal. La aplicación de función principal escucha exclusivamente al centro de eventos principal. La aplicación de funciones secundaria será pasiva y estará inactiva.

En cuanto se inicia la conmutación por error, los publicadores que envíen contenido al alias compartido se enrutarán al centro de eventos secundario. Así pues, la aplicación de funciones secundaria pasará a estar activa y comenzará a desencadenarse automáticamente. La conmutación por error efectiva a una región secundaria se puede controlar íntegramente desde el centro de eventos, donde las funciones solo se activan cuando lo hace el centro de eventos correspondiente.

Durable Functions

Para la recuperación ante desastres de varias regiones para Durable Functions, consulte Recuperación ante desastres y distribución geográfica en Azure Durable Functions.

Resistencia al mantenimiento del servicio

Azure Functions realiza actualizaciones de servicio periódicas y otras tareas de mantenimiento.

  • Resistencia de errores transitorios: Durante el mantenimiento del servicio, las instancias que ejecutan la aplicación de funciones pueden reiniciarse o experimentar interrupciones temporales. Asegúrese de que las aplicaciones cliente que interactúan con la aplicación de funciones son resistentes a errores transitorios.
  • Habilite la redundancia de zona: Al habilitar la redundancia de zona en el plan, también se mejora la resistencia durante las actualizaciones de la plataforma. La implementación de varias instancias en tu plan y la habilitación de la redundancia de zona para tu plan agrega una capa adicional de resiliencia si una instancia o zona deja de funcionar correctamente durante una actualización.

Para mantener la capacidad esperada durante una actualización, la plataforma agrega automáticamente instancias adicionales del plan durante el proceso de actualización.

  • Habilite la redundancia de zona: Al habilitar la redundancia de zona en el plan, también se mejora la resistencia durante las actualizaciones de la plataforma. Los dominios de actualización constan de colecciones de máquinas virtuales que se desconectan durante una actualización y se asignan a zonas de disponibilidad. La implementación de varias instancias en el plan y habilitar la redundancia de zona en el plan agrega una capa adicional de resiliencia si una instancia o zona se vuelve no saludable durante una actualización.

  • App Service Environment: Si hospeda la aplicación de funciones en una instancia de App Service Environment, puede personalizar el ciclo de actualización. Si necesita validar el efecto de las actualizaciones en su carga de trabajo, habilite las actualizaciones manuales. Este enfoque le permite realizar validaciones y pruebas en una instancia que no es de producción antes de aplicarlas a su instancia de producción.

    Para obtener más información sobre las preferencias de mantenimiento, consulte Preferencias de actualización para el mantenimiento planificado de App Service Environment.

Resistencia a las implementaciones de aplicaciones

Las implementaciones de aplicaciones presentan el riesgo de problemas en un entorno de producción. Debe estar preparado para revertir una actualización si provoca problemas. También debe controlar cómo se implementan las actualizaciones para minimizar la interrupción de los reinicios de la aplicación.

Los planes de Consumo Flex admiten estrategias de actualización de sitios, que proporcionan varias maneras de implementar las actualizaciones de la aplicación, incluidas las actualizaciones graduales para despliegues sin tiempo de inactividad.

Las ranuras de implementación de Azure Functions permiten implementaciones sin tiempo de inactividad de las aplicaciones de función. Use ranuras de implementación para minimizar el efecto de las implementaciones y los cambios de configuración para los usuarios. Las ranuras de implementación también reducen la probabilidad de que se reinicie la aplicación. Reiniciar la aplicación produce un error transitorio.

Acuerdo de nivel de servicio

El acuerdo de nivel de servicio (SLA) para Azure servicios describe la disponibilidad esperada de cada servicio y las condiciones que la solución debe cumplir para lograr esa expectativa de disponibilidad. Para obtener más información, consulte Acuerdos de Nivel de Servicio para servicios en línea.

Azure Functions proporciona acuerdos de nivel de servicio de disponibilidad distintos para el plan de consumo y para otros tipos de plan.

Contenido relacionado

  • Last updated on