Operações
Esta seção é sobre execução e manutenção rotineira da infraestrutura. Diferente das outras dimensões, foca em como fazer agora, não em arquitetura, requisitos ou estratégia.
Foco específico desta seção
| O que ENTRA aqui | O que NÃO entra (vai pra outra dimensão) |
|---|---|
| Runbooks de procedimentos rotineiros | Conceitos arquiteturais → Camadas |
| Lessons learned de upgrades reais | Decisões arquiteturais → ADRs |
| Rotinas de manutenção (semanal/mensal) | Política horizontal → Capacidades transversais |
| Procedimentos de emergência | Estratégia + entregas → Frentes estratégicas |
| Inventários operacionais vivos | Sequência temporal de evolução → Roadmap |
| Notas de incidentes resolvidos | |
| Calendário de manutenção |
Estrutura interna
Pra evitar concentrar tudo em uma seção genérica, runbooks específicos vivem dentro da camada relevante:
| Tipo de procedimento | Onde fica |
|---|---|
| Backup VyOS | /camadas/2-backup/backup-vyos-sp/ |
| PVE9 upgrade lessons | /camadas/0-virtualizacao/pve9-upgrade-lessons-sp/ |
| Tiers de hardware (inventário) | /camadas/0-virtualizacao/tiers-de-hardware/ |
| Hostnames públicos | /camadas/4-ingress/hostnames/ |
Esta seção /operacoes/ concentra procedimentos transversais a camadas (que envolvem várias) ou operacionais gerais (calendário, escalation, etc).
Conteúdo a popular
Calendário de manutenção
Rotinas planejadas por frequência:
- Diária: monitoramento, alertas
- Semanal: status review, drift check ArgoCD
- Mensal: upgrade kernel/PVE, validação backup, limpeza logs
- Trimestral: DR drill, security audit
- Anual: revisão capacidade hardware, LGPD audit
Procedimentos de emergência
- Falha de site (Franca ou SP)
- Falha LINSTOR controller HA
- Cilium/CNI travado (recuperação)
- Cloudflare offline (DNS fallback manual)
- Pesquisador travou GPU (cleanup)
Lessons learned cumulativos
Aprendizados de incidentes resolvidos — não viram ADR (não são decisão), mas vale registrar.
Notas de incidentes
Registro datado de incidentes: o que aconteceu, como foi diagnosticado, como foi resolvido.
Princípio “memória viva”
Todo runbook é datado e versionado. Quando situação muda, runbook é atualizado (não substituído sem registro). Histórico via git blame / git log.
Pra emergências
Antes de ir na operação, leia o runbook relevante se existir. Se não existir, escreva um depois de resolver — próximo admin agradece.
Articulação com outras dimensões
| Outra dimensão | Como se conecta com Operações |
|---|---|
| Camadas | Runbooks específicos vivem dentro da camada (ex: backup VyOS em camada 2) |
| Transversais | Política horizontal define o que; Operações documenta como executar (ex: “rotação de secrets” — política em /transversais/secrets/, runbook aqui) |
| Frentes estratégicas | Frente define entrega; Operações faz a entrega virar rotina mantida |
| Roadmap | Roadmap planeja evolução; Operações reflete como o que já está pronto é mantido |