SDR — Operação (C2): níveis N1–N3, VIP, especialista e capacidade

Página estática gerada a partir do Markdown do repositório — o texto abaixo já vem no HTML (adequado a importação por URL em ferramentas que não executam o ver-md.html). Arquivo: sdr-0006-operacao-c2-niveis-capacidade.md

SDR — Operação (C2): níveis N1–N3, VIP, especialista e capacidade

Eixo: Modelo de Servicos (Modelo de Servicos | Arquitetura Contratual | Ambos)

Campo Valor
SSoT Sim — dono de regras construtíveis de capacidade e níveis de suporte do contrato de Operação (C2), com base em CMDB/CIs
Estado âncora; síntese no site em Operação — Regras mínimas do TR

1. Base de contagem (CMDB)

  • Itens de configuração (CIs) inventariados no CMDB, no critério de congelamento de base do período (alinhado ao ANS e ao SDR IMR).
  • Categorias (PC, servidor, rede, serviço digital, etc.) definidas no TR.
  • Sem dupla contagem do mesmo CI em denominadores incompatíveis (N2 por localidade vs. N3 por perfil): o TR e o anexo de capacidade fecham a parametrização.

2. N1 — central própria do fornecedor

  • Operação em central própria do fornecedor; primeiro atendimento integral (não só triagem).
  • Acesso remoto à estação do usuário (canal pactuado; LGPD e política de acesso).
  • Leitura de logs e correlação com o serviço de segurança do contrato C3 (SIEM, EDR, identidade) no nível necessário para identificar e corrigir causa operacional, sem substituir decisão e resposta de incidente de segurança do SOC (C3). Ver matriz em Segurança do site.
  • Escalamento ao N2: quando for necessária intervenção física no posto de trabalho ou em ativos de campo de escopo N2 (estações, periféricos, impressão local, cabeamento na unidade, conforme TR); ou requisito de negócio com mudança/janela presencial; ou fila VIP (prioridade, não diluição de posto salvo TR). Causa cuja raiz esteja em servidor, rede corporativa ou nuvemescalonar ao N3 (remoto), com registro no ITSM do que foi tentado no N1.
  • Repasse ao N2 ou N3: no ITSM, histórico sintético de ações e resultados.

3. VIP (prioridade)

  • São elegíveis ao perfil VIP, em caráter automático, os ocupantes de cargo institucional de direção ou equivalente, conforme estrutura remuneratória e tabela de cargos do órgão — critério mínimo e nomenclatura fixados no TR (ex.: equivalências em órgãos que não usem a mesma sigla de cargo).
  • Adicionalmente, a Administração poderá designar usuários estratégicos como VIP mediante solicitação formal da área interessada e aprovação expressa do gestor ou fiscal do contrato.
  • O teto percentual de VIP e a base do denominador (por exemplo, ocupantes do nível mínimo de direção registrados no sistema de gestão de pessoas) são definidos no TR; o modelo sugere, como referência de planejamento, até 5% — sem substituir o que estiver pactuado no instrumento.
  • A lista VIP é auditada periodicamente pelo C1-GOV com base no cadastro de cargos vigente; alterações de quadro que impliquem perda de elegibilidade devem ser refletidas pelo gestor do contrato em até 30 dias.
  • VIP altera SLA e prioridade de fila, não a tabela de postos N2/N3, salvo TR explícito.

4. N2 — presencial (júnior e pleno) por localidade

  • Presencial; janela contínua por localidade (ex.: superintendências); alinhado ao parque e localidades e ao planejamento IN94/ETP.
  • Competências típicas: diagnóstico e execução presencial no ambiente do usuário e nos ativos de endpoint de escopo (estações, periféricos, impressoras, cabeamento local na unidade e outros CIs de campo definidos no TR); instalação, configuração e suporte a software de usuário; demandas que exijam intervenção física no posto. Quando a causa raiz estiver na infraestrutura de rede corporativa, servidores ou nuvem, o N2 encaminha ao N3 com registro completo no ITSM (hipóteses levantadas e o que foi descartado em campo). Não é escopo típico do N2 substituir o N3 na operação remota de datacenter/nuvem — salvo TR explícito para exceções pontuais.

