Métricas de Engenharia, Blindagem de Capacidade e Governança de Crise

1. Blindagem de Capacidade da Evolução

O desenvolvimento de sistemas complexos de saúde exige concentração profunda, continuidade de raciocínio e rigor no cumprimento de prazos regulatórios. O fenômeno da troca frequente de contexto (context switching) e as interrupções desordenadas constituem os maiores fatores de degradação da qualidade do código, aumento de bugs de regressão e esgotamento técnico da equipe.

Para proteger a frente de Evolução (Scrum 2+1) e garantir o cumprimento do Release Train, o modelo operacional do e-SUS AF estabelece três camadas sucessivas de filtro:

flowchart TD
    Demanda([Demandas de Usuários / Municípios / Estados]) --> C1[1. Camada 1: Filtro Funcional e Operacional
Suporte N1 / N2]

    C1 -->|Dúvida, FAQ, Regra Negocial, Parametrização| R1[Resolução Funcional / Orientação ao Usuário]
    C1 -->|Inconsistência Técnica Confirmada + DoR Válido| C2[2. Camada 2: Filtro Técnico e de Dados
Suporte N3 - 2 Membros Dedicados]

    C2 -->|Inconsistência de BD / Sem Bug de Código| R2[Script SQL Transacional Aprovado & Executado]
    C2 -->|Defeito de Código Sev 1 ou Sev 2| C3[3. Camada 3: Filtro de Engenharia Cirúrgica
Célula de Sustentação - Kanban]
    C2 -->|Defeito de Código Sev 3 ou Sev 4| BKG[Backlog de Evolução
Refinamento & Priorização pelo PO]

    C3 -->|Hotfixes Sev 1 / Bugfixes Sev 2| PROD[Esteira Curta de Produção - Patch vX.Y.Z]

    subgraph Blindagem_Evolucao["Área Blindada: Engenharia de Evolução (Scrum 2+1)"]
        BKG --> EVO_PLAN[Sprint Planning & Execução Focada]
        EVO_PLAN --> EVO_DEV[2 Sprints Dev: Novas Features & Débitos]
        EVO_DEV --> EVO_STAB[1 Sprint Estabilização & QA]
        EVO_STAB --> PROD_REL[Release Oficial vX.Y.0]
    end

    style Blindagem_Evolucao fill:#f0f9ff,stroke:#0284c7,stroke-width:2px,stroke-dasharray: 5 5

1.1. As Três Camadas de Filtro

1. Camada 1: Filtro Funcional e Operacional (Suporte N1/N2 - NQS)

   • Missão: Atender os municípios no primeiro contato, sanar dúvidas operacionais, consultar FAQs, validar parametrizações municipais e esclarecer regras de negócio da Assistência Farmacêutica.
   • Impacto na Blindagem: Absorve e resolve a esmagadora maioria das demandas sem demandar qualquer esforço de engenharia.
   • Critério de Passagem: Somente chamados que apresentem falhas de sistema não explicadas por regras de negócio e que atendam rigorosamente ao Definition of Ready (DoR) do N3 são escalonados.

2. Camada 2: Filtro Técnico e de Dados (Suporte N3 - 2 Membros Dedicados)

   • Missão: Realizar a investigação profunda de causa raiz, análise de stack traces, payloads de API e dados relacionais, reproduzir o defeito em ambiente de homologação e elaborar scripts SQL corretivos sob protocolo transacional seguro.
   • Anti-Escopo: O Suporte N3 não codifica alterações no sistema nem abre Pull Requests.
   • Impacto na Blindagem: Resolve internamente problemas decorrentes de corrupção ou inconsistência de dados operacionais e gera especificações técnicas prontas e reproduzíveis quando há defeito de código, evitando que a engenharia gaste tempo com triagem inicial.
   • Critério de Passagem: Se o problema exigir alteração no código-fonte, o N3 classifica a severidade:
     • Sev 1 e Sev 2: Encaminhados para a Sustentação (Camada 3).
     • Sev 3 e Sev 4: Encaminhados ao Backlog de Produto para refinamento pelo PO e Líder Técnico.

3. Camada 3: Filtro de Engenharia Cirúrgica (Célula de Sustentação - Kanban)

   • Missão: Atuar em fluxo contínuo sob limites rigorosos de Work in Progress (WIP) para desenvolver correções cirúrgicas, testes automatizados de regressão e pacotes de publicação rápida (Hotfixes/Patches).
   • Impacto na Blindagem: Absorve 100% dos defeitos críticos (Sev 1) e graves (Sev 2) reportados em produção, impedindo que desenvolvedores alocados nas Sprints de Evolução sejam interrompidos para apagar incêndios cotidianos.
   • Critério de Passagem: Somente em situações extremas de indisponibilidade sistêmica generalizada (Protocolo de Swarming) a Sustentação solicita apoio extraordinário da Evolução.

2. Protocolo de Crise e Mobilização Extraordinária (Swarming)

O Swarming é o procedimento formal de mobilização emergencial e temporária de desenvolvedores da frente de Evolução para atuar conjuntamente com a Sustentação na resolução de um incidente catastrófico em ambiente de produção.

