Capítulo 51 — Operação e Gestão de Serviços

51.1 Objetivo do Capítulo

Este capítulo descreve o modelo operacional da Plataforma de Relacionamento Digital com o Cidadão após o go-live de cada tenant, abrangendo os processos, papéis, ferramentas e práticas que garantem disponibilidade, estabilidade, segurança e evolução contínua ao longo dos 60 meses da parceria.

A operação de uma plataforma multi-tenant de serviços públicos não se limita ao monitoramento técnico. Ela abrange: gestão de incidentes com impacto real em cidadãos, controle de mudanças que afetam múltiplos órgãos, operação de SLAs pactuados, resposta a eventos de segurança, manutenção preventiva e comunicação estruturada entre equipes e tenants.

51.2 Modelo Operacional

51.2.1 Visão Geral

A operação é exercida em camadas complementares com responsabilidades distintas:

PRODEMGE (Controladora e Proprietária da Plataforma)
    │ Governança, SLA contratual, relacionamento com órgãos
    │
Parceira Tecnológica (Operadora Técnica)
    │ Operação, sustentação, evolução e suporte N2/N3
    │
Administradores dos Tenants (Órgãos)
    │ Operação funcional, configuração, usuários, N1 de atendimento
    │
Usuários Operacionais dos Tenants
    │ Uso cotidiano dos módulos funcionais

51.2.2 Princípios Operacionais

1. Operação contínua — a plataforma opera 24/7; incidentes fora do horário comercial têm cobertura de plantão;
2. Visibilidade em tempo real — o estado da plataforma é sempre observável: Centro de Comando, dashboards e alertas cobrem todos os componentes;
3. Menor impacto possível — mudanças são planejadas para minimizar impacto em tenants; janelas de manutenção são comunicadas com antecedência;
4. Blameless — incidentes são investigados para aprender e melhorar, não para culpar;
5. Multi-tenant awareness — toda operação considera o impacto em múltiplos tenants; uma ação isolada não pode comprometer outros;
6. Rastreabilidade — toda ação operacional relevante é auditada: quem, quando, o que e com qual impacto;
7. Capacitação contínua — a equipe de operação mantém proficiência atualizada com as evoluções da plataforma.

51.3 Papéis Operacionais

51.4 Centro de Comando

O Centro de Comando é a interface operacional centralizada para a equipe da Parceira e da PRODEMGE. Ele consolida em uma única visão o estado de saúde de todos os componentes da plataforma:

51.4.1 Visão de Saúde

┌──────────────────────────────────────────────────────────────┐
│  CENTRO DE COMANDO — PLATAFORMA                               │
│                                                               │
│  Serviços de Domínio     ●●●●●●●●●●●●●●●● [24/24 OK]       │
│  API Gateway             ● [OK] — p99: 145ms                 │
│  RabbitMQ                ● [OK] — filas: 0 DLQ               │
│  Bancos Operacionais     ● [OK] — connections: 120/500       │
│  Redis                   ● [OK] — hit rate: 89%              │
│  Integrações Externas    ▲ [DEGRADED] — SEI!MG: timeout      │
│  Data Lake               ● [OK] — freshness: 8min            │
│  AI Gateway              ● [OK] — p95: 1.2s                  │
│                                                               │
│  Tenants Ativos: 12      Incidentes Abertos: 1               │
│  Alertas Ativos: 3       Último Deploy: 12h atrás            │
└──────────────────────────────────────────────────────────────┘

51.4.2 Ações Operacionais no Centro de Comando

• visualizar e navegar alertas ativos;
• acessar trilha de auditoria de operações críticas;
• reprocessar DLQs com autorização;
• ativar ou desativar kill switch de capacidade de IA;
• suspender tenant em caso de incidente de segurança;
• iniciar diagnóstico de integração específica;
• acompanhar progresso de deploys em curso.

51.5 Gestão de Incidentes

51.5.1 Classificação de Severidade

51.5.2 Ciclo de Vida do Incidente

Detecção (alerta automático ou reporte)
    │
Classificação de Severidade
    │
Notificação da equipe on-call (PagerDuty ou equivalente)
    │
Abertura de incidente com identificador único
    │
Comunicação inicial às partes afetadas
    │
Investigação e diagnóstico
    │
Ações de contenção (se possível antes da resolução)
    │
Resolução
    │
Validação de restauração
    │
