Capítulo 53 — SLA — Acordos de Nível de Serviço

53.1 Objetivo do Capítulo

Este capítulo formaliza os Acordos de Nível de Serviço da Plataforma de Relacionamento Digital com o Cidadão — o conjunto de compromissos mensuráveis que definem o padrão mínimo aceitável de operação, o que acontece quando esse padrão é violado, e como a plataforma demonstra continuamente que os compromissos estão sendo cumpridos.

SLA não é cláusula contratual genérica. É o vocabulário compartilhado entre a parceira e a PRODEMGE para discutir qualidade de serviço em termos objetivos: números, prazos e consequências. A ausência de SLA bem definido transforma cada incidente em negociação sobre o que deveria ou não ter acontecido. A presença de SLA converte a mesma situação em verificação de fato.

A estrutura deste capítulo cobre três planos distintos: o plano de disponibilidade (a plataforma funciona?), o plano de suporte (quando falha, com que velocidade é resolvido?) e o plano de desempenho (quando funciona, com que qualidade?). Os três planos são interdependentes, mas medem dimensões diferentes da operação e têm regimes de medição, reporte e gestão de desvio próprios.

A relação com os capítulos anteriores é deliberada: o Capítulo 51 (Operação e Gestão de Serviços) estabelece os processos operacionais; o Capítulo 52 (Sustentação e Suporte Técnico) define a estrutura de atendimento a chamados; este capítulo formaliza os compromissos numéricos que esses processos são responsáveis por cumprir.

53.2 Contexto

A plataforma opera em modelo multi-tenant: múltiplos órgãos da Administração Pública do Estado de Minas Gerais utilizam a mesma infraestrutura, o mesmo código, os mesmos serviços de backend. Essa arquitetura cria uma relação de dependência cruzada: a degradação de um componente de plataforma pode afetar todos os tenants simultaneamente, enquanto a degradação em nível de tenant pode estar restrita a uma configuração específica.

Esse contexto exige que o SLA opere em dois níveis: o nível de plataforma, que define compromissos sobre a infraestrutura e os serviços compartilhados, e o nível de tenant, que permite que cada órgão compreenda exatamente o que está garantido para seu ambiente. O modelo de reporte deve distinguir claramente o impacto por tenant do impacto sistêmico.

A parceria com a PRODEMGE acrescenta uma dimensão adicional: a PRODEMGE é ao mesmo tempo cliente-âncora da plataforma e parceira no modelo de negócio. Os SLAs definidos aqui governam a relação operacional entre a parceira tecnológica (provedora da plataforma) e a PRODEMGE (responsável pela gestão dos órgãos clientes). A rastreabilidade ao contrato de parceria e ao Plano de Negócio é, portanto, direta.

53.3 Escopo

O capítulo cobre:

• definição dos indicadores de SLA por categoria (disponibilidade, suporte, desempenho);
• classificação de serviços por criticidade e seus níveis de compromisso diferenciados;
• janelas de medição, exclusões e critérios de apuração;
• gestão de desvio: protocolo de notificação, relatório de causa e plano de correção;
• créditos de serviço e penalidades por descumprimento;
• ciclo de revisão e evolução dos acordos;
• rastreabilidade com documentos do edital.

Não estão no escopo deste capítulo os SLAs de atendimento ao cidadão definidos por cada órgão para seus próprios serviços, que são configurados por tenant no módulo de CRM conforme descrito no Capítulo 18.

53.4 Descrição Técnica

53.4.1 Hierarquia de Serviços

A plataforma é composta por serviços de natureza e criticidade distintas. O SLA não é uniforme: serviços que suportam o atendimento ao cidadão em tempo real têm exigências mais severas do que serviços de processamento analítico em batch. A hierarquia de criticidade define o regime de SLA aplicável a cada serviço.

Nível Crítico — Serviços de Atendimento em Tempo Real

Compõem o núcleo do atendimento ao cidadão. A indisponibilidade impede o uso da plataforma pelos canais digitais.

• Portal Web (frontend e BFF de apresentação)
• Aplicativo Mobile (backend de APIs móveis)
• IAM — autenticação e emissão de tokens
• CRM — criação e atualização de interações
• BPM — submissão e transição de solicitações
• Módulo de Notificações (emissão de confirmações e alertas críticos)
• API Gateway — roteamento de todas as requisições externas

