Recomendações para definir destinos de fiabilidade

Aplica-se a esta recomendação da lista de verificação de fiabilidade do Azure Well-Architected Framework:

RE:04

Defina destinos de fiabilidade e recuperação para os componentes, os fluxos e a solução geral. Visualize os objetivos para negociar, obter consenso, definir expectativas e impulsionar ações para alcançar o estado ideal. Utilize os destinos definidos para criar o modelo de estado de funcionamento. O modelo de estado de funcionamento define o aspeto dos estados em bom estado de funcionamento, degradados e em mau estado de funcionamento.

Este guia descreve as recomendações para definir métricas de destino de disponibilidade e recuperação para cargas de trabalho e fluxos críticos. Os destinos de fiabilidade são derivados de exercícios de workshop com intervenientes empresariais. Os destinos são refinados através da monitorização e do teste.

Com os intervenientes internos, defina expectativas realistas de fiabilidade da carga de trabalho para que os intervenientes possam comunicar essas expectativas aos clientes através de contratos contratuais. As expectativas realistas também ajudam os intervenientes a compreender e apoiar as suas decisões de design de arquitetura e a saber que está a conceber o ideal para cumprir os objetivos acordados.

Considere utilizar as seguintes métricas para quantificar os requisitos empresariais.

Termo	Definição
Objetivo de nível de serviço (SLO)	Um destino de percentagem que representa o estado de funcionamento do componente e o escalão de fiabilidade. Quanto maior for o escalão, mais fiável será o componente. O SLO composto representa o destino agregado de toda a carga de trabalho e contas para os SLOs do componente.
Indicador de nível de serviço (SLI)	Uma métrica emitida por um serviço. As métricas SLI são agregadas para quantificar um valor SLO.
Contrato de nível de serviço (SLA)	Um contrato contratual entre o fornecedor de serviços e o cliente do serviço. O contrato define os SLOs. O incumprimento do contrato pode ter consequências financeiras para o fornecedor de serviços.
Tempo médio de recuperação (MTTR)	O tempo necessário para restaurar um componente após a deteção de uma falha.
Tempo médio entre a falha (MTBF)	A duração para a qual a carga de trabalho pode executar a função esperada sem interrupção, até que falhe.
Objetivo de tempo de recuperação (RTO)	O tempo máximo aceitável durante o qual uma aplicação pode ficar indisponível após um incidente.
Objetivo de ponto de recuperação (RPO)	A duração máxima aceitável da perda de dados durante um incidente.

Defina os valores de destino da carga de trabalho para estas métricas no contexto dos fluxos de utilizador e dos fluxos de sistema. Identifique e classifique esses fluxos pelo quão críticos são para os seus requisitos. Utilize os valores para impulsionar a conceção da carga de trabalho em termos de arquitetura, revisão, teste e operações de gestão de incidentes. O não cumprimento dos objetivos afetará a empresa para além do nível de tolerância.

Principais estratégias de conceção

Os debates técnicos não devem impulsionar a forma como define os destinos de fiabilidade para os seus fluxos críticos. Em vez disso, os intervenientes empresariais devem concentrar-se nos clientes à medida que definem os requisitos de uma carga de trabalho. Os especialistas técnicos ajudam os intervenientes a atribuir valores numéricos realistas que estão correlacionados com esses requisitos. À medida que partilham conhecimentos, os peritos técnicos permitem negociação e consenso mútuo sobre SLOs realistas.

Considere um exemplo de como mapear requisitos para valores numéricos mensuráveis. Os intervenientes estimam que, para um fluxo de utilizador crítico, uma hora de tempo de inatividade durante o horário comercial normal resulta numa perda de X dólares em receitas mensais. Esse montante em dólares é comparado com o custo estimado da conceção de um fluxo que tem um SLO de disponibilidade de 99,95 por cento em vez de 99,9%. Os decisores têm de discutir se o risco dessa perda de receitas supera os custos acrescidos e os encargos de gestão necessários para a proteger contra ela. Siga este padrão à medida que examina os fluxos e cria uma lista completa de destinos.

Lembre-se de que os destinos de fiabilidade diferem dos destinos de desempenho. Os destinos de fiabilidade focam-se na disponibilidade e na recuperação. Para definir destinos de fiabilidade, comece por definir os requisitos mais amplos e, em seguida, defina métricas mais específicas para cumprir os requisitos de alto nível.

