Confiabilidade no Azure Functions

Azure Functions é um serviço de computação controlado por eventos que executa pequenos blocos de código ou functions, sem provisionamento ou gerenciamento de infraestrutura explícito. As funções podem responder a eventos como solicitações HTTP, temporizadores, mensagens de fila e alterações em outros serviços Azure. Essa funcionalidade torna o Functions adequado para processamento de dados, integração do sistema e tarefas em segundo plano.

Quando você usa o Azure, a confiabilidade é uma responsabilidade compartilhada. A Microsoft fornece uma variedade de recursos para dar suporte à resiliência e recuperação. Você é responsável por entender como esses recursos funcionam em todos os serviços que você usa e selecionar os recursos necessários para atender aos seus objetivos de negócios e metas de tempo de atividade.

Este artigo descreve como tornar o Functions resiliente a várias possíveis interrupções e problemas, incluindo falhas transitórias, falhas na zona de disponibilidade e falhas em toda a região. Ele também destaca as principais informações sobre o SLA (contrato de nível de serviço) do Functions.

Recomendações de implantação de produção

O Azure Well-Architected Framework fornece recomendações sobre confiabilidade, segurança, custo, operações e desempenho. Para saber como essas áreas influenciam umas às outras e contribuem para uma solução confiável do Functions, consulte as práticas recomendadas de arquitetura para funções.

Visão geral da arquitetura de confiabilidade

Ao implantar o Functions, é importante familiarizar-se com esses conceitos:

  • Planos de hospedagem: Os planos representam o ambiente de hospedagem para seus aplicativos de funções. O plano determina os recursos de computação disponíveis, o modelo de preços e o comportamento de dimensionamento.

  • Contas de armazenamento: Ao criar um aplicativo de funções, você deve especificar uma conta de armazenamento de host. A conta de armazenamento gerencia aspectos das operações internas do aplicativo de funções, incluindo armazenamento do código da função, registro de logs e gerenciamento de simultaneidade (como concessões de objetos de armazenamento para tipos de gatilho específicos).

    Você também pode usar uma conta de armazenamento para implantação. Essa conta de armazenamento pode ser a mesma que sua conta de armazenamento de host ou uma conta de armazenamento diferente.

    Importante

    As contas de armazenamento são uma parte crítica da arquitetura de confiabilidade do Functions. Configure-os para atender aos requisitos de resiliência do aplicativo de funções.

  • Gatilhos e associações: Gatilhos e associações permitem que sua função responda a eventos, receba dados de outros serviços e escreva dados em outros serviços.

  • Funções duráveis: As funções duráveis são um recurso do Functions. Ele fornece funções com estado, como orquestrações de longa execução e entidades com estado.

    Ao usar funções duráveis, você configura um provedor de armazenamento que armazena o estado. Avalie as características de confiabilidade do repositório de estado escolhido e configure-o para atender aos seus requisitos de resiliência.

Resiliência a falhas transitórias

Falhas transitórias são falhas curtas e intermitentes nos componentes. Elas ocorrem com frequência em um ambiente distribuído, como a nuvem, e são uma parte normal das operações. Falhas transitórias se corrigem após um curto período de tempo. É importante que seus aplicativos possam lidar com falhas transitórias, geralmente repetindo solicitações afetadas.

Todos os aplicativos hospedados na nuvem devem seguir as diretrizes transitórias de tratamento de falhas do Azure quando eles se comunicam com qualquer APIs, bancos de dados e outros componentes hospedados na nuvem. Para obter mais informações, confira Recomendações para tratamento de falhas transitórias.

Considere as seguintes recomendações para lidar com falhas transitórias em seus aplicativos de funções:

  • Gatilhos e associações: A plataforma functions inclui tratamento de falhas transitórias internas para gatilhos e associações. Quando ocorre uma falha transitória enquanto um gatilho com suporte é acionado ou uma associação com suporte lê ou grava dados, a plataforma pode repetir automaticamente a operação. Esse comportamento de repetição interno garante que problemas temporários de conectividade ou interrupções de serviço não impeçam a execução da função. Para obter mais informações, consulte o tratamento de erros e tentativas de repetição no Functions.

    Essa proteção abrange apenas falhas transitórias. A plataforma não tenta novamente falhas persistentes, como um cadeia de conexão configurado incorretamente ou um recurso excluído.

    A plataforma trata falhas persistentes e falhas transitórias repetidas como erros. Configure o log para capturar informações sobre erros de execução de função. Para obter mais informações, consulte Configurar o monitoramento para funções.

  • Seu código de função: No código de função, você é responsável por lidar com falhas transitórias quando sua função chama serviços externos. Implemente lógica de repetição, tempos limite e padrões de disjuntor conforme apropriado para chamadas de serviço externas feitas em seu código de função. Projete suas funções para serem idempotentes sempre que possível e as repetições não criem efeitos colaterais duplicados.

  • Clientes: Os aplicativos cliente que se conectam a funções de forma síncrona, como por meio de uma conexão HTTP, devem ser resilientes a falhas transitórias.

