Backups e recuperação de desastres
Um sistema confiável sobrevive a falhas de hardware, exclusões acidentais e ataques. Para isso você precisa de cópias de segurança testadas (um backup que você não sabe restaurar não é um backup) e um plano de recuperação de desastres (disaster recovery). Mede-se com dois objetivos:
- RPO (Recovery Point Objective): quantos dados você pode se dar ao luxo de perder, expresso em tempo. Um RPO de 1 hora significa "no máximo perdemos a última hora", o que define de quanto em quanto tempo fazer cópias.
- RTO (Recovery Time Objective): quanto tempo você pode ficar fora do ar enquanto restaura o serviço.
SLA, SLO e error budget
- SLA (Service Level Agreement): o contrato com o cliente, com consequências (p. ex. reembolsos) se não for cumprido. É um compromisso externo.
- SLO (Service Level Objective): o objetivo interno que você define (p. ex. 99,9 % de disponibilidade). Costuma ser mais rigoroso que o SLA para ter margem.
- Error budget: o que "resta gastar" do SLO. Se o seu objetivo é 99,9 %, esses 0,1 % de falhas permitidas são o seu orçamento. Enquanto sobrar orçamento, você pode fazer deploy e arriscar; se acabar, congela mudanças e se concentra na estabilidade.
Resposta a incidentes e postmortems sem culpa
Quando algo quebra, você segue um processo de resposta a incidentes: detectar, declarar o incidente, mitigar, comunicar e resolver. Depois escreve-se um postmortem: o que aconteceu, impacto, causa raiz e ações para evitar que se repita.
O postmortem é sem culpa (blameless): analisam-se sistemas e processos, não se busca alguém para apontar. Só assim as pessoas contam o que de verdade aconteceu e a organização aprende.
Deploys seguros: blue-green, canary e rollback
Fazer deploy é um dos momentos de maior risco. Estratégias para reduzi-lo:
- Blue-green: você mantém dois ambientes idênticos. Um (blue) serve o tráfego enquanto você faz o deploy no outro (green); quando está pronto, você troca o tráfego de uma vez. Se falhar, você volta ao anterior na hora.
- Canary: você libera a versão nova para uma pequena porcentagem de usuários (os "canários"). Se as métricas se mantiverem saudáveis, você amplia aos poucos até 100 %; se piorarem, você para antes de afetar todos.
- Rollback: a capacidade de voltar rapidamente à versão anterior estável quando um deploy dá errado. Ter um rollback rápido e ensaiado é o que torna seguro fazer deploy com frequência.