Os requisitos de fiabilidade e recuperação de nível mais elevado e as métricas correlacionadas podem incluir, por exemplo, uma disponibilidade de aplicação de 99,9% para todas as regiões ou um RTO de destino de 5 horas para a região américas. Definir estes tipos de destinos ajuda-o a identificar que fluxos críticos estão envolvidos nesses destinos. Em seguida, pode considerar os destinos ao nível do componente.

Desvantagem: pode existir uma lacuna conceptual entre as limitações técnicas dos componentes da carga de trabalho e o que isso significa para a empresa, por exemplo, débito em megabits por segundo versus transações por segundo. Criar um modelo entre estas duas vistas pode ser um desafio. Em vez de sobrecarregar a solução, tente abordá-la de uma forma económica, mas significativa.

Métricas de disponibilidade

SLOs e SLAs

As métricas de disponibilidade estão correlacionadas com os SLOs, que utiliza para definir SLAs. O SLO da carga de trabalho determina quanto tempo de inatividade é tolerável num determinado período, por exemplo, menos de 1 hora por mês. Para se certificar de que consegue cumprir o destino do SLO, reveja os SLAs da Microsoft para cada componente. Preste atenção à quantidade de redundância necessária para cumprir SLAs elevados. Por exemplo, a Microsoft garante SLAs mais elevados para implementações de várias regiões do Azure Cosmos DB do que as garantias para implementações de região única.

Nota

Os SLAs do Azure nem sempre abrangem todos os aspetos de um serviço. Por exemplo, Gateway de Aplicação do Azure tem um SLA de disponibilidade, mas a funcionalidade de Firewall de Aplicações Web do Azure não garante a passagem de tráfego malicioso. Considere esta limitação quando desenvolver os seus SLAs e SLOs.

Depois de recolher os SLAs para os componentes de carga de trabalho individuais, calcule um SLA composto. O SLA composto deve corresponder ao SLO de destino da carga de trabalho. Calcular um SLA composto envolve vários fatores, consoante a estrutura da arquitetura. Considere os seguintes exemplos.

Nota

Os valores de SLA nos exemplos seguintes são hipotéticos e destinam-se apenas a fins de demonstração.Não se destinam a representar os valores atuais suportados pela Microsoft.

Os SLAs compostos envolvem vários serviços que suportam uma aplicação, com diferentes níveis de disponibilidade. Por exemplo, considere uma aplicação Web Serviço de Aplicações do Azure que escreve na Base de Dados do SQL do Azure. Hipoteticamente, estes SLAs podem ser:

• Serviço de Aplicações aplicações Web = 99,95 por cento
• Base de Dados SQL = 99,99 por cento

Qual é o tempo de inatividade máximo que pode esperar para esta aplicação? Se um dos serviços falhar, toda a aplicação falha. A probabilidade de cada serviço falhar é independente, pelo que o SLA composto para esta aplicação é de 99,95% × 99,99 por cento = 99,94 por cento. Esse valor é inferior aos SLAs individuais. Esta conclusão não é surpreendente porque uma aplicação que depende de vários serviços tem mais pontos de falha potenciais.

Pode melhorar o SLA composto ao criar caminhos de contingência independentes. Por exemplo, se Base de Dados SQL estiver indisponível, coloque as transações numa fila para serem processadas mais tarde:

Neste design, a aplicação ainda está disponível mesmo que não consiga ligar à base de dados. No entanto, falha se a base de dados e a fila falharem ao mesmo tempo. A percentagem de tempo esperada para uma falha simultânea é de 0,0001 × 0,001, pelo que eis o SLA composto para este caminho combinado:

Base de dados ou fila = 1,0 } (0,0001 × 0,001) = 99,999999 por cento

O SLA composto total:

Aplicação Web e (base de dados ou fila) = 99,95% × 99,99999% = ~99,95 por cento

Esta abordagem representa desvantagens:

• A lógica da aplicação é mais complexa.
• Paga-se pela fila.
• Tem de considerar problemas de consistência de dados.

Para implementações de várias regiões, o SLA composto é calculado da seguinte forma:

• N é o SLA composto para a aplicação implementada numa região.

