Skip to content
CPPS Docs

Apresentação

Esta documentação reúne informações sobre a infraestrutura computacional alocada nos seguintes parceiros:

  • Centro de Pesquisa Política e Social da UNESP (CPPS/UNESP/Franca)

  • Laboratório Multiusuário do Instituto de Políticas Públicas e Relações Inernacionais da UNESP (IPPRI/UNESP/São Paulo)

  • Aspectos comuns e feitos em conjunto estão aglutinados no Colaboratório de Humanidades Digitais

Financiamento e parceiros

  • FAPESP — Fundação de Amparo à Pesquisa do Estado de São Paulo
  • CNPq — Conselho Nacional de Desenvolvimento Científico e Tecnológico
  • INCT-INEU — Instituto Nacional de Ciência e Tecnologia para Estudos sobre Estados Unidos

Objetivo da documentação

É referência operacional (pra quem opera, mantém ou desenvolve a infra) e memória institucional (registro de decisões, contexto, motivação). Foi feita pra ser lida por:

  • Admins que precisam entender e operar a stack
  • Pesquisadores que vão usar os recursos computacionais
  • Estudantes que estão aprendendo sobre infra computacional
  • Comitês institucionais (FAPESP, UNESP) que avaliam o projeto
  • Novos integrantes do Colaboratório que vão replicar o modelo

As 5 dimensões da documentação

A documentação se organiza em 5 dimensões com focos distintos e complementares. Cada uma responde uma pergunta diferente — não há sobreposição, mas há articulação.

DimensãoPergunta que respondeFoco
CamadasComo cada parte da infra funciona tecnicamente?Arquitetura técnica bottom-up
Capacidades transversaisQue requisitos atravessam todas as camadas?Requisitos horizontais de funcionamento
Frentes estratégicasQue entregas concretas articulam camadas + transversais?Entregas prioritárias por objetivo institucional
OperaçõesComo a infra é mantida e executada no dia-a-dia?Manutenção e execução rotineira
RoadmapEm que sequência tudo evolui ao longo do tempo?Evolução temporal da infraestrutura

Relação entre as 5 dimensões

                  ┌──────────────────────────────────┐
                  │       FRENTES ESTRATÉGICAS       │  ← Entregas concretas
                  │  (sites, dados, GPU, IDP, apps)  │     com objetivo institucional
                  └─────────────┬────────────────────┘
                                │ articula
                                ▼
   ┌─ CAPACIDADES TRANSVERSAIS ───────────────────────────────┐
   │  IAM, Secrets, Certs, Observabilidade, CI/CD, Supply,    │  ← Requisitos horizontais
   │  Segurança, Backup/continuidade, Governança              │     que atravessam tudo
   └─┬────────────────────────────────────────────────────────┘
     │
     ▼ (atravessa)
   ┌─ CAMADAS ───────────────────────────────────────────────┐
   │  9 Workloads | 8 Multi-cluster | 7 GitOps | ...         │  ← Arquitetura técnica
   │  ...                                                    │     bottom-up
   │  0 Virtualização (Proxmox)                              │
   └─────────────────────────────────────────────────────────┘
                                │
                  manutenção:   │   evolução:
                                ▼
        ┌─────────────────────┐   ┌─────────────────────┐
        │     OPERAÇÕES       │   │      ROADMAP        │
        │  Runbooks vivos +   │   │  Sequência temporal │
        │  rotinas + lessons  │   │  + ADRs + fases     │
        └─────────────────────┘   └─────────────────────┘

Diferenças importantes que evitam sobreposição

Camadas vs Frentes estratégicas

  • Camada 9 (workloads) descreve tecnicamente Tutor, Invenio, OJS, vLLM
  • Frente “Aplicações acadêmicas próprias” descreve a estratégia institucional dessas apps (LGPD, ciclo de vida, governança, replicação cross-site)
  • Mesma app aparece nos 2 lugares com focos diferentes — não há repetição, há articulação

Transversais vs Operações

  • Transversal “Backup e continuidade” define política (3 camadas: snapshots → PBS local → PBS cross-site)
  • Operações tem o runbook concreto (backup VyOS, restore VM, etc) — execução do que a política prevê

Frentes estratégicas vs Roadmap

  • Frentes descrevem o que entregar (data lake operacional, GPU compartilhada, IDP)
  • Roadmap descreve quando e em que sequência entregar
  • ADRs (roadmap/adrs/) registram decisões pontuais que afetam várias frentes

Operações vs Roadmap

  • Operações é rotina viva (manutenção, monitoring, incidentes do dia-a-dia)
  • Roadmap é eixo temporal evolutivo (fases, dependências, custo, prazo)

Por onde começar

PerfilCaminho sugerido
🗺️ Quero explorar visualmenteCatálogo Visual — 48 componentes em 4 visualizações interativas (pirâmide, mapa, jornada, contexto)
🆕 Novo no projetoApresentação → Contexto institucional → Fundamentos → Camadas bottom-up
🛠️ Vou operar / debugar agoraCamadas na camada relevante OU Operações pra runbooks
📚 Quero entender uma decisãoADRs — 9 registros de decisões arquiteturais
🎯 Quero saber o que vem aíRoadmap (sequência temporal) ou Frentes estratégicas (entregas)
📊 Sou avaliador FAPESP / comitêContexto institucional → Frentes estratégicas → Roadmap
🤝 Vou colaborar tecnicamenteFundamentos → Arquitetura → Camadas específica

Princípio orientador

A infraestrutura existe pra apoiar pesquisa em humanidades — não pra ser elegante. Toda decisão técnica é ancorada em propósito institucional.

Quando aparecer dúvida arquitetural, sempre voltar ao contexto institucional e perguntar: isso atende a missão CPPS + finalidade do Lab Multiusuário + compromissos FAPESP?

Outras visões gerais