Preciso fazer manutenção preventiva
Resposta rápida
Manutenção preventiva em TI é o que separa operação madura de operação reativa: em vez de apagar incêndio às duas da manhã, agendar janela controlada quando o impacto é menor. Monte um calendário com três cadências: semanal (patches de menor risco, limpeza de logs, verificação de backup), mensal (atualizações de sistemas, revisão de capacidade, manutenção de hardware crítico, patches de segurança não emergenciais) e trimestral (atualização maior de plataformas, testes de plano de contingência, revisão de configuração). Para cada janela, defina horário (em geral fora do horário comercial), responsável, comunicação prévia, procedimento documentado e plano de rollback. Sem essa disciplina, "manutenção" vira só reação a incidente — e cada incidente custa muito mais do que a janela planejada teria custado.
Na empresa pequena, manutenção preventiva costuma ser invisível: ou o MSP faz silenciosamente, ou ninguém faz. O risco característico é descobrir que estação de trabalho do contador roda Windows desatualizado há dois anos, ou que o roteador da matriz nunca foi reiniciado desde a instalação. O calendário aqui é simples: uma janela mensal de duas a três horas no fim do dia (sábado ou último dia útil do mês) para patches críticos e revisão básica, e um check trimestral mais amplo de equipamentos. Se o MSP cuida, exija o relatório do que foi feito — sem o relatório, você não sabe se a manutenção aconteceu. Hardware crítico costuma resumir-se a um servidor de arquivos, o firewall e o switch principal; o inventário cabe em uma página e atualizá-lo a cada mudança é viável.
Na empresa média, manutenção preventiva passa a exigir calendário formal e comunicação às áreas-cliente. O time de TI tem dois a oito profissionais, e a divisão começa: alguém responde por servidores e infraestrutura, alguém por estações e impressoras, alguém por sistemas. Janela mensal de quatro a seis horas (geralmente fim de semana ou madrugada) cobre o grosso dos patches; janelas trimestrais maiores tratam upgrades de plataforma. O risco característico desse porte é o calendário existir no papel mas não rodar — falta de tempo, demanda urgente, e a janela é adiada repetidamente até que algo dá errado em horário comercial. Disciplina de defender a janela como reunião inegociável (a não ser por crítico real) é o que separa a TI organizada da TI permanentemente atrasada.
Na empresa grande, manutenção preventiva é processo industrializado com janela formal de mudanças (change window), aprovação por CAB (Change Advisory Board), automação parcial via ferramenta de configuration management (Ansible, Puppet, SCCM, Intune) e calendário trimestral publicado para áreas. O risco aqui não é falta de processo, é processo demais — cada patch trivial vira reunião de CAB, e a fila de mudança incha. O foco é segmentar nível de mudança (standard pré-aprovada, normal, emergencial), reservar CAB para o que realmente exige aprovação cruzada, e automatizar o restante. Patches são distribuídos por anéis de risco — primeiro ambiente de teste, depois piloto, depois produção geral — para detectar problema antes da escala. Janela aqui pode envolver coordenação internacional, se houver operação multi-fuso.
- Você só lembra de atualizar quando algo já quebrou
- Patches críticos acumulam por meses sem janela para aplicar
- O backup nunca foi testado de fato
- Equipamentos críticos rodam desde a instalação sem revisão
- Incidentes acontecem regularmente em horário comercial
- Não há comunicação prévia quando algum sistema vai cair
As três cadências de manutenção
Manutenção preventiva bem rodada opera em três cadências sobrepostas: semanal, mensal e trimestral. Cada cadência tem propósito diferente e exige nível diferente de planejamento.
Semanal são tarefas leves, automatizáveis em grande parte: rotação de logs, limpeza de temporários, verificação de backup do dia anterior, monitoramento de espaço em disco. Cabem em meia hora e raramente exigem janela com impacto.
Mensal é o coração do calendário. Patches de sistema operacional, atualizações de aplicações não emergenciais, revisão de capacidade (CPU, memória, disco), manutenção de hardware crítico (limpeza, verificação de UPS, troca de filtros em rack), reset programado de equipamentos de rede. Janela típica de duas a seis horas fora do horário comercial.
Trimestral trata o que é mais arriscado e exige preparação maior. Upgrade de versão maior de plataforma, atualização de firmware de hardware crítico, teste de plano de contingência, revisão de configuração de segurança. Janela típica de seis a doze horas, geralmente em fim de semana, com plano de rollback testado.
Patches de segurança são caso à parte
Vulnerabilidades críticas (CVE alto, exploit ativo) não esperam o próximo ciclo mensal. Para essas, processo emergencial: análise de impacto em 24 a 48 horas, janela emergencial com aprovação acelerada, comunicação às áreas afetadas. O calendário regular não substitui o processo de patch crítico — eles convivem.
- Comunique com antecedência. Para janelas com impacto perceptível, avisar áreas afetadas com pelo menos 48 horas. Mensagem objetiva: o que cai, quando, por quanto tempo, o que fazer em caso de problema.
- Tenha procedimento escrito. Passo a passo do que será feito, em que ordem, com pontos de verificação. Sem procedimento, a janela vira improviso e o rollback fica frágil.
- Garanta backup antes. Snapshot, backup full ou export, conforme o caso. Janela sem ponto de retorno é roleta russa.
- Execute com olho no relógio. Defina ponto de não retorno — se passar de certo horário sem estar concluído, executa-se o rollback para não bater no horário comercial.
- Valide funcionando. Não basta o procedimento terminar sem erro; rode testes de fumaça nos serviços críticos antes de declarar concluída.
- Comunique o encerramento. Avise as áreas e registre o resultado: o que foi feito, tempo decorrido, problemas encontrados, ajustes para a próxima.
Definindo a janela certa
A janela ideal é aquela em que o impacto, se houver, atinge o menor número de pessoas e processos. Em empresa comercial, fim de semana ou madrugada de domingo para segunda; em operação 24/7, janela negociada por turno menos crítico, com comunicação a quem opera nessa hora. Em empresa multi-fuso, escolher a janela exige mapear quais regiões estão ativas — o que é madrugada no Brasil é horário comercial em outro país.
Resistir à pressão de fazer manutenção em horário comercial "porque é rápido" é parte do trabalho. O custo de uma manutenção em horário comercial que dá errado é maior do que o custo de virar uma noite. Quando a área pede "faz agora que é rapidinho", a resposta é janela formal — mesmo que pareça burocracia.
Manutenção de hardware físico
Manutenção preventiva inclui hardware que pessoas esquecem. Limpeza de poeira em rack, verificação de UPS (com teste de bateria periódico, não só visual), troca de filtros, verificação de temperatura na sala de servidores, teste de gerador, inspeção visual de cabeamento. Para hardware crítico, fabricante costuma definir ciclo de manutenção — seguir o que está no manual evita falha prematura coberta por garantia que dependia da manutenção feita.
Janela sem rollback testado. Plano de rollback que existe no papel mas nunca foi executado é mais perigoso do que reconfortante. Testar o rollback uma vez por semestre, em ambiente de homologação, salva quando a manutenção real der errado.
Aproveitar janela para fazer extra. Mudança não planejada que entra "porque já está aberto" é a fonte número um de incidente em janela de manutenção. Disciplina é executar só o escopo aprovado.
Adiar a janela repetidamente. Cada adiamento parece pequeno, mas em seis meses acumula patches críticos não aplicados. Defender a janela como compromisso é mais importante do que executá-la perfeitamente cada vez.
Manutenção sem registro. O que foi feito, quando, por quem, quais problemas apareceram. Sem registro, o próximo plantão não aprende nada da janela anterior e os mesmos erros se repetem.
- Áreas afetadas foram comunicadas com antecedência suficiente
- Procedimento escrito com passos, ordem e pontos de verificação
- Backup, snapshot ou export atualizado antes da mudança
- Plano de rollback escrito e idealmente já testado
- Ponto de não retorno definido em hora específica
- Lista de testes de validação para rodar após a mudança
- Canal de comunicação aberto com plantão e usuários-chave