Resiliência a falhas de zona de disponibilidade

As zonas de disponibilidade são grupos fisicamente separados de datacenters em uma região do Azure. Quando uma zona falha, os serviços podem fazer o failover de uma das zonas restantes.

Os planos de consumo não dão suporte a zonas de disponibilidade. Se a redundância de zona for um requisito para seu workload, considere utilizar os planos Flex Consumo, Premium ou Dedicado (Serviço de Aplicativo do Azure).

Os Flex Consumption plans dão suporte a implantações com redundância de zona.

Os planos Premium suportam implantações com redundância de zona.

Quando a redundância de zona está habilitada, a plataforma espalha automaticamente suas instâncias de plano em todas as zonas de disponibilidade na região selecionada. Se qualquer zona de disponibilidade na região tiver um problema, suas funções continuarão sendo executadas usando instâncias em zonas saudáveis.

Você deve habilitar o ZRS (armazenamento com redundância de zona) na conta de armazenamento do host, o que garante que ele também seja resiliente a interrupções de zona.

Diagrama que mostra um plano de funções com redundância de zona que tem três instâncias espalhadas por três zonas e uma conta ZRS.

O plano Dedicado (Serviço de Aplicativo) dá suporte a implantações com redundância zonal. Quando a redundância de zona está habilitada, a plataforma espalha automaticamente suas instâncias em todas as zonas de disponibilidade na região selecionada. Você configura a redundância de zona no plano. Para obter mais informações sobre como Serviço de Aplicativo do Azure lida com a redundância de zona, consulte Reliability no Serviço de Aplicativo.

Seu plano é nonzonal ou regional quando você não habilita a redundância de zona. A plataforma pode colocar instâncias de planos em qualquer zona de disponibilidade na região ou na mesma zona. As instâncias de plano não são resilientes a falhas de zona de disponibilidade. Seu plano pode enfrentar tempo de inatividade durante uma interrupção em qualquer zona da região.

Requisitos

  • Suporte à região: Você pode implantar planos de Consumo Flex com redundância de zona em um conjunto específico de regiões. Você pode recuperar a lista atual de regiões com suporte usando a CLI do Azure. Para obter mais informações, consulte Exibir regiões que dão suporte a zonas de disponibilidade.

  • Suporte à região: Você pode implantar planos Premium redundantes por zona nas regiões a seguir.

    Américas Europa Médio Oriente Africa Pacífico Asiático
    Sul do Brasil França Central Israel Central Norte da África do Sul Leste da Austrália
    Canadá Central Centro-oeste da Alemanha Catar Central Índia Central
    EUA Central Norte da Itália Norte dos EAU Norte da China 3
    Leste dos EUA Europa Setentrional Ásia Oriental
    Leste dos EUA 2 Leste da Noruega Leste do Japão
    Centro-Sul dos EUA Suécia Central Sudeste Asiático
    Oeste dos EUA 2 Norte da Suíça
    Oeste dos EUA 3 Sul do Reino Unido
    Oeste da Europa

  • Sistemas operacionais: a plataforma dá suporte à implantação de planos Windows e Linux com redundância de zona.

  • Contagem mínima de instâncias: A redundância de zona para planos Premium requer um mínimo de duas instâncias sempre prontas.

  • Conta de armazenamento do host: Você deve configurar a conta de armazenamento de host padrão do aplicativo de funções para usar o ZRS. Se você usar uma conta de armazenamento de host que não está configurada para ZRS, seu aplicativo poderá se comportar inesperadamente durante uma interrupção de zona.
  • Conta de armazenamento de contêiner de implantação: Se você usar uma conta de armazenamento separada para o contêiner de implantação do aplicativo, atualize-a para ser com redundância de zona.

