Cenário de dois noves (99%)

Essas cargas de trabalho são úteis para a empresa, mas isso só é um inconveniente se elas estiverem indisponíveis. Esse tipo de carga de trabalho pode ser ferramentas internas, gerenciamento de conhecimento interno ou rastreamento de projetos. Ou podem ser cargas de trabalho reais voltadas ao cliente, mas servidas de um serviço experimental, com um recurso de alternância que pode ocultar o serviço, se necessário.

Essas cargas de trabalho podem ser implantadas em uma Região e em uma zona de disponibilidade.

Monitorar recursos

Teremos monitoramento simples, indicando se a página inicial do serviço está retornando um status HTTP 200 OK. Quando ocorrem problemas, nosso playbook indica que o registro da instância pode ser usado para estabelecer a causa raiz.

Adaptar-se às mudanças de demanda

Teremos manuais para falhas de hardware comuns, atualizações de software urgentes e outras alterações que causam interrupção.

Implementar alterações

Usaremos o AWS CloudFormation para definir nossa infraestrutura como código e especificamente para acelerar a reconstrução em caso de falha.

As atualizações de software são realizadas manualmente usando um runbook, sendo necessário tempo de inatividade para a instalação e o reinício do serviço. No caso de um problema durante a implantação, o runbook descreve como reverter para a versão anterior.

Todas as correções do erro são feitas usando a análise de logs pelas equipes de operações e desenvolvimento, e a correção é implantada depois que a correção é priorizada e concluída.

Fazer o backup de dados

Usaremos uma solução de backup especialmente criada para enviar dados de backup criptografados para o Amazon S3 usando um runbook. Testaremos se os backups funcionam restaurando os dados e garantindo a disponibilidade de usá-los regularmente empregando um runbook. Configuramos o controle de versões de nossos objetos do Amazon S3 e removemos permissões de exclusão de backups. Usamos uma política de ciclo de vida de bucket do Amazon S3 para arquivar ou excluir em caráter permanente conforme nossos requisitos.

Arquitetar para resiliência

As cargas de trabalho são implantadas com uma região e uma zona de disponibilidade. Implantamos o aplicativo, incluindo o banco de dados, em uma única instância.

Testar a resiliência

O pipeline de implantação do novo software é programado, com algum teste de unidade, mas principalmente teste de caixa branca/caixa preta da carga de trabalho montada.

Planejar para a recuperação de desastres (DR)

Durante falhas, aguardamos a falha terminar, opcionalmente roteando as solicitações a um site estático usando modificação de DNS por meio de um runbook. O tempo de recuperação para isso será determinado pela velocidade em que a infraestrutura pode ser implantada e o banco de dados restaurado para o backup mais recente. Essa implantação pode ser na mesma zona de disponibilidade ou em uma zona de disponibilidade diferente no caso de uma falha da zona de disponibilidade usando um runbook.

Meta de design de disponibilidade

Levamos 30 minutos para entender e decidir executar a recuperação, implantamos toda a pilha no AWS CloudFormation em 10 minutos. Vamos supor que implantamos em uma nova zona de disponibilidade e o banco de dados pode ser restaurado em 30 minutos. Isso implica cerca de 70 minutos para a recuperação de uma falha. Supondo uma falha por trimestre, nosso tempo de impacto estimado para o ano é de 280 minutos, ou quatro horas e 40 minutos.

Isso significa que o limite superior de disponibilidade é de 99,9%. A disponibilidade geral depende também da taxa real de falha, da duração da falha e da rapidez com que cada falha se recupera realmente. Para essa arquitetura, precisamos que o aplicativo fique offline para atualizações (estimando 24 horas por ano: quatro horas por alteração, seis vezes por ano) mais eventos reais. Assim, consultando a tabela sobre disponibilidade de aplicativo anterior no whitepaper, vemos que nossa meta de design de disponibilidade é 99%.

Resumo

Tópico	Implementação
Monitorar recursos	Somente verificação de integridade do site; sem alertas.
Adaptar-se às mudanças de demanda	Escalabilidade vertical por meio de nova implantação.
Implementar alterações	Runbook para implantar e reverter.
Fazer o backup de dados	Runbook para backup e restauração.
Arquitetar para resiliência	Recompilação completa, restaurar de um backup.
Testar a resiliência	Recompilação completa, restaurar de um backup.
Planejar para a recuperação de desastres (DR)	Backups criptografados são restaurados para uma zona de disponibilidade diferente, se necessário.