Publicado a

Desenhar para falhar

Tudo falha mais cedo ou mais tarde. Uma arquitetura madura decide de antemão quanto tempo pode estar em baixo e quantos dados pode perder, desenha-se para o cumprir e testa-o antes de precisar.

Linha de serviço Arquitetura Cloud

A pergunta não é se falha

Discos, regiões, fornecedores, implementações, pessoas: tudo falha em algum momento. Uma arquitetura não se mede por falhar ou não, mas por quanto dano faz quando falha e quanto tempo demora a voltar.

Isso não se improvisa durante o incidente. Decide-se antes, desenha-se e testa-se.

Dois números que decidem tudo

Linha do tempo de um incidenteIncidente ilustrativo: o objetivo de perda de dados cumpre-se e o de tempo de recuperação não.ARQUITETURA · RECUPERAÇÃOO que se acordou e o que aconteceuÚltima cópia válida9:45Falha10:00Deteção10:12Decisão10:20Restaurado10:52Serviço normal11:05RPO real 15 minRTO real 65 minPerda de dadosAcordado: 15 min · Real: 15 minCumpre o objetivo.Tempo em baixoAcordado: 60 min · Real: 65 minNão cumpre: o desenho é revisto.Detetado aos 12 minutos: metade do excesso esteve na deteção, não no restauro.Dados ilustrativos, não correspondem a nenhum caso realN100F · n100f.com

  • Objetivo de ponto de recuperação (RPO): quantos dados se podem perder, medidos em tempo. Se for de quinze minutos, é preciso copiar ou replicar pelo menos de quinze em quinze minutos.
  • Objetivo de tempo de recuperação (RTO): quanto tempo pode o serviço estar em baixo. Se for de uma hora, a recuperação completa (detetar, decidir, restaurar, verificar) tem de caber numa hora.

Cada valor tem um custo: quanto mais pequenos, mais redundância e mais gasto mensal. Por isso, acordam-se com o negócio e escrevem-se, como os restantes requisitos de qualidade.

Do número ao desenho

Objetivo Desenho habitual
Horas em baixo e um dia de dados aceitáveis Cópias diárias e restauro manual documentado
Uma hora em baixo, minutos de dados Cópias frequentes, réplicas e recuperação automatizada na mesma região
Minutos em baixo, sem perda prática Réplicas síncronas e implementação em várias zonas ou regiões, com comutação automática

O que não está testado não existe

Uma cópia de segurança que nunca foi restaurada é uma suposição. Um plano de recuperação que nunca foi executado é um documento. A recuperação testa-se:

  1. Restaurando de verdade, de forma periódica, num ambiente separado, e medindo quanto demora.
  2. Simulando falhas controladas (uma instância, uma zona, uma dependência) para verificar que o sistema reage como foi desenhado.
  3. Ensaiando o procedimento com as pessoas que o vão executar, não só com quem o escreveu.

Cada teste deixa um resultado escrito: tempo real de recuperação, dados perdidos e o que foi preciso corrigir. Se o tempo real ultrapassar o objetivo, o desenho não cumpre o seu requisito, mesmo que nunca tenha falhado.


Como o aplicamos: Arquitetura Cloud.

Se o seu custo cloud cresce sem que ninguém saiba porquê, ou a sua arquitetura depende de quem a montou, falemos.

Falemos