Como contar postos (total de CIs de escopo N2 da localidade no CMDB):

  1. Plenos: para cada 50 CIs em blocos completos, um profissional pleno.
  2. Júniores: o que sobrar após os blocos de 50; a cada 25 CIs restantes (blocos completos), um júnior.

Localidades com menos de 50 CIs de escopo N2 não recebem N2 presencial dedicado. A decisão fundamenta-se em custo-benefício: localidades de pequeno porte (tipicamente poucos usuários) não justificam alocação permanente de técnico presencial nessa unidade quando o custo seria desproporcional à demanda.

A solução primária é atendimento remoto qualificado pelo N1 e, quando necessário, escalonamento remoto ao N3 de infraestrutura. O fornecedor deve garantir que o canal remoto cumpra os SLAs pactuados no ANS para essas localidades, sem lacuna de responsabilidade.

Em situações excepcionais que exijam intervenção física (ex.: falha de hardware crítico sem substituto local), o TR pode prever visita presencial eventual por técnico N2 lotado na mesma localidade ou região metropolitana da localidade atendida, nos limites da legislação e regulamentação aplicáveis à contratação pública e ao deslocamento. Deslocamentos que ultrapassem o município ou a região metropolitana pactuada não são regra: tratam-se de exceção fundamentada e aprovada pela Administração caso a caso.

O TR deve registrar explicitamente essa solução, para que a ausência de N2 dedicado não seja lida como omissão contratual.

Um único técnico na unidade (quando houver): perfil pleno, jornada no horário comercial, até 8 h/dia.

Total de CIs (exemplo) Plenos Sobrou após blocos de 50 Júniores
49 nenhum (abaixo do mínimo; ver TR)
75 1 25 CIs 1
100 2 nada 0

5. N3 — júnior, pleno e sênior (por perfil)

  • O N3 é responsável pela infraestrutura de servidores, rede (corporativa/datacenter), nuvem e plataformas de serviço de escopo C2, operando predominantemente de forma remota (console, acesso seguro, APIs de gestão). A presença física concentra-se na sede (ex.: Brasília-DF) e em polos com infraestrutura robusta de datacenter/telecom — lista no TR.
  • Sede em Brasília (DF); outras localidades com infra robusta — lista a definir no TR (critério MS/outros explicitado no processo).
  • Modalidade (semana): sênior 3 presencial / 2 remoto; pleno N3 4 / 1; júnior N3 presencial (sede ou polo) — compatível com necessidade de presença em datacenter/polo sem contradizer o predomínio remoto na execução técnica diária.
  • Perfis (cada um com contagem de CIs no escopo N3; exemplos: nuvem, dados, SO, rede, segurança da operação — distinto do SOC C3; serviços: web, DNS, filas, APIs do C2).

Por perfil, aplicar nesta ordem ao total de CIs N3:

  1. Sênior: a cada 300 CIs (blocos completos), um sênior.
  2. Pleno N3: no que sobrar, a cada 100 CIs, um pleno N3.
  3. Júnior N3: no que ainda sobrar, a cada 50 CIs, um júnior N3 (presencial).

O TR pode exigir mínimo de um sênior em todo perfil com CI > 0 (a ratificar).

Exemplo (750 CIs em um perfil): 2 blocos de 300 CIs, logo 2 profissionais sênior (600 CIs) → sobram 150 → 1 pleno (100) → sobram 50 → 1 júnior.

Regra de ouro: não contar o mesmo ativo duas vezes na dotação N2 (por localidade) e N3 (por perfil) — anexo de capacidade do TR/ANS.