sequenceDiagram
    autonumber
    actor N3 as Suporte N3 / Monitoramento
    participant TL as Líder Técnico
    participant PO as Product Owner
    participant EVO as Time de Evolução (Mobilizados)
    participant SUST as Célula de Sustentação
    participant STG as Ambiente Staging
    participant PROD as Produção

    N3->>TL: Alerta de Incidente Crítico (Sev 1 Catastrófico)
    TL->>PO: Análise de Impacto & Solicitação de Swarming
    PO-->>TL: Autorização Conjunta de Swarming & Renegociação de Sprint
    TL->>EVO: Convocação para War Room & Despriorização de Tarefas da Sprint

    rect rgb(254, 242, 242)
        Note over TL,SUST: Atuação em War Room (Sala de Crise)
        TL->>SUST: Coordenação do Diagnóstico e Seam Cirúrgico
        EVO->>SUST: Programação em Pares / Resolução do Incidente
        SUST->>STG: Deploy do Patch & Criação de Teste de Regressão
        TL->>STG: Validação Técnica & Aprovação do Hotfix
    end

    TL->>PROD: Merge na main (Tag vX.Y.Z+1) & Deploy Emergencial
    TL->>PO: Notificação de Restabelecimento dos Serviços

    rect rgb(240, 253, 244)
        Note over TL,EVO: Estabilização & Desmobilização
        PROD-->>TL: Janela de Observabilidade Estável (2h a 4h)
        TL->>EVO: Desmobilização do Time de Evolução -> Retorno à Sprint
        TL->>PO: Condução do Blameless Post-Mortem & Registro de Ações
    end

2.1. Gatilhos Objetivos e Critérios de Elegibilidade

O Swarming não pode ser banalizado. Para que seja declarado estado de crise e autorizada a convocação extraordinária, o incidente deve preencher cumulativamente os seguintes requisitos:

1. Classificação Estrita como Sev 1:
   • Indisponibilidade generalizada do e-SUS AF em nível nacional ou regional abrangente;
   • Risco iminente e em larga escala de perda ou corrupção irreversível de dados clínicos e farmacêuticos;
   • Paralisação total do módulo de dispensação de medicamentos sem qualquer alternativa de contorno;
   • Bloqueio total das integrações estruturantes do Ministério da Saúde (RNDS, CADSUS, Base Nacional);
   • Vulnerabilidade crítica de segurança ou autenticação explorável ativamente.
2. Esgotamento da Capacidade da Sustentação:
   • A complexidade arquitetural, a extensão do código afetado ou o volume de análise exigem especialistas de domínio que estão atualmente no time de Evolução.
3. Inadmissibilidade para Outras Severidades:
   • É terminantemente proibido acionar o Swarming para incidentes Sev 2, Sev 3 ou Sev 4, bem como para solicitações de negócio urgentes sem natureza de incidente crítico.

2.2. Governança e Convocação

• Autorização Obrigatória em Dupla Chave: O acionamento do Swarming exige o consenso formal entre o Líder Técnico (que valida a inviabilidade de resolução apenas pela Sustentação) e o Product Owner (que avalia as implicações negociais e chancela o impacto na Sprint de Evolução).
• Papel do Comandante de Incidente (Incident Commander): O Líder Técnico (ou engenheiro sênior por ele delegado) assume o comando unificado da operação técnica, centralizando as decisões arquiteturais, delegando tarefas e blindando o grupo de crise contra ruídos externos.
• Instalação da War Room (Sala de Crise): Criação imediata de um canal de comunicação síncrono exclusivo (canal dedicado de chat e videoconferência contínua). Toda a discussão técnica sobre o incidente ocorre exclusivamente dentro da War Room.
• Mobilização Cirúrgica: Apenas os engenheiros com conhecimento específico no módulo impactado são convocados, preservando o restante do time de Evolução em suas atividades planejadas.

2.3. Renegociação Formal de Escopo da Sprint

A mobilização de desenvolvedores para a crise gera impacto imediato na capacidade produtiva da frente de Evolução. Para manter a governança íntegra e evitar sobrecarga da equipe:

1. Ajuste de Capacidade: A velocidade planejada da Sprint é recalculada com base nas horas/dias consumidos na crise.
2. Descompromissamento Formal de Histórias: O PO e o Líder Técnico identificam no Sprint Backlog quais histórias de usuário ou débitos técnicos serão retirados da Sprint corrente e devolvidos ao Backlog do Produto.
3. Registro Transparente: O painel da Sprint (Jira/GitLab) é atualizado imediatamente com a marcação das histórias despriorizadas por motivo de Swarming.
4. Cultura de Não-Culpa na Sprint: O não cumprimento da meta original da Sprint em decorrência de Swarming formalmente aprovado é registrado como evento de força maior, não configurando déficit de desempenho do time de Evolução.

2.4. Desmobilização e Retrospectiva Pós-Crise (Blameless Post-Mortem)

A conclusão da crise segue etapas rigorosas de encerramento para garantir que o problema não retorne:

