Capítulo 52 — Sustentação e Suporte Técnico

52.1 Objetivo do Capítulo

Este capítulo descreve o modelo de sustentação e suporte técnico da plataforma ao longo do ciclo de vida da parceria. O suporte técnico não é uma camada acessória — é o mecanismo pelo qual a plataforma mantém sua qualidade operacional, corrige desvios, absorve demandas e evolui de forma controlada após a implantação inicial de cada tenant.

A sustentação cobre quatro modalidades distintas e complementares: manutenção corretiva (falhas e incidentes), manutenção preventiva (degradação antecipada), manutenção adaptativa (adequações a mudanças externas) e manutenção evolutiva (melhorias funcionais e técnicas). O suporte técnico estrutura o atendimento a chamados, a triagem de incidentes, a escalação entre níveis e a comunicação com os órgãos participantes.

A relação entre o Capítulo 51 (Operação e Gestão de Serviços), o Capítulo 52 (Sustentação e Suporte Técnico) e o Capítulo 53 (SLA — Acordos de Nível de Serviço) é deliberada: a operação produz os dados que alimentam o suporte; o suporte executa as ações que protegem os SLAs; os SLAs formalizam os compromissos que estruturam toda a cadeia.

52.2 Princípios da Sustentação

A sustentação da plataforma é orientada pelos seguintes princípios:

Resolução na origem. Cada nível de suporte tem competência e autonomia para resolver o que pode resolver. Escalações desnecessárias aumentam tempo de resposta e diluem responsabilidade — cada escalação deve ser justificada.

Rastreabilidade completa. Toda solicitação, incidente, decisão de encaminhamento e ação corretiva é registrada. O histórico do chamado é o contrato implícito com o órgão participante.

Separação entre sintoma e causa. O suporte não encerra um chamado ao remover o sintoma; a causa raiz é documentada e a correção definitiva é planejada. Workarounds temporários são registrados como débito técnico ativo com prazo de resolução.

Contexto multi-tenant preservado. Qualquer ação de suporte em nível de infraestrutura ou plataforma é avaliada quanto ao impacto sobre outros tenants. Mudanças cirúrgicas isolam o efeito ao tenant afetado sempre que possível.

Comunicação proativa. O órgão participante é notificado antes da janela de impacto, durante o incidente com atualizações periódicas, e após a resolução com relatório de causa e medidas adotadas.

52.3 Estrutura de Níveis de Suporte

O suporte é organizado em três níveis com competências, canais e SLAs distintos. A PRODEMGE opera o N1 junto aos órgãos; a parceira tecnológica opera os níveis N2 e N3.

52.3.1 N1 — Suporte de Primeiro Nível

Operado pela PRODEMGE como ponto de contato primário dos órgãos participantes. O N1 é a frente de atendimento: recebe chamados, classifica, trata os casos resolvíveis com base em procedimentos operacionais padronizados e encaminha ao N2 os que extrapolam sua competência.

Competências do N1:

• recepção e registro de chamados por canal (portal, e-mail, telefone);
• triagem e classificação por tipo (incidente, solicitação, dúvida, melhoria);
• atribuição de prioridade inicial conforme critérios do SLA vigente;
• resolução de casos de uso operacional (redefinição de senha, ajuste de permissão, configuração de parâmetro tenant, dúvidas funcionais);
• comunicação com o órgão durante o atendimento;
• escalação documentada ao N2 quando o caso requer diagnóstico técnico da plataforma.

O N1 não executa alterações em código, banco de dados de produção, configurações de infraestrutura ou integrações externas. Sua atuação é restrita ao contexto operacional do tenant.

52.3.2 N2 — Suporte de Segundo Nível

Operado pela equipe técnica da parceira com especialização funcional e de integração. O N2 trata incidentes que exigem diagnóstico técnico dentro da camada de aplicação: análise de logs de serviço, verificação de comportamento de APIs, diagnóstico de falhas em integrações, análise de fluxos BPM com erro, problemas de configuração de tenant que não estão expostos na interface administrativa.