Nível Alto — Serviços de Suporte Operacional

Ampliam a capacidade operacional da plataforma. A degradação impacta funcionalidades importantes mas não bloqueia o atendimento básico.

• ECM/GED — upload e consulta de documentos
• Comunicação Omnichannel (canais de mensageria assíncrona: e-mail, WhatsApp, SMS)
• Ouvidoria — submissão e consulta de manifestações
• Agendamentos — criação e consulta de agendamentos
• Módulo de Administração (configuração de tenant)

Nível Padrão — Serviços de Inteligência e Analytics

Entregam valor agregado sem bloquear o fluxo principal de atendimento.

• Copiloto de IA — assistente de atendimento
• Analytics e Data Lake — processamento analítico
• Dashboards e Business Intelligence
• Busca Semântica e Indexação Vetorial

Nível Operacional — Serviços de Infraestrutura e Gestão

Componentes de plataforma usados internamente ou por administradores técnicos.

• Observabilidade e Monitoramento
• Pipeline CI/CD
• Portal de Administração da Plataforma (PRODEMGE)

53.4.2 Indicadores de Disponibilidade

Definição de Disponibilidade

Disponibilidade é a proporção de tempo, dentro da janela de medição, em que o serviço está operacional e acessível para uso, medida do ponto de vista do usuário final — não do ponto de vista do servidor.

Um serviço é considerado indisponível quando mais de 1% das requisições retornam erro HTTP 5xx por um intervalo contínuo de 2 minutos ou mais, ou quando o health check do Kubernetes indica falha de todos os pods do serviço.

A medição é realizada de forma sintética por probes executados a cada 30 segundos, em conjunto com a observação das métricas reais de taxa de erro coletadas via OpenTelemetry.

Compromissos de Disponibilidade por Nível

A janela de medição é o mês calendário. A apuração é realizada mensalmente e reportada nos primeiros cinco dias úteis do mês seguinte.

Janela de Medição e Exclusões

A disponibilidade é medida sobre o período total do mês. São excluídas do cômputo de indisponibilidade:

• janelas de manutenção programada comunicadas com mínimo de 48 horas de antecedência;
• indisponibilidade causada por falha comprovada de serviços de terceiros sobre os quais a parceira não tem controle (provedores de cloud, operadoras de telecomunicações, APIs governamentais externas);
• degradação causada por uso da plataforma em volumes comprovadamente superiores ao dimensionamento acordado, quando não houver cláusula de elasticidade aplicável;
• indisponibilidade decorrente de ações do próprio órgão-tenant (configuração incorreta, operação fora dos procedimentos acordados).

Exclusões são documentadas e submetidas à PRODEMGE com evidência objetiva (logs, registros de monitoramento, notificações recebidas de terceiros) antes de serem aplicadas no relatório de apuração.

53.4.3 Indicadores de Suporte

O SLA de suporte governa os tempos de resposta e resolução para incidentes registrados no sistema de gestão de chamados. A classificação de severidade usada nos acordos de suporte espelha a estrutura de gestão de incidentes definida no Capítulo 52, com correspondência direta entre os níveis operacionais e os compromissos contratuais.

Tabela de SLA de Suporte

Definições

Tempo de Resposta é o intervalo entre o registro do chamado (detecção pelo monitoramento ou abertura manual) e a confirmação de que um engenheiro qualificado está ativamente trabalhando na investigação — com comunicação registrada no sistema de gestão de chamados.

Tempo de Resolução é o intervalo entre o registro do chamado e o encerramento formal com o serviço restaurado ao comportamento esperado. A resolução pode ser definitiva (causa raiz corrigida) ou com workaround documentado; neste último caso, a correção definitiva tem prazo próprio definido na seção 53.4.6.

O tempo de resolução é contado continuamente (24×7) para S1 e S2, e em horas úteis (segunda a sexta, 8h–18h, exceto feriados estaduais de Minas Gerais) para S3 e S4.

Metas de Aderência

A aderência ao SLA de suporte é medida pelo percentual de chamados de cada severidade resolvidos dentro do prazo acordado, apurada mensalmente.

