O que fazer durante uma interrupção de serviço Azure

Na Microsoft, trabalhamos arduamente para garantir que nossos serviços estejam sempre disponíveis para você quando você precisar deles. No entanto, ocorrem interrupções não planeadas do serviço. Este artigo explica o que acontece quando isso acontece.

A Microsoft fornece um Acordo de Nível de Serviço (SLA) para muitos dos seus serviços como compromisso de disponibilidade e conectividade. O SLA para serviços individuais do Azure pode ser encontrado em Contratos de Nível de Serviço do Azure.

Compreender o âmbito do incidente

Quando há um incidente, se compreenderes a dimensão desse incidente, podes determinar o melhor curso de ação.

Para compreender a dimensão de um incidente, siga estes passos:

1. Vá ao Azure Service Health, que oferece:

   • Informação sobre questões ou eventos que possam estar a afetar os seus serviços.

   • Alertas automáticos de atualização de incidentes, para que possa ser notificado automaticamente de quaisquer atualizações de estado do incidente. Quando a Microsoft compreende a dimensão de um incidente, atualizamos o estado do incidente. Pode configurar estas atualizações de estado para ir a um grupo de ações Azure Monitor, que pode enviar alertas para vários locais, como um endereço de email ou para o seu próprio sistema de gestão de incidentes.

2. Se tiver problemas de acesso ao portal Azure, vá ao estado Azure.

   Observação

   O estado do Azure só mostra problemas generalizados que cumprem certos critérios. Como a página de Estado do Azure não sabe que subscrições e inquilinos gere, não pode fornecer uma visão precisa de problemas menores que possam estar a afetar os seus serviços.

3. Se houver problemas com a página de estado, verifique publicações de @AzureSupport na plataforma social X.

Incidentes em zonas de disponibilidade e centros de dados

Muitos problemas estão limitados a uma única zona de disponibilidade. As zonas de disponibilidade representam centros de dados, ou grupos de centros de dados, que estão isolados de outras zonas de disponibilidade na mesma região. Quando uma zona de disponibilidade enfrenta um problema, o impacto que observa depende da forma como um serviço é implementado:

• Os serviços zonais que estejam fixados na zona de disponibilidade afetada podem ser afetados.
• É pouco provável que os serviços redundantes por zona sejam afetados. Não deves precisar de tomar qualquer ação de remediação para recursos redundantes em zonas.
• Os serviços regionais (não zonais) podem ser afetados porque podem utilizar a zona de disponibilidade afetada.

Para saber mais sobre o suporte a zonas de disponibilidade nos serviços Azure e as diferenças entre serviços zonais, redundantes de zona e regionais (não zonais), consulte Serviços Azure com suporte a zonas de disponibilidade.

Se houver alguma preocupação com recursos zonais ou regionais destacados na zona de disponibilidade afetada, considere iniciar os seus planos de continuidade do negócio e recuperação de desastres (BC/DR).

Zonas lógicas vs. de disponibilidade física

Cada subscrição Azure apresenta uma lista diferente de zonas de disponibilidade. As zonas lógicas usadas por cada subscritor podem corresponder a diferentes zonas físicas . Podes mapear entre as tuas zonas lógicas e as zonas físicas para confirmar quais os recursos que correm na zona de disponibilidade física afetada. Para mais informações, consulte zonas de disponibilidade física e lógica.

Incidentes regionais

Por vezes, os problemas afetam toda uma região. Problemas regionais podem acontecer quando uma região não tem zonas de disponibilidade. Quando ocorre um incidente regional, pode ser necessário considerar iniciar o seu plano de recuperação de desastres. O teu plano pode incluir fazer failover para outra região.

Priorizar a continuidade do negócio

Quando confrontado com um incidente, a prioridade máxima é manter as operações do seu negócio a funcionar. Demasiado foco em isolar ou corrigir a causa de um problema pode desviar a sua atenção da restauração das operações da sua solução e da manutenção da continuidade do negócio.

Os seguintes fatores apresentam situações em que não é necessariamente necessário fazer nada para preservar a continuidade do negócio:

• O impacto real do problema nos seus recursos de produção e nos seus utilizadores ou cargas de trabalho. Por exemplo, um problema que ocorra fora do horário comercial normal pode não exigir que faça nada imediatamente.

• A dimensão do incidente. Para problemas isolados a uma única zona de disponibilidade, talvez não precise de intervir se estiver a usar recursos com redundância entre zonas ou se os recursos que utiliza estiverem numa zona de disponibilidade física não afetada.

• O tempo estimado de resolução, se estiver disponível. A Microsoft esforça-se por fornecer prazos claros para a recuperação o mais rapidamente possível. Se os seus procedimentos de recuperação demorarem um período significativo de tempo a ser concluídos, considere se é esperado que o problema esteja resolvido quando terminarem.

• Os objetivos de nível de serviço (SLOs) estabelecidos com os utilizadores da carga de trabalho afetada, se os tiveres. Os SLOs estão lá para orientar a tomada de decisões neste tipo de situação. Por exemplo, em algumas situações pode mudar para operações manuais até que os seus serviços estejam saudáveis, e essa decisão pode refletir-se no seu SLO para o sistema. Para saber mais sobre SLOs e como os definir, consulte Recomendações para definir metas de fiabilidade no Azure Well-Architected Framework.

No entanto, se a continuidade do negócio exigir algum tipo de ação, e tiver um plano de recuperação de desastres implementado, o próximo passo é considerar se deve iniciar esse plano.

Considere o seu plano de recuperação de desastres