Competências do N2:

• diagnóstico técnico de incidentes de aplicação;
• análise de logs estruturados por tenant e por serviço via Kibana/Loki;
• investigação de falhas em fluxos de mensageria (filas, DLQ, reprocessamento);
• verificação e correção de configurações de tenant em base de dados quando não acessíveis via admin;
• diagnóstico de falhas em integrações com sistemas externos (SEI!MG, GOV.BR, outros);
• aplicação de patches de configuração sem alteração de código;
• coordenação com N3 quando o incidente aponta para falha de componente da plataforma.

O N2 tem acesso a ambientes de produção em modo somente leitura para diagnóstico, e acesso de escrita restrito a operações pré-aprovadas com registro de auditoria. Nenhuma alteração não planejada é executada sem aprovação registrada.

52.3.3 N3 — Suporte de Terceiro Nível

Operado por engenheiros de plataforma da parceira com acesso ao código-fonte, à arquitetura de dados e à infraestrutura de produção. O N3 atua em falhas que exigem correção de código, redesign de configuração de infraestrutura, ajuste de schema de banco ou intervenção em componentes críticos da plataforma.

Competências do N3:

• diagnóstico e correção de bugs em código de produção;
• análise de falhas de desempenho com impacto em múltiplos tenants;
• intervenção direta em banco de dados de produção (sob procedimento aprovado);
• rollback de versão quando o deploy corrente apresenta regressão;
• análise de causa raiz de incidentes críticos com RCA documentado;
• coordenação com fornecedores de infraestrutura (cloud provider, provedor de observabilidade) quando o incidente está fora da camada de aplicação.

O N3 é o nível de resolução definitiva. Toda correção implementada no N3 origina uma entrada no backlog de manutenção com a correção permanente e o prazo para deploy em produção.

52.4 Tipos de Manutenção

52.4.1 Manutenção Corretiva

Corrige falhas identificadas em produção que causam comportamento divergente do especificado. A manutenção corretiva é acionada por incidente registrado no sistema de gestão de chamados ou detectada proativamente pelo monitoramento antes de impacto ao usuário.

A classificação de severidade determina o SLA de resposta e resolução:

Incidentes S1 ativam o processo de gestão de crise: notificação imediata à PRODEMGE e ao órgão afetado, ativação do engenheiro de plantão (on-call), status page atualizado a cada 30 minutos, e RCA entregue em até 24 horas após resolução.

52.4.2 Manutenção Preventiva

Atua antes que a falha ocorra, com base em análise de tendências de observabilidade, alerts de capacidade, resultado de testes de carga periódicos e revisão técnica programada de componentes críticos.

Ações preventivas típicas incluem:

• limpeza e reindexação de bases de dados com crescimento acima do esperado;
• rotação preventiva de credenciais próximas do vencimento;
• atualização de bibliotecas com vulnerabilidades identificadas antes de exploração;
• substituição de componentes de infraestrutura próximos do fim de suporte;
• ajuste de limites de auto-scaling com base em projeção de crescimento.

A manutenção preventiva é planejada em janelas de manutenção pré-acordadas com os tenants afetados, preferencialmente em horários de baixo volume, com notificação mínima de 48 horas de antecedência.

52.4.3 Manutenção Adaptativa

Adequa a plataforma a mudanças externas: alterações em APIs de sistemas integrados, mudanças em requisitos regulatórios (LGPD, normas de acessibilidade, diretrizes do governo digital), atualizações de protocolo de autenticação GOV.BR, ou alterações nos sistemas de referência dos órgãos parceiros.

A manutenção adaptativa não é acionada por falha — é acionada por mudança no ambiente. Por isso exige planejamento com antecedência: quando uma API externa anuncia descontinuação de versão ou um órgão comunica mudança em sistema legado, a adaptação é incluída no planejamento de sprint com prazo suficiente para implementação e teste antes do corte.

