INASOFT · visão estratégica
Este questionário será respondido individualmente por Marcelo, Wellington, Hudson e Bruno. O objetivo é entender o que cada pessoa pensa sobre o projeto Inasoft antes de tomar decisões definitivas sobre produto, arquitetura, catálogo de monitores e estratégia comercial.
Este não é um teste de conhecimento. Não existem respostas certas ou erradas na maioria das perguntas.
“Não sei” não significa “sou contra”: significa só “não tenho informação suficiente para formar uma opinião”. Da mesma forma, “preciso de mais detalhes” não significa “não quero essa funcionalidade”, e sim “antes de decidir, quero entender melhor”. Essas respostas são analisadas separadamente.
As respostas são salvas sozinhas a cada alteração. Você pode sair e voltar depois com a mesma senha.
Queremos decidir juntos: o que a Inasoft deve ser, o que não deve ser, o que desenvolver primeiro, o que pode virar produto e o que é complexo demais para o início.
A Inasoft é uma proposta de plataforma de monitoramento voltada principalmente para saber se aplicações, serviços, integrações e processos realmente estão funcionando. A ideia não é simplesmente verificar se um servidor está ligado ou se CPU e memória estão sendo utilizadas.
O foco principal é responder perguntas como:
A Inasoft pretende transformar essas informações em monitoramento, eventos, incidentes, evidências, histórico, indicadores, relatórios, SLA e informações úteis para tomada de decisão.
A ideia é não criar simplesmente “mais uma ferramenta de monitoramento”. Ferramentas tradicionais normalmente são muito fortes em CPU, memória, disco, processos, servidores, SNMP, métricas de infraestrutura, bancos de dados e disponibilidade básica. A Inasoft pode utilizar algumas dessas capacidades futuramente, mas o foco inicial é diferente: monitorar aquilo que realmente importa para o negócio.
“O servidor está funcionando?” é diferente de “O sistema que roda nesse servidor está permitindo que o usuário conclua a operação X?”
“A internet está funcionando?” é diferente de “Este cliente consegue acessar a SEFAZ neste momento?”
“A aplicação está online?” é diferente de “Um usuário consegue entrar, acessar determinada tela e executar uma operação importante?”
A proposta é aproximar o monitoramento da experiência real do serviço.
URL pública, HTTPS, API pública, DNS, serviços externos, disponibilidade de endpoints, tempo de resposta.
Quando for necessário executar o teste de dentro da infraestrutura do cliente: acessar recursos internos, testar serviços internos, executar comandos, testar comunicação, verificar integrações, realizar testes que não podem ser feitos externamente.
Um agente pode executar testes específicos dentro do ambiente do cliente. A ideia é que ele seja reutilizável e configurável, evitando criar um programa diferente para cada cliente.
Alguns monitores podem exigir integração com Oracle, APEX, banco de dados, ORDS, procedimentos, consultas ou operações específicas. A intenção é avaliar quando isso realmente agrega valor e quando a instalação dentro do banco deve ser evitada.
Tecnologias como Playwright ou Selenium permitem simular um usuário real: abrir a aplicação, realizar login, acessar determinada tela, preencher informações, executar uma operação, validar o resultado e registrar tempo e resultado. Esse tipo de monitor fica muito mais próximo de um teste funcional real.
A Inasoft também poderá possuir agentes físicos. Exemplo inicial: ESP32 + PZEM-004T para monitoramento de energia (tensão, corrente, potência, energia, frequência, fator de potência, interrupções e retorno de energia). Outros sensores e equipamentos poderão ser utilizados futuramente.
Sempre que possível, a comunicação deve ser iniciada pelo cliente em direção à Inasoft. A Inasoft não deve depender de abrir portas de entrada no firewall do cliente. Isso facilita implantação e segurança.
CLIENTE | | HTTPS v INASOFT
INASOFT | | conexão de entrada v CLIENTE
À esquerda, o desenho pretendido; à direita, o que se quer evitar.
A arquitetura prevê que os agentes enviem eventos para a Inasoft. Cada evento deverá possuir identificadores que permitam rastrear exatamente o que aconteceu: client_id, agent_id, monitor_id e event_id. O event_id é obrigatório: permite evitar duplicidade e controlar eventos.
{
"client_id": "cliente-001",
"agent_id": "agent-001",
"monitor_id": "monitor-001",
"event_id": "evt-000001",
"event_type": "transaction_result",
"created_at": "2026-10-06T10:00:00-03:00",
"payload": {}
}
O conteúdo de payload poderá variar conforme o tipo de monitor.
Uma preocupação importante é não perder informações caso o cliente fique sem Internet, o servidor da Inasoft fique temporariamente indisponível ou exista uma falha de comunicação.
MONITOR ↓ EVENTO ↓ SALVAR LOCALMENTE ↓ TENTAR ENVIAR ↓ ACK DA INASOFT ↓ MARCAR COMO ENTREGUE
EVENTO ↓ FICA ARMAZENADO ↓ TENTA NOVAMENTE ↓ COMUNICAÇÃO VOLTA ↓ ENVIA BACKLOG
Para eventos importantes, a intenção é manter retenção local mínima de aproximadamente 24 horas no primeiro desenho do ESP32. Heartbeat muito frequente não necessariamente precisa ser gravado em flash a cada ocorrência, para evitar desgaste desnecessário da memória.
O primeiro hardware considerado é ESP32 NodeMCU, PZEM-004T V4.0, módulo relé e acessórios de conexão. O primeiro objetivo é utilizar o ESP32 como agente de monitoramento. O firmware deve ser genérico e reutilizável: não queremos um firmware diferente para cada cliente.
PZEM → ESP32 → EVENT ENGINE → FILA LOCAL → HTTPS → INASOFT
A ideia é que o cliente consiga configurar o equipamento de maneira simples. No primeiro uso:
ESP32 ↓ Cria Wi-Fi temporário ↓ Cliente conecta pelo celular ↓ Portal de configuração ↓ Informa Wi-Fi ↓ ESP32 conecta na rede do cliente ↓ Registra na Inasoft ↓ Começa a monitorar
Também deve existir possibilidade de reconfiguração posterior sem precisar gravar firmware novamente.
No futuro, o agente deverá poder receber atualizações de firmware remotamente: atualização de firmware, controle de versão, rollout, auditoria e rollback quando suportado. A intenção é evitar que cada atualização exija acesso físico ao equipamento.
O ESP32 poderá enviar evento de boot, heartbeat, uptime, motivo do reset, versão do firmware e identificador do boot. Isso permite detectar situações como:
Heartbeat 22:20:15 uptime = 115s ↓ aproximadamente 20 segundos depois Heartbeat 22:20:35 uptime = 10s
Isso indica que houve uma reinicialização entre os dois eventos. O motivo do reset também poderá ajudar a classificar: power-on, software reset, watchdog, brownout, panic, outros.
Sem uma fonte de energia independente, não devemos afirmar com certeza absoluta que toda ausência de comunicação foi causada por falta de energia. Devemos trabalhar com evidências e correlação.
Podemos ter o teste do cliente até a SEFAZ e, ao mesmo tempo, um teste de referência da Inasoft até a SEFAZ:
| Cliente | Inasoft | Leitura provável |
|---|---|---|
| OK | OK | Provavelmente o serviço externo está funcionando. |
| FAIL | OK | Pode indicar problema no ambiente ou na comunicação do cliente. |
| OK | FAIL | Pode indicar problema específico no ponto de referência da Inasoft. |
| FAIL | FAIL | Aumenta a probabilidade de problema na dependência externa. |
Isso é uma correlação. Não significa que a Inasoft possa afirmar com 100% de certeza a origem do problema em todos os casos. Quanto mais pontos de referência e histórico existirem, melhor poderá ser a análise.
Um dos possíveis produtos da Inasoft é fornecer evidência de SLA. Exemplo:
Serviço: Sistema X Disponibilidade: 99,92% Interrupções: 3 Tempo total indisponível: 34m12s Maior interrupção: 21m03s Última interrupção: 06/10/2026 08:42
O relatório poderá incluir disponibilidade, indisponibilidade, duração e quantidade dos incidentes, maior interrupção, latência, percentis, dependências, evidências, janelas de manutenção e histórico. A ideia é que possa ser apresentado inclusive a terceiros.
Depois que os quatro responderem, as respostas serão consolidadas pergunta a pergunta, identificando consenso, maioria, divergência, ausência de opinião, necessidade de mais informações, respostas com baixa confiança, ideias novas e possíveis oportunidades.
Não vamos decidir apenas pela maioria. Uma resposta diferente das outras não será simplesmente descartada: pode significar que a pessoa conhece um risco que os outros não conhecem, tem uma experiência diferente, que a pergunta não estava clara, que falta informação ou que existe uma oportunidade não percebida pelos demais. O objetivo é encontrar o melhor caminho para o projeto, não contar votos.
O projeto terá um Catálogo Oficial de Monitores Inasoft, construído depois a partir das ideias e respostas do grupo. Cada tipo de monitor será classificado conforme:
| Característica | Classificação |
|---|---|
| Pode funcionar sem instalação? | Sim / Não / Depende |
| Precisa de agente Linux/Windows? | Sim / Não / Depende |
| Precisa de ESP32? | Sim / Não / Depende |
| Precisa de navegador automatizado? | Sim / Não / Depende |
| Precisa instalar algo no Oracle/DB? | Sim / Não / Depende |
| Precisa de hardware específico? | Sim / Não / Depende |
| Pode funcionar externamente? | Sim / Não / Depende |
| Pode ser padronizado? | Sim / Não / Depende |
| Pode ser reutilizado em outros clientes? | Sim / Não / Depende |
| Potencial comercial | Baixo / Médio / Alto |
| Complexidade | Baixa / Média / Alta |
| Prioridade | Baixa / Média / Alta |
| Deve fazer parte do catálogo oficial? | Sim / Não / Avaliar |
| Deve ser projeto personalizado? | Sim / Não / Avaliar |
| Parece tecnicamente inviável? | Sim / Não / Avaliar |
Depois da análise será criada a matriz final de decisão (interesse do grupo, complexidade, instalação, agente, ESP32, navegador, banco, potencial comercial e prioridade por monitor), usada para definir o catálogo oficial e o roadmap de desenvolvimento.
A Inasoft não deve tentar monitorar tudo simplesmente porque tecnicamente é possível. A pergunta principal deve ser:
“Isso resolve um problema real, pode ser reutilizado, pode ser vendido e conseguimos entregar de forma confiável?”
O objetivo deste questionário é justamente ajudar o grupo a separar essas situações.
Concluir só avisa que você terminou. Dá para reabrir e ajustar as respostas depois.
Legenda: A–D alternativas · N não tenho opinião · S não sei · M preciso de mais detalhes · O outra ideia · ▾ baixa confiança. O consenso considera só quem marcou alguma alternativa de A a D; uma resposta diferente das outras não deve ser descartada só por ser minoria.