Capítulo 40 — Laboratório de verificação II
Mapa da aula
Aula 40 publicada. Mapa, exemplo, EX118.
flowchart TD
N0["40.1 Ponta a ponta"]
N1["40.2 Falhas"]
N2["40.3 Aprovação"]
N3["40.2b Observabilidade no laboratório"]
N4["40.3b Testes instáveis"]
N5["40.1b Paridade de ambiente"]
N6["Nota de prática"]
N7["40.4b Evidência da aprovação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX118"]
Desenho lógico
flowchart LR
N0["40.1 Ponta a ponta"]
N1["40.2 Falhas"]
N2["40.3 Aprovação"]
N3["40.2b Observabilidade no laboratório"]
N4["40.3b Testes instáveis"]
N5["40.1b Paridade de ambiente"]
N6["Nota de prática"]
N7["40.4b Evidência da aprovação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX118"]
[40.1 Ponta a ponta]
|
v
[40.2 Falhas]
|
v
[40.3 Aprovação]
|
v
[40.2b Observabilidade no laboratório]
|
v
[40.3b Testes instáveis]
|
v
[40.1b Paridade de ambiente]
|
v
[Nota de prática]
|
v
[40.4b Evidência da aprovação]
|
v
[Exemplo resolvido] --> [Exercício EX118]
Objetivos de aprendizagem
Você vai (1) verificar o fluxo de ponta a ponta, da ação ao ticket e à cobertura; (2) injetar falhas; (3) assinar uma candidata a release.
40.1 Ponta a ponta
Ação sintética → decisão do TrackScope → evento → ticket no FindingsDesk → atualização da cobertura no PulseMap. Registre hashes em cada salto. Verdes em testes unitários ainda podem esconder um caminho de eventos quebrado até o FindingsDesk. O ponta a ponta sobre fixtures sintéticos exercita permitir, negar, falha fechada e um upsert completo de achado antes que uma candidata a release seja criada. O script do Laboratório II de Sam é a etapa citada no Capstone II. O Capstone II não pode citar um verde só de testes unitários como evidência do Laboratório II; o script precisa imprimir o id do achado no FindingsDesk, para que a lista de verificação possa apontar para ele.
40.2 Falhas
Derrube o FindingsDesk no meio do fluxo; confirme que o TrackScope continua negando e que os rascunhos entram na fila. Corrompa um arquivo de evidência; confirme o alerta de hash divergente.
"""Verify integrity of a synthetic evidence package."""
import hashlib, json
files = {
"roe.pdf": b"SYNTHETIC-ROE-v1",
"scope.csv": b"host,port\n10.20.1.10,443\n",
"findings.json": b'[{"id":"SYN-001"}]',
}
expected = {n: hashlib.sha256(b).hexdigest()[:16] for n,b in files.items()}
# Simulate tampering of findings.json
current = dict(expected)
current["findings.json"] = hashlib.sha256(b'[{"id":"SYN-001"},{"id":"TAMPERED"}]').hexdigest()[:16]
print(json.dumps(expected, indent=1))
for n in sorted(expected):
status = "OK" if expected[n] == current[n] else "MISMATCH"
print(f"{n:16} {status}")
Saída esperada:
{
"roe.pdf": "18d74983d403e7db",
"scope.csv": "01cc4815eddf3de6",
"findings.json": "7f5f178ab43ef00f"
}
findings.json MISMATCH
roe.pdf OK
scope.csv OK
Injetar um arquivo de política ausente e um FindingsDesk morto no laboratório é como a degradação segura continua provada. O resultado esperado é negar tudo e enfileirar rascunhos, nunca um allow. Sam reprova o Laboratório II se qualquer uma das injeções produzir um allow ou uma contagem de rascunhos perdida. A história da queda com catorze rascunhos é o tamanho de fixture usado na injeção do FindingsDesk morto. Os operadores observam a profundidade da fila subir até catorze e cair a zero durante a reprodução, como parte da execução pontuada.
40.3 Aprovação
Lista de verificação da candidata a release assinada por quem implementou e por um revisor; as linhas de segurança precisam estar verdes. A aprovação independente segue a mesma regra de incentivos do Laboratório I: quem implementa não dá verde na própria release. A lista de verificação cita os SHAs das ferramentas, os hashes dos fixtures e os resultados das injeções de falha. As notas de release de Sam apontam para a lista de verificação assinada, não para uma captura de tela de uma demonstração local. Quem implementou e assina a própria lista de verificação é rejeitado pelo script de release antes que a tag seja criada.
Caso sintético — Riverstone Transit. O Laboratório II descobriu que a cobertura era atualizada antes da criação do ticket numa nova tentativa — a ordem foi corrigida com um outbox.
40.4 Erros e limites
Ponta a ponta sem injeção de falhas só prova o caminho feliz. Execuções de ponta a ponta instáveis ensinam as pessoas a clicar de novo até ficar verde. Ponha as instabilidades em quarentena, corrija-as ou apague o teste — não pule o Laboratório II. A última instabilidade de Sam foi uma diferença de relógio na etapa de horário; bloqueou duas releases até que o fixture passasse a usar horários UTC fixos. Uma instabilidade numa linha de falha fechada agora abre um P1 com a mesma severidade de um bug de negação em produção. Clicar de novo até ficar verde é registrado como incidente de processo quando envolve essas linhas.
40.2b Observabilidade no laboratório
O Laboratório II ativa logs de depuração temporariamente, mas sela uma cópia com dados ocultados. Deixar a depuração ligada em construções de engajamento pode vazar tokens para os agregados de logs. A chave faz parte da lista de verificação de aprovação. Se o laboratório não consegue mostrar os códigos de motivo das negações e a profundidade da fila, os operadores ficarão cegos numa queda real. O Laboratório II afirma que esses painéis se atualizam durante as injeções de falha. Sam observa no ambiente sintético os mesmos painéis que o plantão vai observar numa sexta-feira à noite. Se o painel de códigos de motivo ficar vazio durante uma injeção de negação, o Laboratório II reprova mesmo que o status HTTP pareça certo.
40.3b Testes instáveis
Um Laboratório II instável é um bloqueador, não um ritual de tentar de novo até ficar verde. Ponha o teste em quarentena, corrija a condição de corrida (relógios, ordenação) e execute de novo. Lançar com "às vezes falha fechada" é lançar com falha aberta. Uma instabilidade que toca linhas de falha fechada é um P1, não uma curiosidade estatística. A quarentena só a tira da etapa de merge com um dono e uma data de entrega. O quadro de Sam mostra os testes de segurança em quarentena em vermelho até que voltem estáveis por uma semana de execuções. Uma quarentena sem data de entrega é rejeitada pela automação do quadro.
40.1b Paridade de ambiente
O ambiente do Laboratório II espelha as versões das ferramentas de produção e as chaves de assinatura de políticas (chaves de teste). Lacunas de paridade explicam as surpresas de "verde no laboratório, vermelho no engajamento". Um Laboratório II num laptop com layout diferente do jump host prova o laptop, não o caminho do engajamento. Paridade significa o mesmo carregador de políticas, a mesma configuração de bucket e o mesmo tipo de destino de eventos. A imagem de laboratório de Sam é reconstruída toda segunda-feira a partir do mesmo branch de referência do jump host. Uma aprovação só no laptop recebe o rótulo de demonstração e não satisfaz o Capstone II.
Nota de prática
O Laboratório II inclui um pacote de fixtures maliciosos: hashes errados, eventos reordenados, carimbos de tempo no futuro. Passar só nos fixtures felizes é um laboratório incompleto. O pacote malicioso é versionado ao lado dos fixtures de referência e coberto pelo CODEOWNERS, para que não possa ser enfraquecido discretamente para deixar uma release verde.
Sele os logs do Laboratório II com a mesma ferramenta de manifesto que o dossiê usa, para que os estudantes pratiquem um único fluxo de hashing.
Os scripts de injeção de falhas ficam versionados na pasta do laboratório e fixados por SHA no relatório.
Caminho feliz verde com o pacote malicioso vermelho ainda reprova a aprovação do Laboratório II.
40.4b Evidência da aprovação
O pacote de aprovação do Laboratório II guarda o plano de testes, os logs das execuções, a lista de falhas injetadas com o comportamento observado e as pendências com seus donos. Um engenheiro independente só assina depois de reproduzir dois resultados escolhidos ao acaso no pacote. A lista de verificação assinada, os hashes dos fixtures e os logs das injeções de falha são selados ao lado da tag do binário. Sem eles, "Laboratório II verde" é um boato. O repositório de artefatos de Sam rejeita uma tag de release sem o hash da lista de verificação nos metadados. Metadados ausentes foram como um verde de corredor quase foi lançado; a verificação do repositório o barrou.
Exercícios
- EX118 — Ordem. Por que criar o ticket antes que a contagem de cobertura aumente? Rubrica: 3 = a cobertura precisa refletir achados registrados; 2 = vago; 1 = qualquer ordem; 0 = nada.
- EX119 — Falha. Comportamento esperado do TrackScope quando o FindingsDesk está fora do ar. Rubrica: 3 = continuar avaliando/negando; enfileirar rascunhos; 2 = parcial; 1 = falhar aberto; 0 = nada.
- EX120 — Aprovação. Duas assinaturas exigidas — de quem? Rubrica: 3 = quem implementou + revisor independente; 2 = uma; 1 = só o gestor; 0 = nada.
Síntese
Ponta a ponta com falhas; segurança verde; duas assinaturas.
Continue estudando — capítulo 40 de 50
← Capítulo 39 (rascunho) · Índice de capítulos do curso · Capítulo 41 (rascunho) →