Este documento fornece diretrizes sobre planejamento de desastres para sistemas de tecnologia da informação. Ele discute a importância de arquiteturas distribuídas e redundantes, os diferentes níveis de disponibilidade de componentes, e como um único ponto de falha pode comprometer todo o sistema. Também fornece recomendações sobre comunicação, escalonamento de equipes e análise pós-mortem durante incidentes.

1. Planejamento de Desastre!
CMG Brasil 2014
camposr@gmail.com!
@xinu

2. $ whoami
• Orgulhosamente crimpando cabos desde 1992
• Descobri o que era colisão de IP quando meu chefe acreditou
que o aniversário dele seria uma boa subnet em 1993
• Derrubei um portal web inteiro testando uma versão
experimental de Linux em S/390 em 1999
• Já vi equipamentos high end falhando espetacularmente
devido a bugs e erros operacionais
(1992,1993,1994,1995,1996,1997,1998,…,2014,…)
• Tem sido sofrido mas adoro o meu trabalho!

3. “Lasciate ogni speranza,
voi ch'entrate"
Dante Alighieri no vestíbulo do inferno

4. Sh*t happens

5. Na noite de 27 de Outubro de 2011
uma série de erros derrubou um cluster
inteiro de serviços na nuvem.

6. Todos os clientes foram afetados.

7. Levamos 72 horas para recuperar os
serviços.

8. Alguns clientes perderam seus dados
para sempre…

9. Um sumário
• Equipamento High-end
• Totalmente redundante
• Alta disponibilidade
• Todos os ovos em uma cesta muito cara

10. Um sumário
• O time de engenharia contrariou todas as
tendências em sistemas distribuídos e optou por
uma arquitetura centralizada para storage
• Todas as VMs seriam armazenadas na SAN, em
um único frame de Storage de última geração
• A disponibilidade seria garantida por componentes
totalmente redundantes do Storage
• Seria mais fácil de gerenciar…

11. Raio da Explosão
210
Network
Storage
Servers
Virtualization
Guest OS
Middleware
Runtime
Data
Application

12. Raio da Explosão
210
Network
Storage
Servers
Virtualization
Guest OS
Middleware
Runtime
Data
Application
Power Supply

13. Lições Aprendidas

14. Uptime != Disponível
Componente Downtime por ano
99% 3,65 dias
99,9% 8,76 horas
99,99% 52,56 minutos
99,999% 5,26 minutos

15. Tempo de Reparo
Para cada componente que falha no ambiente
o tempo de reparo de suas dependências
pode e irá exceder o SLA do componente.
!
eg.: se o fornecimento de energia tiver
99,9999% (31,5 segundos / ano) a
disponibilidade do ambiente será bem menos
do que isso.

16. • Impacto baixo, controlado
• Geralmente documentado
• Método e ferramentas para
correção conhecidos
• Geralmente o time de operações
atua independentemente
Falhas

17. • Alto impacto
• Caótico e inesperado
• Métodos e ferramentas
disponíveis podem não ser
suficientes
• É um problema de tecnologia e
de negócio
Desastres

18. Existem falhas e desastres
• Algumas empresas lidam com
as duas situações da mesma
forma
• Não faça isso…
• Não há como se planejar para
tudo

19. Até onde você precisa ir?
• Muitas vezes terá de fazer uma “escolha de Sofia”
• Seus sistemas de BI precisam de um plano de
recuperação de desastre?
• Seu CMS precisa de um plano de recuperação de
desastre?
• Todos precisam do mesmo nível de desempenho do seu
site principal?

20. Até onde você precisa ir?
• Warroom no Datacenter
• Telefones? Impressoras? Agendas (de papel)?
• Ativo-Ativo, Ativo-Passivo
• Impactos profundos na arquitetura de rede e storage

21. A linha do tempo
Detecção Diagnóstico Recuperação
Operação
Degradada
Recuperação
Análise
Post-Mortem
Downtime
Horas
Dias
Semanas
∞

22. Quem decide se é um desastre?
• Resposta rápida: ninguém.
• Você deve ter um processo documentado para
categorizar incidentes
• Se não houver tal procedimento você dependerá
de julgamento humano

23. High PriorityMedium Priority
Medium PriorityLow Priority
Valor de Negócio
Abrangência
Quem decide se é um desastre?

24. High
Priority
Medium Priority
Medium
Priority
Low Priority
Valor de Negócio
Abrangência
Quem decide se é um desastre?

25. Regra #1-Não entre em pânico
Temos um desastre

26. • Reação típica: LIGUE PARA TODOS AGORA!!
• Não faça isto…
• Comece a pensar em turnos
• Tenha uma política de comunicação definida
Temos um desastre

27. A linha do tempo
Detecção Diagnóstico Recuperação
Operação
Degradada
Recuperação
Análise
Post-Mortem
• Garanta retenção automatizada de logs
• Tenha um processo de registro de
mudança eficiente
• Sistemas de relacionamento de eventos
são essenciais

28. A linha do tempo
Detecção Diagnóstico Recuperação
Operação
Degradada
Recuperação
Análise
Post-Mortem
• Chame seus SMS
• Chame o fornecedor se for o caso
• Mantenha um staff operacional mínimo
• Comece a pensar em turnos
• Alimentação e condições de trabalho
• Hospedagem e transporte

29. A linha do tempo
Detecção Diagnóstico Recuperação
Operação
Degradada
Recuperação
Análise
Post-Mortem
• Estabeleça um ponto de contato
responsável por cada componente
• Estabeleça checkpoints e um período de
tempo entre eles
• Dentro do possível libere os especialistas
e tire tarefas operacionais deles
• Mantenha a área de negócio ciente

30. A linha do tempo
Detecção Diagnóstico Recuperação
Operação
Degradada
Recuperação
Análise
Post-Mortem
• Reforce e alinhe expectativas claras do
que está contemplado no seu plano
• Mantenha a rotina de checkpoints
• Revise a escala de plantões e
acionamentos

31. A linha do tempo
Detecção Diagnóstico Recuperação
Operação
Degradada
Recuperação
Análise
Post-Mortem
• Exercite a cautela ao notificar os clientes
internos e externos de que o serviço foi
recuperado
• Tenha uma rotina de check-up definida

32. A linha do tempo
Detecção Diagnóstico Recuperação
Operação
Degradada
Recuperação
Análise
Post-Mortem
• Defina um processo de post-mortem antes
do incidente
• O mesmo deve ser conciso e não pode ser
um “dossiê"
• Inicie o plano de retorno ao site principal

33. Um plano não testado é só
um pedaço de papel

34. Testes no século XXI
• Em produção… sim, em produção
• Netflix Chaos Monkey
• Blazemeter
• SOASTA

35. Perguntas