Aderência abaixo da meta por dois meses consecutivos em qualquer severidade ativa revisão formal do processo de suporte, com plano de ação submetido à PRODEMGE em até cinco dias úteis após o fechamento do segundo mês com desvio.

53.4.4 Indicadores de Desempenho

Os indicadores de desempenho medem a qualidade da resposta da plataforma quando esta está disponível. Disponibilidade sem desempenho aceitável é insuficiente: um portal que responde em 10 segundos está tecnicamente disponível mas inutilizável.

Latência de APIs

A medição é feita sobre requisições completas, incluindo serialização, processamento de negócio e serialização de resposta. Latência de rede entre cliente e servidor não está no escopo da medição, mas a arquitetura de deploy prioriza regiões geograficamente próximas ao Estado de Minas Gerais.

Throughput e Capacidade

A plataforma é dimensionada para suportar, sem degradação dos indicadores de latência acima, o volume base acordado com a PRODEMGE ao longo do contrato. O dimensionamento inicial suporta:

• 500 requisições por segundo (RPS) no agregado de todos os tenants, distribuídas entre os serviços de nível Crítico;
• 100 uploads de documentos simultâneos de até 10MB cada;
• 200 sessões de copiloto de IA ativas concorrentemente.

Quando o volume observado se aproxima de 80% dos limites estabelecidos, a arquitetura de auto-scaling do Kubernetes expande automaticamente a capacidade. A PRODEMGE é notificada quando a expansão automática é acionada de forma recorrente (mais de três vezes no mesmo dia), o que pode indicar necessidade de revisão do dimensionamento base.

Taxa de Erro

A taxa de erro de aplicação (respostas HTTP 5xx divididas pelo total de requisições) deve ser inferior a 0,1% em janela de 5 minutos para serviços de nível Crítico, e inferior a 0,5% para demais níveis. Taxa de erro acima dos limiares por mais de 2 minutos aciona alerta imediato e inicia o protocolo de incidente.

53.4.5 Indicadores de Segurança e Conformidade

O SLA inclui compromissos sobre tempo de resposta a eventos de segurança, que têm criticidade própria independente de impactar ou não a disponibilidade operacional.

Os prazos de notificação à PRODEMGE são independentes do status de resolução — a notificação é feita mesmo quando a investigação ainda está em andamento.

53.4.6 Compromissos de Pós-Resolução

Incidentes de alta severidade geram obrigações que estendem o SLA além da resolução imediata.

Relatório de Causa Raiz (RCA)

O RCA contém: linha do tempo do incidente, causa raiz identificada, impacto medido, solução aplicada, correção definitiva com prazo e responsável, e ações preventivas para evitar recorrência.

Correção Definitiva de Workarounds

Quando um incidente é encerrado com workaround (solução temporária) em vez de correção definitiva, a correção definitiva tem prazo máximo de 30 dias corridos para ser implementada e deployada em produção. O prazo é registrado no sistema de gestão de chamados e monitorado pelo fiscal do contrato.

Taxa de Reincidência

Incidentes com a mesma causa raiz em janela de 30 dias são tratados como reincidência. A meta é que a taxa de reincidência seja inferior a 5% do total de incidentes do mês. Reincidências são evidência de que a correção definitiva não foi adequada ou que o processo de melhoria contínua não está funcionando.

53.5 Arquitetura de Medição

53.5.1 Coleta de Métricas

A arquitetura de medição dos SLAs é construída sobre a infraestrutura de observabilidade descrita no Capítulo 41. A sobreposição é intencional: o mesmo sistema que detecta degradação em tempo real alimenta o cálculo de SLA para o relatório mensal.

Os dados de disponibilidade provêm de três fontes complementares:

Probes sintéticos externos são executados a partir de ponto externo à infraestrutura da plataforma, a cada 30 segundos, verificando endpoints críticos de cada serviço. Detectam indisponibilidade do ponto de vista do usuário externo, não da saúde interna dos pods.

Métricas de taxa de erro são coletadas via OpenTelemetry e armazenadas no Prometheus. A taxa de erro por serviço em janela deslizante de 5 minutos determina se um serviço está em estado de degradação.

