As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Reduzindo MTTR

Depois que uma falha é descoberta, o restante do MTTR tempo é o reparo real ou a mitigação do impacto. Para reparar ou mitigar uma falha, você precisa saber qual é o problema. Há dois grupos principais de métricas que fornecem informações durante essa fase: 1/ métricas de Avaliação de Impacto e 2/ métricas de Saúde Operacional. O primeiro grupo informa o escopo do impacto durante uma falha, medindo o número ou a porcentagem dos clientes, recursos ou workloads afetados. O segundo grupo ajuda a identificar por que há impacto. Depois que o motivo é descoberto, os operadores e a automação podem responder e resolver a falha. Consulte o Apêndice 1 — MTTD e as métricas MTTR críticas para obter mais informações sobre essas métricas.

Rota para contornar falhas

A abordagem mais rápida para mitigar o impacto é por meio de subsistemas de antecipar-se à falha. Essa abordagem usa redundância para reduzir, MTTR transferindo rapidamente o trabalho de um subsistema com falha para um sobressalente. A redundância pode variar de processos de software a EC2 instâncias, de várias a várias AZs regiões.

Subsistemas de reposição podem MTTR reduzir o valor para quase zero. O tempo de recuperação é apenas o necessário para redirecionar o trabalho para o sobressalente em espera. Isso geralmente acontece com latência mínima e permite que o trabalho seja concluído dentro do definidoSLA, mantendo a disponibilidade do sistema. MTTRsIsso produz atrasos leves, talvez até imperceptíveis, em vez de períodos prolongados de indisponibilidade.

Por exemplo, se seu serviço utiliza EC2 instâncias por trás de um Application Load Balancer ALB (), você pode configurar verificações de saúde em um intervalo de até cinco segundos e exigir apenas duas verificações de saúde com falha antes que um destino seja marcado como não íntegro. Isso significa que, em 10 segundos, você pode detectar uma falha e parar de enviar tráfego para o host não íntegro. Nesse caso, MTTR é efetivamente igual ao, MTTD pois assim que a falha é detectada, ela também é mitigada.

É isso que as workloads de alta disponibilidade ou disponibilidade contínua estão tentando alcançar. Queremos contornar rapidamente as falhas na workload detectando rapidamente os subsistemas com falha, marcando-os como falhados, parando de enviar tráfego para eles e, em vez disso, enviá-lo para um subsistema redundante.

Observe que o uso desse tipo de mecanismo para antecipar-se à falha torna sua workload muito sensível a erros transitórios. No exemplo fornecido, certifique-se de que as verificações de integridade do balanceador de carga estejam realizando verificações de integridade superficiais ou dinâmicas e locais apenas da instância, sem testar dependências ou fluxos de trabalho (geralmente chamados de verificações de integridade profundas). Isso ajudará a evitar a substituição desnecessária de instâncias durante erros transitórios que afetam a workload.

A observabilidade e a capacidade de detectar falhas em subsistemas são essenciais para que o roteamento em torno da falha seja bem-sucedido. Você precisa conhecer o escopo do impacto para que os recursos afetados possam ser marcados como insalubres ou com falha e retirados de serviço para que possam ser encaminhados. Por exemplo, se uma única AZ apresentar uma deficiência parcial no serviço, sua instrumentação precisará ser capaz de identificar que há um problema localizado na AZ para contornar todos os recursos dessa AZ até que ela se recupere.

Ser capaz de contornar falhas também pode exigir ferramentas adicionais, dependendo do ambiente. Usando o exemplo anterior com EC2 instâncias atrás de umaALB, imagine que instâncias em uma AZ possam estar passando por verificações de saúde locais, mas uma deficiência isolada de AZ esteja fazendo com que elas não consigam se conectar ao banco de dados em outra AZ. Nesse caso, as verificações de integridade do balanceamento de carga não tirarão essas instâncias de serviço. Seria necessário um mecanismo automatizado diferente para remover a AZ do balanceador de carga ou forçar as instâncias a falharem nas verificações de integridade, o que depende da identificação de que o escopo do impacto é uma AZ. Para workloads que não estão usando um balanceador de carga, seria necessário um método semelhante para impedir que recursos em uma AZ específica aceitassem unidades de trabalho ou removessem completamente a capacidade da AZ.

Em alguns casos, a mudança de trabalho para um subsistema redundante não pode ser automatizada, como o failover de um banco de dados primário para o secundário, em que a tecnologia não fornece sua própria eleição de líder. Esse é um cenário comum para arquiteturas multirregionais da AWS. Como esses tipos de failovers exigem algum tempo de inatividade para serem realizados, não podem ser revertidos imediatamente e deixam a workload sem redundância por um período de tempo, é importante ter uma pessoa no processo de tomada de decisão.

