Buscar Entrar

Coleta de logs e diagnóstico

Registre o sintoma, preserve as evidências e informe o impacto para facilitar a análise do suporte.

Antes de abrir um chamado

InformeO que registrar
QuandoData, hora e duração.
OndeProjeto, servidor, máquina e tela afetados.
SintomaMensagem completa e comportamento observado.
ImpactoQuem ou o que ficou indisponível.
EvidênciasPrint, versão e logs disponíveis do Flessor, IIS, Windows ou SQL Server.
Teste feitoAções já executadas e respectivos resultados.

Os caminhos dos logs variam conforme a instalação. Preserve os registros do período da ocorrência. Se não souber onde encontrá-los, informe a versão e o componente afetado para receber orientação.

Prepare a solicitação

Descreva o resultado esperado e o observado, identifique os arquivos anexados e informe as verificações já realizadas. Não reinicie serviços apenas para tentar eliminar a mensagem antes de preservar as evidências e combinar a intervenção.

Precisa de ajuda com este caso?

Consultar o fórum de dúvidas · E-mail: suporte@flessor.com (copie o endereço) · WhatsApp: +55 46 9125-6322

Use o fórum para informações que possam ser públicas; combine com o suporte o envio de arquivos do projeto. Informe contexto, impacto e evidências disponíveis.

Consultar rotina de manutenção e suporte pós-entrega

Referência complementar para acompanhar a instalação após a entrega.

Após o deploy, o projeto entra em operação real. A partir desse momento, o integrador deve acompanhar a estabilidade do sistema, comunicação com máquinas, funcionamento do banco de dados, relatórios, backups, acesso Web, permissões, alarmes sistêmicos e desempenho geral do servidor.

  • organizar rotina de suporte pós-entrega;
  • acompanhar comunicação com máquinas;
  • verificar saúde do servidor;
  • monitorar banco de dados e espaço em disco;
  • validar backups;
  • revisar IIS e acesso Web;
  • acompanhar alarmes sistêmicos;
  • diagnosticar falhas recorrentes;
  • registrar atendimentos;
  • orientar operação e manutenção;
  • estruturar plano de manutenção preventiva do supervisório.

O que é suporte pós-entrega

Figura 38.1 — Acompanhamento de operação pós-entrega.
Figura 38.1 — Acompanhamento de operação pós-entrega.

Inclui:

Suporte pós-entrega é o conjunto de atividades realizadas após o sistema entrar em operação. (ver Figura 38.1).

  • acompanhamento inicial;
  • correção de pendências;
  • resposta a falhas;
  • análise de logs;
  • monitoramento de comunicação;
  • ajustes de telas;
  • ajustes de relatórios;
  • revisão de alarmes;
  • orientação ao operador;
  • backup periódico;
  • atualização controlada;
  • manutenção preventiva do servidor.

A entrega do projeto não termina quando a tela abre. Ela termina quando o sistema está estável, validado e a operação consegue utilizá-lo com segurança.

Período de acompanhamento inicial

Sugestão:

Tipo de projetoAcompanhamento inicial sugerido
Projeto pequeno1 a 3 dias
Projeto médio1 a 2 semanas
Projeto crítico2 a 4 semanas
Projeto com comandos remotosacompanhamento assistido
Projeto com integração externaacompanhamento até estabilização

Após publicar o projeto, recomenda-se acompanhar o sistema por um período inicial.

Esse período pode variar conforme o porte do projeto.

Durante esse período, o integrador deve observar se os dados estão chegando corretamente, se os alarmes estão coerentes, se os relatórios são gerados e se os usuários conseguem operar o sistema.

Responsabilidades após entrega

AtividadeResponsável sugerido
Operação diáriaCliente / operador
Verificação de alarmesOperação
Manutenção do servidorTI/OT do cliente ou integrador contratado
Ajustes de telasIntegrador
Ajustes de variáveisIntegrador / automação
Banco de dadosTI/OT / integrador
BackupCliente ou integrador, conforme contrato
AtualizaçõesIntegrador
Comandos e lógica de campoAutomação / responsável técnico

