O que é a gestão de continuidade de serviços de TI
"A gestão de continuidade de serviços de TI (ITSCM) é a prática ITIL que assegura que os serviços podem ser restaurados dentro dos prazos acordados após uma interrupção grave ou desastre."
A ITSCM foca-se em eventos de alto impacto e baixa probabilidade: desastres naturais, ciberataques em larga escala, falhas catastróficas de infraestrutura ou perda total de um centro de dados. Estes cenários são raros, mas o seu impacto pode ser irreversível para o negócio sem preparação adequada.
É importante distinguir a ITSCM da gestão de incidentes. A gestão de incidentes trata interrupções normais do dia a dia, com foco em restaurar o serviço rapidamente. A ITSCM trata cenários de desastre onde a infraestrutura normal está indisponível e é necessário activar planos de recuperação alternativos.
No ITIL 4, a ITSCM é uma prática de gestão de serviços. A sua relação com outras práticas é estreita, em particular com a gestão de disponibilidade, que trata da continuidade no dia a dia, e com o Service Level Management, que define os níveis de serviço a garantir mesmo em situações de crise.
A ITSCM é também uma componente central do Business Continuity Planning (BCP). O BCP abrange toda a organização - processos de negócio, recursos humanos, instalações - enquanto a ITSCM foca especificamente os serviços de TI que suportam esses processos.
| Prática | Âmbito | Tipo de eventos |
|---|---|---|
| Gestão de incidentes | Serviços individuais | Interrupções frequentes, baixo a médio impacto |
| Gestão de disponibilidade | Todos os serviços | Falhas recorrentes, foco em SLA |
| ITSCM | Serviços críticos | Desastres, alto impacto, baixa probabilidade |
| BCP | Toda a organização | Qualquer ameaça à continuidade do negócio |
Conceitos-chave
Para implementar uma estratégia de continuidade eficaz, é necessário compreender os conceitos fundamentais que definem os objectivos e limites de recuperação.
Tempo máximo aceitável para restaurar um serviço após uma interrupção. Quanto menor o RTO, maior o investimento necessário em infraestrutura de recuperação. Um RTO de 4 horas exige soluções diferentes de um RTO de 15 minutos.
Quantidade máxima de dados que a organização aceita perder. Define a frequência dos backups: um RPO de 1 hora significa que os backups devem ser feitos de hora a hora. O RPO zero exige replicação em tempo real.
Análise que identifica os serviços críticos para o negócio e quantifica o impacto da sua indisponibilidade ao longo do tempo. O BIA é a base para definir o RTO e RPO de cada serviço e priorizar os investimentos em continuidade.
Período máximo que uma interrupção pode durar antes de causar danos irreversíveis ao negócio. O MTPD define o prazo absoluto de recuperação - o RTO deve ser inferior ao MTPD.
Documento que descreve os procedimentos detalhados para restaurar os serviços após um desastre. Inclui contactos de emergência, sequência de acções, papéis e responsabilidades, e instruções de acesso ao site de recuperação.
O RTO deve ser sempre inferior ao MTPD. Se o MTPD de um sistema de pagamentos é 8 horas (após as quais os danos são irreversíveis), o RTO deve ser definido, por exemplo, em 4 horas, deixando margem para atrasos imprevistos durante a recuperação.
O processo de ITSCM
A implementação da ITSCM segue um ciclo de vida estruturado em cinco fases. Cada fase constrói sobre a anterior e o processo é iterativo - os planos devem ser revistos e melhorados continuamente.
Análise de impacto no negócio (BIA)
Identificar os serviços críticos para o negócio. Determinar o impacto financeiro, operacional e reputacional da sua indisponibilidade ao longo do tempo. Definir o RTO e RPO para cada serviço com base nesses dados.
Avaliação de riscos
Identificar as ameaças relevantes: desastres naturais (inundações, incêndios), ciberataques (ransomware, DDoS), falhas de infraestrutura (energia, telecomunicações) e erros humanos. Avaliar a probabilidade e o impacto de cada ameaça.
Definir estratégia de continuidade
Escolher as abordagens de recuperação para cada serviço crítico. As opções incluem cold site, warm site, hot site, cloud DR e replicação activa-activa. A escolha depende do RTO definido e do orçamento disponível.
Desenvolver e implementar planos
Documentar os procedimentos de recuperação com o nível de detalhe necessário para serem executados sob pressão. Definir papéis e responsabilidades, configurar a infraestrutura de DR e garantir que as credenciais de acesso estão disponíveis.
Testar e manter
Realizar testes regulares para validar que os planos funcionam. Um plano não testado é um plano que não funciona. Actualizar os planos sempre que a infraestrutura ou os processos de negócio mudam.
Estratégias de recuperação
A escolha da estratégia de recuperação é determinada pelo RTO de cada serviço. Estratégias mais rápidas têm custos mais elevados - o objectivo é encontrar o equilíbrio certo para cada serviço.
Estratégias de recuperação por nível de prontidão
| Estratégia | RTO típico | RPO típico | Custo relativo |
|---|---|---|---|
| Cold site | Dias | Dias | Baixo |
| Warm site | Horas | Horas | Médio |
| Hot site | Minutos | Minutos | Elevado |
| Cloud DR | Minutos a horas | Minutos | Variável (pay-per-use) |
| Activa-activa | Segundos | Zero | Muito elevado |
Tipos de testes de continuidade
Os testes são a parte mais crítica da ITSCM. Um plano de continuidade que nunca foi testado não é um plano - é uma lista de intenções. Os testes validam que os procedimentos funcionam, que as pessoas sabem o que fazer e que a infraestrutura de DR está operacional.
| Tipo de teste | Descrição | Complexidade | Frequência recomendada |
|---|---|---|---|
| Tabletop | Discussão teórica do plano com os stakeholders. Percorrer o cenário de desastre em sala, identificar lacunas sem activar sistemas | Baixa | Semestral |
| Walkthrough | Percorrer os procedimentos passo a passo com as equipas responsáveis. Mais detalhado que o tabletop, mas sem activar a infraestrutura de DR | Média | Semestral |
| Simulação | Simular um cenário de desastre real sem afectar o ambiente de produção. As equipas executam os procedimentos como se fosse real | Alta | Anual |
| Teste parcial | Testar componentes específicos do plano, como o failover de uma base de dados ou a activação de um site de DR para um serviço concreto | Alta | Trimestral |
| Teste completo | Executar o plano de DR na totalidade, activando o site de recuperação e transferindo tráfego real. Teste mais realista e mais disruptivo | Muito alta | Anual |
Cada teste deve gerar um relatório com as lacunas identificadas e um plano de acção para as corrigir. Os testes que não produzem melhorias nos planos são testes incompletos. A maturidade de uma organização em ITSCM mede-se pela qualidade dos seus testes e pela velocidade com que incorpora as lições aprendidas.
Boas práticas
5 boas práticas para uma estratégia de continuidade eficaz
Testar regularmente
Um plano não testado é um plano que não funciona. Realizar pelo menos um teste de simulação por ano e testes parciais trimestrais. Documentar os resultados e actualizar os planos com base nas lacunas encontradas.
Actualizar os planos em cada mudança
Cada mudança na infraestrutura de TI exige revisão do plano de continuidade. Integrar a revisão da ITSCM no processo de gestão de mudanças para garantir que os planos se mantêm actualizados.
Envolver o negócio no BIA
A análise de impacto no negócio deve ser feita em conjunto com as áreas de negócio, não apenas pela TI. São as áreas de negócio que sabem qual o impacto real da indisponibilidade de cada serviço e quais os prazos toleráveis.
Documentar tudo
Os planos de continuidade devem ser suficientemente detalhados para serem executados por alguém que nunca os leu. Incluir contactos de emergência, procedimentos passo a passo, credenciais de acesso e arquitectura do site de DR.
Considerar o cloud DR
Soluções de Disaster Recovery as a Service (DRaaS) na cloud reduzem o custo e a complexidade comparado com sites físicos. O modelo pay-per-use elimina o investimento em infraestrutura permanente e permite RTOs competitivos.
Descarregue a template de plano de continuidade
Modelo profissional com BIA, estratégias de recuperação e procedimentos de activação.
Ver todas as templates ITSMPerguntas frequentes
A gestão de continuidade de serviços de TI (ITSCM) é a prática ITIL que garante que os serviços de TI podem ser restaurados dentro dos prazos acordados após uma interrupção grave ou desastre. Distingue-se da gestão de incidentes por se focar em cenários de alto impacto e baixa probabilidade, como desastres naturais, ciberataques massivos ou falhas catastróficas de infraestrutura.
O RTO (Recovery Time Objective) é o tempo máximo aceitável para restaurar um serviço após uma interrupção. O RPO (Recovery Point Objective) é a quantidade máxima de dados que a organização aceita perder, definindo assim a frequência dos backups. Por exemplo, um RPO de 1 hora significa que os backups devem ser feitos de hora a hora. Quanto menores o RTO e o RPO, maior o investimento necessário em infraestrutura de recuperação.
O Business Continuity Planning (BCP) é mais abrangente e cobre a continuidade de toda a organização, incluindo processos de negócio, recursos humanos e instalações. A ITSCM é uma componente do BCP que se foca especificamente nos serviços de TI. Em termos práticos, o ITSCM é o plano que garante que a TI suporta o BCP quando ocorre um desastre.
A frequência depende do tipo de teste. Os testes tabletop e walkthrough devem ser realizados semestralmente. Os testes de simulação e os testes completos devem ser realizados pelo menos anualmente. Os testes parciais, focados em componentes específicos como failover de base de dados, podem ser feitos trimestralmente. Um plano não testado é um plano que não funciona - os testes regulares são essenciais para validar que os procedimentos funcionam quando são necessários.
São estratégias de recuperação com diferentes níveis de prontidão. Um cold site é um espaço físico preparado mas sem equipamento activo, com RTO de dias e custo mais baixo. Um warm site tem infraestrutura parcialmente configurada, com RTO de horas e custo médio. Um hot site é uma réplica completa em standby permanente, com RTO de minutos mas custo elevado. A escolha depende do RTO definido para cada serviço crítico.
Para muitas organizações, sim. O cloud DR permite criar infraestrutura de recuperação na cloud de forma flexível e com modelo pay-per-use, eliminando o custo de manter um site físico permanente. Soluções como AWS, Azure e Google Cloud oferecem capacidades de Disaster Recovery as a Service (DRaaS) que permitem RTOs muito baixos a um custo inferior ao de sites físicos. No entanto, é necessário considerar a largura de banda necessária para replicação e os requisitos regulatórios de localização dos dados.
Quer proteger os seus serviços de TI?
Aprenda a implementar a gestão de continuidade e todas as práticas ITIL com formação certificada.
Ver formação ITIL