Health checks do Kubernetes fornecem visibilidade interna sobre o estado dos pods. São complementares aos probes externos, mas não são a fonte primária de apuração de disponibilidade — um serviço com pods saudáveis mas respondendo com erro do ponto de vista do usuário é tratado como indisponível.

A combinação das três fontes garante que a apuração de disponibilidade não depende de uma única fonte de verdade e que desvios entre as fontes — quando uma indica saudável e outra indica degradado — são investigados como anomalia.

53.5.2 Cálculo de Disponibilidade

A disponibilidade mensal é calculada como:

Disponibilidade (%) = 
  (Minutos do mês - Minutos de indisponibilidade efetiva) 
  / Minutos do mês × 100

Minutos de indisponibilidade efetiva = 
  Total de minutos de indisponibilidade detectada
  - Minutos em janelas de manutenção programada
  - Minutos em eventos excluídos por cláusulas contratuais

Um serviço é contabilizado como indisponível em um dado minuto quando:

• o probe sintético detecta falha em pelo menos 2 das 3 verificações executadas naquele minuto (eliminando falsos positivos de probe), ou
• a taxa de erro do serviço supera 1% por intervalo contínuo de 2 minutos.

O critério "ou" é conservador: basta que uma das condições seja verdadeira para que o minuto seja contabilizado como indisponível. Isso reflete o compromisso de que a medição favorece a visão do usuário final, não a defesa da plataforma.

53.5.3 Painel de SLA em Tempo Real

A PRODEMGE e os administradores dos órgãos têm acesso a um painel de SLA em tempo real que exibe:

• status atual de cada serviço por nível de criticidade;
• disponibilidade acumulada no mês corrente por serviço;
• histórico de incidentes dos últimos 30 dias com duração e severidade;
• chamados abertos e respectivos prazos de SLA;
• próximas janelas de manutenção programadas.

O painel é atualizado a cada 60 segundos para os indicadores de disponibilidade e em tempo real para o status de incidentes ativos. Não exige acesso privilegiado: a disponibilidade agregada é pública; dados de incidentes com detalhe técnico exigem autenticação com perfil de administrador.

53.6 Fluxos

53.6.1 Fluxo de Apuração Mensal de SLA

Início do mês N+1
    │
Coleta automática de dados de disponibilidade (Prometheus + probes)
    │
Aplicação de exclusões documentadas com evidência
    │
Cálculo de disponibilidade por serviço
    │
Coleta de dados de suporte (chamados encerrados, tempos de resposta e resolução)
    │
Cálculo de aderência por severidade
    │
Coleta de dados de desempenho (latência P95, P99 por endpoint)
    │
Geração automática do relatório de SLA
    │
Revisão pela equipe de operação (validação de exclusões e anomalias)
    │
Envio à PRODEMGE até o 5º dia útil do mês N+1
    │
Reunião de revisão (se houver desvio em qualquer indicador)
    │
Registro de plano de ação (se aplicável)

53.6.2 Fluxo de Desvio de SLA

Quando um indicador fecha o mês abaixo da meta:

Desvio identificado no relatório mensal
    │
Notificação formal à PRODEMGE (no mesmo relatório)
    │
Análise de causa: falha pontual ou sistêmica?
    │
         ├── Falha pontual (evento isolado, não recorrente)
         │       └── Registro com mitigação para evitar recorrência
         │
         └── Falha sistêmica (padrão de degradação recorrente)
                 └── Plano de ação em até 5 dias úteis
                         └── Revisão do plano na próxima reunião mensal

O desvio de SLA não é tratado como evento contratual adversarial — é tratado como insumo de melhoria. O objetivo do fluxo de desvio é identificar e corrigir a causa, não apenas registrar o evento.

53.7 Diagramas

53.7.1 Visão de Camadas do SLA (Nível Contexto)

O SLA opera em três camadas superpostas: a camada de infraestrutura (disponibilidade dos servidores, rede, storage), a camada de plataforma (disponibilidade dos serviços da aplicação) e a camada de tenant (disponibilidade dos recursos e configurações específicos de cada órgão). A maioria dos SLAs definidos neste capítulo governa a camada de plataforma — é a camada que a parceira controla inteiramente.