• R é o número de regiões onde a aplicação é implementada.

A probabilidade esperada de a aplicação falhar em todas as regiões ao mesmo tempo é ((1 ≤ N) ^ R). Por exemplo, se o hipotético SLA de região única for de 99,95 por cento:

• O SLA combinado para duas regiões = (1 ≤ (1 ≤ 0,9995) ^ 2) = 99,999975 por cento

• O SLA combinado para quatro regiões = (1 ≤ (1 ≤ 0,9995) ^ 4) = 99,9999999 por cento

A definição de SLOs adequados demora tempo e consideração cuidadosa. Os intervenientes empresariais devem compreender como os principais clientes utilizam a aplicação. Também devem compreender a tolerância à fiabilidade. Este feedback deve informar os destinos.

Valores de SLA

A tabela seguinte define valores de SLA comuns.

SLA	Período de indisponibilidade por semana	Período de indisponibilidade por mês	Período de indisponibilidade por ano
99%	1,68 horas	7,2 horas	3,65 dias
99,9%	10,1 minutos	43,2 minutos	8,76 horas
99,95%	5 minutos	21,6 minutos	4,38 horas
99,99%	1,01 minutos	4,32 minutos	52,56 minutos
99,999%	6 segundos	25,9 segundos	5,26 minutos

Quando pensar em SLAs compostos no contexto dos fluxos, lembre-se de que os diferentes fluxos têm definições de crítica diferentes. Considere estas diferenças ao criar os SLAs compostos. Os fluxos não críticos podem ter componentes que deve omitir dos seus cálculos porque não afetam a experiência do cliente se estiverem brevemente indisponíveis.

Nota

As cargas de trabalho voltadas para o cliente e as cargas de trabalho de utilização interna têm SLOs diferentes. Normalmente, as cargas de trabalho de utilização interna podem ter SLOs de disponibilidade muito menos restritivos do que as cargas de trabalho voltadas para o cliente.

SLIs

Pense nas SLIs como métricas ao nível do componente que contribuem para um SLO. Os SLIs mais significativos são os que afetam os seus fluxos críticos da perspetiva dos seus clientes. Para muitos fluxos, os SLIs incluem latência, débito, taxa de erro e disponibilidade. Um bom SLI ajuda-o a identificar quando um SLO está em risco de ser violado. Correlacione o SLI com clientes específicos sempre que possível.

Para evitar recolher métricas inúteis, limite o número de SLIs para cada fluxo. Aponte para três SLIs por fluxo, se possível.

Métricas de recuperação

Os destinos de recuperação correspondem às métricas RTO, RPO, MTTR e MTBF. Ao contrário dos destinos de disponibilidade, os destinos de recuperação para estas medições não dependem muito dos SLAs da Microsoft. A Microsoft publica as garantias RTO e RPO apenas para alguns produtos, como Base de Dados SQL.

As definições para destinos de recuperação realistas dependem da análise do modo de falha e dos seus planos e testes para continuidade empresarial e recuperação após desastre. Antes de concluir este trabalho, discuta os destinos aspiracionais com os intervenientes e certifique-se de que a sua estrutura de arquitetura suporta os objetivos de recuperação da melhor forma que entender. Comunique claramente aos intervenientes que quaisquer fluxos ou cargas de trabalho inteiras que não sejam completamente testadas para métricas de recuperação não devem ter SLAs garantidos. Certifique-se de que os intervenientes compreendem que os destinos de recuperação podem mudar ao longo do tempo à medida que as cargas de trabalho são atualizadas. A carga de trabalho pode tornar-se mais complexa à medida que os clientes são adicionados ou à medida que adota novas tecnologias para melhorar a experiência do cliente. Estas alterações podem aumentar ou diminuir as métricas de recuperação.

Nota

A MTBF pode ser um desafio para definir e garantir. As plataformas como um serviço (PaaS) ou software como serviço (SaaS) podem falhar e recuperar sem qualquer notificação do fornecedor de cloud e o processo pode ser completamente transparente para si ou para os seus clientes. Se definir destinos para esta métrica, cubra apenas os componentes que estão sob o seu controlo.