As cargas de trabalho que podem adotar um modelo de consistência menos rigoroso podem ser reduzidas MTTRs usando a automação de failover em várias regiões para contornar as falhas. Recursos como a replicação entre regiões do Amazon S3 ou as tabelas globais do Amazon DynamoDB fornecem recursos multirregionais por meio de replicação eventualmente consistente. Além disso, usar um modelo de consistência relaxado é benéfico quando consideramos o CAP teorema. Durante falhas de rede que afetam a conectividade com subsistemas com estado, se a workload escolher a disponibilidade em vez da consistência, ela ainda poderá fornecer respostas sem erros, outra forma de contornar a falha.

O roteamento em caso de falha pode ser implementado com duas estratégias diferentes. A primeira estratégia é implementar a estabilidade estática pré-provisionando recursos suficientes para lidar com a carga completa do subsistema com falha. Isso pode ser uma única EC2 instância ou uma capacidade total de AZ. A tentativa de provisionar novos recursos durante uma falha aumenta MTTR e adiciona uma dependência a um plano de controle em seu caminho de recuperação. No entanto, isso tem um custo adicional.

A segunda estratégia é rotear parte do tráfego do subsistema com falha para outros e eliminar a carga do excesso de tráfego que não pode ser tratado pela capacidade restante. Durante esse período de degradação, você pode ampliar novos recursos para substituir a capacidade com falha. Essa abordagem é mais longa MTTR e cria uma dependência de um plano de controle, mas custa menos em capacidade ociosa em espera.

Retorne a um bom estado conhecido

Outra abordagem comum para mitigação durante o reparo é retornar a workload a um estado anterior conhecido como bom. Se uma alteração recente pode ter causado a falha, reverter essa alteração é uma forma de retornar ao estado anterior.

Em outros casos, condições transitórias podem ter causado a falha; nesse caso, reiniciar a workload pode mitigar o impacto. Vamos examinar esses dois cenários.

Durante uma implantação, minimizar o MTTD e MTTR depende da observabilidade e da automação. Seu processo de implantação deve observar continuamente a workload para detectar a introdução de maiores taxas de erro, maior latência ou anomalias. Depois que eles forem reconhecidos, o processo de implantação deverá ser interrompido.

Existem várias estratégias de implantação, como implantações no local, implantações azul/verdes e implantações contínuas. Cada um deles pode usar um mecanismo diferente para retornar a um estado em boas condições. Ele pode voltar automaticamente para o estado anterior, mudar o tráfego de volta para o ambiente azul ou exigir intervenção manual.

CloudFormation oferece a capacidade de reverter automaticamente como parte de suas operações de criação e atualização da pilha, assim como acontece. AWS CodeDeploy CodeDeploy também suporta implantações em azul/verde e contínuas.

Para aproveitar esses recursos e minimizar seusMTTR, considere automatizar todas as suas implantações de infraestrutura e código por meio desses serviços. Em cenários em que você não pode usar esses serviços, considere implementar o padrão de saga AWS Step Functions para reverter implantações com falha.

Ao considerar a reinicialização, existem várias abordagens diferentes. Elas variam desde a reinicialização de um servidor, a tarefa mais longa, até a reinicialização de um thread, a tarefa mais curta. Aqui está uma tabela que descreve algumas das abordagens de reinicialização e os tempos aproximados de conclusão (representativos da diferença de ordens de magnitude, eles não são exatos).

Analisando a tabela, há alguns benefícios claros MTTR em usar contêineres e funções sem servidor (como). AWS Lambda MTTRÉ muito mais rápido do que reiniciar uma máquina virtual ou lançar uma nova. No entanto, usar o isolamento de falhas por meio da modularidade do software também é benéfico. Se você puder conter falhas em um único processo ou thread, a recuperação dessa falha é muito mais rápida do que reiniciar um contêiner ou servidor.

Como abordagem geral para a recuperação, você pode passar de baixo para cima: 1/Reiniciar, 2/reboot, 3/Reimagem/Reimplantar, 4/Substituir. No entanto, quando você chega à etapa de reinicialização, contornar a falha geralmente é uma abordagem mais rápida (geralmente levando no máximo de 3 a 4 minutos). Portanto, para mitigar o impacto mais rapidamente após uma tentativa de reinicialização, contorne a falha e, em segundo plano, continue o processo de recuperação para devolver a capacidade à sua workload.

Diagnóstico de falhas

Parte do processo de reparo após a detecção é o período de diagnóstico. Esse é o período em que os operadores tentam determinar qual é o problema. Esse processo pode envolver a consulta de registros, a revisão de métricas de saúde operacional ou o login em hosts para solucionar problemas. Todas essas ações exigem tempo, portanto, criar ferramentas e runbooks para agilizar essas ações também pode ajudar a MTTR reduzi-las.

Runbooks e automação

Da mesma forma, depois de determinar qual é o problema e qual curso de ação reparará a workload, os operadores normalmente precisam executar um conjunto de etapas para fazer isso. Por exemplo, após uma falha, a maneira mais rápida de reparar a workload pode ser reiniciá-la, o que pode envolver várias etapas ordenadas. A utilização de um runbook que automatize essas etapas ou forneça orientação específica a um operador agilizará o processo e ajudará a reduzir o risco de ações inadvertidas.