Capítulo 10 — Qualidade e solução de problemas

Mapa da aula

Aula 10 publicada. Mapa, exemplo, EX046.

flowchart TD
  N0["10.1 Tickets completos"]
  N1["10.2 Correções paradas"]
  N2["10.3 Métricas de qualidade"]
  N3["10.4 Correções de processo sem culpados"]
  N4["10.5 Solução de problemas nos testes"]
  N5["10.6 Reprovações no reteste"]
  N6["10.7 Qualidade por amostragem"]
  N7["10.8 Escada de escalonamento"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX046"]

Desenho lógico

flowchart LR
  N0["10.1 Tickets completos"]
  N1["10.2 Correções paradas"]
  N2["10.3 Métricas de qualidade"]
  N3["10.4 Correções de processo sem culpados"]
  N4["10.5 Solução de problemas nos testes"]
  N5["10.6 Reprovações no reteste"]
  N6["10.7 Qualidade por amostragem"]
  N7["10.8 Escada de escalonamento"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]

[10.1 Tickets completos]
    |
    v
[10.2 Correções paradas]
    |
    v
[10.3 Métricas de qualidade]
    |
    v
[10.4 Correções de processo sem culpados]
    |
    v
[10.5 Solução de problemas nos testes]
    |
    v
[10.6 Reprovações no reteste]
    |
    v
[10.7 Qualidade por amostragem]
    |
    v
[10.8 Escada de escalonamento]
    |
    v
[Exemplo resolvido] --> [Exercício EX046]

Objetivos de aprendizagem

Você vai (1) revisar tickets quanto à completude; (2) destravar uma correção parada; (3) medir a qualidade do engajamento; (4) corrigir falhas de processo sem buscar culpados.

10.1 Tickets completos

Cada ticket de correção precisa de um responsável, um prazo e uma nota de verificação. Tickets incompletos escondem risco. O lab_ticket marca o T-15 como incompleto em owner e verified, e o T-18 como incompleto em due date; Leo não os conta como prontos para fechamento. T-12 e T-21 são os dois tickets prontos para fechamento, cada um com responsável, prazo e verificação preenchidos, por isso o laboratório mostra dois de quatro tickets prontos para fechamento. Tickets completos são os únicos que não escondem nada, e é por isso que um ticket com qualquer campo em branco fica fora da contagem de prontos para fechamento, por mais perto que sua correção pareça estar.

10.2 Correções paradas

Se um prazo vence, Leo verifica se o responsável mudou, se a correção está bloqueada ou se a constatação foi mal compreendida — e então escala com fatos. No T-18, a lacuna é o prazo, por isso Leo combina um com a equipe de rede antes de escalar qualquer coisa. O escalonamento então leva esses fatos em uma linha do tempo de uma página, e não apenas frustração. Um prazo parado sem essa linha do tempo vira uma discussão de humor; com ela, o CISO pode redistribuir o trabalho ou aceitar o risco em uma única reunião, sem precisar decifrar o humor de ninguém.

10.3 Métricas de qualidade

Métricas úteis: porcentagem de constatações com responsável, mediana do tempo até o reteste, contagem de pausas de escopo. Métricas de vaidade (contagem bruta de constatações) enganam.

"""Lab 10: check synthetic remediation tickets for owner, due date and verification note."""
tickets = [
    {"id": "T-12", "owner": "app-sec", "due": "2026-11-01", "verified": "retest ok"},
    {"id": "T-15", "owner": "", "due": "2026-11-01", "verified": ""},
    {"id": "T-18", "owner": "network", "due": "", "verified": "pending"},
    {"id": "T-21", "owner": "app-sec", "due": "2026-10-20", "verified": "retest ok"},
]
for t in tickets:
    gaps = [k for k in ("owner", "due", "verified") if not t[k]]
    print(f"{t['id']} {'OK' if not gaps else 'INCOMPLETE: ' + ','.join(gaps)}")
print("closed-ready:", sum(1 for t in tickets if t["owner"] and t["due"] and t["verified"] == "retest ok"))

Execute com python3 lab_ticket.py. Saída verificada:

T-12 OK
T-15 INCOMPLETE: owner,verified
T-18 INCOMPLETE: due
T-21 OK
closed-ready: 2

O laboratório mostra dois de quatro tickets prontos para fechamento. Leo informa ao CISO essa taxa de higiene, a mediana do tempo até o reteste e a contagem de pausas de escopo. Contagens brutas de constatações sem validação ficam fora dos slides de gestão.

A mediana do tempo até o reteste vai da nota do responsável dizendo que a correção está no ar até o registro de aprovação ou reprovação de Leo no ticket. A contagem de pausas de escopo inclui a pergunta sobre o nome de host das 09:40, mostrando ao CISO que as pausas acontecem e são registradas.

10.4 Correções de processo sem culpados

Se dois tickets ficaram sem responsável, melhore o modelo, em vez de apenas criticar as pessoas. Depois que dois tickets ficaram sem responsável, Leo atualiza o modelo para que o responsável seja obrigatório na criação, e o rastreador agora se recusa a salvar um novo ticket até que o campo de responsável tenha um nome. As correções de processo impedem que a mesma lacuna volte no mês seguinte. Correções de processo sem culpados são melhores do que apontar indivíduos; a qualidade dos tickets na Harborline Credit Union não pode depender de heróis que se lembrem de perguntar, por isso a HCU mede mudanças no modelo, e não quem esqueceu no mês passado.

10.5 Solução de problemas nos testes

Quando um reteste falha inesperadamente, verifique se você atingiu o mesmo sistema e a mesma versão que o responsável corrigiu. Antes de marcar um reteste como reprovado, Leo compara nomes de host, portas e versões de build com a nota de mudança do responsável; se não coincidirem, ele agenda um esclarecimento do alvo. Atingir o slot de homologação errado desperdiça o tempo de todos e cria uma falsa reprovação que envenena a confiança no rastreador. A solução de problemas em um reteste começa pela identidade do alvo, e não pela culpa de quem fez a correção. Cada divergência que ele encontra é anotada no ticket, para que o responsável e Leo concordem sobre o alvo antes do próximo reteste.

10.6 Reprovações no reteste

Se um reteste ainda encontra o problema, Leo arquiva as evidências, mantém o ticket aberto e pergunta se a correção foi implantada no sistema que ele testou. Muitos "retestes reprovados" são divergências de versão, e não trabalho ignorado. Divergências de versão são comuns quando os responsáveis corrigem a produção e Leo ainda aponta para um build antigo da homologação. A nota de reteste de Leo registra qual build ele atingiu e qual build o responsável implantou, para que qualquer divergência fique visível, e esclarecer o alvo muitas vezes transforma um reteste reprovado em um ajuste de agenda, em vez de uma conversa sobre culpa. Quando o build certo é atingido e o problema persiste, o ticket continua aberto, com as novas evidências anexadas.

10.7 Qualidade por amostragem

Uma vez por mês, Leo sorteia cinco tickets fechados e verifica se existem evidências de verificação. A falta de evidências reabre o ticket, com uma nota ao responsável. Os cinco tickets da amostra são escolhidos ao acaso entre os fechados no mês anterior. A amostragem detecta cedo a deriva do processo; a amostragem mensal é como a Harborline Credit Union percebe a deriva antes de um examinador, e um fechamento sem verificação é rejeitado na revisão semanal. Um ticket reaberto conta contra os números de fechamento que Leo informa ao CISO até que novas evidências de reteste sejam anexadas.

10.8 Escada de escalonamento

Os tickets atrasados vão primeiro ao responsável, depois ao gestor do responsável e depois ao CISO, com o prazo original e o número de lembretes. A escada é escrita para que o escalonamento não seja pessoal, e Leo a segue para que um atraso não vire uma briga pessoal. Cada degrau tem uma espera fixa, para que o gestor do responsável só saiba de um atraso depois que o responsável teve a chance de responder. O CISO vê o prazo original e quantos lembretes já foram enviados, o que torna a próxima decisão simples. Essa decisão — redistribuir, prorrogar ou aceitar o risco — é escrita de volta no ticket.

Exemplo resolvido (HCU sintética)

A verificação de tickets de Leo mostra T-12 e T-21 prontos para fechamento; o T-15 não tem responsável nem verificação; o T-18 não tem prazo. Ele atribui o T-15 à segurança de aplicações, define o prazo do T-18 com a equipe de rede e atualiza o modelo de ticket para exigir esses campos.

Caso sintético — Harborline Credit Union (HCU). A cooperativa de crédito, Leo Okonkwo e todos os números foram inventados para fins didáticos.

Erros e limites

Políticas e leis locais variam; siga a autorização da HCU e a sua jurisdição. Este livro nunca autoriza testes em sistemas reais.

Exercícios

• EX046 — Contagem de prontos para fechamento. O que o laboratório imprime para closed-ready?
  Mostrar critérios de avaliação

  Rubrica: 3 = closed-ready: 2; 2 = 2; 1 = 4; 0 = nada.
• EX047 — Lacunas do T-15. O que está errado com o T-15?
  Mostrar critérios de avaliação

  Rubrica: 3 = faltam o responsável e a verificação; 2 = um dos dois; 1 = vago; 0 = nada.
• EX048 — Perguntas sobre a parada. Dê duas perguntas que Leo faz quando um prazo atrasa.
  Mostrar critérios de avaliação

  Rubrica: 3 = duas entre mudança de responsável, bloqueio, mal-entendido, prioridade; 2 = uma; 1 = culpa; 0 = nada.
• EX049 — Métrica ruim. Por que o "número de constatações" é uma métrica de qualidade fraca?
  Mostrar critérios de avaliação

  Rubrica: 3 = incentiva o ruído / pune a definição cuidadosa do escopo; 2 = parcial; 1 = é a melhor; 0 = nada.
• EX050 — Correção no modelo. Que mudança no modelo evita as lacunas do T-15/T-18?
  Mostrar critérios de avaliação

  Rubrica: 3 = exigir responsável, prazo e verificação antes que o ticket saia da triagem; 2 = parcial; 1 = vago; 0 = nada.

Síntese

Qualidade é ter tickets completos, métricas honestas e correções de processo quando a mesma lacuna se repete.

Continue estudando — capítulo 10 de 12

← Capítulo 09 (rascunho) · Índice de capítulos do curso · Capítulo 11 (rascunho) →