Defina claramente quem é responsável por cada item.

Essa definição evita dúvidas quando ocorre uma falha.

Rotina diária recomendada

Checklist diário:

ItemVerificado
Supervisório acessível☐
Login funcionando☐
Tela inicial carregando☐
Máquinas principais comunicando☐
Alarmes ativos revisados☐
Relatórios automáticos gerados☐
Espaço em disco sem alerta☐
Banco de dados acessível☐
Backup recente confirmado, quando aplicável☐
Acesso remoto funcionando, se usado☐

Em sistemas críticos, a operação ou suporte deve fazer verificações diárias.

A rotina diária deve ser simples, objetiva e rápida.

Rotina semanal recomendada

Checklist semanal:

ItemVerificado
Histórico de alarmes revisado☐
Alarmes recorrentes analisados☐
Comunicação intermitente verificada☐
Relatórios semanais conferidos☐
Tamanho do banco avaliado☐
Espaço em disco avaliado☐
Logs principais revisados☐
Backups conferidos☐
Usuários temporários revisados☐
Pendências de suporte atualizadas☐

A rotina semanal ajuda a identificar problemas antes que virem falhas graves.

Rotina mensal recomendada

Checklist mensal:

ItemVerificado
Backup restaurável testado☐
Banco de dados revisado☐
Crescimento do histórico avaliado☐
Certificados revisados, se aplicável☐
DDNS ou acesso externo testado☐
Relatórios mensais validados☐
Alarmes mais recorrentes analisados☐
Usuários e permissões revisados☐
Atualizações pendentes avaliadas☐
Documentação do projeto atualizada☐

A rotina mensal deve gerar um pequeno registro de saúde do sistema.

Monitoramento da comunicação

Monitore:

Sinais de problema:

A comunicação com máquinas é um dos pontos mais importantes do supervisório.

CLPs, medidores, remotas, NVRs, câmeras, gateways, estações hidrotelemétricas, bancos de dados externos, APIs e sistemas integrados.

  • Valores congelados
  • Falha de comunicação recorrente
  • Alarmes de timeout
  • Dados nulos
  • Variáveis sem atualização
  • Comunicação oscilando
  • Relatórios com lacunas

Use Visualizar Variáveis para confirmar valores em tempo real.

Diagnóstico de comunicação intermitente

Possíveis causas:

Ações recomendadas:

Comunicação intermitente costuma ser mais difícil que falha permanente.

cabo de rede instável, switch com problema, fonte de alimentação oscilando, roteador travando, Wi-Fi inadequado, VPN instável, firewall encerrando sessão, equipamento reiniciando, timeout curto, scan muito agressivo, excesso de variáveis e rede industrial congestionada.

  • Identificar horário da falha.
  • Verificar se afeta uma máquina ou várias.
  • Comparar com logs de rede.
  • Avaliar perda de pacotes.
  • Revisar scan cycle.
  • Verificar alimentação dos equipamentos.
  • Registrar recorrência.
  • Ajustar configuração com critério.

Monitoramento do servidor

Verifique:

O servidor deve ser acompanhado como parte da operação.

uso de CPU, uso de memória, espaço em disco, serviços em execução, disponibilidade do SQL Server, disponibilidade do IIS, logs de erro, horário do sistema, sincronismo NTP, antivírus, atualizações do Windows e reinicializações inesperadas.

Um problema no servidor pode parecer problema do supervisório, mas a causa pode ser infraestrutura.

Espaço em disco

Monitore:

Sugestão de alerta:

Espaço livreAção
Acima de 30%Normal
Entre 15% e 30%Acompanhar
Entre 10% e 15%Planejar limpeza
Abaixo de 10%Ação urgente
Abaixo de 5%Risco crítico