Considerações

Comportamentos fora do tempo de execução: A redundância de zona só garante continuidade operacional para aplicativos implantados. Uma interrupção da zona de disponibilidade pode afetar aspectos do Functions, mesmo que o aplicativo continue a atender ao tráfego. Esses comportamentos incluem dimensionamento de plano, criação de aplicativo, configuração de aplicativo e publicação de aplicativos.

Distribuição de instâncias entre zonas

Quando você configura aplicativos de plano Flex de consumo com redundância de zona, a plataforma distribui automaticamente as instâncias do plano entre várias zonas na região selecionada, com regras diferentes para instâncias sempre prontas e sob demanda.

  • As instâncias sempre prontas são distribuídas em pelo menos duas zonas usando a distribuição round-robin.

    Para garantir a resiliência da zona, a plataforma mantém automaticamente pelo menos duas instâncias sempre prontas para cada função ou grupo de dimensionamento por função, independentemente da configuração sempre pronta para o aplicativo. As instâncias criadas pela plataforma são gerenciadas pela plataforma, cobradas como instâncias sempre disponíveis e não alteram as configurações de sempre disponíveis.

  • As instâncias sob demanda resultam de volumes de origem de eventos à medida que o aplicativo é dimensionado além da contagem de instâncias sempre prontas. As instâncias sob demanda são distribuídas entre zonas de disponibilidade com base em melhor esforço. A plataforma prioriza uma expansão mais rápida em relação à distribuição uniforme entre zonas. A plataforma tenta equilibrar a distribuição ao longo do tempo.

Quando você configura os planos do aplicativo de funções Elastic Premium como redundantes em zona, a plataforma espalha automaticamente as instâncias do plano por várias zonas na região selecionada. A propagação de instância segue estas regras, mesmo quando o aplicativo é escalonado para cima e para baixo:

  • A contagem mínima de instâncias do aplicativo de funções é duas.

  • Quando você especifica uma capacidade maior que o número de zonas, as instâncias são distribuídas uniformemente somente quando a capacidade é um múltiplo do número de zonas.

  • Para um valor de capacidade maior que o número de zonas multiplicadas pelo número de instâncias, instâncias extras são distribuídas entre as zonas restantes.

Quando o Azure Functions aloca instâncias para um plano Premium com redundância de zona, ele usa o balanceamento de zona por melhor esforço, que os conjuntos de dimensionamento de máquinas virtuais do Azure subjacentes fornecem. Azure considera um plano Premium balanceado quando cada zona tiver o mesmo número de VMs (máquinas virtuais) que as outras zonas do plano, mais ou menos uma VM.

Custo

Você não incorre em nenhum custo extra ao habilitar a redundância de zona. O preço de um plano com redundância de zona é o mesmo que um plano de zona única. No entanto, habilitar a redundância de zona afeta o número mínimo de instâncias do seu plano.

Quando você habilita zonas de disponibilidade em um aplicativo com uma configuração de instância sempre pronta de menos de duas instâncias para cada função ou grupo de dimensionamento por função, a plataforma cria automaticamente duas instâncias do tipo sempre pronto para cada função ou grupo de dimensionamento por função. Essas novas instâncias também são cobradas como instâncias sempre prontas.

Se você habilitar zonas de disponibilidade em um plano que tenha menos de duas instâncias, a plataforma imporá uma contagem mínima de duas instâncias para esse plano e você será cobrado por ambas as instâncias.

Para obter detalhes de preços completos, consulte os preços do Functions.

Configurar o suporte à zona de disponibilidade

  • Crie um novo plano de funções com redundância de zona. Você pode habilitar a redundância de zona ao criar um novo plano. Para obter mais informações, consulte Criar um aplicativo de funções com redundância de zona.

  • Habilite a redundância de zona em um plano existente. Você pode ativar ou desativar zonas de disponibilidade para planos Elástico Premium existentes. Os planos Elastic Premium têm um comportamento de capacidade específico que difere dos planos dedicados (Serviço de Aplicativo) e exige etapas de configuração extras. Para obter etapas detalhadas, consulte Habilitar redundância de zona em um plano existente.

  • Crie um novo plano de funções com redundância de zona. Você pode habilitar a redundância de zona ao criar um novo plano. Para obter mais informações, consulte Criar um aplicativo de funções com redundância de zona.

  • Habilite a redundância de zona em um plano existente. Para planos Premium, você pode habilitar a redundância de zona somente durante a criação do plano. Você não pode converter um plano Premium existente em um com redundância de zona. Em vez disso, migre seu aplicativo criando uma implantação lado a lado em um novo aplicativo de plano Premium. Para obter mais informações, consulte Habilitar redundância de zona em um plano existente.