6. Especialista (remoto, sob demanda)

  • Nichos (BD, web, servidores, nuvem, segurança, etc.); estratégia e custo internos do fornecedor.
  • Remuneração pela contratante só com aprovação prévia, por escrito; até 3 ocorrências por trimestre (salvo anexo). Demais: sem ônus à contratante, salvo TR/aditivo.
  • A remuneração cobrada à Administração refere-se exclusivamente a acionamentos de interesse da contratante para demandas não previstas no escopo padrão do contrato — por exemplo, avaliações técnicas pontuais, consultoria ad hoc ou apoio a decisões estratégicas. Incidentes (qualquer severidade), sustentação, continuidade e resposta a crises operacionais são de responsabilidade integral do fornecedor (C2-OPR ou C3-SEC, conforme a natureza do caso), sem depender de acionamento remunerado extra da Administração para garantir capacidade especializada. O fornecedor deve manter capacidade interna suficiente para os cenários previstos no ANS.
  • Faixas de duração máxima (horas efetivas, podem ser fracionadas): ex. até 3, 10 e 20 h; tarifa-hora e tabela no edital/instrumento.

7. N0 — self-service (autoatendimento)

  • É obrigação do C2-OPR identificar, propor e implantar itens de autoatendimento, priorizando serviços de alta frequência, baixa complexidade e fácil uso (ex.: redefinição de senha, solicitação de acesso padronizado, instalação de software catalogado, consulta de status de chamado).
  • O fornecedor deve orientar os usuários ao canal de self-service: pelos técnicos N1 (ao receber chamado elegível, indicar e ensinar o caminho) e pelo portal de abertura de chamados.
  • Para remuneração por IC, quando o modelo estiver adotado: cada item de autoatendimento ativo no catálogo pode ser tratado como IC na CMDB conforme sdr-0023a; a parcela recorrente associada segue sdr-0023d — em especial uso ou prestação efetiva no período (itens sem uso no ciclo não geram linha recorrente artificial).
  • O C1-GOV audita catálogo e histórico de uso no ITSM no ciclo mensal.

8. Derivação para documentos de contratação (checklist)

Entregável O que trazer deste SDR
TR / anexos técnicos Níveis (N0–N3), localidades, perfis N3, VIP (critério e base), teto de especialista, integração C2↔C3 (logs), sem dupla contagem de CI; escopo N2 campo × N3 infra.
ETP / justificativa Premissas de parque e dimensionamento N2 (localidades); remissão à estimativa por localidade.
ANS Síntese e parâmetros alinhados a ANS modelo (§ 1.3 e anexos).
Proposta / preço Encargos de pessoal e faixas de especialista; coerente com arquitetura 3 contratos.

9. Vínculo PPSI / GSI (C2 — medidas técnicas executadas)

O PPSI é a base central de referência do projeto. O C2 executa mudança, disponibilidade, patching, inventário operacional e operação de rede/endpoints alinhados ao IN GSI/PR nº 3/2021 — em especial Capítulo II (inventário de ativos e software) e Capítulo V (gestão de mudanças nos aspectos de SI). Mapa medida × contrato: sdr-0014a. Catálogo de normas GSI/DSIC: sdr-0015a.

Controle PPSI (amostra) Tema Execução C2 (resumo)
1 Inventário de ativos CMDB operacional, descoberta, DHCP
2 Software Instalação, licenças, ciclo de vida
4 Configuração segura Baseline, aplicação de hardening pactuado
7 Vulnerabilidades Patch em janela, validação operacional pós-patch
11 Recuperação de dados Restore, mídia, continuidade operacional
12 Rede Switches, SD-WAN, links, operação de campo
13 Monitoramento de rede NOC, alarmes operacionais (com handover ao SOC C3)

Ligações

Consumidores


Agentes de conformidade (Cursor)

Os três agentes abaixo aplicam-se à edição e à revisão dos arquivos SDRs/sdr-*.md (exceto SDRs/templates/ e normas em SDRs/governance/). Este bloco é informativo; use o script na raiz do repositório para diagnóstico estrutural.

Agente Regra Cursor Norma em SDRs/governance/rules/
Verificador de conformidade SDR sdr-conformity-checker.mdc sdr-conformity-checker.md
Detector de implementação sem vínculo SDR implementation-without-sdr-detector.mdc implementation-without-sdr-detector.md
Anti-vibecoding sem SDR no-vibecoding-without-sdr.mdc no-vibecoding-without-sdr.md

Processo: governance/README.md · Rastreabilidade código: traceability.md · Checagem: python scripts/check_sdr_conformity.py (na raiz do repositório).