Um plano de recuperação de desastres explica o que espera fazer no caso de um incidente grave. Os planos de recuperação de desastres incluem normalmente ações como as seguintes:

• Para uma interrupção isolada dentro de uma zona de disponibilidade, amplie o recurso se possível.
• Para uma falha na zona de disponibilidade quando usar serviços zonais, implemente para outra zona de disponibilidade e faça o failover para outra zona de disponibilidade.
• No caso de uma falha na zona de disponibilidade ao utilizar serviços com redundância de zona, poderá não precisar de tomar nenhuma ação. Se detetar problemas de desempenho, considere escalar o seu recurso para que as instâncias nas zonas restantes possam processar o fluxo de tráfego que recebem.
• Para uma falha regional, implemente em outra região e realize o failover.

Importante

Não tome nenhuma ação sem pensar bem. Decisões precipitadas podem, por vezes, piorar as coisas. Se já desenvolveu um plano de recuperação de desastres que cobre o cenário, normalmente é melhor usá-lo em vez de criar um plano no momento.

O failover pode ser um processo complexo. Só deve desencadear um failover quando conseguir justificar os custos e riscos. Em algumas situações, pode resultar em perda de dados, como se as alterações recentes não fossem replicadas entre regiões antes de qualquer tempo de inatividade. Também pode experimentar indisponibilidade, especialmente se precisar de redirecionar o tráfego para uma implementação noutra região. Dependendo da forma como a sua solução está desenhada, pode ser necessário atualizar os registos DNS e esperar que se propaguem.

Failover iniciado pela Microsoft

Alguns serviços Azure fazem automaticamente failover para regiões alternativas durante incidentes. A Microsoft gere o processo de failover desses serviços. No entanto, o failover iniciado pela Microsoft é geralmente realizado como último recurso e após um tempo significativo dedicado a tentativas de recuperação. Em geral, a política da Microsoft é minimizar a perda de dados, mesmo que isso signifique um tempo de recuperação mais longo. Não deve depender exclusivamente do failover iniciado pela Microsoft para as suas próprias soluções, especialmente se precisar de minimizar o tempo de recuperação. Se puderes, usa o failover iniciado pelo cliente para serviços como o Azure Storage.

suporte do Azure

Se o incidente de serviço já estiver a ser comunicado no Azure Service Health, então toda a informação mais recente é fornecida lá, e não há necessidade de abrir um pedido de suporte.

No entanto, pode considerar abrir um caso de apoio quando:

• Está a ver problemas no Azure Service Health que não estão cobertos pela descrição do incidente.

• Precisa de ajuda da Microsoft como parte dos seus esforços de recuperação.

  Sugestão

  Se for afetado por uma interrupção do serviço, poderá abrir um pedido de suporte gratuito até 72 horas após a resolução do problema, para ajudar em quaisquer medidas que possa precisar de tomar para a recuperação.

Ao abrir um caso de apoio, explique claramente os recursos afetados e o impacto do problema. Especifique o ID da subscrição Azure e a região que está a ter problemas. Defina a gravidade do caso de suporte com base no impacto no seu negócio. Esteja ciente de que muitos clientes podem estar a contactar o suporte Azure de forma reativa durante uma interrupção do serviço Azure, fora destas condições descritas. Esta carga adicional nos recursos de suporte do Azure pode, infelizmente, atrasar a resposta das suas necessidades de suporte.

Após um incidente

1. Para compreender o que a Microsoft aprendeu com o incidente, leia a Revisão Pós-Incidente (PIR) no painel de histórico de saúde do Azure Service Health, ou através dos alertas de Service Health configurados pelo cliente. Incidentes diferentes podem resultar em diferentes tipos de PIRs. Os PIRs preliminares são normalmente publicados alguns dias após um incidente, e os PIRs mais abrangentes seguem-se algumas semanas depois.

2. Para incidentes graves listados na nossa página de estado público, junte-se a uma transmissão em direto do Azure Incident Retrospective para esclarecer quaisquer dúvidas, ou assista à gravação.

3. Se acha que pode ser elegível para um crédito SLA, crie um novo pedido de suporte com o tipo de problema "Pedido de Reembolso" – e inclua o ID de Rastreio do Incidente.

4. Considere o que pode aprender com o incidente para melhorar a sua própria resiliência e processos. Considere perguntas como:

   • Quão bem funcionou o seu plano de recuperação de desastres? Há alguma melhoria que possas fazer? Para mais informações, consulte as orientações do Azure Well-Architected Framework sobre estratégias de recuperação de desastres.

   • A sua resposta ao incidente foi adequada para a sua gravidade? Se não, há formas de estares melhor informado e tomar melhores decisões sobre o que fazer?

   • Existem guias de fiabilidade de serviços Azure para os serviços que utiliza? Guias de fiabilidade fornecem informações sobre quantos serviços Azure podem ser configurados para satisfazer os seus requisitos de resiliência.

   • Existe algum compromisso de design que possa fazer para melhorar a sua resiliência no futuro face a este tipo de problema? Para mais informações, consulte o pilar de fiabilidade do Azure Well-Architected Framework.

   • O SLO ou SLA oferecido aos vossos utilizadores ainda é adequado agora que experienciaram esta falha não planeada? Agora é um bom momento para rever os compromissos que está a assumir com a sua base de utilizadores para alinhar as expectativas com o que aprendeu com este incidente.

   • Deves configurar Azure Service Health para seres automaticamente notificado de quaisquer incidentes futuros?

5. Se tiver feedback sobre como podemos melhorar a nossa resposta a incidentes, por favor informe-nos através do seu representante Microsoft designado ou através do site de feedback Azure.