Planejamento e gerenciamento de capacidade

Os aplicativos de funções com redundância de zona continuam a ser executados mesmo quando as zonas na região enfrentam uma interrupção.

Durante uma interrupção de zona, o Functions detecta instâncias perdidas e tenta localizar ou criar automaticamente instâncias de substituição nas zonas íntegras. A plataforma executa esse processo com o melhor esforço e não garante o sucesso. Se sua carga de trabalho exigir um número específico de instâncias para manter o nível de serviço esperado, considere superprovisionar o número de instâncias sempre prontas. O excesso de provisionamento permite que a solução tolere a perda de capacidade e continue funcionando sem desempenho reduzido. Para obter mais informações, consulte Gerenciar capacidade por excesso de provisionamento.

Comportamento quando todas as zonas estão saudáveis

Esta seção descreve o que se deve esperar quando um plano tem redundância de zona, a conta de armazenamento do host utiliza ZRS e todas as zonas de disponibilidade estão operacionais.

  • Operação entre zonas: Quando você configura a redundância de zona no Functions, as solicitações são distribuídas automaticamente entre as instâncias em cada zona de disponibilidade. Uma solicitação pode ir para qualquer instância em qualquer zona de disponibilidade.

  • Replicação de dados entre zonas: O Functions é um serviço de computação sem estado, portanto, não há dados a serem replicados entre zonas. A plataforma replica a configuração entre zonas automaticamente.

    Se sua conta de armazenamento de host usar o ZRS, o Armazenamento do Azure replicará de forma síncrona seus dados em várias zonas de disponibilidade.

    Para funções duráveis, examine seu provedor de armazenamento para saber como ele replica dados entre zonas.

Comportamento durante uma falha de zona

Esta seção descreve o que esperar quando um plano é redundante entre zonas, a conta de armazenamento do host utiliza ZRS, e ocorre uma interrupção em uma zona de disponibilidade.

  • Detecção e resposta: A plataforma functions é responsável por detectar uma falha em uma zona de disponibilidade. Você não precisa iniciar um failover de zona.
  • Notificação: a Microsoft não notifica você automaticamente quando uma zona está inativa. No entanto, você pode usar Azure Resource Health para monitorar a integridade de um recurso individual e pode configurar alertas Resource Health para notificar você sobre problemas. Você também pode usar Integridade do Serviço do Azure para entender a integridade geral do serviço, incluindo quaisquer falhas de zona, e você pode configurar alertas Service Health para notificar você sobre problemas.

  • Solicitações ativas: Quando uma zona de disponibilidade não está disponível, as solicitações em andamento que se conectam a uma instância na zona de disponibilidade com falha terminam e devem ser repetidas. Verifique se seus aplicativos estão preparados seguindo as diretrizes transitórias de tratamento de falhas.

  • Perda de dados esperada: Não se espera que falhas de zona causem perda de dados porque o Functions é um serviço sem estado.

    Se sua conta de armazenamento de host usar ZRS, o Armazenamento garantirá que não haja perda de dados de uma falha de zona.

    Para funções duráveis, examine seu provedor de armazenamento para saber se a perda de dados é possível durante uma falha de zona.

  • Tempo de inatividade esperado: Durante interrupções de zona, as conexões podem sofrer breves interrupções que normalmente duram alguns segundos à medida que o tráfego é redistribuído. Verifique se seus aplicativos estão preparados seguindo as diretrizes transitórias de tratamento de falhas.

  • Redirecionamento de tráfego: O Functions detecta as instâncias perdidas dessa zona e tenta encontrar novas instâncias de substituição. Depois que o Functions localiza substituições, ele distribui o tráfego entre as novas instâncias conforme necessário.

    Importante

    O Azure não garante que as solicitações por mais instâncias sejam bem-sucedidas em um cenário de queda de zona. A plataforma tenta repor as instâncias perdidas com base no melhor esforço possível. Se você precisar de capacidade garantida durante uma falha na zona de disponibilidade, crie e configure seus planos para considerar a perda de zona superprovisionando a capacidade.

  • Comportamentos fora do tempo de execução: Os aplicativos em um plano de aplicativo de função com redundância por zona continuam a ser executados e atendem ao tráfego mesmo que uma zona de disponibilidade sofra uma parada. No entanto, comportamentos que não são de runtime ainda podem ser afetados durante uma interrupção da zona de disponibilidade. Esses comportamentos incluem dimensionamento de aplicativo de funções, criação de aplicativo, configuração de aplicativo e publicação de aplicativos.