Históricos, relatórios, logs e backups podem consumir disco ao longo do tempo.

disco do sistema, pasta do projeto, pasta de relatórios, banco de dados, backups locais, logs antigos, arquivos temporários e imagens ou exportações.

Não deixe o servidor operar com disco quase cheio.

Banco de dados

Verifique periodicamente:

Verificações:

O banco de dados pode crescer conforme frequência de coleta, quantidade de variáveis, alarmes, eventos e relatórios.

tamanho do banco, tamanho dos arquivos de log, espaço livre em disco, desempenho de consultas, geração de relatórios, retenção de histórico, backups do banco, integridade do banco, permissões de usuário e conexão do projeto com o banco.

  • Relatório lento
  • Banco muito grande
  • Log do SQL crescendo
  • Sem espaço em disco
  • Falha de conexão
  • Histórico com lacunas

Retenção de dados

Exemplos:

Tipo de dadoRetenção sugerida
Alarmes operacionaisconforme contrato ou requisito
CEPsconforme necessidade de auditoria
Relatórios geradosconforme exigência operacional/regulatória
Logs técnicosmenor retenção, salvo investigação
Backupspolítica específica
Dados hidrológicosconforme exigência do cliente

Defina com o cliente por quanto tempo os dados devem ser mantidos.

Sem política de retenção, o banco pode crescer indefinidamente.

Backups periódicos

Recomendações:

Backups devem ser rotina, não exceção.

  • backup automático quando possível;
  • backup manual antes de alterações;
  • backup do projeto;
  • backup do banco;
  • cópia fora do servidor principal;
  • teste periódico de restauração;
  • registro de data e responsável;
  • armazenamento seguro.

Um backup que nunca foi testado não deve ser considerado totalmente confiável.

Verificação dos backups

Verifique:

ItemVerificação
Backup foi geradoSim/Não
Arquivo possui tamanho coerenteSim/Não
Data está atualSim/Não
Local está acessívelSim/Não
Banco foi incluídoSim/Não
Projeto foi incluídoSim/Não
Restauração foi testadaSim/Não

Backups automáticos podem falhar silenciosamente. Confira.

IIS e acesso Web

Verifique:

O IIS deve permanecer saudável para que o supervisório Web funcione.

site ativo, pool de aplicação ativo, porta correta, certificado válido, se HTTPS, permissões de pasta, logs do IIS, erros HTTP, acesso local, acesso pela rede e acesso externo, se aplicável.

Se o acesso local funciona e o acesso externo não funciona, investigue rede, firewall, NAT, DNS ou certificado.

Certificados e DDNS

Quando houver HTTPS, DDNS ou subdomínio, acompanhe:

Problemas típicos:

  • validade do certificado;
  • renovação automática;
  • apontamento DNS;
  • IP público;
  • NAT;
  • firewall;
  • mudança de provedor de internet;
  • bloqueio de portas;
  • vencimento de domínio, quando aplicável.
  • Certificado expirado
  • Subdomínio apontando para IP antigo
  • Roteador substituído sem refazer NAT
  • Provedor mudou IP público
  • Firewall bloqueou porta

Acesso remoto deve ser testado periodicamente.

Serviços e processos

Exemplos:

Verifique:

  • se o serviço está ativo;
  • se reiniciou recentemente;
  • se há erro em log;
  • se consome CPU ou memória excessiva;
  • se está configurado para iniciar com o Windows.

Quando o ambiente usar serviços ou processos auxiliares, monitore se estão em execução.

runtime principal, serviço de monitoramento, serviço de relatórios, serviço de DDNS/certificado, SQL Server, IIS, tarefas agendadas, serviços de comunicação, integrações externas e monitor remoto.

Horário do servidor

Problemas causados por horário incorreto:

O horário do servidor deve estar correto.

  • relatórios com horário errado;
  • alarmes fora de ordem;
  • CEPs com data incorreta;
  • certificados inválidos;
  • falha de autenticação;
  • inconsistência em históricos;
  • comparação incorreta de eventos.

