Capítulo 46 — Projeto final de engenharia II
Mapa da aula
Aula 46 publicada. Mapa, exemplo, EX136.
flowchart TD
N0["46.1 Congelamento"]
N1["46.2 Verificar"]
N2["46.3 Documentação"]
N3["46.2b Acompanhamento do operador"]
N4["46.3b Roteiro da demo"]
N5["46.1b Passagem para operações"]
N6["Nota de prática"]
N7["46.4b Teste final de aceitação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX136"]
Desenho lógico
flowchart LR
N0["46.1 Congelamento"]
N1["46.2 Verificar"]
N2["46.3 Documentação"]
N3["46.2b Acompanhamento do operador"]
N4["46.3b Roteiro da demo"]
N5["46.1b Passagem para operações"]
N6["Nota de prática"]
N7["46.4b Teste final de aceitação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX136"]
[46.1 Congelamento]
|
v
[46.2 Verificar]
|
v
[46.3 Documentação]
|
v
[46.2b Acompanhamento do operador]
|
v
[46.3b Roteiro da demo]
|
v
[46.1b Passagem para operações]
|
v
[Nota de prática]
|
v
[46.4b Teste final de aceitação]
|
v
[Exemplo resolvido] --> [Exercício EX136]
Objetivos de aprendizagem
Você vai (1) concluir a implementação contra a proposta congelada; (2) executar o Laboratório de verificação II; (3) entregar a documentação para operadores.
46.1 Congelamento
A data de congelamento de funcionalidades é real: depois dela, só correções de segurança. Ideias novas vão para uma proposta de continuação. Depois do congelamento, ideias de funcionalidades vão para uma proposta de continuação, não para commits "pequenos" que contornam o Laboratório II. As correções de segurança continuam fluindo. Sam registrou um documento de continuação para um formato de exportação desejável no dia do congelamento, em vez de enfiá-lo escondido no branch da política assinada. As correções de segurança ainda precisam de linhas do Laboratório II que toquem o caminho alterado. Propostas de continuação não podem reabrir o branch congelado sem um novo Projeto Final I.
46.2 Verificar
O projeto final precisa passar no Laboratório II (Capítulo 40) sobre fixtures sintéticos, com a lista de verificação assinada. O Laboratório II sobre fixtures sintéticos com uma lista de verificação assinada é o portão do Projeto Final II citado antes. Verdes de testes unitários não são um substituto. A tag do Projeto Final II de Sam aponta para o hash da lista de verificação da execução do Laboratório II do mesmo dia em que o runbook foi atualizado. O hash da lista de verificação é impresso no README do Projeto Final II ao lado da tag. O README e a tag precisam concordar, ou o script de release aborta. Uma divergência imprime os dois hashes, para que o autor saiba qual arquivo se desviou.
46.3 Documentação
Seção do runbook, ADR, tutorial para operadores com capturas de tela da interface sintética — sem dados de clientes.
"""Rebuild a synthetic engagement timeline from event records."""
events = [
("09:00", "ROE brief signed", "auth"),
("09:15", "scoped host inventory loaded (12 hosts)", "prep"),
("10:02", "service enumeration on 10.20.1.0/28", "enum"),
("10:45", "finding SYN-001 noted on staging UI", "find"),
("11:10", "stop: host 10.20.0.1 probed — out of scope", "stop"),
("11:12", "escalated to client contact; confirmed deny-list", "comm"),
("13:00", "resume on in-scope hosts only", "auth"),
("15:30", "debrief draft shared with client", "report"),
]
# print chronological with phase tags; compute stop latency
print("phase timeline:")
for t, msg, phase in events:
print(f" {t} [{phase:6}] {msg}")
t0 = 10*60+45; t1 = 11*60+10
print(f"minutes from SYN-001 note to stop: {t1-t0}")
print(f"stop reason present: yes")
print(f"events={len(events)} phases={len(set(p for _,_,p in events))}")
Saída esperada:
phase timeline:
09:00 [auth ] ROE brief signed
09:15 [prep ] scoped host inventory loaded (12 hosts)
10:02 [enum ] service enumeration on 10.20.1.0/28
10:45 [find ] finding SYN-001 noted on staging UI
11:10 [stop ] stop: host 10.20.0.1 probed — out of scope
11:12 [comm ] escalated to client contact; confirmed deny-list
13:00 [auth ] resume on in-scope hosts only
15:30 [report] debrief draft shared with client
minutes from SYN-001 note to stop: 25
stop reason present: yes
events=8 phases=7
Caso sintético — Riverstone Transit. O Projeto Final II entregou a distribuição de política assinada; Laboratório II verde; runbook atualizado no mesmo dia.
Runbook, ADR e tutorial para operadores com capturas de tela sintéticas fazem parte do pronto. Dados de clientes na documentação são uma reprovação. O tutorial de Sam usa apenas a interface do laboratório da Riverstone e foi atualizado no mesmo dia em que o Laboratório II ficou verde para a distribuição de política assinada. As capturas de tela são recortadas para remover qualquer papel de parede do host que possa identificar um local real.
46.4 Erros e limites
Mágica de demo num laptop com a falha fechada explicada no gogó não passa. No Projeto Final II, a execução silenciosa do operador e a lista de verificação do Laboratório II são a prova. A primeira tentativa de aceitação de Sam falhou em duas etapas da documentação; mágica não foi oferecida como substituto. A rubrica publicada, que os estudantes veem na primeira semana, dá zero para uma demo em laptop sem a lista de verificação, para que ninguém a trate como estratégia surpresa. Os avaliadores executam eles mesmos a lista de verificação na versão entregue, em vez de aceitar o relato do estudante sobre uma execução bem-sucedida.
46.2b Acompanhamento do operador
Antes de declarar pronto, um segundo engenheiro segue o runbook a frio, com dados sintéticos, enquanto o autor fica em silêncio. Os pontos onde ele empaca viram correções na documentação. O Projeto Final II não está pronto até que a execução silenciosa tenha sucesso. O silêncio do autor durante a execução a frio é o que revela passos ausentes. A sessão de acompanhamento de Sam empacou no caminho do kill switch até que a página do fichário nomeasse a localização do arquivo que o exercício de mesa tinha encontrado antes. As notas de empaque são registradas como tickets de documentação antes que o script de aceitação seja tentado. O engenheiro que acompanha assina o log da execução quando a execução silenciosa finalmente passa.
46.3b Roteiro da demo
A demo do Projeto Final II segue um roteiro sobre dados sintéticos: mostrar a falha fechada, mostrar o denominador da cobertura, mostrar uma ação interrompida. Demos improvisadas pulam a segurança. Registre o roteiro ao lado do relatório do laboratório. Um roteiro que mostra a negação com a política ausente, uma exportação de cobertura 5/7 e uma ação interrompida mantém a defesa honesta. Sam registrou o roteiro ao lado do relatório do Laboratório II, para que os examinadores pudessem pedir o mesmo caminho. Os examinadores podem pedir para pausar o roteiro e inspecionar ao vivo o código de motivo da negação.
46.1b Passagem para operações
Código de projeto final sem um dono em operações no merge está inacabado. Nomeie o esquadrão dono no README e no CODEOWNERS antes da aprovação do Laboratório II. Propriedade no CODEOWNERS e no README antes da aprovação do Laboratório II impede projetos finais órfãos. Um esquadrão de operações que nunca concordou não pode ser surpreendido no plantão. O README de Sam nomeou o esquadrão de plataforma e a escala de plantão antes que o script de aceitação rodasse. A ciência de operações é uma caixa de seleção no formulário de aprovação do Laboratório II. A aprovação vermelha fica visível no quadro do Projeto Final II ao lado do Laboratório II.
Nota de prática
O teste silencioso do runbook é gravado em vídeo para o orientador (apenas dados sintéticos). Ver um colega empacar é desconfortável e singularmente eficaz para revelar pré-requisitos ausentes — por exemplo, nunca ter documentado que a chave de política de teste é obrigatória.
Referencie o hash do vídeo da execução silenciosa no relatório do Laboratório II para auditoria do orientador.
A aceitação de operações é uma assinatura obrigatória ao lado do Laboratório II na lista de verificação de release.
Sem a assinatura de operações, a tag de release não é criada, mesmo que o Laboratório II esteja verde.
A revisão do orientador assiste à gravação da execução silenciosa a 1,5x e registra problemas de documentação antes da aprovação.
46.4b Teste final de aceitação
Antes que o projeto final seja entregue, um operador que não o construiu roda sozinho o script de aceitação, usando apenas a documentação. Duas etapas falharam na primeira tentativa de Sam porque a documentação supunha um conhecimento que ele tinha; ambas foram reescritas, e a segunda execução do operador passou. Conhecimento suposto na documentação é um defeito que o operador a frio vai encontrar. Essa reescrita faz parte da evidência do projeto final, não é um constrangimento a esconder. As etapas reescritas e a segunda execução verde são ambas seladas no dossiê.
Exercícios
- EX136 — Congelamento. O que é permitido depois do congelamento de funcionalidades? Rubrica: 3 = só correções de segurança; 2 = "bugs"; 1 = funcionalidades; 0 = nada.
- EX137 — Artefatos. Liste cinco artefatos de entrega. Rubrica: 3 = cinco (código, testes, relatório do laboratório, ADR, runbook…); 2 = três; 1 = só código; 0 = nada.
- EX138 — Linha do tempo. Onde fica a verificação do projeto final em relação ao uso em engajamentos? Rubrica: 3 = antes de qualquer janela de cliente; 2 = vago; 1 = durante; 0 = nada.
Síntese
Congele, verifique, documente — então, e só então, opere.
Continue estudando — capítulo 46 de 50
← Capítulo 45 (rascunho) · Índice de capítulos do curso · Capítulo 47 (rascunho) →