Caso de redução de indisponibilidade em IT

Quando uma aplicação de faturação fica indisponível durante duas horas, o problema não é apenas técnico. Há encomendas que não avançam, equipas comerciais sem informação, clientes sem resposta e uma direção a gerir incerteza. Este caso de redução de indisponibilidade representa uma situação comum em empresas portuguesas: infraestrutura que funciona até ao momento em que uma falha expõe dependências sem redundância, processos manuais e responsabilidades dispersas.

A indisponibilidade raramente nasce de um único erro. Pode começar num servidor sem capacidade, num switch sem configuração resiliente, numa actualização sem validação ou num backup que existe, mas nunca foi testado em recuperação. O impacto, esse, chega todo ao mesmo tempo.

O ponto de partida: falhas curtas, impacto prolongado

Uma empresa de distribuição com cerca de 180 utilizadores dependia de um ERP on-premises, serviços de ficheiros, correio electrónico em cloud e ligação permanente a armazéns remotos. Ao longo de seis meses, registou vários episódios de lentidão e três interrupções relevantes. Nenhuma tinha sido classificada internamente como desastre, mas o acumulado já afectava operação, confiança dos clientes e produtividade.

O ambiente tinha crescido por etapas. Havia um servidor de virtualização próximo do fim de vida, armazenamento sem tolerância adequada a falhas, cópias de segurança executadas durante a noite e vários fornecedores envolvidos. Um fornecia hardware, outro backup, outro conectividade e outro suporte aplicacional. Quando surgia um incidente, cada parte analisava a sua área. Ninguém detinha responsabilidade pelo serviço completo.

Este é um ponto decisivo: comprar equipamentos certificados não garante continuidade operacional. A disponibilidade resulta da arquitectura, da configuração, da monitorização, da disciplina de mudança e da capacidade de recuperar dentro de um tempo aceite pelo negócio.

O custo que não aparece no relatório de incidentes

A organização contabilizava apenas as horas em que o ERP não estava acessível. Ficavam de fora o tempo de reconciliação posterior, as tarefas introduzidas em papel, os atrasos na expedição e as horas da equipa de IT consumidas a contactar fornecedores. Também não existia uma estimativa formal do custo por hora de paragem.

Sem esse número, qualquer investimento em redundância parecia uma despesa técnica difícil de justificar. Com esse número, tornou-se uma decisão de risco operacional. Nem todos os sistemas exigem disponibilidade máxima, mas todos devem ter um nível de serviço deliberado e validado.

Diagnóstico antes de comprar tecnologia

O trabalho começou por um diagnóstico orientado para dependências e impacto, não por uma lista de produtos. Foram identificados os serviços críticos, os fluxos entre aplicações, os pontos únicos de falha e a diferença entre aquilo que a empresa assumia estar protegido e aquilo que conseguia efectivamente recuperar.

A análise revelou três fragilidades principais. A primeira era a concentração de cargas críticas num único host. A segunda era a ausência de testes regulares de restauro. A terceira estava no processo: não existia uma matriz clara de escalamento, nem procedimentos para decidir quem actuava durante os primeiros 30 minutos de um incidente.

Foi igualmente necessário separar conceitos que muitas empresas tratam como equivalentes. Backup protege dados. Alta disponibilidade reduz a interrupção perante uma falha localizada. Disaster recovery permite recuperar serviços após um incidente grave. Monitorização deteta sintomas e acelera resposta. Cada camada resolve um problema diferente.

Definir RTO e RPO com a direção

Antes da arquitectura, foram acordados objetivos por serviço. Para o ERP, o RTO - Recovery Time Objective - ficou definido em duas horas e o RPO - Recovery Point Objective - em 30 minutos. Isto significava que, perante um incidente grave, o serviço deveria estar operacional em até duas horas, com perda máxima aceitável de 30 minutos de dados.

Para ficheiros departamentais, o RTO podia ser superior. Para ficheiro histórico, a recuperação podia decorrer no dia útil seguinte. Esta distinção evitou sobredimensionar o investimento e permitiu concentrar recursos onde uma interrupção teria consequências comerciais imediatas.

RTO e RPO não são valores técnicos escolhidos pelo departamento de IT. São compromissos de negócio que a tecnologia tem de cumprir. Se a empresa exige recuperação em minutos, mas mantém cópias de segurança diárias num único destino, existe uma contradição que convém resolver antes do incidente.

A arquitectura para reduzir indisponibilidade

A solução foi desenhada em camadas. As máquinas virtuais críticas passaram para uma plataforma com redundância de computação e armazenamento, alimentada por UPS dimensionadas e com componentes monitorizados. A conectividade entre a sede e os armazéns recebeu caminhos alternativos e regras de failover testadas, em vez de depender apenas de uma ligação principal.

