Qualquer coisa que possa dar errado, vai dar errado.

Parte 1: Introdução (esta)
Parte 2: Engenharia Tradicional — Padrões de Arquitetura
Parte 3: Engenharia Tradicional — Padrões de Programação

Ao criar qualquer tipo de serviço, muitas coisas podem dar errado durante sua vida útil, desde bugs típicos do desenvolvedor até eventos de cisne negro, como um datacenter ficando offline.

Ao observar a complexidade do sistema e os erros que ela acarreta, no gráfico a seguir, temos de um lado a probabilidade de falha e do outro a classificação, que é definida na ordem do mais provável ao menos provável.

Indo da esquerda para a direita, temos os erros mais prováveis , que são coisas como 1 erros, bugs genéricos do desenvolvedor, erros transitórios, falta de recursos etc. isso de novo” ou “ligue para essa pessoa para consertar”.

E por último o Desconhecido que são as coisas que não esperamos e as coisas que surgem do nada.

As 3 categorias acima podem ser divididas nas seguintes (lista não exaustiva) “correções”.

1. Engenharia Tradicional

• Padrões arquitetônicos
• Padrões de programação
• Padrões de codificação
• teste

• Métricas, Logs e Alertas
• Sinalização de recurso
• Teste canário
• Documentação
• Rotação de plantão
• Autocura
• post-mortem

• Engenharia do Caos
• Tempo de atividade reverso

Degradação graciosa

Correr em um estado degradado quase sempre será melhor do que não correr.

Grande parte da literatura e do pensamento sobre resiliência gira em torno da degradação graciosa.

Colheita ( whitepaper aqui )

A colheita é função Data available / Total dataou, em outras palavras, a veracidade de uma determinada consulta.

Digamos que temos um mecanismo de pesquisa que consiste em 100 partições de dados.

Se 1 partição cair, teremos uma colheita de 99%, o que na maioria dos casos será mais do que bom.

A execução em um estado degradado está intimamente relacionada ao padrão Fallback ou caminhos alternativos, como também pode ser chamado.

Ao empregar caminhos alternativos inteligentes para dependências com falha e garantir que seu serviço não fique inoperante diante de um erro, você ainda pode atender consultas a seus usuários/dependentes upstream.

Em suma, o usuário prefere ter uma experiência do que nenhuma experiência.

Resiliência de serviço com estado x sem estado

O que é estado?

Considere uma aplicação de contagem simples;

Ou ele poderia manter a contagem atual na memória, isso seria considerado um aplicativo com estado.

Ou

Poderia manter a contagem atual em um banco de dados, isso seria um aplicativo sem estado.

No entanto, isso não significa que, se o seu serviço salvar coisas em um banco de dados, ele não terá estado.

Você pode ter um aplicativo que faz cálculos de várias etapas de execução longa, isso seria considerado um aplicativo com estado, pois o estado está sendo gerenciado pelo aplicativo.

Considerando a resiliência de um aplicativo como esse, o pior que pode acontecer é o serviço ser encerrado sem aviso no meio de uma etapa.

Acompanhar as etapas de cálculo ou os cálculos intermediários e persistir nesse estado pode ser uma maneira de lidar com esse cenário.

Pergunta a considerar ao arquitetar e desenvolver aplicativos altamente confiáveis

• Quais metas e métricas de confiabilidade você definiu para seu aplicativo?
• Como você garantiu que a arquitetura de seu aplicativo seja resiliente a falhas?
• Como você garantiu que a capacidade e os serviços necessários estão disponíveis nas regiões-alvo?
• Como você está lidando com a recuperação de desastres para esta carga de trabalho?
• Quais decisões foram tomadas para garantir que a plataforma do aplicativo atenda aos seus requisitos de confiabilidade?
• Quais decisões foram tomadas para garantir que a plataforma de dados atenda aos seus requisitos de confiabilidade?
• Como a lógica do seu aplicativo lida com exceções e erros?
• Quais decisões foram tomadas para garantir que a rede e a conectividade atendam aos seus requisitos de confiabilidade?
• Quais concessões de confiabilidade para escalabilidade e desempenho você fez?
• Que concessões de confiabilidade para segurança você fez?
• Como você testa o aplicativo para garantir que ele seja tolerante a falhas?
• Como você monitora e mede a integridade do aplicativo?