Recuperação de zona

Quando a zona de disponibilidade se recupera, o Functions restaura automaticamente instâncias na zona de disponibilidade, remove instâncias temporárias criadas nas outras zonas de disponibilidade e redireciona o tráfego entre suas instâncias normalmente.

Testar falhas em zonas

A plataforma Functions gerencia o roteamento de tráfego, o failover e a recuperação por zona para recursos com redundância de zona. Você não precisa iniciar nada. Azure gerencia totalmente esse recurso, portanto, você não precisa validar os processos de falha da zona de disponibilidade.

Resiliência a falhas em toda a região

O Functions é um serviço de região única. Se a região ficar indisponível, o recurso do Functions também ficará indisponível.

Soluções personalizadas de várias regiões para resiliência

Para evitar interrupções em seu serviço durante interrupções em toda a região, você pode implantar com redundância as mesmas funções em aplicativos de funções em várias regiões.

Você é responsável por:

  • Implantando aplicativos de funções em várias regiões.

  • Gerenciando a distribuição de tráfego entre regiões.

  • Implementando mecanismos de comutação por falha.

  • Garantindo a consistência de dados entre regiões (se aplicável).

  • Monitoramento e gerenciamento de implantações entre regiões.

Ao executar o mesmo código de função em várias regiões, considere os modelos ativo-ativo e ativo-passivo. As seções a seguir introduzem esses padrões, mas não fornecem diretrizes detalhadas ou etapas de configuração.

Padrão ativo-ativo para funções de gatilho HTTP

Em um padrão ativo-ativo, as funções em ambas as regiões executam e processam eventos ativamente, de maneira duplicada ou em rotação. Use um padrão ativo-ativo em combinação com Azure Front Door para suas funções críticas disparadas por HTTP, que podem rotear e distribuir de forma alternada solicitações HTTP entre funções que podem se espalhar por várias regiões. O Azure Front Door também pode monitorar periodicamente a integridade de cada ponto de extremidade. Se uma função em uma região parar de responder a verificações de integridade, Azure Front Door a removerá da rotação e encaminhará apenas o tráfego para as funções restantes que estiverem operacionais.

Diagrama que mostra um exemplo de arquitetura ativa-ativa. Azure Front Door roteia entre aplicativos do Funções em regiões diferentes, cada uma com seu próprio banco de dados.

Padrão ativo-passivo para funções de gatilho não HTTP

Para funções controladas por eventos, não disparadas por HTTP (como gatilhos Barramento de Serviço do Azure e Hubs de Eventos do Azure), use um padrão ativo-passivo. Em um padrão ativo-passivo, as instâncias de função são executadas na região que recebe eventos, enquanto as instâncias na região secundária permanecem ociosas. Esse padrão garante que apenas uma função processe cada mensagem, o que ajuda a manter a consistência dos dados. Ele também fornece uma maneira de fazer alternância automática para a região secundária durante um desastre, como uma interrupção regional.

Considere o failover do aplicativo de funções junto com os comportamentos de failover de outros serviços que você usa, como:

Considere uma topologia de exemplo que usa um gatilho do Event Hubs, em que o namespace do Event Hubs está configurado para recuperação de desastres geográficos. Nesse caso, o padrão ativo-passivo requer os seguintes componentes:

  • Namespaces de Hubs de Eventos implantados em uma região primária e secundária.

  • Recuperação de desastre geográfico habilitada para emparelhar os hubs de eventos primários e secundários. Essa configuração também cria um alias que você pode usar para se conectar ao namespace dos Hubs de Eventos e alternar o alias do primário para o secundário sem alterações nas informações de conexão.

  • Aplicativos de funções implantados na região primária e secundária. O aplicativo na região secundária permanece ocioso porque não recebe mensagens.

  • Os gatilhos de cada aplicativo de funções usam a direct (não-alias) string de conexão para seu respectivo namespace do Hub de Eventos.

  • Os editores do namespace dos Hubs de Eventos publicam no alias cadeia de conexão.

