Capítulo 13 — Solução de problemas
Mapa da aula
Aula 13 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["13.1 Árvore"]
N1["13.2 Falha de ferramenta"]
N2["13.3 Pacote de escalonamento"]
N3["13.4 Contornos"]
N4["13.5 Depuração em dupla"]
N5["13.6 Impacto nos clientes"]
N6["13.7 Baseline sabidamente boa"]
N7["13.8 Tempo limitado para o ego"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["13.1 Árvore"]
N1["13.2 Falha de ferramenta"]
N2["13.3 Pacote de escalonamento"]
N3["13.4 Contornos"]
N4["13.5 Depuração em dupla"]
N5["13.6 Impacto nos clientes"]
N6["13.7 Baseline sabidamente boa"]
N7["13.8 Tempo limitado para o ego"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[13.1 Árvore]
|
v
[13.2 Falha de ferramenta]
|
v
[13.3 Pacote de escalonamento]
|
v
[13.4 Contornos]
|
v
[13.5 Depuração em dupla]
|
v
[13.6 Impacto nos clientes]
|
v
[13.7 Baseline sabidamente boa]
|
v
[13.8 Tempo limitado para o ego]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem
Você vai (1) seguir uma árvore de solução de problemas para verificações que falharam; (2) separar falhas de ferramenta de achados reais; (3) escalar com evidências; (4) documentar contornos com segurança.
13.1 Árvore
Sintoma → reproduzir → verificar escopo/conta/ferramenta → verificar a saúde da homologação → escalar. Na prática, a árvore começa pelo escopo, depois a saúde da ferramenta e então o ambiente. A situação de aprovação do serviço em escuta é a primeira pergunta do cartão de solução de problemas, então Sam verifica se a porta 8080 foi alguma vez aprovada antes de depurar por que o lab_ports a relatou. Pôr o escopo em primeiro lugar evita caçadas falsas à ferramenta: uma hora gasta consertando uma ferramenta de varredura que sinalizou corretamente uma porta não aprovada é uma hora tirada da janela para nada. Só depois de o escopo estar resolvido o cartão passa às verificações da ferramenta e do ambiente.
13.2 Falha de ferramenta
Erros de certificado no notebook do testador não são achados da API. Uma falha de ferramenta, como uma queda ou uma saída vazia, é registrada junto com a versão fixada da ferramenta. Sam então passa para o script de baseline sabidamente bom, a versão da semana anterior, cujo caminho está escrito no caderno, e não guardado na memória. Improvisar novas flags no meio de um incidente é proibido, porque uma flag não testada pode mudar o padrão de tráfego e romper os limites de taxa combinados no cartão de método.
13.3 Pacote de escalonamento
Sintoma, passos, capturas de tela, horário, o que você já descartou. O pacote de escalonamento do ENG-512 de Sam tem quatro campos: o identificador do chamado, o último hash bom, a mensagem de parada exata que foi publicada e os contatos do responsável. O último hash bom diz ao plantão qual arquivo de evidência estava íntegro antes do problema, para que ninguém o colete de novo às cegas. Montar o pacote leva cerca de cinco minutos e poupa ao engenheiro de plantão uma longa história verbal. Listar o que já foi descartado impede que o engenheiro repita verificações que Sam fez uma hora antes.
13.4 Contornos
Flags temporárias de ferramenta são registradas e removidas depois; elas não viram configuração permanente silenciosa. Contornos que mudam o escopo são proibidos de saída. Se um contorno sondaria um host que não está na lista do ENG-512, ele espera por um texto de ROE atualizado, e um pedido de atualização das ROE é a única forma legítima de um contorno acrescentar um host. Mudanças de escopo engenhosas feitas no meio de uma sessão travada não são solução de problemas; são testes não aprovados, e são registradas como tal na revisão pós-ação, em vez de desculpadas porque a ferramenta original estava falhando.
13.5 Depuração em dupla
Problemas difíceis ganham um segundo técnico depois de quinze minutos. A depuração em dupla põe esse segundo técnico na visão do jump host, onde ele vê a mesma saída e pode cortar um buraco de coelho que já estourou o tempo limitado. As sessões em dupla são marcadas no calendário antes de a janela abrir, para que o horário exista antes de alguém travar. Torcer para que um colega passe por acaso não é trabalhar em dupla, e geralmente significa que o engenheiro travado continua cavando sozinho até que a maior parte da janela tenha passado.
13.6 Impacto nos clientes
Se os passageiros podem ser afetados, pare e ligue para o contato de emergência antes de uma depuração profunda. Impacto nos clientes significa passageiros vendo erros no planejador de viagens. Qualquer indício de dano visível aos passageiros interrompe imediatamente todo trabalho de ENG, antes de a análise de causa raiz continuar, e a parada usa o mesmo modelo de mensagem do exercício do laço de autenticação. O impacto vem antes da curiosidade sobre uma causa raiz inacabada: a causa pode ser investigada depois que o contato de emergência confirmar que os passageiros não são mais afetados e que a homologação voltou a ficar estável.
13.7 Baseline sabidamente boa
Sam mantém um curl sabidamente bom para o endpoint de saúde da homologação. Se ele falha, o ambiente está quebrado e os achados esperam. Ao lado do curl, a baseline sabidamente boa é o script fixado da semana anterior e as linhas ok que ele imprimiu. Quando surge de repente uma tempestade de NOT APPROVED, Sam abre essa saída fixada e compara a nova execução com ela antes que alguém abra uma conversa culpando a rede. Se o script antigo ainda imprime as linhas esperadas, a mudança está no alvo ou no escopo; se não imprime, o ambiente é o primeiro suspeito.
13.8 Tempo limitado para o ego
Depois de quinze minutos sozinho, ele precisa pedir ajuda. O silêncio heroico desperdiça a janela do engajamento. O tempo limitado existe para proteger a janela do ENG-512 do orgulho. Quinze minutos travado numa ferramenta significam escalar para a dupla ou para o líder, e não tentar mais uma flag em silêncio. Quando o ego atrasa a chamada, a revisão pós-ação diz isso claramente e registra quantos minutos foram perdidos, para que o padrão fique visível para toda a equipe. Escalar cedo é recompensado nessa revisão, e não tratado como sinal de fraqueza.
13.9 Disciplina de campo
As notas de solução de problemas de Sam usam os mesmos rótulos Fato/Palpite dos casos. "Palpite: o WAF está bloqueando meu IP" só vira Fato depois que o log do WAF mostra o bloqueio. Essa disciplina o impede de "consertar" o WAF com volume para ver o que acontece — um comportamento que parece uma negação de serviço e viola as ROE. A disciplina de campo para a solução de problemas é árvore, baseline, dupla, tempo limitado e parada diante de impacto nos passageiros. A revisão pós-ação de Sam recompensa o escalonamento cedo. Esses hábitos importam mais do que resolver todas as falhas, porque cada um impede que uma sessão travada vire um teste não aprovado ou inseguro.
13.10 Nota de encerramento
Quando o escalonamento é necessário, Sam avisa juntos o líder do engajamento e o responsável pelo produto, para que ninguém saiba de segunda mão que a homologação não está saudável. A regra final é que a solução de problemas existe para proteger a janela e os sistemas por trás dela. Encontrar a falha plantada importa menos do que parar quando alertas de tarifa aparecem em qualquer lugar, então um alerta de tarifa encerra a solução de problemas mesmo com a falha plantada ainda sem solução. Uma falha não resolvida pode ser retomada na próxima sessão, mas um teste que continuou durante um alerta de tarifa é uma falha de segurança que nenhuma correção posterior desfaz.
Exemplo resolvido (NMT sintética)
As verificações de API de Sam falham com erros de TLS; a homologação funciona normalmente no navegador do jump host. Ele atualiza o repositório de certificados raiz do notebook, executa de novo e documenta o problema do notebook separadamente dos achados.
Caso sintético — Northline Municipal Transit (NMT). A operadora de transporte, Sam Park e todos os números foram inventados para fins didáticos.
Erros e limites
Sistemas de transporte reais e equipamentos de tarifa nunca são testados sem uma autorização separada e especializada. Este livro usa apenas dados sintéticos e não concede autorização para testar sistemas reais.
Exercícios
- EX049 — Primeiros passos. Ordene: escalar, reproduzir, verificar a ferramenta. Rubrica: 3 = reproduzir, verificar a ferramenta, escalar; 2 = quase; 1 = escalar sempre primeiro; 0 = nada.
- EX050 — Não é achado. Por que um erro de TLS no notebook não é um achado da API? Rubrica: 3 = repositório de confiança do lado do cliente; a homologação funciona em outro lugar; 2 = parcial; 1 = é achado; 0 = nada.
- EX051 — Pacote de escalonamento. Liste quatro itens de um pacote de escalonamento. Rubrica: 3 = quatro do capítulo; 2 = três; 1 = um; 0 = nada.
- EX052 — Impacto nos passageiros. E se a solução de problemas puder afetar os passageiros? Rubrica: 3 = parar; contato de emergência; 2 = parar; 1 = continuar; 0 = nada.
Síntese
Resolva problemas com uma árvore, prove onde a falha está e escale com um pacote limpo.
Continue estudando — capítulo 13 de 18
← Capítulo 12 (rascunho) · Índice de capítulos do curso · Capítulo 14 (rascunho) →