planejamento (e recuperação) de desastres por rodrigo campos
Post on 28-Jun-2015
274 Views
Preview:
TRANSCRIPT
$ 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!
“Lasciate ogni speranza, voi ch'entrate"
Dante Alighieri no vestíbulo do inferno
Sh*t happens
Na noite de 27 de Outubro de 2011 uma série de erros derrubou um cluster
inteiro de serviços na nuvem.
Todos os clientes foram afetados.
Levamos 72 horas para recuperar os serviços.
Alguns clientes perderam seus dados para sempre…
Um sumário
• Equipamento High-end
• Totalmente redundante
• Alta disponibilidade
• Todos os ovos em uma cesta muito cara
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…
Raio da Explosão
210
NetworkStorage
ServersVirtualization
Guest OSMiddleware
RuntimeData
Application
Raio da Explosão
210
NetworkStorage
ServersVirtualization
Guest OSMiddleware
RuntimeData
Application
Power Supply
Lições Aprendidas
Uptime != DisponívelComponente Downtime por ano
99% 3,65 dias
99,9% 8,76 horas
99,99% 52,56 minutos
99,999% 5,26 minutos
Tempo de ReparoPara 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.
• Impacto baixo, controlado • Geralmente documentado • Método e ferramentas para
correção conhecidos • Geralmente o time de operações
atua independentemente
Falhas
• 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
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
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?
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
A linha do tempo
Detecção Diagnóstico Recuperação Operação Degradada Recuperação Análise
Post-Mortem
Downtime
Horas Dias
Semanas ∞
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
High PriorityMedium Priority
Medium PriorityLow Priority
Valor de Negócio
Abra
ngên
cia
Quem decide se é um desastre?
High Priority
Medium Priority
Medium Priority
Low Priority
Valor de Negócio
Abra
ngên
cia
Quem decide se é um desastre?
Regra #1-Não entre em pânico
Temos um desastre
• 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
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
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
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
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
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
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
Um plano não testado é só um pedaço de papel
Testes no século XXI
• Em produção… sim, em produção
• Netflix Chaos Monkey
• Blazemeter
• SOASTA
Perguntas
top related