Recomenda-se usar sincronização NTP confiável.

Logs

Locais possíveis:

Ao analisar um log, registre:

CampoInformação
Data/horaQuando ocorreu
ServiçoQual componente gerou
MensagemTexto do erro
FrequênciaÚnico ou recorrente
ImpactoAfetou operação?
AçãoO que foi feito

Logs ajudam a diagnosticar problemas.

logs do Flessor, logs do runtime, logs do IIS, logs do Windows, logs do SQL Server, logs de tarefas agendadas, logs de serviços auxiliares e logs de integração externa.

Não apague logs relevantes antes de concluir diagnóstico.

Alarmes sistêmicos

Exemplos:

Além dos alarmes de máquina, acompanhe alarmes sistêmicos.

  • falha de banco de dados;
  • falha de comunicação geral;
  • falha de sincronismo;
  • falha de envio de relatório;
  • servidor sem espaço em disco;
  • estação hidrotelemétrica sem atualização;
  • NVR offline;
  • serviço parado;
  • erro de licença;
  • falha de acesso externo.

Esses alarmes ajudam a identificar problemas de infraestrutura e integração.

Alarmes recorrentes

Exemplo:

Possíveis causas:

Ação recomendada:

Alarmes recorrentes merecem análise.

Falha de comunicação com CLP UG01 ocorre 15 vezes por dia.

rede instável, scan muito rápido, equipamento reiniciando, cabo ruim, switch com problema, timeout inadequado e driver mal configurado.

  1. Levantar frequência.
  2. Identificar horário.
  3. Verificar se há padrão.
  4. Consultar operação.
  5. Verificar rede.
  6. Ajustar configuração, se necessário.
  7. Registrar correção.

Não normalize alarme recorrente apenas aumentando delay sem entender causa.

Relatórios automáticos

Quando houver relatórios automáticos, verifique:

Verificações:

se foram gerados, se possuem dados, se o período está correto, se o envio por e-mail funcionou, se os anexos abriram, se o cabeçalho está correto, se os valores fazem sentido e se não há lacunas.

  • Relatório gerado vazio
  • E-mail não enviado
  • Anexo corrompido
  • Banco sem dados no período
  • Variável removida do relatório

E-mail e notificações

Se o projeto envia e-mails ou notificações:

teste credenciais, teste servidor SMTP ou serviço usado, confirme destinatários, revise limites de envio, revise spam/bloqueio, confirme anexos, revise mensagens e confirme envio de alarmes críticos, se aplicável.

Notificações devem ser úteis. Excesso de mensagens reduz atenção.

Usuários e permissões

Revise periodicamente:

Boas práticas:

  • remover usuários não usados;
  • evitar conta compartilhada;
  • usar níveis adequados;
  • registrar quem tem acesso a comandos críticos;
  • revisar permissões após mudanças de equipe.

usuários ativos, usuários temporários, usuários de integrador, senhas padrão, permissões de tela, permissões de comando, permissões de relatórios, acessos de manutenção e usuários desligados da empresa.

Segurança do acesso remoto

Se houver acesso remoto:

  • preferir VPN ou método seguro aprovado;
  • evitar exposição desnecessária de portas;
  • usar HTTPS;
  • manter senhas fortes;
  • revisar usuários;
  • revisar firewall;
  • revisar logs de acesso;
  • remover acessos temporários;
  • documentar quem acessa e por quê.

Acesso remoto é útil para suporte, mas precisa ser controlado.

Atualizações do Windows

Cuidados:

Atualizações do sistema operacional podem ser necessárias, mas devem ser planejadas.

  • agendar janela;
  • fazer backup;
  • avisar operação;
  • verificar se o servidor pode reiniciar;
  • testar IIS após atualização;
  • testar SQL Server;
  • testar runtime;
  • testar comunicação com máquinas;
  • registrar resultado.

