Redução do MTTD
Depois que uma falha é descoberta, o restante do tempo de MTTR é o reparo real ou a mitigação do impacto. Para reparar ou mitigar uma falha, você precisa saber o que está errado. Há dois grupos principais de métricas que fornecem informações durante essa fase: métricas de Avaliação de Impacto e 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 — Métricas críticas de MTTD e MTTR para obter mais informações sobre essas métricas.
Regra 9
A observabilidade e a instrumentação são fundamentais para reduzir o MTTD e o MTTR.
Rota para contornar falhas
A abordagem mais rápida para mitigar o impacto é por meio de subsistemas que evitam falhas. Essa abordagem usa redundância para reduzir o MTTR transferindo rapidamente o trabalho de um subsistema com falha para um sobressalente. A redundância pode variar de processos de software a instâncias do EC2, a várias AZs e a várias regiões.
Subsistemas de reposição podem reduzir o MTTR a 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 SLA definido, mantendo a disponibilidade do sistema. Isso produz MTTRs que são experimentados como atrasos leves, talvez até imperceptíveis, em vez de períodos prolongados de indisponibilidade.
Por exemplo, se seu serviço utiliza instâncias do EC2 por trás de um Application Load Balancer (ALB), você pode configurar verificações de integridade em um intervalo de até cinco segundos e exigir apenas duas verificações de integridade 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, o MTTR é efetivamente o mesmo que o 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 rápido 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
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 instâncias do EC2 por trás de um ALB, imagine que instâncias em uma AZ possam estar passando por verificações de integridade 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 do AWS
Workloads que podem adotar um modelo de consistência menos rigoroso podem obter MTTRs mais curtos usando a automação de failover multirregional para contornar falhas. Recursos como a replicação entre regiões do Amazon S3 ou as tabelas globais do Amazon DynamoDB
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 instância do EC2 ou pode ser uma AZ inteira em capacidade. A tentativa de provisionar novos recursos durante uma falha aumenta o MTTR e adiciona uma dependência a um ambiente de gerenciamento 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
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 o 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.
O CloudFormation oferece a capacidade de reverter automaticamente como parte de suas operações de criação e atualização de pilha, assim como o AWS CodeDeploy. O CodeDeploy também suporta implantações azul/verde e contínuas.
Para aproveitar esses recursos e minimizar seu MTTR, 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 com o 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).
| Mecanismo de recuperação de falhas | MTTR estimado |
|---|---|
| Iniciar e configurar o novo servidor virtual | 15 minutos |
| Reimplantar o software | 10 minutos |
| Reinicializar servidor | 5 minutos |
| Reiniciar ou iniciar o contêiner | 2 segundos |
| Invocar nova função sem servidor | 100 ms |
| Reiniciar processo | 10 ms |
| Reiniciar thread | 10 μs |
Analisando a tabela, há alguns benefícios claros do MTTR no uso de contêineres e funções sem servidor (como AWS Lambda
Como abordagem geral para a recuperação, você pode passar de baixo para cima: 1/Reiniciar, 2/Reiniciar, 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.
Regra 10
Concentre-se na mitigação do impacto, não na resolução de problemas. Escolha o caminho mais rápido de volta à operação normal.
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 o que está errado. 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 reduzir o MTTR.
Runbooks e automação
Da mesma forma, depois de determinar o que está errado 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.