A camada de infraestrutura em ambiente de cloud é parcialmente controlada pelo provedor; desvios atribuíveis ao provedor são tratados como exclusões documentadas. A camada de tenant é influenciada pelas configurações que cada órgão realiza — desvios atribuíveis a configuração do tenant são registrados e tratados como suporte.

53.7.2 Fluxo de Dados de Medição (Nível Componentes)

Probes Externos (30s)
    │
    └─► Prometheus (coleta + armazenamento de séries temporais)
            │
            ├─► Alertmanager (alertas em tempo real)
            │
            └─► SLA Calculator (job mensal)
                    │
                    ├─► Painel de SLA (exibição em tempo real)
                    │
                    └─► Relatório Mensal (PDF + dados brutos)

OpenTelemetry (métricas de aplicação)
    │
    └─► Prometheus
            │
            └─► SLA Calculator (taxa de erro, latência por endpoint)

53.8 Exemplos

53.8.1 Apuração de Disponibilidade — Exemplo Prático

Julho de 2026 tem 31 dias = 44.640 minutos.

O Portal Web (nível Crítico, meta 99,5%) registra:

• Incidente S1 em 05/07, duração 47 minutos → contabilizado integralmente
• Janela de manutenção programada em 15/07, duração 90 minutos → excluída
• Degradação em 22/07, duração 8 minutos → contabilizada (probe detectou falha)

Minutos de indisponibilidade efetiva: 47 + 8 = 55 minutos (os 90 de manutenção são excluídos).

Disponibilidade = (44.640 - 55) / 44.640 × 100 = 99,877%

O Portal Web fechou o mês acima da meta de 99,5%. Não há desvio a reportar para este serviço.

53.8.2 Aplicação do SLA de Suporte — Exemplo

Um incidente S2 é registrado às 14h30 de uma quarta-feira:

• O engenheiro de plantão confirma o início da investigação às 14h52 → tempo de resposta: 22 minutos (dentro dos 30 minutos acordados).
• O workaround é aplicado às 18h40 → tempo de resolução: 4 horas e 10 minutos (dentro das 8 horas acordadas).
• A correção definitiva é deployada 12 dias depois.

O chamado foi encerrado dentro do SLA. O workaround documentado registra prazo de 30 dias para correção definitiva, que foi cumprido.

53.9 Boas Práticas

Medir o que importa para o usuário, não o que é fácil de medir. Métricas de infraestrutura (CPU, memória, rede) são indicadores internos. O SLA é medido na camada de experiência do usuário: o serviço responde com sucesso dentro do tempo esperado.

Distinguir desvio de violação. Um mês com disponibilidade de 99,4% contra uma meta de 99,5% é desvio — foi próximo, é investigado, é corrigido. Um mês com 97,0% é violação que exige reação proporcional. Tratar ambos da mesma forma dilui a urgência.

Documentar exclusões com antecedência, não retrospectivamente. Janelas de manutenção são comunicadas e registradas antes de ocorrer. Eventos de terceiros são documentados no momento em que ocorrem. Exclusões aplicadas na apuração mensal sem documentação prévia não são aceitas.

Manter o painel de SLA acessível sem burocracia. O administrador do órgão não precisa abrir chamado para saber se a plataforma está operando dentro dos parâmetros acordados. O painel é o contrato em tempo real.

Usar o SLA como ferramenta de melhoria, não de culpabilização. O objetivo do regime de SLA é identificar padrões de degradação e corrigi-los antes que se tornem crônicos. RCAs e planos de ação são documentos de aprendizado organizacional.

53.10 Justificativas Técnicas das Decisões

Por que 99,5% e não 99,9% para serviços críticos?

99,9% de disponibilidade mensal equivale a 43 minutos de downtime por mês. Para uma plataforma nova em ambiente de cloud com múltiplos tenants sendo integrados progressivamente, esse nível exige investimento em redundância ativa-ativa completa, eliminação de todos os single points of failure e zero downtime durante deploys — condições que requerem arquitetura e operação maduras, construídas ao longo do tempo. 99,5% (3 horas e 36 minutos/mês) é um compromisso desafiador mas honesto para o estágio inicial da parceria, com trajetória de evolução definida na seção 53.4.7.