Comunicação de encerramento
    │
Postmortem (SEV-1 e SEV-2 obrigatório; SEV-3 opcional)

51.5.3 Comunicação Durante o Incidente

Para SEV-1 e SEV-2, a comunicação segue cronograma predefinido:

51.5.4 War Room

Para SEV-1, o War Room é ativado imediatamente: canal de comunicação dedicado, papéis definidos (incident commander, technical lead, communication lead), acesso ao Centro de Comando e logs em tempo real.

O Incident Commander coordena; o Technical Lead executa; o Communication Lead mantém stakeholders informados. Ninguém age sem coordenação do Incident Commander.

51.5.5 Postmortem

O postmortem é um documento blameless produzido após SEV-1 e SEV-2. Contém:

• linha do tempo do incidente;
• causa raiz identificada;
• impacto: tenants afetados, duração, funcionalidades indisponíveis;
• o que funcionou bem na resposta;
• o que pode ser melhorado;
• ações preventivas com responsável e prazo.

O postmortem é revisado pela PRODEMGE e alimenta o processo de melhoria contínua.

51.6 Monitoramento e Alertas

O monitoramento é detalhado no Capítulo 41 (Observabilidade e Monitoramento). Este capítulo descreve como o monitoramento se integra à operação de serviços.

51.6.1 Alertas Acionáveis

Todo alerta em produção é acionável — tem um responsável, um runbook e uma ação esperada. Alertas sem runbook ou sem ação conhecida são revisados e eliminados do conjunto de alertas ativos (redução de alert fatigue).

Um alerta que dispara mas não demanda ação deve ter seu threshold revisto ou ser removido.

51.6.2 On-Call

A equipe de plantão (on-call) é definida em escala rotativa:

O plantão recebe o contexto do incidente anterior, o estado atual dos alertas ativos e os deploys realizados nas últimas 24 horas como parte do handover de turno.

51.6.3 Runbooks

Runbooks documentam a resposta a cenários operacionais específicos:

• Runbook: serviço de domínio com taxa de erro acima do threshold
• Runbook: fila RabbitMQ acumulando sem consumidor
• Runbook: integração SEI!MG com timeout recorrente
• Runbook: queda de disponibilidade do AI Gateway
• Runbook: Data Lake com freshness vencida
• Runbook: certificado TLS próximo ao vencimento
• Runbook: banco de dados com pool de conexão saturado
• Runbook: tentativas de acesso cross-tenant detectadas

Runbooks são testados periodicamente em exercícios de simulação.

51.7 Gestão de Mudanças

51.7.1 Categorias de Mudança

51.7.2 Change Advisory Board (CAB)

Mudanças normais são revisadas em reunião semanal do CAB, com participação de:

• Platform Operations Manager (Parceira);
• PRODEMGE Platform Officer;
• representante técnico da área afetada.

O CAB aprova, rejeita ou solicita ajustes. Mudanças aprovadas entram no backlog de deploy.

51.7.3 Comunicação de Mudanças

Para mudanças com impacto perceptível nos tenants:

51.7.4 Janelas de Manutenção

As janelas de manutenção planejadas são definidas no início de cada mês para o mês seguinte, com horários fora do pico de operação dos órgãos. Mudanças emergenciais podem ocorrer fora da janela planejada; são comunicadas com a menor antecedência viável.

51.8 Gestão de Releases

51.8.1 Cadência de Releases

51.8.2 Processo de Release

Feature concluída em branch
    │
Pull Request + Code Review + testes unitários
    │
Pipeline CI: SAST, SCA, container scanning, testes de integração
    │
Deploy em Integration
    │
Testes de integração automatizados (incluindo isolamento multi-tenant)
    │
Deploy em Homologation
    │
Validação funcional com PRODEMGE
    │
Aprovação de release
    │
Deploy em Produção (blue-green ou canary)
    │
Monitoramento da janela de deploy
    │
Rollback automático se métricas degradam
    │
Release notes publicados + materiais de capacitação atualizados

51.8.3 Release Notes

Release notes são publicados na Central de Conhecimento antes do deploy em produção. Incluem:

• versão e data;
• novas funcionalidades por módulo;
• correções de bug relevantes;
• mudanças de comportamento que podem afetar usuários;
• impacto por perfil (atendente, administrador, cidadão);
• itens a observar nos primeiros dias após o deploy.

51.9 Gestão de Capacidade

