Documento MestrePRODEMGE
Parte VII — Operação
Parte VII — OperaçãoCapítulo 48 Revisado

Capítulo 48 — Implantação e Onboarding de Tenants

Este capítulo descreve o processo completo de provisionar, configurar, validar e colocar em operação um novo tenant na plataforma. O onboarding é automatizado o máximo possível, mas mantém checkpoints de validação e apro…

48.1 Objetivo do Capítulo

Este capítulo descreve o processo completo de provisionar, configurar, validar e colocar em operação um novo tenant na plataforma. O onboarding é automatizado o máximo possível, mas mantém checkpoints de validação e aprovação onde apropriado.

O capítulo cobre: modelo operacional, fluxo de requisição, provisionamento automatizado, configuração inicial, testes de integração, treinamento, go-live e suporte inicial.


48.2 Princípios de Onboarding

  1. Self-service com governança — tenants autoservem o máximo possível; checkpoints críticos exigem aprovação;
  2. Automação total — provisão, configuração, testes, ambiente — sem intervenção manual;
  3. Validação contínua — cada etapa valida pré-condições e pós-condições automaticamente;
  4. Rastreabilidade — toda ação é auditada e reversível até certo ponto;
  5. Isolamento desde o início — dados, permissões, quotas segregados desde a criação;
  6. Testes obrigatórios — ambiente staging com dados de teste antes de produção;
  7. Documentação executável — runbooks testados, não apenas descrições;
  8. Suporte responsável — equipe designada para o novo tenant nos primeiros 30 dias.

48.3 Modelo Operacional de Onboarding

48.3.1 Papéis

PapelResponsabilidade
RequerenteÓrgão/entidade solicitando onboarding
Produto ManagerAprova requisição, alinha escopo
Platform TeamExecuta provisionamento, validação, suporte inicial
Security TeamValida conformidade, políticas, isolamento
OperationsMonitora saúde pós-go-live

48.3.2 Timeline Padrão

Requisição aprovada
  │
  ├─ Dia 1-2: Provisionamento automatizado
  │
  ├─ Dia 3-5: Testes de integração + validação
  │
  ├─ Dia 6-10: Staging com dados de teste
  │
  ├─ Dia 11-14: Treinamento e documentação
  │
  ├─ Dia 15: Go-live para produção
  │
  └─ Dia 16-45: Suporte intensivo (on-call)

Prazo total: ~4 semanas da aprovação ao suporte normal.


48.4 Fluxo de Requisição de Onboarding

48.4.1 Submissão

Requerente completa formulário com:

  • Nome da organização
  • Sigla/código
  • Órgão responsável
  • Escopo de serviços (quais módulos)
  • Previsão de usuários
  • Data desejada de go-live
  • Contatos técnicos e de negócio

48.4.2 Validação de Pré-Requisitos

Sistema verifica automaticamente:

  • Sigla única (sem duplicatas)
  • Dados de contato válidos
  • Capacidade de cluster (quotas disponíveis)
  • Requisitos de serviços atendíveis

Se falhar: rejeição automática com motivo; requerente corrige e resubmete.

48.4.3 Aprovação

Aprovador (Produto Manager) verifica:

  • Alinhamento com estratégia
  • Conflitos de interesse
  • Capacidade orçamentária

Aprova ou rejeita com justificativa.

48.4.4 Agendamento

Após aprovação, Platform Team agenda:

  • Reunião kickoff
  • Slots de validação
  • Slot de go-live (fora de horário de pico)

48.5 Provisionamento Automatizado

48.5.1 Pipeline de Provisionamento

Requisição aprovada
  │
  ├─ Criar tenant no IAM
  │
  ├─ Criar namespace Kubernetes
  │
  ├─ Provisionar banco de dados (schema + credenciais)
  │
  ├─ Provisionar storage (buckets, quotas)
  │
  ├─ Criar coleção de vector store
  │
  ├─ Configurar network policies (isolamento)
  │
  ├─ Configurar RBAC (perfis iniciais)
  │
  ├─ Registrar tenant em service discovery
  │
  └─ Notificar conclusão

48.5.2 IaC — Terraform/Helm

Provisionamento declarativo via IaC:

# tenants/org-a/main.tf
module "tenant" {
  source = "../../modules/tenant"
  
  tenant_id = "org-a"
  tenant_name = "Secretaria de Educação"
  
  namespace = "tenant-org-a"
  
  database = {
    storage = "100Gi"
    backup_retention = 30
  }
  
  quotas = {
    cpu = "10"
    memory = "20Gi"
    storage = "500Gi"
  }
  
  modules = ["solicitacoes", "agendamentos", "documentos"]
}

Terraform apply provisiona toda a infraestrutura.

48.5.3 Automação com CI/CD

# .github/workflows/tenant-onboarding.yml
name: Tenant Onboarding

on:
  workflow_dispatch:
    inputs:
      tenant_id:
        description: 'Tenant ID'
        required: true

jobs:
  provision:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      - name: Terraform Plan
        run: |
          terraform -chdir=tenants/${{ inputs.tenant_id }} plan -out=tfplan
      
      - name: Terraform Apply
        run: |
          terraform -chdir=tenants/${{ inputs.tenant_id }} apply tfplan
      
      - name: Validate Tenant
        run: |
          ./scripts/validate-tenant.sh ${{ inputs.tenant_id }}
      
      - name: Notify Success
        run: |
          curl -X POST $WEBHOOK_URL -d '{"tenant": "${{ inputs.tenant_id }}", "status": "provisioned"}'

48.6 Configuração Inicial

48.6.1 Dados de Configuração

Platform Team configura:

  • Identidade visual — logomarca, cores, textos institucionais
  • Políticas de autenticação — MFA obrigatória, política de senha
  • Canais de comunicação — e-mail, SMS, WhatsApp
  • Integrações — SEI!MG, MG API, Data Lake
  • Quotas de usuários — limite inicial, upgrade posterior
  • Retenção de dados — política por tipo

48.6.2 Usuários Iniciais

# scripts/create-initial-users.sh
#!/bin/bash

TENANT_ID=$1

# Criar usuários administrativos
kubectl exec -it tenant-admin-$TENANT_ID -- \
  python manage.py create_user \
    --username "admin@$TENANT_ID" \
    --role "TENANT_ADMIN" \
    --send-invite

# Criar usuários operacionais
kubectl exec -it tenant-admin-$TENANT_ID -- \
  python manage.py bulk_create_users \
    --file ./users-$TENANT_ID.csv \
    --role "OPERATOR" \
    --send-invite

48.7 Testes de Integração

48.7.1 Suite de Testes Automatizada

# scripts/validate-tenant.sh
#!/bin/bash

TENANT_ID=$1
ENDPOINT="https://api.platform/tenants/$TENANT_ID"

echo "1. Verificando conectividade..."
curl -f $ENDPOINT/health || exit 1

echo "2. Verificando isolamento de dados..."
curl -f $ENDPOINT/api/solicitacoes \
  -H "Authorization: Bearer $TOKEN_ORG_B" \
  && exit 1 # Deve falhar para outro tenant

echo "3. Verificando integrações..."
curl -f $ENDPOINT/integrations/sei/health || exit 1

echo "4. Verificando storage..."
curl -f -X POST $ENDPOINT/documents/test \
  -F "file=@test.pdf" || exit 1

echo "5. Verificando IA..."
curl -f -X POST $ENDPOINT/ai/chat \
  -d '{"message": "Teste"}' || exit 1

echo "Validação concluída com sucesso!"

48.7.2 Cenários de Teste

CenárioDescriçãoStatus
Isolamento multi-tenantDados de tenant A não acessíveis por B
AutenticaçãoLogin com credenciais inválidas falha
AutorizaçãoOperador não acessa endpoints admin
Integração SEI!MGSincronização bidirecional
CriptografiaDados sensíveis criptografados em repouso
BackupSnapshot restaurável

48.8 Staging com Dados de Teste

48.8.1 Ambiente de Staging

Cópia espelhada de produção com dados sintéticos:

# tenants/org-a/staging-values.yaml
environment: staging
replicas: 2 # produção tem 3+

database:
  pool_size: 10 # menor que produção
  
  # Dados de teste
  seed_services: 20
  seed_requests: 500
  seed_users: 50

48.8.2 Dados de Teste Realistas