No domínio da proteção de dados, foram implementadas cópias imutáveis e separadas do ambiente de produção, com retenção alinhada com o risco de ransomware e com requisitos de auditoria. A regra não foi simplesmente manter várias cópias. Foi garantir que pelo menos uma cópia permanecia inacessível a credenciais comprometidas e que podia ser restaurada de forma verificável.

Para as cargas mais críticas, foi criado um plano de recuperação num ambiente alternativo. A escolha entre cloud, datacenter secundário ou modelo híbrido depende da latência, das aplicações, da soberania de dados, do volume a recuperar e do orçamento. Não há uma resposta universal. Há, sim, uma obrigação de testar o cenário escolhido.

Segurança também é disponibilidade

Num incidente de ransomware, a indisponibilidade pode resultar da decisão correcta de isolar sistemas antes de o ataque se propagar. Por isso, a redução de indisponibilidade não pode ser tratada à margem da cibersegurança.

Foram reforçados controlos de identidade, autenticação multifactor para acessos administrativos, segmentação de rede e proteção de endpoints. Os alertas de segurança passaram a integrar a operação de infraestrutura. A equipa deixou de avaliar apenas se um servidor respondia e passou a acompanhar se respondia de forma segura.

Este equilíbrio exige critério. Um controlo de segurança mal aplicado pode bloquear trabalho legítimo; uma excepção permanente pode abrir uma porta crítica. A governance activa serve precisamente para rever estas decisões, documentar riscos aceites e evitar que a urgência operacional se transforme numa vulnerabilidade estrutural.

Implementação sem criar uma nova paragem

Uma modernização destinada a reduzir risco não pode introduzir indisponibilidade desnecessária. A implementação foi faseada, com janelas de intervenção aprovadas, plano de reversão, responsáveis nomeados e critérios objectivos para avançar entre fases.

Primeiro, foram preparados os novos componentes e validadas compatibilidades. Depois, migraram-se serviços não críticos para confirmar desempenho, acessos e integrações. Só após essa validação foram transferidas as cargas de maior impacto. Durante cada alteração, a equipa registou tempos, incidentes, decisões e desvios ao plano.

Este método parece mais lento do que uma intervenção concentrada num fim de semana. Na prática, reduz retrabalho e limita o raio de impacto quando aparece uma dependência que não estava documentada. A rapidez que interessa não é a de instalar equipamento. É a de pôr serviços em produção sem criar problemas para corrigir na segunda-feira.

O resultado do caso de redução de indisponibilidade

Após a estabilização, a organização reduziu interrupções não planeadas e ganhou previsibilidade na resposta. Mais relevante do que o número de incidentes foi a mudança de controlo: passou a existir uma visão comum sobre serviços críticos, dependências, RTO/RPO, procedimentos de escalamento e responsáveis por cada acção.

Os testes de recuperação deixaram de ser uma actividade excepcional. Em ciclos definidos, são restauradas máquinas e dados em ambiente isolado, validando integridade, tempos de recuperação e acessos aplicacionais. Um backup só é um activo de continuidade depois de ser recuperado com sucesso.

A monitorização contínua passou a vigiar capacidade, disponibilidade, alertas de hardware, desempenho de armazenamento, estado das cópias de segurança e eventos de segurança. Mas monitorizar sem processo apenas produz notificações. Cada alerta relevante ficou associado a um limiar, a uma prioridade, a um procedimento e a um SLA contratual de resposta.

O que medir a partir daqui

A disponibilidade deve ser tratada como uma métrica de gestão, não como uma percepção. Além da percentagem de uptime, vale a pena acompanhar o número de incidentes por serviço, o tempo médio de deteção, o tempo médio de recuperação, a taxa de sucesso dos backups e o cumprimento dos RTO/RPO em testes reais.

Também convém medir causas recorrentes. Se o mesmo alerta regressa todos os meses, resolver apenas o sintoma não é operação madura. É necessário corrigir capacidade, configuração, processo ou comportamento de utilização que está na origem.

Continuidade é responsabilidade operacional

A redução de indisponibilidade não resulta de uma compra isolada nem de uma promessa genérica de suporte. Exige diagnóstico, arquitectura adequada, implementação controlada e operação contínua. Exige também um parceiro que assuma a stack como um todo, em vez de encaminhar cada falha para um fornecedor diferente.

Na ITPOINT, a conversa começa pela operação que a empresa não pode parar. A pergunta útil não é apenas “que equipamento precisamos de substituir?”. É “quanto tempo podemos estar sem este serviço e o que está hoje a impedir-nos de recuperar dentro desse prazo?”. A resposta orienta a arquitectura e transforma continuidade num compromisso verificável.