O recovery time objective
- A)é o tempo médio para se corrigir, após a interrupção, o item de configuração afeto ao serviço de TI.
Errada: isso descreve o tempo para corrigir um item de configuração ou falha, não o prazo máximo para restaurar o serviço após a interrupção.
- B)é o tempo necessário para que os impactos adversos se tornem inaceitáveis e pode surgir como resultado do não fornecimento de um serviço.
Errada: essa ideia se aproxima de impacto adverso inaceitável ou continuidade de negócio, mas não define o tempo de recuperação do serviço.
- C)é o atraso máximo aceitável entre a interrupção do serviço e sua restauração.
Certa: o RTO é exatamente o atraso máximo aceitável entre a interrupção do serviço e sua restauração.
- D)deve ser igual para interrupções não programadas e de recuperação de desastres.
Errada: o RTO não precisa ser igual para interrupções não programadas e desastres; ele é definido conforme a criticidade e o plano de continuidade.
Gabarito: C
O Recovery Time Objective, ou RTO, é uma métrica de continuidade de negócios que indica quanto tempo você pode ficar com um serviço parado até ele voltar ao ar. Em português simples: é o prazo máximo aceitável entre a interrupção e a restauração do serviço. Se passar desse limite, o prejuízo pode deixar de ser tolerável para a operação. Na prática, o RTO ajuda a definir o desenho do plano de contingência, a prioridade de restauração e até o investimento em redundância e backups. Quanto menor o RTO, mais rápido o sistema precisa se recuperar, o que normalmente exige soluções mais robustas e, claro, mais caras. Por isso, a alternativa C está correta: ela descreve exatamente o atraso máximo aceitável entre a interrupção do serviço e sua restauração. A banca costuma cobrar isso junto com outras siglas da continuidade, como RPO, que trata da perda máxima aceitável de dados, e não do tempo de volta do serviço. Como referência doutrinária, essa definição é a consagrada em gestão de continuidade e recuperação de desastres, especialmente em materiais alinhados à ISO 22301 e às práticas de IT Service Continuity. Não há pegadinha jurídica aqui, é mais conceito de gestão mesmo, daqueles que adoram aparecer em prova para testar se você não confunde tempo de recuperação com tempo de perda de dados.