# 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](../../arquitetura-contratual/site/operacao.html#regras-contratuais-c2) | --- ## 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](./sdr-0002-imr-unidades-e-evidencias.md)). - 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](../../arquitetura-contratual/site/seguranca.html). - **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 nuvem** — **escalonar 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](./sdr-0004-parque-localidades-ativos.md) 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](./sdr-0023a-catalogo-ic-por-contrato.md); a **parcela recorrente** associada segue [sdr-0023d](./sdr-0023d-prestacao-efetiva-ic-periodo-faturado.md) — 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](../processo-contratacao/02_planejamento_in94/documentos/estimativa-quantitativa-ativos-por-localidade.md). | | **ANS** | Síntese e parâmetros alinhados a [ANS modelo](../../arquitetura-contratual/ANS-Acordo-de-Niveis-de-Servico-modelo.md) (§ 1.3 e anexos). | | **Proposta / preço** | Encargos de pessoal e faixas de especialista; coerente com [arquitetura 3 contratos](./sdr-0001-arquitetura-tres-contratos.md). | --- ## 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](./sdr-0014a-ppsi-mapeamento-trilateral.md). Catálogo de normas GSI/DSIC: [sdr-0015a](./sdr-0015a-catalogo-gsi-dsic.md). | 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 - [sdr-0002-imr-unidades-e-evidencias.md](./sdr-0002-imr-unidades-e-evidencias.md) — CIs, evidência, congelamento - [sdr-0004-parque-localidades-ativos.md](./sdr-0004-parque-localidades-ativos.md) — localidades e premissas de inventário - [sdr-0001-arquitetura-tres-contratos.md](./sdr-0001-arquitetura-tres-contratos.md) — fronteira C1/C2/C3 - [sdr-0003-indice-fonte-unica.md](./sdr-0003-indice-fonte-unica.md) - [sdr-0014a-ppsi-mapeamento-trilateral.md](./sdr-0014a-ppsi-mapeamento-trilateral.md) - [sdr-0015a-catalogo-gsi-dsic.md](./sdr-0015a-catalogo-gsi-dsic.md) - [sdr-0023a-catalogo-ic-por-contrato.md](./sdr-0023a-catalogo-ic-por-contrato.md) - [sdr-0023d-prestacao-efetiva-ic-periodo-faturado.md](./sdr-0023d-prestacao-efetiva-ic-periodo-faturado.md) ## Consumidores - [Operação (site) — regras mínimas TR](../../arquitetura-contratual/site/operacao.html#regras-contratuais-c2), ETP, TR, anexo de capacidade, ANS. --- ## 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`](../.cursor/rules/sdr-conformity-checker.mdc) | [`sdr-conformity-checker.md`](./governance/rules/sdr-conformity-checker.md) | | Detector de implementação sem vínculo SDR | [`implementation-without-sdr-detector.mdc`](../.cursor/rules/implementation-without-sdr-detector.mdc) | [`implementation-without-sdr-detector.md`](./governance/rules/implementation-without-sdr-detector.md) | | Anti-vibecoding sem SDR | [`no-vibecoding-without-sdr.mdc`](../.cursor/rules/no-vibecoding-without-sdr.mdc) | [`no-vibecoding-without-sdr.md`](./governance/rules/no-vibecoding-without-sdr.md) | **Processo:** [`governance/README.md`](./governance/README.md) · **Rastreabilidade código:** [`traceability.md`](./traceability.md) · **Checagem:** `python scripts/check_sdr_conformity.py` (na raiz do repositório).