Partilhar via


Recomendações para definir alvos de fiabilidade

Aplica-se a esta recomendação da lista de verificação de Fiabilidade do Power Platform Well-Architected:

RE:04 Defina metas de fiabilidade e recuperação para os componentes, os fluxos e a solução geral. Visualize as metas para negociar, obter consenso, definir expetativas 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 como são os estados em bom estado de funcionamento, os estados degradados e os estados em mau estado de funcionamento.

Este guia descreve as recomendações para definir as métricas de disponibilidade e de alvo de recuperação para cargas de trabalho críticas. Os alvos de fiabilidade são obtidos através de exercícios de workshop com os intervenientes da empresa.

Os objectivos são melhorados através da monitorização e de testes. Trabalhe com os intervenientes internos para estabelecer expetativas realistas de fiabilidade. Este exercício também ajudará os intervenientes a apoiar as suas escolhas de estrutura arquitetónica e a compreender que está estruturar para uma melhor correspondência com os alvos acordados.

O Microsoft Power Platform lida com a maioria das preocupações de disponibilidade e fiabilidade ao nível da infraestrutura em seu lugar. No entanto, a disponibilidade das cargas de trabalho que criar é uma responsabilidade partilhada. É importante entender que, mesmo com o compromisso da Microsoft com a elevada disponibilidade, o risco de tempo de inatividade do sistema nunca é zero.

Considere utilizar as métricas seguintes para quantificar os requisitos de negócio.

Termo Definição
Objetivo de nível do serviço (SLO) Um alvo percentual que representa o estado de funcionamento do componente e do escalão de fiabilidade. Quanto mais alto for escalão, mais fiável é o componente. O SLO composto representa o alvo agregado de toda a carga de trabalho e contabiliza os SLOs dos componentes.
Indicador de nível de serviço (SLI) Uma métrica emitida por um serviço. As métricas de SLI são agregadas para quantificar um valor de SLO.
Contrato de nível de serviço (SLA) Um acordo 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 prestador de serviços.
Tempo médio de recuperação (MTTR) O tempo necessário para restaurar um componente após uma falha ser detetada.
Tempo médio entre falhas (MTBF) A duração de execução da função esperada pela carga de trabalho 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 estar 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 alvo da carga de trabalho para estas métricas no contexto dos fluxos de utilizador e do sistema. Identifique e classifique estes fluxos de acordo com a sua importância para os seus requisitos. Utilize os valores para orientar a estruturação da sua carga de trabalho em termos de operações de arquitetura, revisão, teste e gestão de incidentes. O não cumprimento dos alvos afetará o negócio além do nível de tolerância.

Principais estratégias de design

As discussões técnicas não devem orientar a forma como define alvos de fiabilidade para os seus fluxos críticos. Em vez disso, os intervenientes da empresa devem concentrar-se nos seus requisitos e nas expetativas dos utilizadores finais da carga de trabalho. Os especialistas técnicos ajudam os intervenientes a atribuir valores numéricos realistas que cumpram estes requisitos. Através do intercâmbio de informações, os peritos técnicos permitem a discussão e o acordo sobre os SLOs viáveis.

Considere um exemplo de como mapear requisitos para valores numéricos mensuráveis. Os intervenientes estimam que, para um fluxo crítico de utilizadores, uma hora de inatividade durante o horário de expediente normal resulta numa perda de X dólares na receita mensal. Este valor em dólares é comparado com o custo estimado de estruturar um fluxo que tenha um SLO de disponibilidade de 99,95% em vez de 99,9%. Os decisores devem discutir se o risco dessa perda de receitas compensa os custos adicionais e os encargos de gestão necessários para se protegerem contra a mesma.

Siga este padrão enquanto examina fluxos e cria uma lista completa de alvos.

Lembre-se de que os alvos de fiabilidade diferem dos alvos de desempenho. Os alvos de fiabilidade concentram-se na disponibilidade e na recuperação. Para definir alvos 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 ao mais alto nível e as métricas correlacionadas podem incluir, por exemplo, uma disponibilidade de aplicações de 99,9% para todas as regiões ou um RTO pretendido de 5 horas para a região das Américas. A definição destes tipos de alvps ajuda-o a identificar quais os fluxos críticos envolvidos nesses alvos. Em seguida, pode considerar alvos ao nível do componente.

Métricas de disponibilidade

Os alvos de disponibilidade correspondem às métricas de SLO, SLA e SLI.

SLOs e SLAs

As métricas de disponibilidade estão correlacionadas com os SLOs, que utiliza para definir os 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 pode atingir o alvo de SLO, reveja os SLAs da Microsoft para cada componente.

Para estabelecer os seus SLOs, pense em:

  • Requisitos não funcionais da sua carga de trabalho (por exemplo, taxas de pedidos de pico, utilizadores simultâneos) nos próximos 1-2 anos.

  • Métricas disponíveis sobre aquilo que pode medir, ao longo de um período de tempo específico. Estes dados informarão que SLIs deve especificar.

