Capítulo 29 — Construção do trabalho de conclusão
Mapa da aula
Aula 29 publicada. Mapa, exemplo, EX085.
flowchart TD
N0["29.1 O enunciado do trabalho de conclusão"]
N1["29.2 Incrementos"]
N2["29.3 Registro de decisões"]
N3["29.4 Pronto para avaliação"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX085"]
Desenho lógico
flowchart LR
N0["29.1 O enunciado do trabalho de conclusão"]
N1["29.2 Incrementos"]
N2["29.3 Registro de decisões"]
N3["29.4 Pronto para avaliação"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX085"]
[29.1 O enunciado do trabalho de conclusão]
|
v
[29.2 Incrementos]
|
v
[29.3 Registro de decisões]
|
v
[29.4 Pronto para avaliação]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX085]
Objetivos de aprendizagem
Você vai (1) construir um artefato de conclusão que resolve um problema definido da NCS; (2) trabalhar em incrementos, com testes; (3) manter um registro de decisões; e (4) preparar o artefato para avaliação e entrega.
29.1 O enunciado do trabalho de conclusão
O trabalho de conclusão de Priya: um "verificador de deriva de TO" que roda semanalmente no host de gerenciamento da NCS, combinando a comparação de inventário do Capítulo 11, a comparação de fluxos do Capítulo 12, a verificação de novos interlocutores do Capítulo 19 e a verificação de certificados do Capítulo 22 num único relatório, com um único status de saída. Ele lê apenas arquivos exportados e nunca contata dispositivos. Cada uma das quatro verificações já existe e já rodou sobre dados da NCS; o trabalho do projeto é combiná-las, validar as suas entradas e fazer do resultado algo que o gerente de instalações consiga executar sem Priya.
29.2 Incrementos
Semana 1: um script que roda as quatro verificações sobre arquivos de exemplo e imprime seções. Semana 2: um formato de saída comum (verificação, item, estado, arquivo de evidência). Semana 3: testes para cada verificação usando pequenos fixtures, incluindo entradas vazias. Semana 4: agendamento, registro e o alerta de "a tarefa não rodou". Cada incremento funciona de ponta a ponta antes que o seguinte comece. A semana 3 encontrou um defeito real: um arquivo de captura vazio fazia a verificação de novos interlocutores reportar todos os hosts da linha de base como ausentes, em vez de "sem dados". Priya acrescentou um estado "no-data" que reprova a execução, porque uma entrada vazia normalmente significa que a captura falhou.
29.3 Registro de decisões
Exemplos: "Decisão 3 — retornar status de saída diferente de zero se qualquer verificação devolver UNAPPROVED, EXPIRED ou VERSION-CONFLICT; alternativa (sempre zero) rejeitada porque o agendador não conseguiria alertar." "Decisão 5 — nenhuma remediação automática; todas as ações via chamados." Outra decisão veio da semana 3: "Decisão 6 — um arquivo de entrada vazio produz o estado NO-DATA e uma saída diferente de zero; alternativa (tratar como zero eventos) rejeitada porque reportava todos os hosts da linha de base como ausentes, e uma captura vazia normalmente significa que a captura falhou." Cada entrada nomeia a alternativa e a razão pela qual ela perdeu, para que um avaliador possa discordar da razão em vez de adivinhá-la.
29.4 Pronto para avaliação
A pasta do artefato contém o código, os testes, as entradas de exemplo, um README explicando como executá-lo, o registro de decisões e um guia curto de operação. Um avaliador precisa conseguir executá-lo a partir de um checkout limpo e obter a saída documentada. A pasta de Priya atendeu a isso com 23 testes que passam a partir de um checkout limpo. Foi no guia de operação que a avaliadora depois encontrou a lacuna: o gerente de instalações conseguia executar o verificador, mas ainda precisava de ajuda para interpretar VERSION-CONFLICT. Um revisor consegue seguir cada estado, dos arquivos de entrada até o relatório, sem perguntar nada a ela.
Exemplo resolvido (NCS sintética)
Na semana 3, os testes de Priya revelam que um arquivo de captura vazio faz a verificação de novos interlocutores reportar todos os hosts da linha de base como ausentes, em vez de "sem dados". Ela acrescenta um estado "no-data" que reprova a execução, porque uma entrada vazia normalmente significa que a captura falhou — exatamente o que o local precisa saber.
Caso sintético — Northgate Cold Storage. O trabalho de conclusão é um exemplo didático.
Erros e limites
Combinar verificações multiplica as formas pelas quais os arquivos de entrada podem estar errados; valide as entradas primeiro. Uma ferramenta que só Priya consegue executar não está terminada.
Exercícios
- EX085 — Escolhendo os status de saída. Quais estados devem fazer o verificador de deriva sair com status diferente de zero? Rubrica: 3 = UNAPPROVED, EXPIRED, VERSION-CONFLICT, no-data (qualquer problema); 2 = alguns; 1 = vago; 0 = nada.
- EX086 — Um fixture de teste. Descreva um fixture que teste o limite de 30 dias da verificação de certificados. Rubrica: 3 = certificado a exatamente 30 dias espera renew-now, a 31 espera plan; 2 = um; 1 = vago; 0 = nada.
- EX087 — Por que sem remediação automática? Justifique a decisão 5 em duas frases. Rubrica: 3 = ações em TO precisam de aprovação/contexto; erros automatizados poderiam parar a operação; 2 = um; 1 = vago; 0 = nada.
Síntese
Construir um trabalho de conclusão é fazer incrementos pequenos, testar nas bordas, registrar as decisões e entregar um artefato que outra pessoa consegue executar.
Continue estudando — capítulo 29 de 30
← Capítulo 28 · Índice de capítulos do curso · Capítulo 30 →
Siga para a próxima lição escrita.