52.4.4 Manutenção Evolutiva

Incorpora melhorias funcionais e técnicas na plataforma: novas funcionalidades solicitadas pelos tenants, ajustes de UX identificados em pesquisas de satisfação, refatorações técnicas para redução de débito, atualizações de componentes de terceiros para versões com melhorias significativas.

A manutenção evolutiva é governada pelo backlog compartilhado entre PRODEMGE e parceira, priorizado por valor de negócio, esforço técnico e impacto em múltiplos tenants. O Capítulo 55 (Gestão da Evolução da Plataforma) detalha o processo de priorização e entrega evolutiva.

52.5 Canais de Suporte

52.5.1 Portal de Atendimento

O canal primário de abertura de chamados é o portal de atendimento, acessível a usuários com perfil administrativo de cada tenant. O portal permite:

• abertura de chamado com formulário estruturado por tipo (incidente, solicitação, dúvida);
• upload de evidências (prints, logs exportados, arquivos de configuração);
• acompanhamento do status em tempo real;
• histórico completo de chamados do tenant;
• notificações automáticas a cada transição de status;
• avaliação do atendimento após resolução.

O portal é integrado ao sistema interno de gestão de chamados da parceira via API, garantindo rastreabilidade bidirecional sem esforço manual de transferência.

52.5.2 E-mail

Canal alternativo para casos em que o portal está indisponível ou para comunicações formais. E-mails recebidos são convertidos automaticamente em chamados no sistema de gestão com prioridade normal, salvo quando a linha de assunto contém indicação de emergência — nesse caso o chamado é criado com severidade provisória S1 e um humano confirma a classificação em até 15 minutos.

52.5.3 Linha de Emergência (24×7)

Para incidentes de severidade S1, o órgão participante dispõe de número telefônico direto para ativação do plantão (on-call). A linha de emergência não substitui a abertura de chamado — o engenheiro que atende cria o chamado durante ou imediatamente após a chamada.

A linha de emergência é restrita a representantes técnicos dos órgãos com perfil previamente cadastrado. Chamadas de usuários finais do cidadão são redirecionadas ao suporte funcional do tenant.

52.6 Fluxo de Atendimento

Abertura do chamado (portal / e-mail / emergência)
        │
Classificação automática por tipo e severidade (N1)
        │
        ├─ Dúvida ou solicitação operacional → N1 resolve
        │
        ├─ Incidente S3/S4 → N1 investiga com base em procedimento
        │       │
        │       └─ N1 não resolve → Escalação documentada ao N2
        │
        ├─ Incidente S2 → Abertura direta ao N2 com notificação ao N1
        │
        └─ Incidente S1 → Abertura imediata ao N2 + ativação do N3 + notificação PRODEMGE
                │
                ├─ N2 resolve → Resolução com RCA simplificado
                │
                └─ N2 não resolve em 30 min → Escalação obrigatória ao N3
                        │
                        ├─ N3 resolve → RCA completo em 24h
                        │
                        └─ Falha em infraestrutura externa → Acionamento do fornecedor + comunicação ao tenant

Cada transição de nível é registrada no chamado com: responsável, data/hora, diagnóstico parcial e justificativa da escalação. O chamado nunca fica sem dono.

52.7 Gestão de Chamados

52.7.1 Sistema de Gestão

Os chamados são gerenciados em sistema dedicado com integração ao portal de atendimento, ao sistema de observabilidade (alertas que geram chamados automaticamente), e ao backlog de desenvolvimento (chamados de manutenção evolutiva promovidos para sprint).

Campos obrigatórios por chamado:

52.7.2 Ciclo de Vida do Chamado

ABERTO
    │
EM ATENDIMENTO (atribuído a nível)
    │
    ├─ AGUARDANDO RESPOSTA DO TENANT (quando complementação é necessária)
    │       │
    │       └─ Timeout → encerramento com nota após período configurado
    │
