Plataforma de analytics concebida para transformar eventos operacionais de conectividade em indicadores rastreáveis de disponibilidade, SLA, incidentes, reincidência e desempenho por operadora e unidade.
Planilhas, ITSM, monitoramento e controles manuais fragmentam o histórico e dificultam transformar eventos em decisão operacional.
Sem uma camada analítica comum, perguntas simples exigem consolidação manual: onde a indisponibilidade se concentra, quais links reincidem, qual operadora acumula maior impacto e quanto tempo a operação leva para restaurar o serviço.
O projeto organiza ingestão, validação, normalização, métricas e datasets de apresentação antes de construir a interface. O dashboard consome saídas processadas e não redefine silenciosamente os KPIs no navegador.
O escopo foi limitado a perguntas operacionais verificáveis, sem machine learning, tempo real ou infraestrutura distribuída prematura.
Python e Pandas calculam os KPIs e geram contratos JSON/CSV versionados; o React consome esses artefatos sem recalcular métricas críticas. A publicação Cloudflare continua fora do estado atual.
O MVP usa dados sintéticos e reproduzíveis. Nenhum dado corporativo, pessoal ou identificador operacional sensível deve entrar no repositório público.
Regras como downtime, MTTR, disponibilidade e recorrência pertencem à camada analítica. A interface apresenta, filtra e explica — não altera a definição das métricas.
Workers, D1 ou outro backend em runtime só entram se volume, atualização frequente, autenticação ou consultas server-side justificarem a mudança.
As Sprints 0, 1 e 2 estão na branch principal. A Sprint 3 está implementada em branch dedicada, passou no CI e aguarda homologação visual e autorização de merge.
Contrato versionado, gerador sintético, normalização determinística, rejeição de duplicidades e inconsistências temporais, relatório de qualidade e cálculo de disponibilidade sem dupla contagem.
Visão geral, rankings por operadora, unidade e causa, timeline, detalhe serializável e seis artefatos JSON/CSV reconciliados. A disponibilidade usa site-time com união de intervalos sobrepostos.
Cards executivos, evolução temporal, rankings, filtros de detalhe, tabela de incidentes e estados loading, error e empty, com responsividade e sem mover KPIs críticos para o navegador.
O modelo mínimo combina identificação técnica, dimensão operacional, tempo, causa e origem do registro.
| Grupo | Campos | Regra principal |
|---|---|---|
| Identidade | incident_id, site_id | ID técnico único e site anonimizado. |
| Operação | carrier, status, cause_category | Dimensões normalizadas e status controlado. |
| Tempo | opened_at, restored_at | Resolvidos exigem restauração posterior à abertura. |
| Segmentação | region, link_type | Permite análise geográfica e tecnológica. |
| Rastreabilidade | source | Origem explícita; dataset público identificado como sintético. |
O projeto adota uma ordem explícita para reduzir decisões invisíveis e impedir que uma demo visual seja confundida com produto homologado.
O ambiente foi criado, mas integração, build reproduzível, URL pública, smoke test e rollback ainda precisam ser validados. O deploy só pertence à Sprint 5 e exige autorização explícita.
O avanço depende de qualidade e evidência, não apenas de calendário.
O case reúne definição do problema, arquitetura, contrato de dados, pipeline, metodologia de KPIs, frontend e governança de entrega. Essa combinação conecta experiência operacional de NOC com construção de produto analítico.
O MVP só será concluído quando pipeline, fórmulas, testes, contratos, build, segurança, documentação e homologação pública puderem ser verificados a partir do repositório.
O estado atual comprova pipeline de dados, regras de qualidade, métricas documentadas, contratos de apresentação e dashboard React buildável. O próximo gate é a homologação humana da Sprint 3; deploy público, auditoria UX aprofundada e hardening permanecem fora desta entrega.