Quando contexto, decisões e atualizações de um incidente ficam distribuídos em múltiplos canais, cresce o risco de retrabalho, perda de histórico, duplicidade de ação e falhas de comunicação entre equipes. O NOC Flow Cloud nasceu para transformar esse cenário em uma única fonte operacional de verdade, mantendo incidente, timeline, ator e contexto ligados ao mesmo fluxo.
← Voltar ao portfólio
Case · Operations + Software Engineering
NOC Flow Cloud
Plataforma full-stack multi-tenant criada para transformar operações fragmentadas de NOC em um fluxo centralizado, rastreável e protegido por controles de identidade e autorização server-side.
Release atualv0.4.0-beta
Sprint 4Homologada para demo privada
Sprint 5Em revisão
Produção públicaNão disponível
53testes backend
24testes frontend
95%cobertura backend
0vulnerabilidades conhecidas nos audits
Baseline medida no CI do PR #61 em 25/09/2026. Os números descrevem essa execução e não uma promessa de produção.
01 · Contexto
O problema não era falta de ferramenta. Era fragmentação.
Em um NOC, informação operacional pode se espalhar entre monitoramento, ITSM, planilhas, chats e registros de passagem de turno.
02 · Arquitetura & trade-offs
Decisões feitas para consistência, segurança e evolução.
Cada escolha técnica resolve um problema específico do domínio, em vez de existir apenas para aumentar a stack.
FastAPI
Contratos HTTP claros
FastAPI foi adotado para manter validação com Pydantic, documentação OpenAPI integrada e uma camada HTTP fina. A aplicação separa apresentação, aplicação, domínio e infraestrutura para evitar regras de negócio espalhadas nas rotas.
PostgreSQL
Estado + histórico
PostgreSQL, SQLAlchemy e Alembic sustentam persistência transacional e migrations reproduzíveis. O estado corrente do incidente é separado de sua timeline de eventos, preservando rastreabilidade operacional.
Multi-tenancy
Tenant definido no servidor
O modelo usa banco e schema compartilhados com tenant_id explícito. O cliente não escolhe livremente o tenant que deseja consultar: o escopo vem do contexto autenticado e é aplicado server-side.
Docker + CI
Ambiente reproduzível
Frontend, API e PostgreSQL executam via Docker Compose. O CI valida backend, frontend, migrations, testes, audits de dependências e smoke tests da stack integrada.
| Decisão | Benefício | Custo aceito |
|---|---|---|
| Monólito modular | Deploy e debugging simples no estágio atual | Módulos não escalam de forma independente |
| Schema compartilhado | Menor custo e operação mais simples | Tenant scoping precisa ser obrigatório em todos os acessos |
| RBAC no banco | Autorização interna e auditável | Memberships exigem ciclo de vida próprio |
| Timeline append-only | Preserva a trilha operacional | Correções exigem novo evento |
| Cloudflare Access | Protege a demo antes da aplicação | Adiciona dependência externa e homologação real de sessão |
03 · Segurança
OIDC autentica. O banco autoriza.
A identidade externa comprova quem é o usuário; a autorização final permanece sob controle da aplicação.
OIDC / JWT
Identidade validada criptograficamente
O backend valida assinatura via JWKS, issuer, audience, expiração e subject. A demo privada também pode operar atrás de Cloudflare Access.
RBAC server-side
Roles não são confiadas ao token
Após autenticar a identidade, o backend consulta users e tenant_memberships para resolver a role interna. As permissões são derivadas dessa membership, reduzindo a superfície para escalada de privilégio.
Fluxo de autorização
Token externo
OIDC / Cloudflare Access
→OIDC / Cloudflare Access
Validação
JWKS · iss · aud · exp · sub
→JWKS · iss · aud · exp · sub
Membership interna
user + tenant + role
→user + tenant + role
Permissions
RBAC server-side
→RBAC server-side
Recurso
tenant-scoped
tenant-scoped
Roles atuais
Quatro perfis
Admin, Supervisor, Operator e Viewer. O Viewer permanece somente leitura; operações de escrita dependem de permissões explícitas como incident:create, incident:update e incident:normalize.
Testes de segurança
Cenários negativos também contam
A suíte cobre token expirado, tenant inválido, membership ausente ou inativa, tentativa de acesso cross-tenant e negação de escrita para perfil sem permissão.
04 · Execução
Incidente e timeline como fontes complementares.
O estado atual responde “como está agora”; a timeline responde “como chegamos aqui”.
Modelo operacional
Timeline append-only
Criação, atualização e normalização geram eventos cronológicos. O fluxo HTTP suportado não possui endpoints para editar ou apagar eventos já registrados, preservando a trilha operacional.
Autoridade do backend
Metadados críticos não vêm do cliente
tenant_id, ator, identificadores e timestamps são definidos ou resolvidos pelo servidor. Isso reduz inconsistências e impede que o frontend se torne fonte de autoridade para campos sensíveis.
01AlertaEvento ou indisponibilidade detectada
02TriagemContexto, impacto e evidências
03AcionamentoOperadora, contato e protocolo
04AcompanhamentoAtualizações e timeline
05NormalizaçãoValidação e registro do resultado
Produto demonstrativo
Telas do fluxo operacional.
Mockups de portfólio baseados no conceito do produto. Todos os nomes, IDs, lojas, operadoras, métricas e contatos exibidos são sintéticos.
Arquitetura atual
Separação de responsabilidades
Angular
Interface
→Interface
FastAPI
API / contratos
→API / contratos
Application + Domain
Regras
→Regras
Repository
Persistência
→Persistência
PostgreSQL
SQLAlchemy + Alembic
SQLAlchemy + Alembic
Integrações planejadas
Ecossistema do NOC
Zabbix, notificações e plataformas ITSM permanecem no backlog pós-v1.0. Não são apresentadas como funcionalidades da release atual.
05 · Evidências
Cada afirmação aponta para uma prova verificável.
“Implementado”, “em revisão” e “planejado” são estados diferentes. O case mantém essa separação explicitamente.
| Capacidade | Estado | Evidência |
|---|---|---|
| PostgreSQL e Alembic | Implementado | Migrations e job PostgreSQL do CI |
| Docker Compose | Implementado | Smoke Nginx → FastAPI → PostgreSQL |
| OIDC/JWT e RBAC | Implementado | Testes de token, memberships e permissões |
| Isolamento multi-tenant | Implementado | Cenários negativos cross-tenant |
| Dashboard e handover | Homologado | Sprint 4 Functional Smoke + homologação v0.4.0-beta |
| Auditoria e logging estruturado | Em revisão | PRs #59 e #60; ainda fora da baseline da main |
| Azure e Application Insights | Planejado | Roadmap da Sprint 6 |
| Zabbix, WhatsApp e ITSM | Backlog | Backlog pós-v1.0 |
Limites atuais
O que ainda não é entrega.
- Produção pública e deploy Azure ainda não foram homologados.
- Métricas, tracing e Application Insights permanecem em evolução.
- Não existe benchmark para declarar tenants, concorrência ou incidentes por dia.
- As imagens públicas usam dados sintéticos e não representam ambiente corporativo real.
Decisões que eu mudaria hoje
Evolução técnica consciente.
- Mediria cobertura desde a primeira sprint.
- Introduziria OpenTelemetry mais cedo, mantendo o domínio vendor-neutral.
- Manteria o E2E da autenticação protegida como gate externo explícito.
- Avaliaria PostgreSQL RLS como defesa adicional, sem substituir o tenant scoping da aplicação.
Minha atuação
Do problema à homologação.
Conduzi levantamento do problema operacional, requisitos, backlog, arquitetura, modelagem, contratos, implementação, segurança, estratégia de testes, CI, documentação e gates de homologação.
Ferramentas de IA apoiaram implementação e revisão; requisitos, decisões, validações e responsabilidade técnica permaneceram sob condução humana.
Regra de comunicação
Sem maquiagem de roadmap.
Uma capacidade só aparece como entregue quando existe na baseline aplicável, possui teste ou evidência correspondente e está documentada de forma coerente. PR aberto permanece “em revisão”; intenção permanece “planejada”.
06 · Estado atual & próximos passos
Sprint 4 homologada; Sprint 5 em revisão.
A release v0.4.0-beta cobre incidentes, timeline, dashboard, passagem de turno versionada, PostgreSQL com migrations, Docker Compose, testes automatizados, OIDC/JWT, Cloudflare Access, RBAC server-side e isolamento multi-tenant. Auditoria e observabilidade estão em revisão; Azure e integrações permanecem no roadmap.
O objetivo da arquitetura não é prometer alta disponibilidade antes da hora, mas criar uma base que possa evoluir com segurança sem reescrever o domínio.
Ver implementação no GitHub ↗