A redução a 99,5% não é concessão de qualidade — é reconhecimento de que SLAs inalcançáveis criam cultura de justificativas em vez de cultura de melhoria.

Por que o tempo de resposta S1 é 15 minutos?

Quinze minutos é o tempo máximo para que um engenheiro on-call confirme que está ativo na investigação de um incidente crítico, considerando o processo de notificação via PagerDuty, o acesso a ferramentas de diagnóstico e a abertura do canal de comunicação de crise. Não é o tempo para resolver o problema — é o tempo para garantir que o problema está sendo tratado com urgência por alguém qualificado.

Por que S3 e S4 são medidos em horas úteis?

Incidentes de severidade média e baixa têm workaround disponível (S3) ou impacto cosmético (S4). Exigir resposta 24×7 para esses casos implica plantão constante de profissionais para um volume de trabalho que pode ser atendido adequadamente em horário comercial — o que aumenta custo operacional sem benefício proporcional para o usuário final.

Por que o cálculo de disponibilidade usa critério "ou" entre probe e taxa de erro?

O critério conservador protege o órgão cliente. Um serviço pode ter todos os seus pods saudáveis internamente mas ainda assim estar devolvendo erros para um subconjunto de usuários — por problema de configuração de rede, por bug em determinado fluxo de código, ou por indisponibilidade de um serviço dependente. Exigir que os dois indicadores confirmem degradação antes de contabilizar o minuto como indisponível favoreceria a plataforma na apuração. O critério "ou" favorece a visão do usuário.

53.11 Trade-offs

Disponibilidade vs. velocidade de entrega de novas funcionalidades. Metas de disponibilidade rigorosas criam pressão para reduzir a frequência de deploys e aumentar o rigor dos testes de regressão. A plataforma equilibra isso com um pipeline de CI/CD com blue-green deployment e feature flags — deploys frequentes sem interrupção de serviço, rollback em menos de 5 minutos se necessário.

Granularidade do SLA vs. complexidade de gestão. SLAs por serviço individual criam máxima transparência mas exigem infraestrutura de medição mais elaborada e relatórios mais extensos. SLA único para toda a plataforma é mais simples mas oculta onde estão os problemas. O modelo por nível de criticidade é o equilíbrio: quatro níveis são suficientemente granulares para identificar onde há degradação sem criar complexidade excessiva.

Janela de medição mensal vs. janela semanal. Medição semanal capturaria desvios mais rapidamente mas tornaria a gestão de exclusões e a negociação de desvios contínua. Medição mensal é o padrão de mercado e cria um ciclo de revisão previsível. O painel em tempo real compensa: o desvio é visto imediatamente — apenas a apuração formal é mensal.

Créditos de serviço vs. planos de ação. Créditos financeiros pelo descumprimento de SLA são o mecanismo tradicional de penalidade. Num modelo de parceria como este — onde os riscos são compartilhados — planos de ação formais com prazo definido tendem a ser mais eficazes: criam comprometimento com a melhoria, não apenas com o pagamento da penalidade.

53.12 Alternativas Descartadas e Razões

SLA único de 99,9% para todos os serviços. Descartado por impossibilidade prática sem investimento de redundância que não é compatível com o estágio inicial da parceria. Adicionalmente, nivelamento único ignora que analytics e dashboards têm natureza fundamentalmente diferente de autenticação e submissão de solicitações.

Medição exclusivamente por probe externo. Descartado porque probe externo não captura degradação interna (como um bug que afeta apenas determinadas configurações de tenant) antes de ela se manifestar externamente. A combinação com métricas de taxa de erro via OpenTelemetry garante detecção mais precoce.

Relatório de SLA produzido exclusivamente pela parceira. Considerado e mantido com controle: a PRODEMGE tem acesso direto ao painel de SLA com os dados brutos que alimentam o relatório. A parceira produz o relatório, mas a PRODEMGE pode verificar os números de forma independente a qualquer momento. Isso elimina o conflito de interesse inerente em relatórios autoproduzidos.

Penalidades financeiras automáticas por desvio. Descartado para o modelo primário de gestão de desvio em favor de planos de ação — mas não eliminado. Desvios recorrentes (mesmo indicador abaixo da meta por três ou mais meses consecutivos) ativam apuração de penalidades, conforme definido nos mecanismos contratuais. O objetivo é criar incentivo à melhoria antes de criar incentivo à penalidade.

