- Wagner Elias – Think Security First - http://wagnerelias.com -

Recovery Time Objective

Posted By Elias Wagner On 19 19America/Denver December, 2007 @ 7:24 am In BCP | 1 Comment

O termo RTO (Recovery Time Objective) é conhecido pela maioria dos profissionais que atuam direta ou indiretamente com Continuidade de Negócios.O RTO consiste no tempo em que determinado processo tem para que, uma solução de recuperação e/ou contingência seja executada/ativada antes que o processo venha causar impacto a organização.

Se já sabemos o que é o RTO, não existe dificuldade em identificar junto aos responsáveis pelo processo, qual o RTO de cada processo. Errado, boa parte dos RTOs identificados em trabalhos de Continuidade de Negócios não condizem com a realidade e acabam direcionando as organizações a tomar decisões precipitadas.

A primeira coisa que devemos nos ater é, o RTO é apenas o tempo que o processo tem disponível para ser suportado por uma solução alternativa que o mantenha a níveis satisfatórios sem causar impactos a organização. Neste tempo teremos apenas uma solução de contorno (Workaround), o que difere do tempo total que um processo pode ficar indisponível. O tempo total que um processo pode ficar indisponível é definido segundo a BS 25999-1 como MTPD (Maximum Tolerable Period of Disruption).

Então podemos identificar pelo diagrama abaixo que, eu preciso subtrair do tempo total que o processo pode ficar indisponível o RTO mais o tempo para reestabelecer a normalidade.
MTPD [1]

Se não bastasse o equívoco cometido quanto aos tempos de RTO/MTPD, muitos generalizam o tempo assumindo que o MTPD é o RTO, ainda temos um problema mais sério. A maioria dos RTOs mapeados em projetos é muito mais baixo do que deveria. Na prática são raras as exceções onde um processo tem RTO menor que 1, 2 hora. O que quero dizer com isto? A maioria dos profissionais valorizam muito os RTOs sem medir ou conhecer as consequências. Um processo que pode ter até 24 horas de RTO é mapeado com um 1 hora como se não houvesse problema nisto.

O grande problema quando mapeamos RTOs relativamente baixos é a solução de estratégia. Sabemos que os RTOs e critícidades dos processos da organização são mapeados na BIA (Business Impact Analysis), fase esta que antecede e serve como tomada de decisão para a próxima fase, seleção de estratégia.

Na fase de Seleção de Estratégia vamos planejar e identificar soluções para atender os tempos mapeados como objetivo (RTO) na BIA. O que acontece quando os RTOs são muito baixo? As soluções para atender estes tempos serão soluções de alta disponibilidade e consequentemente terão um custo muito mais alto que qualquer plano de resposta. Ao contrário do que muita gente pensa, Se sabemos que são raras as exceções de RTO entre 1 e 2 horas, consequentemente são raras as exceções onde você necessita de Alta Disponibilidade para atender as necessidades da organização.

Resumindo, Planos para Continuidade do Negócio estão longe de ser soluções de contingência e a maioria das organizações estão gastando mais do que deviam com soluções de Alta Disponibilidade e Contingência.

No próximo post vou falar sobre o RPO (Recovery Point Objective).


1 Comment (Open | Close)

1 Comment To "Recovery Time Objective"

#1 Pingback By Conceitos, RSS e RTO « João Rodolfo Weblog On 27 27America/Denver June, 2008 @ 2:48 am

[...] Significado de RTO é (Recovery Time Objective), não vou falar o mesmo, se alguém tiver dúvidas recomendo o excelente post do [...]

[2] [2]

Article printed from Wagner Elias – Think Security First: http://wagnerelias.com

URL to article: http://wagnerelias.com/2007/12/19/recovery-time-objective/

URLs in this post:

[1] Image: http://wagnerelias.com/wp-content/uploads/2007/12/rto-mtbd.PNG

[2] : #

Copyright © 2007 Wagner Elias - Think Security First | BCP, BIA, DRP, Security Assessment, Risk Assessment, Security Developer. All rights reserved.