À medida que define os destinos de recuperação, defina limiares para iniciar uma recuperação. Por exemplo, se um nó Web estiver indisponível durante mais de 5 minutos, é adicionado automaticamente um novo nó ao conjunto. Defina limiares para todos os componentes, tendo em conta a recuperação de um componente específico, incluindo o efeito noutros componentes e dependências. Os limiares também devem ser responsáveis por falhas transitórias para garantir que não inicia ações de recuperação muito rapidamente. Documente e partilhe com os intervenientes os potenciais riscos das operações de recuperação, como perda de dados ou interrupções de sessão para os clientes.

Criar um modelo de estado de funcionamento

Utilize os dados recolhidos para os seus destinos de fiabilidade para criar o seu modelo de estado de funcionamento para cada carga de trabalho e fluxos críticos associados. Um modelo de estado de funcionamento define estados saudáveis, degradados e em mau estado de funcionamento para os fluxos e cargas de trabalho. Os estados garantem a atribuição de prioridades operacionais adequada. Este modelo também é conhecido como um modelo de semáforo. O modelo atribui verde para bom estado de funcionamento, amarelo para degradado e vermelho para mau estado de funcionamento. Um modelo de estado de funcionamento garante que sabe quando o estado de um fluxo muda de bom estado de funcionamento para degradado ou em mau estado de funcionamento.

A forma como define estados saudáveis, degradados e em mau estado de funcionamento depende dos seus objetivos de fiabilidade. Seguem-se alguns exemplos de formas de definir os estados:

• Um estado verde ou saudável indica que os principais requisitos e destinos não funcionais estão totalmente satisfeitos e que os recursos são utilizados de forma ideal. Por exemplo, 95% dos pedidos são processados em <=500 ms com a utilização de nó Azure Kubernetes Service (AKS) em X por cento.

• Um estado amarelo ou degradado indica que um ou mais componentes do fluxo estão a alertar para o limiar definido, mas o fluxo está operacional. Por exemplo, foi detetada limitação de armazenamento.

• Um estado vermelho ou em mau estado de funcionamento indica que a degradação persistiu mais tempo do que o permitido pelos seus destinos de fiabilidade ou que o fluxo ficou indisponível.

Nota

O modelo de estado de funcionamento não deve tratar todas as falhas da mesma forma. O modelo de estado de funcionamento deve distinguir entre falhas transitórias e nãotransientes . Deve distinguir claramente entre falhas transitórias, mas recuperáveis esperadas, e um verdadeiro estado de desastre.

Este modelo funciona através de uma estratégia de monitorização e alerta que é desenvolvida e operada com base nos princípios de melhoria contínua. À medida que as cargas de trabalho evoluem, os seus modelos de estado de funcionamento têm de evoluir com elas.

Para obter considerações de design detalhadas e recomendações para um modelo de estado de funcionamento de aplicações em camadas, veja a documentação de orientação de modelação de estado de funcionamento encontrada nas áreas de estrutura da carga de trabalho críticas para a missão. Para obter orientações detalhadas sobre configurações de monitorização e alertas, veja o guia de monitorização do estado de funcionamento.

Visualização

Para manter as equipas de operações e os intervenientes da carga de trabalho informados sobre o estado em tempo real e as tendências gerais do modelo de estado de funcionamento da carga de trabalho, considere criar dashboards na sua solução de monitorização. Discuta as soluções de visualização com os intervenientes para garantir que fornece as informações que valorizam e que é fácil de consumir. Também podem querer ver relatórios gerados semanalmente, mensalmente ou trimestralmente.

Facilitação do Azure

Os SLAs do Azure fornecem os compromissos da Microsoft para o tempo de atividade e a conectividade. Os diferentes serviços têm SLAs diferentes e, por vezes, os SKUs num serviço têm SLAs diferentes. Para obter mais informações, veja Contratos de nível de serviço para serviços online.

O SLA do Azure inclui procedimentos para obter um crédito de serviço se o SLA não for cumprido, juntamente com definições de disponibilidade para cada serviço. Esse aspeto do SLA atua como uma política de imposição.

Ligações relacionadas

• Well-Architected Framework orientações críticas para a modelação do estado de funcionamento: Modelação do estado de funcionamento e observabilidade de cargas de trabalho críticas para a missão no Azure

Lista de verificação de fiabilidade

Veja o conjunto completo de recomendações.

Lista de verificação de fiabilidade