Não permita reinicialização automática em horário crítico sem alinhamento com o cliente.

Antivírus e proteção do servidor

Verifique:

Antivírus pode afetar desempenho ou bloquear arquivos.

exclusões necessárias, quarentena, bloqueio de executáveis, bloqueio de scripts, bloqueio de portas, impacto em SQL Server, impacto em IIS e varreduras em horário crítico.

A política deve ser definida com TI do cliente.

Desempenho do supervisório

Sinais de desempenho ruim:

Possíveis causas:

Ação recomendada:

  • Identificar onde está a lentidão.
  • Separar problema de tela, banco, rede ou servidor.
  • Medir antes de alterar.
  • Corrigir gradualmente.
  • Testar após cada ajuste.

telas lentas, login demorado, relatórios lentos, valores atrasados, navegador travando, CPU alta, memória alta, banco lento e disco em uso constante.

imagens muito pesadas, telas com muitos componentes, scan muito agressivo, banco grande, servidor subdimensionado, scripts JS pesados, excesso de alarmes ou eventos e rede instável.

Manutenção de telas

Exemplos:

Após a entrega, telas podem precisar de ajustes.

reposicionar valores, corrigir legenda, melhorar contraste, ajustar unidade, incluir novo indicador, corrigir variável, remover componente inútil, melhorar botão e incluir diagnóstico.

Toda alteração em tela deve ser registrada e versionada.

Manutenção de alarmes

Possíveis ajustes:

Alarmes devem ser revisados após uso real.

corrigir mensagem, ajustar delay, corrigir nível, adicionar causa e solução, remover falso alarme, separar alarme e trip, criar alarme sistêmico e revisar notificação.

Não desative alarme apenas porque incomoda. Primeiro investigue se ele está indicando problema real.

Manutenção de relatórios

Revise:

Relatórios podem exigir ajustes após primeiras entregas.

variáveis, unidades, período, cabeçalho, logotipo, agrupamentos, campos ausentes, excesso de informação, desempenho e envio automático.

Relatório deve atender quem usa a informação, não apenas quem configurou.

Manutenção de variáveis

Situações comuns:

Alterações no CLP, protocolo ou equipamento podem exigir revisão de variáveis.

CLP recompilado, símbolos alterados, endereço Modbus mudou, OID SNMP diferente, equipamento substituído, driver atualizado, variável removida e unidade corrigida.

Após qualquer alteração de variável, revise telas, alarmes, relatórios, Tags Virtuais, CEPs, horímetros e sincronismos associados.

Manutenção de comandos

Antes de alterar comando:

Comandos devem ser tratados com controle rigoroso.

confirmar solicitação, revisar risco, fazer backup, validar variável, validar permissão, validar confirmação, testar em condição segura e registrar alteração.

Comando alterado sem controle pode causar operação indevida.

Registro de atendimento

Modelo:

CampoPreenchimento
Data/hora
Cliente
Projeto
Solicitante
TipoDúvida / Falha / Melhoria / Emergência
Descrição
Diagnóstico
Ação executada
Arquivos alterados
Versão antes
Versão depois
Responsável
StatusAberto / Em andamento / Resolvido
Observações

Todo atendimento deve ser registrado.

Esse registro protege o integrador e melhora suporte futuro.

Classificação de chamados

CriticidadeExemploPrazo sugerido
Baixaajuste visual, dúvida simplesconforme contrato
Médiarelatório incorreto, tela com dado secundário erradocurto prazo
Altaperda de comunicação com máquina importanteatendimento prioritário
Críticasupervisório indisponível, comando crítico com erroatendimento imediato

Classifique chamados por criticidade.

O prazo real depende do contrato de suporte.

Atendimento remoto

Antes de atendimento remoto:

confirmar autorização, registrar horário, confirmar escopo, fazer backup antes de alterar, evitar mudanças sem registro, não testar comando sem responsável local, registrar o que foi feito e informar conclusão.