-- scripts/seed-staging.sql
INSERT INTO services (tenant_id, name, description) VALUES
  ('org-a', 'Matrícula Escolar', 'Processo de matrícula em escolas públicas'),
  ('org-a', 'Licença Escolar', 'Solicitação de licença médica'),
  ('org-a', 'Transferência Escolar', 'Transferência entre escolas');

INSERT INTO requests (tenant_id, service_id, citizen_id, status, created_at) VALUES
  ('org-a', 1, 'citizen-001', 'SUBMITTED', NOW() - INTERVAL 5 DAY),
  ('org-a', 2, 'citizen-002', 'APPROVED', NOW() - INTERVAL 2 DAY),
  ('org-a', 3, 'citizen-003', 'REJECTED', NOW() - INTERVAL 1 DAY);

48.8.3 Validação em Staging

Requerente testa:

  • Jornada completa de cidadão (login → solicitação → acompanhamento)
  • Jornada de operador (atendimento, complementação, conclusão)
  • Integrações (envio para SEI!MG, recebimento de atualizações)
  • Performance (carga com 100 usuários simultâneos)
  • Segurança (tentativa de acesso cruzado)

Feedback é capturado e bugs são corrigidos.


48.9 Treinamento e Documentação

48.9.1 Materiais de Treinamento

  • Vídeos tutoriais — jornada do cidadão, jornada do operador (5-10 min cada)
  • Guias passo a passo — abertura de solicitação, consulta de protocolo
  • Referência rápida — funcionalidades principais em 1 página
  • FAQ — perguntas comuns e respostas
  • Glossário — termos da plataforma

48.9.2 Sessões de Treinamento

Dia 1: Visão geral (2h)
  - Contexto: por que a plataforma, alinhamento com políticas
  - Visão geral de funcionalidades
  - Segurança e privacidade

Dia 2: Jornada do cidadão (3h)
  - Portal web
  - Aplicativo mobile
  - Integração com GOV.BR

Dia 3: Jornada do operador (3h)
  - Painel de gestão
  - Atendimento, complementação, conclusão
  - Relatórios e analytics

Dia 4: Suporte e troubleshooting (2h)
  - Contatos de suporte
  - Escalação
  - Health checks básicos

48.9.3 Documentação Customizada

# Plataforma de Relacionamento Digital — Guia da Secretaria de Educação

## Serviços Disponíveis

1. **Matrícula Escolar** — cidadão solicita matrícula em escola pública
2. **Licença Escolar** — solicitação de licença médica
3. **Transferência Escolar** — transferência entre unidades

## Contatos

- **Suporte técnico**: suporte@plataforma.gov.br, (31) 3999-9999
- **Gestor de Projeto**: gerente@educacao.mg.gov.br
- **Escalação**: escalacao@plataforma.gov.br

48.10 Go-Live

48.10.1 Checklist Pré-Go-Live

  • Todas as integrações testadas
  • Dados de teste limpados
  • Backups iniciados
  • Monitoramento configurado
  • On-call designado
  • Rollback plan documentado
  • Comunicação preparada (avisos ao cidadão)

48.10.2 Janela de Go-Live

Agendado para fora de picos de uso (ex.: 2h da manhã, domingo).

T-0: Último backup de staging
T+0: Deploy em produção (blue-green ou canary)
T+5min: Smoke tests
T+15min: Monitoramento ativo
T+1h: Liberação de acesso para primeiros usuários (10%)
T+4h: Aumento gradual para 50% dos usuários
T+8h: 100% dos usuários com monitoramento intensivo
T+24h: Validação de sucesso, celebração

48.11 Suporte Intensivo (Primeiros 30 Dias)

48.11.1 Equipe Dedicada

Designados:

  • Engenheiro sênior — resolução de bugs e performance
  • Especialista em integração — suporte a APIs externas
  • Especialista de negócio — questões de funcionalidade

Disponível 24/7 com SLA de resposta 1h.

48.11.2 Monitoramento Proativo

# monitoring/tenant-health.yaml
alerts:
  - name: error_rate_high
    condition: error_rate > 1%
    action: page_oncall
  
  - name: database_connection_pool_high
    condition: pool_usage > 80%
    action: page_oncall
  
  - name: backup_failed
    condition: last_backup > 24h
    action: email_team