51.9.1 Monitoramento de Capacidade

A equipe de operação monitora tendências de crescimento de:

• número de tenants e usuários ativos;
• volume de solicitações, atendimentos e eventos;
• storage consumido por tenant;
• consumo de tokens de IA por capacidade;
• uso de recursos de Kubernetes (CPU, memória, pods);
• tamanho do Data Lake e taxas de ingestão.

51.9.2 Planejamento de Capacidade

Mensalmente, a equipe produz projeção de capacidade para os 3 meses seguintes. Quando a projeção indica necessidade de expansão de infraestrutura (novos nós, storage adicional, upgrades de banco), a PRODEMGE é informada com pelo menos 60 dias de antecedência para planejamento orçamentário.

51.9.3 Limites por Tenant

Limites de uso por tenant (storage, usuários, tokens de IA) são monitorados pela plataforma. Alertas são enviados ao administrador do tenant e à PRODEMGE quando o uso atinge 80% e 95% do limite. O comportamento ao atingir o limite é descrito no Capítulo 30 (Gestão Multi-Tenant).

51.10 Gestão de Configuração

A gestão de configuração é detalhada no Capítulo 58. No contexto operacional, os princípios aplicados são:

• Infrastructure as Code — toda configuração de infraestrutura é declarativa e versionada;
• Configuração em cofre de segredos — credenciais e segredos nunca em arquivos de configuração versionados;
• Imutabilidade — configurações de produção não são alteradas manualmente; toda mudança passa pelo pipeline;
• Rastreabilidade — alterações de configuração são auditadas com autor, data e motivo.

51.11 Gestão de Vulnerabilidades

51.11.1 Detecção

Vulnerabilidades são detectadas por:

• SCA no pipeline CI (dependências com CVE conhecidos);
• container scanning na build (vulnerabilidades em imagens base);
• DAST no ambiente de integração;
• monitoramento de boletins de segurança (NVD, CISA, fabricantes);
• relatos da equipe de operação e da PRODEMGE.

51.11.2 Triagem e Priorização

51.11.3 Processo de Remediação

Vulnerabilidades críticas e altas são tratadas como mudanças emergenciais: atualização da dependência ou imagem, novo build, validação no ambiente de integração, deploy em produção com monitoramento intensivo.

51.12 Gestão de Backups e Continuidade

A estratégia completa de backup e recuperação de desastre é detalhada no Capítulo 47. No contexto operacional:

• backups são executados de forma automatizada e monitorados;
• alertas detectam falha de backup antes do próximo ciclo;
• restore tests são executados mensalmente em ambiente de integração;
• o RPO e o RTO por componente são monitorados e reportados à PRODEMGE trimestralmente.

51.13 Relatórios Operacionais

51.13.1 Relatório Semanal de Operação

Produzido semanalmente pela Parceira e enviado à PRODEMGE:

• disponibilidade por serviço e por tenant na semana;
• incidentes abertos e fechados com severidade e duração;
• status dos postmortems em elaboração;
• deploys realizados com resultado;
• alertas mais frequentes (top 5);
• tendências de capacidade relevantes;
• vulnerabilidades em triagem.

51.13.2 Relatório Mensal de Desempenho

Produzido mensalmente para revisão com a PRODEMGE:

• cumprimento dos SLAs contratuais por indicador;
• incidentes do mês por severidade com análise de tendência;
• releases entregues vs. planejados;
• métricas de qualidade do código (cobertura de testes, débito técnico);
• status dos postmortems e ações preventivas;
• uso de capacidade vs. limites;
• atualizações do roadmap do próximo mês.

51.13.3 Revisão Trimestral de Operação (QBR)

Revisão trimestral com gestores da PRODEMGE e da Parceira:

• SLA acumulado do trimestre;
• análise de tendências de incidentes e capacidade;
• evolução do produto: funcionalidades entregues e próximas;
• satisfação dos órgãos (pesquisa periódica);
• riscos operacionais identificados;
• ajustes contratuais se necessário.

51.14 Comunicação Estruturada

51.14.1 Canais de Comunicação Operacional

51.14.2 Portal de Status

O Portal de Status é uma página pública que exibe:

• status atual de cada componente da plataforma (Operacional, Degradado, Indisponível);
• incidentes em andamento com atualizações em tempo real;
• histórico de incidentes dos últimos 90 dias;
• manutenções planejadas com janela e impacto esperado.