Acesso remoto deve ser usado com responsabilidade.

Atendimento em campo

Em atendimento presencial, leve:

notebook com Studio, backup mais recente, instalador compatível, documentação do projeto, lista de IPs, credenciais autorizadas, cabos de rede, adaptador USB/RJ45, acesso ao servidor, contato da operação, contato da automação e plano de testes.

Após atendimento, gere relatório técnico simples.

Relatório de suporte

Modelo de relatório:

CampoPreenchimento
Cliente
Unidade
Data
Responsável
Motivo do atendimento
Diagnóstico
Ação executada
Testes realizados
Resultado
Pendências
Recomendações

Esse relatório pode ser enviado ao cliente após intervenção relevante.

Indicadores de saúde do sistema

Exemplos:

IndicadorObjetivo
Disponibilidade do supervisórioSaber se o sistema está acessível
Máquinas onlineMonitorar comunicação
Alarmes críticos ativosIdentificar risco
Falhas de comunicação por diaIdentificar instabilidade
Tempo de geração de relatórioAvaliar desempenho
Espaço livre em discoEvitar parada por disco cheio
Último backup válidoGarantir recuperação
Uso de CPU/memóriaAvaliar servidor
Última atualização de hidrotelemetriaVerificar dados externos

É útil acompanhar indicadores simples.

Esses indicadores podem ser exibidos em uma tela de diagnóstico.

Tela de diagnóstico do sistema

Conteúdo sugerido:

Recomenda-se criar uma tela de diagnóstico administrativo.

status do servidor, status do banco, status do IIS, comunicação das máquinas, falhas de sincronismo, status de relatórios, espaço em disco, última atualização de dados, status de NVR/câmeras, status de hidrotelemetria, versão do projeto, data do último backup e usuários conectados, quando disponível.

Essa tela deve ter permissão adequada.

Pendências pós-entrega

Registre:

CampoPreenchimento
Pendência
TipoCorreção / Melhoria / Aguardando cliente
Responsável
Prazo
ImpactoBaixo / Médio / Alto
StatusAberta / Em andamento / Resolvida
Observação

Nem toda entrega termina sem pendências.

Pendência não registrada tende a virar conflito futuro.

Revisão periódica com o cliente

Pauta sugerida:

Agende revisões periódicas quando houver contrato de suporte.

principais alarmes do período, falhas de comunicação, relatórios gerados, solicitações de melhoria, usuários e permissões, backups, desempenho, necessidade de atualização, pendências abertas e riscos identificados.

Essa reunião pode ser mensal ou trimestral.

Atualizações planejadas

Antes de atualizar:

Atualizações devem seguir processo.

registrar motivo, revisar impacto, fazer backup, testar em homologação, quando possível, agendar janela, avisar operação, preparar rollback, aplicar alteração, testar e registrar conclusão.

Evite atualizações improvisadas em produção.

Melhorias evolutivas

Exemplos:

Após a entrada em operação, o cliente pode solicitar melhorias.

novas telas, novos relatórios, novos alarmes, dashboards, integração com câmera, integração com API, novos usuários, novas permissões, novas máquinas, análise preditiva e telas de manutenção.

Trate melhoria como nova demanda, com escopo, prazo e validação.

Não misturar suporte com alteração de escopo

Diferencie:

SituaçãoClassificação
Valor aparece errado por escala configurada erradaCorreção
Cliente quer nova telaMelhoria
Cliente quer novo relatórioMelhoria
Comunicação caiu por switch queimadoSuporte/infraestrutura
CLP mudou tags sem avisarAjuste técnico
Botão comanda variável erradaCorreção crítica
Operador esqueceu senhaSuporte operacional

Essa distinção evita desgaste contratual.

Encerramento de chamado

Antes de encerrar:

  • Confirmar que o problema foi resolvido.
  • Testar com usuário ou responsável.
  • Registrar alteração.
  • Atualizar versão, se aplicável.
  • Gerar backup, se houve mudança.
  • Informar o cliente.
  • Registrar pendências remanescentes.