48.11.3 Daily Standups

Reunião diária (15 min) com:

  • Requerente (gestor do projeto)
  • Platform Team (lead + engenheiro)
  • Agenda: issues do dia anterior, blockers, próximas ações

48.12 Encerramento do Onboarding

48.12.1 Critérios de Sucesso

  • 95%+ de disponibilidade nos primeiros 7 dias
  • Nenhum incidente crítico não resolvido
  • Feedback positivo do requerente
  • Documentação atualizada
  • Suporte transicionado para equipe normal

48.12.2 Retrospectiva

Reunião pós-go-live com:

  • O que funcionou bem
  • O que pode melhorar
  • Lições para próximos onboardings
  • Feedback do requerente

48.13 Runbook de Onboarding

#!/bin/bash
# runbook-onboarding.sh

TENANT_ID=$1
TENANT_NAME=$2

set -e

echo "=== Onboarding de Tenant ==="

# 1. Validar pré-requisitos
echo "1. Validando pré-requisitos..."
./scripts/validate-prereqs.sh $TENANT_ID

# 2. Provisionar
echo "2. Provisionando infraestrutura..."
terraform -chdir=tenants/$TENANT_ID apply -auto-approve

# 3. Validar provisionamento
echo "3. Validando provisionamento..."
./scripts/validate-tenant.sh $TENANT_ID

# 4. Configurar
echo "4. Configurando tenant..."
./scripts/configure-tenant.sh $TENANT_ID "$TENANT_NAME"

# 5. Testes
echo "5. Executando testes..."
./scripts/run-tests.sh $TENANT_ID

# 6. Notificar
echo "6. Notificando conclusão..."
curl -X POST $WEBHOOK_URL \
  -d "{\"tenant\": \"$TENANT_ID\", \"status\": \"onboarded\"}"

echo "=== Onboarding concluído com sucesso! ==="

48.14 Rastreabilidade com Anexo III

O Capítulo 48 suporta:

Item ANX-IIIAtendimento
1.1Canal multicanal com onboarding automatizado
1.11Personalização por tenant desde a criação
6.1Isolamento estrutural desde provisionamento

48.15 Riscos e Mitigações

RiscoMitigação
Dados de teste não limposValidação automática pré-go-live
Falha parcial de provisionamentoIdempotência de scripts; retry automático
Configuração incorretaValidação pós-provisionamento
Suporte indisponívelOn-call 24/7 por 30 dias
Rollback falhaTeste de rollback antes de go-live

48.16 ADRs

ADRTema
ADR-1501Automatização de provisionamento — IaC vs. scripts
ADR-1502Timeline de onboarding — 4 semanas vs. acelerado
ADR-1503Suporte intensivo — 30 dias vs. sob demanda
ADR-1504Data de go-live — noturna vs. horário comercial
ADR-1505Rollback — automático vs. manual

48.17 Controle de Versão

CampoValor
DocumentoDocumento Mestre — Plataforma de Relacionamento Digital com o Cidadão
Capítulo48 — Implantação e Onboarding de Tenants
Versão1.0
SituaçãoConcluído
Última atualização16/07/2026

48.18 Rastreabilidade PRODEMGE

  • [ANX-III] Bloco 1 itens 1.1, 1.11; Bloco 6 item 6.1
  • [ANX-IV] Capacidades 3.1.10 (multi-tenancy), 3.3.1 (escalabilidade)
  • [ANX-V] Item 2.1 (manutenibilidade via automação)
  • [PNR] Anexo I seção 3.1.10 — onboarding de tenants automatizado

48.19 Próximo Capítulo

O Capítulo 49 detalha a Operação e Suporte Contínuo após o onboarding inicial, incluindo monitoramento, incident response e evolução.


48.20 Referências Internas

  • Capítulo 30 — Gestão Multi-Tenant
  • Capítulo 37 — Infraestrutura e Computação em Nuvem
  • Capítulo 40 — DevSecOps e Entrega Contínua
  • Capítulo 41 — Observabilidade e Monitoramento
  • Capítulo 45 — Auditoria e Rastreabilidade

On this page