RESOLVIDO (solução aplicada e validada)
    │
    └─ ENCERRADO (confirmado pelo tenant ou após período de confirmação automática)

Chamados encerrados não podem ser reabertos. Se o problema recorre, um novo chamado é aberto com referência ao anterior. Isso preserva a integridade do histórico e evita que métricas de tempo de resolução sejam distorcidas por reabertura.

52.7.3 Priorização de Fila

A fila de chamados é processada por combinação de severidade e tempo de espera. Chamados S1 têm fila dedicada e processamento imediato. Chamados S2 têm SLA de primeira resposta de 2 horas. Chamados S3 e S4 seguem fila normal com priorização por tempo de espera acumulado — um S4 aguardando mais de 5 dias sobe automaticamente de prioridade.

52.8 Plantão Operacional (On-Call)

52.8.1 Estrutura de Plantão

O plantão cobre 24 horas por dia, 7 dias por semana, 365 dias por ano. A escala é semanal com cobertura por engenheiro de plantão primário e engenheiro de escalonamento (backup). As semanas de plantão são rotativas entre a equipe de engenharia de plataforma.

O engenheiro de plantão primário tem obrigação de resposta em até 15 minutos para alertas S1 (via PagerDuty ou equivalente — SMS + push + ligação em sequência até confirmação de recebimento). O escalonamento assume automaticamente se o primário não confirma recebimento em 15 minutos.

52.8.2 Responsabilidades do Plantão

O engenheiro de plantão não é apenas receptor de alertas — é responsável por:

• confirmar o alerta e avaliar se é falso positivo ou incidente real;
• abrir ou vincular o chamado ao alerta no sistema de gestão;
• executar diagnóstico inicial seguindo o runbook do incidente;
• comunicar ao N1 e à PRODEMGE quando o impacto for confirmado;
• escalar ao N3 ou ao engenheiro especialista quando o diagnóstico aponta para componente específico;
• atualizar o status da plataforma (status page) a cada 30 minutos durante incidente ativo;
• documentar o timeline do incidente para o RCA.

52.8.3 Runbooks

Cada categoria de incidente tem runbook documentado e testado. O runbook não substitui o julgamento do engenheiro — é o ponto de partida para diagnóstico estruturado em situações de pressão.

Estrutura de um runbook de incidente:

RUNBOOK: [Nome do cenário]
Severidade típica: [S1/S2/S3]
Módulos afetados: [lista]
Sintomas identificadores: [como reconhecer]

DIAGNÓSTICO
  Passo 1: [verificação]
  Passo 2: [verificação]
  ...

REMEDIAÇÃO
  Se [condição A]: [ação]
  Se [condição B]: [ação]
  Se nenhuma condição se aplica: escalar ao especialista [nome do domínio]

PÓS-REMEDIAÇÃO
  [ ] Validar que o serviço está respondendo normalmente
  [ ] Verificar que não há tenants afetados secundariamente
  [ ] Documentar o que foi feito no chamado
  [ ] Avaliar se o incidente exige RCA completo

Runbooks são versionados no repositório de operações. Toda execução de runbook em incidente produtivo é registrada com resultado — se a execução revelou que o runbook está desatualizado, uma tarefa de revisão é aberta imediatamente.

52.9 Comunicação com Órgãos Participantes

52.9.1 Durante Incidente Ativo

Para incidentes S1 e S2, a comunicação com o órgão participante segue protocolo definido:

• Abertura: notificação imediata ao responsável técnico do tenant assim que o incidente é confirmado, com descrição do impacto e hora de início.
• Atualizações: a cada 30 minutos para S1; a cada hora para S2; com status (em investigação / com workaround / em resolução) e estimativa de resolução quando disponível.
• Resolução: notificação com descrição da solução aplicada, serviços restaurados e próximos passos (RCA, correção definitiva).