Não encerre chamado apenas porque a alteração foi feita. Encerre após validação.

Diagnóstico rápido

Supervisório indisponível

Possíveis causas:

Ações recomendadas:

IIS parado, servidor desligado, runtime parado, firewall bloqueando, certificado com problema, porta ocupada, falha de licença, atualização do Windows e disco cheio.

  1. Testar acesso local.
  2. Verificar IIS.
  3. Verificar serviços.
  4. Verificar logs.
  5. Verificar disco.
  6. Verificar licença.
  7. Restaurar serviço ou acionar rollback.

Valores pararam de atualizar

Possíveis causas:

Ações recomendadas:

máquina sem comunicação, rede industrial com falha, driver parado, CLP desligado, IP alterado, firewall bloqueando e variável removida.

  1. Abrir Visualizar Variáveis.
  2. Verificar comunicação da máquina.
  3. Testar rede.
  4. Conferir IP e porta.
  5. Verificar CLP/equipamento.
  6. Registrar ocorrência.

Relatórios deixaram de ser gerados

Possíveis causas:

Ações recomendadas:

banco indisponível, serviço parado, tarefa agendada falhou, período sem dados, e-mail bloqueado, template alterado e falta de permissão na pasta.

  1. Verificar banco.
  2. Verificar logs.
  3. Testar relatório manual.
  4. Verificar tarefa ou serviço.
  5. Conferir template.
  6. Corrigir e registrar.

Backup não existe ou falhou

Possíveis causas:

Ações recomendadas:

rotina não configurada, disco cheio, permissão insuficiente, caminho indisponível, serviço de backup falhou e arquivo bloqueado.

Criar backup manual imediato, Corrigir rotina, Testar geração, Testar restauração e Registrar falha.

Acesso remoto parou

Possíveis causas:

Ações recomendadas:

IP público mudou, DDNS falhou, certificado expirou, NAT removido, roteador trocado, firewall alterado e VPN desconectada.

  1. Testar acesso interno.
  2. Testar DNS.
  3. Verificar certificado.
  4. Verificar NAT.
  5. Verificar firewall.
  6. Validar com TI.

Boas práticas

Adote as seguintes práticas:

  • acompanhar o sistema após o deploy;
  • manter rotina diária, semanal e mensal;
  • monitorar comunicação das máquinas;
  • revisar alarmes recorrentes;
  • conferir backups;
  • monitorar banco e disco;
  • revisar IIS e acesso Web;
  • manter usuários atualizados;
  • registrar atendimentos;
  • não alterar produção sem backup;
  • separar correção de melhoria;
  • manter documentação atualizada;
  • validar alterações com o cliente;
  • gerar backup após correções importantes.

Checklist de manutenção pós-entrega

ItemVerificado
Supervisório acessível☐
IIS ativo☐
SQL Server ativo☐
Banco acessível☐
Espaço em disco adequado☐
Comunicação com máquinas validada☐
Visualizar Variáveis conferido☐
Alarmes ativos revisados☐
Alarmes recorrentes analisados☐
Relatórios gerados☐
E-mails/notificações funcionando☐
Backup recente confirmado☐
Restauração de backup testada periodicamente☐
Usuários revisados☐
Permissões revisadas☐
Acesso remoto testado☐
Certificado/DDNS revisado, quando aplicável☐
Logs revisados☐
Pendências registradas☐
Documentação atualizada☐

Verificação inicial da instalação

Registre o estado do Studio, do Console, do IIS e do SQL Server antes de intervir. Teste o acesso web e a comunicação de cada máquina separadamente: um serviço em execução não garante conexão com os dispositivos de campo.

Antes de reiniciar serviços ou alterar configurações, preserve os logs, confira o backup e combine a intervenção com a operação.


Referência: Rotina de Manutenção e Suporte Pós-Entrega, do manual do integrador.