53.13 Riscos e Mitigações

53.14 Benefícios

O regime de SLA formalizado neste capítulo entrega valor em três dimensões distintas.

Para a PRODEMGE e os órgãos participantes, os SLAs criam previsibilidade operacional: é possível planejar, comunicar e gerenciar os serviços digitais ao cidadão com base em compromissos objetivos. Quando um órgão publica um serviço digital na plataforma, sabe com precisão o nível de disponibilidade e suporte que pode oferecer.

Para a parceira, o regime de SLA cria disciplina operacional: metas claras orientam prioridades de investimento em infraestrutura, processos e pessoas. O custo de cumprir o SLA é calculável; o custo de violá-lo sistematicamente, também.

Para a plataforma como produto, o histórico de cumprimento de SLA é um ativo de confiança acumulado ao longo da parceria — que sustenta a expansão para novos órgãos e a justificativa de investimentos em evolução.

53.15 Impactos Arquiteturais

O regime de SLA impõe restrições arquiteturais concretas que influenciam decisões em múltiplos capítulos.

A meta de disponibilidade 99,5% para serviços críticos impõe que esses serviços operem em múltiplas réplicas com balanceamento de carga, que deploys sejam realizados com estratégia blue-green ou rolling update (nunca com downtime), e que dependências externas críticas tenham circuit breakers configurados.

A meta de latência P95 ≤ 500ms para autenticação impõe que o IAM opere com cache distribuído de tokens válidos (Redis), que a verificação de permissões seja local ao serviço sempre que possível, e que chamadas ao banco de dados para autenticação sejam evitadas no caminho crítico.

A meta de resposta S1 em 15 minutos impõe que o sistema de alertas seja configurado com sensibilidade adequada (sem excessivo rate limiting que atrase notificações), que runbooks estejam disponíveis offline e atualizados, e que o engenheiro on-call tenha acesso a todas as ferramentas de diagnóstico de qualquer dispositivo.

53.16 Integrações com Outros Componentes

Observabilidade (Capítulo 41): a infraestrutura de coleta de métricas, probes sintéticos, OpenTelemetry e dashboards do Grafana é a base técnica de toda a medição de SLA. A qualidade da observabilidade determina diretamente a qualidade da apuração de SLA.

Gestão de Incidentes (Capítulo 51): o protocolo de classificação de severidade, o processo de comunicação durante incidentes e o mecanismo de postmortem definidos no Capítulo 51 são operacionalizados pelos compromissos de SLA de suporte deste capítulo.

Sustentação e Suporte Técnico (Capítulo 52): os três níveis de suporte (N1, N2, N3) e suas competências delimitam o mecanismo de cumprimento dos SLAs de tempo de resposta e resolução. Os indicadores de desempenho do suporte (FCR N1, MTTR, aderência) são o espelho operacional das metas de SLA contratuais.

Continuidade de Negócio (Capítulo 47): RTO e RPO definidos no plano de continuidade têm correspondência direta com os tempos de resolução do SLA de suporte. RTO de 4 horas para serviços críticos é compatível com o tempo de resolução S1 de 4 horas.

IAM (Capítulo 43): a disponibilidade do módulo de autenticação é fundacional para todos os outros serviços. Uma indisponibilidade do IAM é automaticamente um incidente S1, pois impede o acesso de todos os usuários a todos os tenants.

LGPD e Proteção de Dados (Capítulo 44): incidentes de violação de dados têm regime de SLA próprio (seção 53.4.5) com prazos de notificação determinados tanto pelo contrato quanto pela legislação aplicável (LGPD, art. 48).

53.17 Relacionamento com Outros Capítulos

Este capítulo encerra a tríade operacional da PARTE VII:

• Capítulo 51 estabelece como a plataforma é operada no dia a dia.
• Capítulo 52 define como problemas são tratados quando ocorrem.
• Capítulo 53 (este capítulo) formaliza os compromissos que vinculam os dois anteriores.

Os capítulos seguintes — Roadmap Tecnológico (54) e Gestão da Evolução da Plataforma (55) — constroem sobre a base operacional aqui estabelecida: a evolução da plataforma respeita os compromissos de SLA vigentes e usa o histórico de cumprimento como insumo para decisões de roadmap.