A comunicação é enviada por e-mail e publicada no portal de atendimento do tenant. Para S1 com impacto em múltiplos tenants, a status page pública também é atualizada.

52.9.2 Relatório de Causa Raiz (RCA)

Incidentes S1 e S2 de resolução complexa (tempo de resolução acima de 2 horas ou impacto em mais de um tenant) geram RCA formal entregue em até 24 horas após a resolução para S1 e em até 72 horas para S2.

Estrutura do RCA:

O RCA não é documento de culpa — é documento de aprendizado. A linguagem é técnica e objetiva, sem atribuição individual de responsabilidade.

52.9.3 Relatório Mensal de Suporte

Todo órgão participante recebe relatório mensal com:

• volume de chamados abertos e encerrados no período por severidade e tipo;
• tempo médio de resposta e resolução por severidade;
• aderência ao SLA (percentual de chamados resolvidos dentro do prazo acordado);
• incidentes do período com resumo de causa e resolução;
• workarounds ativos com prazo de resolução definitiva;
• manutenções preventivas realizadas e planejadas para o próximo período.

52.10 Gestão de Manutenção

52.10.1 Janelas de Manutenção

Manutenções programadas que implicam indisponibilidade parcial ou total de serviços são realizadas em janelas pré-acordadas. As janelas padrão são:

• Janela padrão: terças e quintas, das 23h às 02h (horário de Brasília)
• Janela emergencial: qualquer horário, com notificação mínima de 2 horas, exclusiva para correções de segurança críticas (CVE com CVSS ≥ 9.0) ou falhas que exigem intervenção imediata para preservar a integridade dos dados

Janelas padrão são comunicadas com mínimo de 48 horas de antecedência, com descrição do que será realizado, estimativa de duração e impacto esperado. Quando a janela é cancelada, os tenants são notificados com o novo prazo.

52.10.2 Deploy em Produção

Toda manutenção que envolve deploy de nova versão segue o pipeline DevSecOps descrito no Capítulo 40, com destaque para:

• deploy progressivo (blue/green ou canary) para reduzir janela de impacto;
• monitoramento intensivo durante e após o deploy (30 minutos de observação pós-deploy);
• rollback automático se métricas de taxa de erro ou latência ultrapassam threshold configurado;
• aprovação manual do responsável técnico de operações antes de 100% do tráfego ser migrado.

Deploys que afetam schema de banco de dados seguem processo adicional: migration executada em fase separada do código, com validação de compatibilidade retroativa antes de ativar a nova versão.

52.10.3 Gestão de Vulnerabilidades

Vulnerabilidades identificadas em componentes da plataforma são gerenciadas por criticidade:

O scanning de vulnerabilidades em imagens de container e dependências de código é automático no pipeline CI/CD (Capítulo 40). Vulnerabilidades identificadas em produção que não passaram pelo pipeline (ex.: nova CVE publicada para dependência já implantada) são detectadas por scanning periódico do ambiente de produção com frequência diária.

52.11 Base de Conhecimento e Autoatendimento

52.11.1 Base de Conhecimento Técnica

A base de conhecimento do suporte é mantida pela parceira e acessível à equipe N1 da PRODEMGE. Contém:

• procedimentos operacionais padronizados (POPs) para casos recorrentes de N1;
• guias de diagnóstico por módulo e por tipo de erro;
• FAQs técnicas dos módulos da plataforma;
• registro de soluções aplicadas em incidentes anteriores (knowledge base);
• changelog de cada release com descrição de mudanças comportamentais relevantes.

A base é atualizada após cada incidente resolvido — se a solução não estava documentada, ela é incluída antes do encerramento formal do chamado.

52.11.2 Portal de Autoatendimento do Tenant

Administradores dos tenants têm acesso a um painel de autoatendimento que permite resolver autonomamente os casos mais comuns sem abertura de chamado:

• redefinição de senha de usuários do tenant;
• ajuste de permissões de perfil;
• ativação e desativação de canais de comunicação;
• configuração de horários de atendimento;
• consulta ao histórico de transações e solicitações do tenant;
• download de relatórios operacionais.

O autoatendimento reduz volume de chamados de N1, libera capacidade para casos mais complexos e aumenta a autonomia operacional dos órgãos.

52.12 Métricas de Suporte

O desempenho do suporte técnico é medido por indicadores objetivos, acompanhados mensalmente e consolidados no relatório entregue à PRODEMGE e aos órgãos participantes.

Indicadores abaixo da meta por dois meses consecutivos ativam revisão do processo de suporte com plano de ação definido em até 5 dias úteis.

52.13 Responsabilidades entre PRODEMGE e Parceira

A separação é funcional, não hierárquica. PRODEMGE e parceira atuam de forma coordenada, com canais de comunicação internos estabelecidos para escalação rápida entre as equipes.

52.14 Integração com Observabilidade

O suporte não opera no escuro. Toda a capacidade de observabilidade descrita no Capítulo 41 é diretamente utilizada pelo suporte técnico:

• alertas do Prometheus/AlertManager criam chamados automaticamente no sistema de gestão quando confirmados pelo on-call;
• traces do Jaeger são anexados automaticamente ao chamado quando um trace ID está presente na solicitação do órgão;
• logs estruturados do Loki/Kibana são consultados pelo N2 com filtros por tenant, por serviço e por período de tempo do incidente;
• dashboards de observabilidade têm perfil de acesso read-only para engenheiros de suporte.

Essa integração elimina o gap de informação que frequentemente existe entre monitoramento e suporte: o engenheiro que atende o chamado tem acesso ao mesmo conjunto de dados que o engenheiro que monitora a plataforma.

52.15 Riscos e Mitigações

52.16 Decisões Arquiteturais

52.17 Considerações Finais

A sustentação técnica é onde a arquitetura encontra a realidade. Sistemas bem projetados falham menos — mas falham. A diferença entre uma plataforma de missão crítica e uma que apenas aspira a esse status não está na ausência de falhas, mas na capacidade de detectá-las cedo, respondê-las com precisão e aprender com elas de forma sistemática.

O modelo de suporte em três níveis, com responsabilidades claras entre PRODEMGE e parceira, garante que cada tipo de demanda chegue ao profissional com competência para resolvê-la, sem ruído e sem lacunas de responsabilidade. A documentação de cada chamado, a elaboração de RCAs completos e a manutenção ativa da base de conhecimento transformam incidentes em insumo de melhoria — cada falha resolvida torna a plataforma mais robusta para o próximo ciclo.

O Capítulo 53 detalha os Acordos de Nível de Serviço que formalizam os compromissos de tempo de resposta, resolução e disponibilidade descritos neste capítulo.

52.18 Controle de Versão

52.19 Rastreabilidade PRODEMGE

• [PNR] Item 3.4.4 — Suporte técnico e sustentação: atendimento a incidentes, monitoramento, correção de falhas, gestão de SLA e suporte em múltiplos níveis (N1, N2 e N3).
• [PNR] Item 4.1.21 — Suporte Técnico (2º e 3º Níveis): abrange suporte especializado para resolução de problemas complexos, manutenção corretiva e evolutiva — responsabilidade da parceira.
• [ANX-IV] Item 3.2 — Capacidade de operação e sustentação contínua da solução: evidenciada pela estrutura de três níveis, plantão 24×7, gestão de chamados e indicadores de desempenho.
• [ANX-IV] Item 3.3 — Capacidade de operação em escala: sustentação projetada para operar com múltiplos tenants simultâneos sem degradação de tempo de resposta.
• [EDITAL] — Edital CP001/2026: continuidade dos serviços digitais com gestão estruturada de incidentes e acordos de nível de serviço.