Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure Functions es un servicio de proceso controlado por eventos que ejecuta pequeños bloques de código o funciones sin aprovisionamiento o administración de infraestructuras explícitas. Las funciones pueden responder a eventos como solicitudes HTTP, temporizadores, mensajes de cola y cambios en otros servicios de Azure. Esta funcionalidad hace que Functions sea adecuado para el procesamiento de datos, la integración del sistema y las 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 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 Functions.
Recomendaciones de implementación de producción
Azure Well-Architected Framework proporciona recomendaciones sobre confiabilidad, seguridad, costo, operaciones y rendimiento. Para obtener información sobre cómo estas áreas influyen entre sí y contribuyen a una solución confiable de Functions, consulte Procedimientos recomendados de arquitectura para Functions.
Introducción a la arquitectura de confiabilidad
Al implementar Functions, es importante familiarizarse con estos 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 gestiona aspectos de las operaciones internas de la aplicación de funciones, incluidos el almacenamiento de código de funciones, el registro y la gestión de concurrencia (como en el caso de las concesiones de blobs para tipos específicos 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 una parte fundamental de la arquitectura de confiabilidad de Functions. Configúrelos para satisfacer los requisitos de resistencia de la aplicación de funciones.
Desencadenadores y enlaces: Los desencadenadores y enlaces permiten que la función responda a eventos, reciba datos de otros servicios y escriba datos en otros servicios.
Durable Functions: Durable Functions es una característica de Functions. Proporciona funciones con estado, como orquestaciones de larga duración y entidades con estado.
Cuando se usan funciones duraderas, se configura un proveedor de almacenamiento que almacena el estado. Evalúe las características de confiabilidad del almacén de estado que elija y configúrela para satisfacer los requisitos de resistencia.
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 Functions incluye el control de errores transitorios integrado para desencadenadores y enlaces. Cuando se produce un error transitorio mientras se desencadena un desencadenador compatible o se leen o escriben datos de enlace admitidos, la plataforma puede reintentar automáticamente la operación. Este comportamiento de reintento integrado garantiza que los problemas de conectividad temporal o las interrupciones del servicio no impidan que la función se ejecute. Para obtener más información, consulte Control de errores y reintentos de Functions.
Esta protección solo cubre errores transitorios. La plataforma no reintenta los errores persistentes, como un cadena de conexión mal configurado o un recurso eliminado.
La plataforma trata los errores persistentes y los errores transitorios repetidos como errores. Configure el registro para capturar información sobre los errores de ejecución de funciones. Para obtener más información, consulte Configuración de la supervisión de Funciones.
Tu código de función: En tu código de función, eres responsable de controlar errores transitorios cuando tu función llame a servicios externos. Implemente la lógica de reintento, los tiempos de espera y los patrones de cortacircuito según corresponda para las llamadas de servicio externas realizadas en su código de función. Diseñe las funciones para que sean idempotentes siempre que sea posible, de modo que los reintentos no creen efectos secundarios repetidos.
Clientes: Las aplicaciones cliente que se conectan a funciones de forma sincrónica, como a través de 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 la carga de trabajo, considere la posibilidad de usar los planes flex consumption, Premium o Dedicated (Azure App Service) en su lugar.
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 en instancias de zonas saludables.
Debe habilitar el almacenamiento con redundancia de zona (ZRS) en la cuenta de almacenamiento del host, para garantizar que también sea resistente a las interrupciones de zona.
En el diagrama se muestran tres zonas de disponibilidad. Cada zona contiene una instancia de Functions. Una cuenta de ZRS abarca las tres zonas de disponibilidad.
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 obtener más información sobre cómo Azure App Service controla la redundancia de zona, consulte Reliability in App Service.
El plan es no zonal o regional cuando no se habilita la redundancia de zona. La plataforma puede ubicar instancias de plan en cualquier zona de disponibilidad de la región o en la misma zona. Las instancias del plan no son tolerantes a fallos en las zonas 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: Puede implementar planes de consumo flexible con redundancia de zona 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: Puede implementar planes Premium con redundancia de zona 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: La plataforma permite la implementación de planes de Windows y Linux con soporte de redundancia zonal.
Recuento mínimo de instancias: La redundancia de zona para los planes Premium requiere un mínimo de dos instancias listas para siempre.
- Cuenta de almacenamiento de host: Debe configurar la cuenta de almacenamiento de host predeterminada de la aplicación de funciones para usar 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, actualícela también para que sea redundante de zona.
Consideraciones
Comportamientos no en tiempo de ejecución: La redundancia de zona solo garantiza un tiempo de actividad continuado para las aplicaciones implementadas. Una interrupción de zona de disponibilidad puede afectar a aspectos de Functions, aunque la aplicación siga sirviendo 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 redundantes por zona, la plataforma distribuye automáticamente las instancias del plan en varias zonas de la región seleccionada, aplicando reglas diferentes para instancias siempre activas en comparación con las instancias bajo demanda.
Las instancias siempre disponibles se distribuyen entre al menos dos zonas mediante la distribución 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 que crea la plataforma son administradas por la plataforma, facturadas como instancias listas para siempre y no cambian las opciones de configuración siempre preparadas.
Las instancias a petición se generan a partir de volúmenes fuente de eventos cuando la aplicación se escala más allá del número de instancias siempre listas. Las instancias a petición se distribuyen entre zonas de disponibilidad de la mejor manera posible. La plataforma prioriza un escalado horizontal más rápido en lugar de una 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 distribuye automáticamente las instancias del plan en 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 el número de zonas multiplicado por el número de instancias, las instancias adicionales se distribuyen por las zonas restantes.
Cuando Functions asigna instancias a un plan Premium con redundancia de zona, usa equilibrio de zonas de mejor esfuerzo, que proporcionan los conjuntos de escalado de máquinas virtuales de Azure subyacentes. Azure considera un plan Premium balanced cuando cada zona tiene el mismo número de máquinas virtuales (VM) que las demás zonas del plan, más o menos una máquina virtual.
Costo
No se incurre en ningún costo adicional al habilitar 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, habilitar la redundancia de zona afecta al número mínimo de instancias del plan.
Cuando se habilitan zonas de disponibilidad en una aplicación con una configuración de instancia del tipo siempre lista, y hay 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 lista para cada función o grupo de escalado por función. Estas nuevas instancias también se facturan como instancias siempre listas.
Si habilita zonas de disponibilidad en un plan que tiene 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 Functions.
Configurar soporte de zonas de disponibilidad
Cree un nuevo plan de Funciones con redundancia de zona. Puede habilitar la redundancia de zona al crear un nuevo plan. Para obtener más información, consulte Creación de una aplicación de funciones con redundancia de zona.
Habilite la redundancia de zona en un plan existente. Puede activar o desactivar las zonas de disponibilidad para los planes de Elastic Premium existentes. Los planes elastic Premium tienen un comportamiento de capacidad específico que difiere de los planes dedicados (App Service) y requiere pasos de configuración adicionales. Para ver los pasos detallados, consulte Habilitación de la redundancia de zona en un plan existente.
Cree un nuevo plan de Funciones con redundancia de zona. Puede habilitar la redundancia de zona al crear un nuevo plan. Para obtener más información, 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 Premium existente para que sea compatible con redundancia de zona. En su lugar, migre 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 experimentan una interrupción.
Durante una interrupción en la zona, Functions detecta instancias perdidas e intenta automáticamente buscar o crear instancias de reemplazo en las zonas saludables. La plataforma realiza este proceso en base al mejor esfuerzo y no garantiza el éxito. Si la carga de trabajo requiere un número específico de instancias para mantener el nivel de servicio esperado, considere la posibilidad de sobreaprovisionar el número de instancias siempre listas. El sobreaprovisionamiento permite a la solución tolerar la pérdida de capacidad y seguir funcionando sin reducir el rendimiento. Para más información, consulte Administración de la capacidad mediante el sobreaprovisionamiento.
Comportamiento cuando todas las zonas están en buen estado
En esta sección se describe qué esperar cuando un plan es con redundancia de zona, la cuenta de almacenamiento de host usa ZRS y todas las zonas de disponibilidad están operativas.
Operación entre zonas: Al configurar la redundancia de zona en 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: Functions es un servicio de proceso sin estado, por lo que no hay datos 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 funciones duraderas, revise el proveedor de almacenamiento para obtener información sobre 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 del host usa ZRS y hay una interrupción en una zona de disponibilidad.
- Detección y respuesta: La plataforma Functions es responsable de detectar un error en una zona de disponibilidad. No es necesario iniciar una conmutación por error de 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 se conectan a una instancia de la zona de disponibilidad errónea finalizan y se deben reintentar. 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 Functions es un servicio sin estado.
Si la cuenta de almacenamiento de host utiliza ZRS, el almacenamiento garantiza que no se pierdan datos debido a un fallo de zona.
Para las funciones duraderas, compruebe su proveedor de almacenamiento para saber si la pérdida de datos sea posible durante un fallo 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: Functions detecta las instancias perdidas de esa zona e intenta buscar nuevas instancias de reemplazo. Una vez que Functions encuentra 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 sobreaprovisionamiento 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, 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 Functions administra el enrutamiento del tráfico, la conmutación por error y la recuperación de zona para los recursos con redundancia de zona. No es necesario iniciar nada. Azure administra completamente esta característica, por lo que no es necesario validar los procesos de error de zona de disponibilidad.
Resistencia a errores en toda la región
Functions es un servicio de una sola región. Si la región deja de estar disponible, el recurso de Functions tampoco está disponible.
Soluciones personalizadas de varias regiones para la resistencia
Para evitar interrupciones en su servicio durante caídas regionales, 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, tenga en cuenta los patrones activo-activo y activo-pasivo . En las secciones siguientes se presentan estos patrones, pero no se proporcionan instrucciones detalladas ni pasos de configuración.
Patrón activo-activo para funciones de desencadenador HTTP
En un patrón activo-activo, las funciones en las dos regiones ejecutan activamente y procesan eventos, ya sea de forma duplicada o de manera alternada. Utilice un patrón activo-activo en combinación con Azure Front Door para sus funciones críticas desencadenadas por HTTP, que pueden enrutar y distribuir solicitudes HTTP entre funciones que se están ejecutando en varias regiones. Azure Front Door también puede comprobar periódicamente el estado de cada punto de conexión. Si un servicio de una región deja de responder a las comprobaciones de estado, Azure Front Door lo quita de la rotación y solo reenvía el tráfico a los servicios saludables restantes.
El diagrama muestra Azure Front Door en la parte superior. A continuación aparecen dos regiones: la región primaria de la izquierda y la región secundaria de la derecha. Cada región contiene una aplicación de Functions y una base de datos. Las flechas apuntan de Azure Front Door a ambas aplicaciones de funciones. Una flecha apunta de cada aplicación de función a su base de datos correspondiente.
Patrón activo-pasivo para funciones de desencadenador que no son HTTP
En el caso de funciones dirigidas por eventos que no se activan mediante HTTP (como activadores de Azure Service Bus y Azure Event Hubs), use un patrón activo-pasivo. En un patrón activo-pasivo, las instancias de función se ejecutan en la región que recibe eventos, mientras que las instancias de la región secundaria permanecen inactivas. Este patrón garantiza que solo una función procese cada mensaje, lo que ayuda a mantener la coherencia de los datos. Permite conmutar por error a la región secundaria durante un desastre, como una interrupción de la región.
Considere la conmutación por error de la app de funciones junto con los comportamientos de conmutación por error de otros servicios que use, como:
- Service Bus, replicación geográfica y recuperación ante desastres
- Replicación geográfica de Event Hubs y recuperación ante desastres geográfica
Considere una topología de ejemplo que usa un activador de Event Hubs, donde el espacio de nombres de Event Hubs está configurado para la recuperación ante desastres geográficos. En este caso, el patrón activo-pasivo requiere los siguientes componentes:
Espacios de nombres de Event Hubs implementados tanto en una región primaria como en una secundaria.
Se habilitó la recuperación ante desastres geográfica para vincular los centros de eventos principales y secundarios. Esta configuración también crea un alias que puede usar para conectarse al espacio de nombres de Event Hubs y cambiar el alias de la base de datos principal a la secundaria sin cambios en la información de conexión.
Aplicaciones de funciones desplegadas tanto en la región primaria como en la secundaria. La aplicación de la región secundaria permanece inactiva porque no recibe mensajes.
Los desencadenadores de cada aplicación de funciones utilizan la cadena de conexión direct (noalias) para su espacio de nombres correspondiente de Event Hubs.
Los publicadores del espacio de nombres de Event Hubs publican al alias de la cadena de conexión.
El diagrama muestra una región primaria a la izquierda y una región secundaria a la derecha. La región primaria contiene un espacio de nombres de Event Hubs activo, una aplicación de funciones y una base de datos. La región secundaria contiene un espacio de nombres de Event Hubs pasivo, una aplicación de funciones y una base de datos. Una flecha apunta desde el alias a la recuperación ante desastres geográfica de Event Hubs, que conecta los espacios de nombres principal y secundario de Event Hubs. Las flechas apuntan desde cada centro de eventos a su aplicación de función correspondiente. Una flecha apunta de cada aplicación de función a su base de datos correspondiente.
Antes de la conmutación por error, los publicadores que envían eventos al alias compartido dirigen el tráfico hacia el centro de eventos principal. La aplicación de funciones principal escucha exclusivamente al hub de eventos principal. La aplicación de funciones secundaria permanece pasiva e inactiva.
Cuando se inicia el failover, los publicadores que envían eventos al alias compartido son dirigidos al centro de eventos secundario. La aplicación de funciones secundaria se activa y se desencadena automáticamente. El centro de eventos puede controlar todo el proceso de conmutación por error y cada aplicación de funciones solo se ejecuta cuando su centro de eventos correspondiente está activo.
Durable Functions
Para la recuperación ante desastres en varias regiones para funciones duraderas, consulte Disaster recovery and geo-distribution in Azure durable functions.
Resistencia al mantenimiento del servicio
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. Implementar varias instancias en tu plan y habilitar la redundancia de zonas proporciona una capa adicional de resiliencia si una instancia o una zona se vuelven defectuosas durante un proceso de actualización.
Instancias temporales adicionales: 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 y la habilitación de la redundancia de zona en su plan agrega una capa adicional de resiliencia si una instancia o una zona se vuelve inestable 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 debe validar el efecto de las actualizaciones en la carga de trabajo, habilite las actualizaciones manuales. Use este enfoque para validar y probar una instancia de no producción antes de aplicar las actualizaciones a la 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. Prepárese para revertir una actualización si provoca problemas. Controlar cómo se implementan las actualizaciones para reducir la interrupción de los reinicios de la aplicación.
Los planes de consumo flexible admiten estrategias de actualización del sitio, que proporcionan varias maneras de implementar las actualizaciones de la aplicación. Estas estrategias incluyen actualizaciones graduales para implementaciones sin tiempo de inactividad.
Las ranuras de implementación de Functions permiten implementaciones sin tiempo de inactividad de las aplicaciones de funciones. 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. Los reinicios de la aplicación provocan errores transitorios.
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.
Functions proporciona acuerdos de nivel de servicio de disponibilidad distintos para el plan de consumo y para otros tipos de plan.