1. Critérios de Desmobilização:
   • Hotfix implantado em produção via tag semântica de patch (vX.Y.Z+1);
   • Replicação mandatória do patch na branch release/* ativa via git cherry-pick (se houver release em estabilização);
   • Janela de observabilidade concluída com sucesso (período mínimo de 2 a 4 horas de monitoramento com métricas normais de CPU, memória, latência e ausência de exceções HTTP 500 no módulo);
   • Autorização formal do Líder Técnico para encerramento da War Room e retorno dos desenvolvedores às suas tarefas da Sprint.
2. Condução do Blameless Post-Mortem:
   • Realizado obrigatoriamente em até 48 horas úteis após a resolução do incidente.
   • Participantes: Líder Técnico, PO, desenvolvedores envolvidos, Suporte N3 e QA.
   • Estrutura do Relatório de Post-Mortem:
     • Linha do Tempo Factual: Cronologia precisa desde o primeiro alerta até a normalização do serviço.
     • Análise de Causa Raiz: Aplicação da técnica dos 5 Porquês e análise de falha de barreira (por que os testes automatizados ou o QA não detectaram o problema antes da produção?).
     • Plano de Ações Preventivas e Corretivas: Criação de tarefas técnicas concretas no Backlog de Evolução (ex.: ampliação de testes unitários/E2E, melhoria de alarmes, refatoração de código frágil).

3. Painel Enxuto de Métricas Operacionais por Frente

As métricas operacionais do e-SUS AF são organizadas por frente de atuação, permitindo o diagnóstico precoce de ineficiências, sobrecargas ou deficiências na cobertura de testes.

flowchart LR
    subgraph M_N3["Métricas do Suporte N3"]
        N3_1["MTTD
< 24h úteis"]
        N3_2["Taxa Devolução N2
< 10%"]
        N3_3["Resolução por Script
40% - 60%"]
    end

    subgraph M_SUST["Métricas da Sustentação"]
        S_1["MTTR (Sev 1)
< 24h úteis"]
        S_2["Bugs Reabertos
< 5%"]
        S_3["Throughput Semanal
Estável / Fluido"]
    end

    subgraph M_EVO["Métricas da Evolução"]
        E_1["Taxa de Interrupção
< 10%"]
        E_2["Bugs Escapados
Decrescente"]
        E_3["Lead Time Release Train
4 a 6 semanas"]
    end

    M_N3 -.->|Insumo Qualificado| M_SUST
    M_SUST -.->|Proteção de Capacidade| M_EVO

3.1. Painel de Métricas do Suporte N3 (Diagnóstico & Triagem)

3.2. Painel de Métricas da Sustentação (Kanban & Incidentes)

3.3. Painel de Métricas da Evolução (Scrum & Release Train)

4. Matriz de Riscos Operacionais, Sinais de Alerta e Ações Mitigatórias

A operação de engenharia do e-SUS AF possui riscos mapeados que podem comprometer a estabilidade de produção ou o ritmo das entregas planejadas. A tabela a seguir consolida os riscos, seus sinais precoces de alerta (early warning signs) e as respectivas medidas preventivas e corretivas:

5. Rituais de Governança e Ciclo de Melhoria Contínua

Para manter o painel de métricas vivo e transformar dados em melhorias concretas de engenharia e produto, a equipe adota os seguintes rituais de governança:

flowchart TD
    D[Daily Standup Diária
• Foco em Impedimentos
• Monitoramento de Limites de WIP] --> W[Alinhamento Semanal de Operações Ops Sync
• Revisão de MTTD, MTTR e Throughput
• Identificação de Scripts Recorrentes]

    W --> S[Retrospectiva de Sprint e Release Train
• Avaliação de Taxa de Interrupção
• Análise de Bugs Escapados
• Calibração de Débitos Técnicos]

    S --> P[Relatório Mensal de Saúde Operacional
• Consolidação Executiva para PO e Coordenação
• Revisão de Políticas e SLAs]

1. Daily Standup Diária (15 minutos):
   • Foco direcionado no fluxo de trabalho: verificação de cards bloqueados, respeito estrito aos limites de WIP e acompanhamento de incidentes em andamento.
2. Alinhamento Semanal de Operações (Weekly Ops Sync - 45 minutos):
   • Encontro semanal entre o Suporte N3, a Célula de Sustentação, o QA e o Líder Técnico.
   • Pauta: Análise do MTTD e MTTR da semana, auditoria de scripts SQL executados para identificar necessidades de correção em código (Risco R06) e verificação do status das branches ativas.
3. Retrospectiva de Sprint e Release Review (Ao final de cada ciclo de release):
   • Análise dos indicadores de Taxa de Interrupção da Sprint (TIS), Bugs Escapados para Produção (BEP) e Aderência à Meta da Sprint (SGA).
   • Definição de melhorias nos processos de BDD, refatorações de código e reforço em testes de regressão automatizados.
4. Relatório Mensal de Saúde Operacional da Engenharia:
   • Documento síntese consolidado pelo Líder Técnico e PO, apresentando os indicadores de disponibilidade, tempos de resposta a incidentes e entregas de evolução aos gestores do e-SUS AF e ao Ministério da Saúde.