Diagrama que mostra um exemplo de arquitetura ativa-passiva. A recuperação de desastre geográfico dos Hubs de Eventos abrange várias regiões e aplicativos e bancos de dados de funções separados em cada região.

Antes do failover, os editores que enviam eventos para o alias compartilhado roteiam o tráfego para o hub de eventos primário. O aplicativo de funções primário escuta exclusivamente o hub de eventos primário. O aplicativo de funções secundário permanece passivo e ocioso.

Quando o failover é iniciado, os editores que enviam eventos para o alias compartilhado são roteados para o hub de eventos secundário. O aplicativo de funções secundário se torna ativo e é disparado automaticamente. O hub de eventos pode conduzir todo o processo de failover e cada aplicativo de funções é executado somente quando o hub de eventos correspondente está ativo.

Funções duráveis

Para recuperação de desastre em várias regiões para funções duráveis, consulte Disaster recovery and geo-distribution in Azure durable functions.

Resiliência à manutenção do serviço

As funções executam atualizações de serviço regulares e outras tarefas de manutenção.

  • Resiliência de falha transitória: Durante a manutenção do serviço, as instâncias que executam seu aplicativo de funções podem reiniciar ou sofrer interrupções temporárias. Verifique se os aplicativos cliente que interagem com seu aplicativo de funções são resilientes a falhas transitórias.
  • Habilitar redundância de zona: Ao habilitar a redundância de zona em seu plano, você também melhora a resiliência durante as atualizações da plataforma. Implantar várias instâncias em seu plano e habilitar a redundância de zonas para seu plano adicionará uma camada adicional de resiliência se uma instância ou uma zona se tornar não funcional durante um upgrade.

  • Instâncias temporárias extras: Para manter a capacidade esperada durante uma atualização, a plataforma adiciona automaticamente instâncias extras do plano durante o processo de atualização.

  • Habilitar redundância de zona: Ao habilitar a redundância de zona em seu plano, você também melhora a resiliência durante as atualizações da plataforma. Domínios de atualização consistem em coleções de VMs que ficam offline durante uma atualização e que são mapeados para zonas de disponibilidade. Implementar várias instâncias em seu plano e habilitar a redundância de zona para o plano acrescenta uma camada adicional de resiliência caso uma instância ou zona se torne problemática durante uma atualização.

  • Ambiente do Serviço de Aplicativo: Se você hospedar seu aplicativo de funções em um Ambiente do Serviço de Aplicativo, poderá personalizar o ciclo de atualização. Se você precisar validar o efeito das atualizações em sua carga de trabalho, habilite atualizações manuais. Use essa abordagem para validar e testar uma instância de não produção antes de aplicar as atualizações à instância de produção.

    Para mais informações sobre preferências de manutenção, consulte Preferências de atualização para manutenção planejada do Ambiente do Serviço de Aplicativo.

Resiliência às implantações de aplicativos

As implantações de aplicativos apresentam o risco de problemas em um ambiente de produção. Esteja pronto para reverter uma atualização se ela causar problemas. Controlar como as atualizações são distribuídas para reduzir a interrupção das reinicializações do aplicativo.

Os planos de consumo flex dão suporte a estratégias de atualização de site, que fornecem várias maneiras de implantar as atualizações do aplicativo. Essas estratégias incluem atualizações sem interrupção para implantações de tempo de inatividade zero.

Os slots de implantação de funções permitem implantações contínuas de seus aplicativos de funções, sem tempo de inatividade. Use slots de implantação para minimizar o efeito de implantações e alterações de configuração para seus usuários. Os slots de implantação também reduzem a probabilidade de seu aplicativo ser reiniciado. As reinicializações de aplicativo causam falhas transitórias.

Contrato de nível de serviço

O SLA (contrato de nível de serviço) para serviços de Azure descreve a disponibilidade esperada de cada serviço e as condições que sua solução deve atender para atingir essa expectativa de disponibilidade. Para obter mais informações, consulte SLAs para serviços online.

O Functions fornece SLAs de disponibilidade distintos para o plano de consumo e para outros tipos de plano.

Conteúdo relacionado

  • Last updated on