Depois de reunir os SLAs para os componentes individuais da carga de trabalho, calcule um SLA composto. O SLA composto deverá corresponder ao SLO alvo da carga de trabalho. O cálculo de um SLA composto envolve vários fatores, dependendo da estruturação da arquitetura.

A definição de SLOs adequados requer tempo e consideração cuidadosa. Os intervenientes da empresa devem compreender a tolerância à fiabilidade. Estas informações devem servir de base aos alvos.

Valores do SLA

A tabela seguinte define os valores comuns do SLA.

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 de fluxos de utilizador e de sistema, lembre-se de que fluxos de utilizador e de sistema diferentes têm definições de criticidade diferentes. Considere estas diferenças quando criar os seus SLAs compostos. Os fluxos não críticos podem ter componentes que deverá omitir dos seus cálculos, uma vez que não afetam a experiência do cliente se não estiverem brevemente disponíveis.

SLIs

Pense nos SLIs como as métricas ao nível do componente que contribuem para um SLO. Os SLIs mais significativos são aqueles que afetam os seus fluxos críticos na 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 a recolha de métricas inúteis, limite o número de SLIs para cada fluxo. Se possível, aponte para três SLIs por fluxo.

Métricas de recuperação

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

As definições para alvos de recuperação realistas dependem da sua análise do modo de falha e dos seus planos e testes para continuidade de negócios e recuperação após desastre. Antes de concluir este trabalho, discuta os alvos aspiracionais com os intervenientes e certifique-se de que a sua estrutura arquitetónica suporta os alvos de recuperação da melhor forma possível. Comunique claramente aos intervenientes que quaisquer partes da carga de trabalho que não sejam completamente testadas para métricas de recuperação não devem ter SLAs garantidos. Certifique-se de que os intervenientes entendem que os alvps 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 adota novas tecnologias para melhorar a experiência do utilizador. Estas alterações podem aumentar ou diminuir as suas métricas de recuperação.

Nota

O MTBF pode ser difícil de definir e garantir. As plataformas como serviço (PaaS) ou o 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. Se definir alvos para esta métrica, cobre apenas os componentes que estão sob o seu controlo.

Criar um modelo de bom estado de funcionamento

Utilize os dados recolhidos para os seus alvos de fiabilidade para criar o seu modelo de estado de funcionamento para cada carga de trabalho e os fluxos críticos associados. Um modelo de integridade define os estados bom estado de funcionamento, degradado e mau estado de funcionamento* para os fluxos e as cargas de trabalho. Os estados garantem a priorização operacional adequada. Este modelo também é conhecido como um modelo de semáforo. O modelo atribui verde a bom estado de funcionamento, amarelo a 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 mau estado de funcionamento.

A forma como define os estados bom estado de funcionamento, degradado e mau estado de funcionamento depende dos seus alvos de fiabilidade. Eis alguns exemplos de formas de definir os estados:

  • Um estado verde ou bom estado de funcionamento indica que os principais requisitos e alvos não funcionais estão totalmente satisfeitos e que os recursos são utilizados de forma otimizada.

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

  • Um estado vermelho ou mau estado de funcionamento indica que a degradação persistiu mais tempo do que o permitido pelos seus alvos 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ão transitórias. Deve distinguir claramente entre falhas transitórias esperadas, mas recuperáveis, e um verdadeiro estado de desastre.

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

Para obter orientações detalhadas sobre configurações de monitorização e alerta, consulte o guia de monitorização de estado de funcionamento.

Visualização

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

Facilitação do Power Platform

Os SLAs do Power Platform fornecem os compromissos da Microsoft para o tempo de atividade e conectividade. Serviços diferentes têm SLAs diferentes e, por vezes, as SKUs de um serviço têm SLAs diferentes. Para mais informações, consulte Acordos de nível de serviço para serviços online.

O SLA do Power Platform inclui procedimentos para a obtenção de um crédito de serviço caso o SLA não seja cumprido, juntamente com definições de disponibilidade para cada serviço. Este aspeto do SLA funciona como uma política de imposição.

O Microsoft Business Applications fornece capacidades de Continuidade de Negócio e Recuperação após Desastre (BCDR) a todos os ambientes de tipo de produção nas aplicações SaaS do Dynamics 365 e do Power Platform. Saiba como a Microsoft garante que os seus dados de produção são resilientes durante indisponibilidades regionais.

Alinhamento organizacional

O Cloud Adoption Framework fornece orientações para recomendações para SLOs e SLIs relacionados com a monitorização em toda a organização.

Para obter mais informações, consulte SLOs de monitorização da cloud.

Lista de verificação de fiabilidade

Consulte o conjunto completo de recomendações.