53.18 Referências Internas

• Capítulo 18 — SLA de atendimento ao cidadão configurado por tenant no CRM
• Capítulo 41 — Infraestrutura de observabilidade e coleta de métricas
• Capítulo 47 — RTO/RPO e plano de continuidade
• Capítulo 51 — Operação e gestão de serviços, classificação de severidade
• Capítulo 52 — Estrutura de suporte em três níveis, métricas de desempenho do suporte
• Capítulo 56 — Governança da parceria: reuniões de revisão de SLA
• Capítulo 62 — Indicadores e métricas de desempenho: SLA como componente do painel executivo

53.19 Rastreabilidade PRODEMGE

Edital CP 001/2026:

• Continuidade dos serviços digitais: comprometimento com disponibilidade e gestão estruturada de incidentes como condição operacional da parceria.

Plano de Negócio (Anexo I):

• Item 3.4.4 — Suporte técnico e sustentação: gestão de SLA referenciada como componente do modelo de sustentação.
• Item 4.1.21 — Suporte Técnico (2º e 3º Níveis): os SLAs de tempo de resposta e resolução deste capítulo são os compromissos contratuais que formalizam as capacidades de suporte declaradas.

Funcionalidades (Anexo III) — impacto na pontuação de 60%:

• Bloco 6 — Infraestrutura e Governança: disponibilidade, tempo de resposta e gestão de SLA são requisitos funcionais de governança operacional avaliados no Anexo III.

Capacidades (Anexo IV) — impacto na pontuação de 30%:

• Item 3.2 — Capacidade de operação e sustentação contínua da solução: o regime de SLA deste capítulo é a evidência documentada de que a parceira tem processo estruturado para garantir e medir a qualidade operacional.
• Item 3.3 — Capacidade de operação em escala: os limites de throughput e as metas de latência sob carga demonstram capacidade de operação com múltiplos tenants simultâneos sem degradação.

Sustentabilidade (Anexo V):

• Item 2.4 — Continuidade de negócio: o regime de SLA formaliza como a plataforma garante disponibilidade e recuperação, contribuindo diretamente para os critérios de sustentabilidade operacional avaliados no Anexo V.

Esclarecimentos pertinentes:

• Madrona Advogados — Questionamento 18 — Confirmação de que nenhuma multa, glosa ou desconto é aplicado automaticamente sem contraditório: o processo de apuração de desvio de SLA definido neste capítulo é compatível com essa diretriz.
• Montreal Informática — Questionamento 8 — Mecanismo formal de apuração de responsabilidade antes da aplicação de penalidade: o fluxo de desvio de SLA (seção 53.6.2) documenta o processo de análise e plano de ação antes de qualquer consequência contratual.

53.20 Resumo

O Capítulo 53 formaliza os Acordos de Nível de Serviço da Plataforma de Relacionamento Digital com o Cidadão em três planos: disponibilidade (99,5% para serviços críticos), suporte (resposta S1 em 15 minutos, resolução em 4 horas) e desempenho (latência P95 ≤ 500ms para autenticação). A medição é realizada sobre a camada de experiência do usuário, combinando probes sintéticos externos e métricas de taxa de erro via OpenTelemetry. Desvios geram planos de ação documentados; reincidências sistêmicas ativam apuração de penalidades. O relatório mensal de SLA é entregue nos primeiros cinco dias úteis do mês seguinte, com dados brutos acessíveis à PRODEMGE para verificação independente. O regime de SLA é o contrato operacional que vincula os processos definidos no Capítulo 51 (Operação) e no Capítulo 52 (Suporte) a compromissos mensuráveis e verificáveis.

53.21 Decisões Arquiteturais — ADR

53.22 Próximo Capítulo

O Capítulo 54 — Roadmap Tecnológico — define a trajetória de evolução da plataforma ao longo dos cinco anos da parceria: as capacidades que serão incorporadas, as melhorias arquiteturais planejadas, os marcos de maturidade tecnológica e como o roadmap se relaciona com os compromissos operacionais estabelecidos neste capítulo.

53.23 Controle de Versão