O Portal de Status é atualizado durante incidentes conforme o cronograma de comunicação definido em 51.5.3.

51.15 Operação de Integrações

51.15.1 Monitoramento de Integrações

Cada integração com sistema externo tem monitoramento específico:

• disponibilidade (circuit breaker state);
• latência média e P95 por operação;
• taxa de sucesso, falha técnica e falha de negócio;
• volume de mensagens em DLQ por integração;
• alertas quando degradação ultrapassa threshold.

51.15.2 Resposta a Degradação de Integração

Quando uma integração externa degrada:

1. circuit breaker abre automaticamente (proteção da plataforma);
2. alerta notifica a equipe de operação;
3. diagnóstico: falha na integração ou no sistema externo?
4. comunicação ao tenant afetado se o impacto é perceptível;
5. contato com o responsável pelo sistema externo (GOV.BR, PRODEMGE Infraestrutura, órgão);
6. retomada: circuit breaker testado antes de reabrir;
7. registro no relatório de operação.

51.15.3 Reprocessamento de DLQ

O reprocessamento de mensagens em DLQ é uma ação operacional controlada:

• identificar a causa raiz antes de reprocessar;
• verificar idempotência do consumer;
• reprocessar em taxa controlada (não em burst);
• monitorar resultado de cada mensagem reprocessada;
• registrar a operação em auditoria.

Reprocessamento em produção sem análise prévia é vedado.

51.16 Operação Segura

51.16.1 Acesso à Produção

O acesso à infraestrutura de produção é restrito, auditado e proporcional à necessidade:

• acesso JIT (Just-In-Time) para operações pontuais;
• credenciais temporárias com escopo limitado;
• todo acesso registrado em auditoria;
• revisão periódica de acessos com perfil operacional;
• nenhum acesso permanente de escopo amplo para uso rotineiro.

51.16.2 Separação de Ambientes

Dados de produção nunca são copiados para desenvolvimento ou homologação sem autorização e sanitização. Operações de debug em produção são feitas por logs e traces — sem acesso direto a dados de cidadãos ou tenants.

51.16.3 Eventos de Segurança

Eventos de segurança detectados (tentativa de acesso cross-tenant, anomalia de autenticação, comportamento suspeito de API) são tratados como incidentes com protocolo próprio:

• notificação imediata ao Security Operations;
• isolamento do contexto afetado (tenant ou usuário) quando necessário;
• notificação à PRODEMGE conforme a gravidade;
• registro e análise forense preservada;
• notificação ao titular/órgão quando exigida pela LGPD.

51.17 Indicadores de Operação

51.18 Rastreabilidade com o Edital

51.19 Riscos e Mitigações

51.20 ADRs

51.21 Considerações Finais

A operação de uma plataforma multi-tenant de serviços públicos é fundamentalmente diferente da operação de um sistema monolítico para um único cliente. Cada incidente tem potencial de impactar múltiplos órgãos e milhares de cidadãos simultaneamente. Cada mudança mal gerida pode afetar tenants que não estavam sequer cientes de que havia um deploy.

É exatamente por isso que os processos descritos neste capítulo — gestão estruturada de incidentes, controle de mudanças com aprovação, capacidade planejada com antecedência e comunicação proativa — não são burocracia. São os controles que permitem que a plataforma cresça em número de tenants e em volume sem crescer proporcionalmente em risco operacional.

O Capítulo 52 detalha a Sustentação e Suporte Técnico.

51.22 Controle de Versão

51.23 Rastreabilidade PRODEMGE

• [PNR] Seção 3.4.4 — Suporte Técnico e Sustentação: atendimento a incidentes, monitoramento, correção de falhas, gestão de SLA, suporte em múltiplos níveis.
• [PNR] Seção 4.1.19 — Operação como responsabilidade da Parceira com apoio e governança da PRODEMGE.
• [ANX-III] Bloco 6 — Infraestrutura, Segurança e Governança: monitoramento contínuo, gestão de incidentes, controle de mudanças, continuidade operacional.
• [ANX-V] — Sustentabilidade: postmortems blameless para melhoria contínua, runbooks testados, gestão de mudanças controlada, capacidade planejada.
• [EDITAL] — Edital CP001/2026: plataforma com modelo operacional definido, cobertura de on-call, SLAs pactuados e processos de incidente estruturados.