01
Mensal
Validar integridade dos backups, inventario de ativos criticos e aderencia do catalogo de restore.
1. Visão Operacional da Continuidade
Continuidade operacional, no contexto do AirData, deve ser tratada como uma disciplina de arquitetura aplicada. O ecossistema depende de um núcleo persistente de dados, de uma camada de orquestração, de componentes de publicação e de uma camada de IA com dependencias de GPU, o que exige prioridades claras de proteção e recomposição.
A logica recomendada e simples: restaurar primeiro o que permite recompor o restante. Isso significa tratar PostgreSQL, storage, DAGs, segredos operacionais e infraestrutura de exposição como ativos estruturantes, e não como detalhes perifericos de deploy.
Principios orientadores
- Recuperar primeiro o núcleo de dados e a capacidade de orquestração.
- Separar ativos persistentes de componentes reconstitutiveis.
- Documentar restore com a mesma seriedade dedicada ao deploy.
- Testar recovery em janela controlada, com evidência operacional.
2. Escopo de Proteção por Tipo de Ativo
Ativos persistentes
PostgreSQL
Volumes do Qdrant
Arquivos OWL
Logs e artefatos criticos
Snapshots de storage
↓
Ativos reconstitutiveis
DAGs versionadas
Configs Nginx
FastAPI / apps web
Catalogo de modelos
Portal documental
| Classe de ativo | Exemplos | Estrategia principal | Observação operacional |
|---|---|---|---|
| Dados persistentes | PostgreSQL, Qdrant, datasets operacionais | Backup recorrente, snapshot e teste de restauração | Precisam de proteção forte porque não são baratos de reconstruir. |
| Codigo e configuração | DAGs, apps, Nginx, compose, systemd | Versionamento Git e inventario de implantação | São recuperaveis desde que haja rastreabilidade de configuração. |
| Modelos e runtime | Ollama, embeddings, drivers de GPU | Provisionamento reproduzivel e catalogo documentado | O ganho esta em reduzir tempo de remontagem, não necessariamente em snapshotar tudo. |
| Publicação institucional | OntoSite, portal Next.js, páginas publicas | Build reproduzivel e pipeline de publicação controlado | Tem alto valor de acesso, mas criticidade menor que o núcleo de dados. |
3. Metas de RTO e RPO
As metas abaixo não devem ser lidas como compromisso contratual, mas como uma referência técnica inicial para priorização. Elas podem ser refinadas a medida que a equipe consolidar ambientes, rotina de carga e custo aceitavel de perda ou recomposição.
RTO prioritario
PostgreSQL e Airflow devem ter metas mais agressivas, porque sustentam o fluxo principal do ecossistema.
RPO aceitavel
A perda aceitavel deve seguir a cadencia de ingestao e o custo operacional de reprocessamento dos dados.
Leitura prática
Nem todo serviço precisa do mesmo nivel de proteção. O valor esta em diferenciar prioridades com critério.
| Serviço | RTO alvo | RPO alvo | Comentario |
|---|---|---|---|
| PostgreSQL | 2 a 4 horas | Até 24 horas (ideal < 4h dependendo do batch) | Base central. SLO Alvo: 99.9% Uptime, <50ms query de leitura na chave principal. |
| Airflow | 4 horas | Reprocessável via DAGs versionadas | SLO Alvo: 99% Uptime, tolerância máxima de 1h de atraso nas DAGs Críticas. |
| Quality Check | 8 horas | N/A (Reprocessável via API e Logs) | SLO Alvo: 90% Uptime diário, <200ms de latência HTTP P50. |
| Qdrant | 8 a 12 horas | 24 horas ou Rebuild Assistido | Impacta a camada RAG. SLO Alvo: <100ms de latência de busca vetorial. |
| Ollama | 12 horas | Instantâneo (Catálogo Estático de Modelos) | SLO Alvo: Latência de inferência <5s por token gerado. |
| OntoSite e portal documental | 24 a 48 horas | Git Commit (GitHub Actions) | SLO Alvo: Latência estática HTTP estritamente inferior a 50ms. |
4. Cronograma Recomendado de Testes de Restore
02
Trimestral
Executar restore parcial de PostgreSQL e testar retomada de DAGs prioritarias em ambiente controlado.
03
Semestral
Simular indisponibilidade de serviços da camada RAG e validar recuperação orientada por runbook.
04
Anual
Ensaiar cenario integrado de continuidade envolvendo dados, publicação e validação funcional ponta a ponta.
5. Checklist de Backup por Ativo
Dados centrais
- Backup logico do PostgreSQL executado e verificavel.
- Snapshot de volumes criticos disponivel e datado.
- Procedimento de restauração revisado e acessivel.
- Responsavel e local de retenção explicitados.
Aplicações e configuração
- DAGs, configs e apps versionados em repositorio conhecido.
- Portas, dominios e proxy documentados.
- Dependencias de deploy registradas.
- Segredos catalogados em mecanismo controlado.
IA e publicação
- Catalogo de modelos Ollama atualizado.
- Coleções do Qdrant com politica de persistencia definida.
- Pipeline da ontologia reproduzivel.
- Build do portal com rota de publicação conhecida.
6. Runbooks Prioritarios por Incidente
| Incidente | Diagnostico inicial | Ação de contenção | Recuperação minima |
|---|---|---|---|
| Falha do PostgreSQL | Inspecionar pods ou daemon (systemctl status postgres). | Redirecionar trafégo PGD-Bouncer para read-only e congelar Airflow. | Executar script `make db-restore snapshot=latest` da automação infra-as-code. |
| Interrupção do Airflow | Monitorar Redis queues, RabbitMQ e heartbeat do Airflow Scheduler. | Marcar todas as DAGs pendentes com estado 'failed' para evitar execução massiva fantasma. | Reiniciar o docker-compose, `cd ita-airdata-pipelines && docker-compose up -d`. |
| Indisponibilidade do Qdrant | Alertas de timeout (HTTP 502/504) ou porta fechada na rede overlay Docker. | Degradar a página graciosamente, mantendo o histórico de RAG apenas via cache local se aplicável. | Rodar o pipeline de carga vetorial se snapshot não disponível: `python scripts/qdrant_sync.py`. |
| Falha de GPU ou Ollama | Verificar via utilitário `nvidia-smi` se o Ollama travou o uso de VRAM bloqueando novas requisições. | Kill do processo GPU pendente: `kill -9 $(lsof -t /dev/nvidia0)`. | Recarregar o LLM instanciando o container de Inferência novamente `systemctl restart ollama`. |
| Quebra de proxy ou publicação | Checar se o Nginx está travado com conf inválida `nginx -t` e se HTTP responde HTTP 50x. | Redirecionar o IP para uma página estática de manutenção ('We are experiencing issues'). | Corrigir sintaxe no git config, dar pull (`git pull origin main`) e rodar `systemctl reload nginx`. |
7. Governança Operacional e Proximas Evoluções
Rotina minima recomendada
- Nomear lideres tecnicos por dominio de recovery.
- Registrar evidencias de testes de restauração.
- Versionar runbooks e checklists junto da documentação.
- Revisar RTO e RPO sempre que a arquitetura mudar.
Próximo ciclo de maturidade
- Amarrar esta página a um inventario real de backups e destinos.
- Vincular cada runbook aos responsaveis por sistema.
- Criar indicadores visuais de aderencia operacional.
- Evoluir para um quadro de continuidade por ambiente.