Capítulo 11 — Projeto aplicado
Mapa da aula
Aula 11 publicada. Mapa, exemplo, EX051.
flowchart TD
N0["11.1 Escolha do projeto"]
N1["11.2 Linha de base"]
N2["11.3 Projeto"]
N3["11.4 Implantação"]
N4["11.5 Avaliação"]
N5["11.6 Efeitos colaterais"]
N6["11.7 Relato"]
N7["Envolvimento das partes interessadas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX051"]
Desenho lógico
flowchart LR
N0["11.1 Escolha do projeto"]
N1["11.2 Linha de base"]
N2["11.3 Projeto"]
N3["11.4 Implantação"]
N4["11.5 Avaliação"]
N5["11.6 Efeitos colaterais"]
N6["11.7 Relato"]
N7["Envolvimento das partes interessadas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX051"]
[11.1 Escolha do projeto]
|
v
[11.2 Linha de base]
|
v
[11.3 Projeto]
|
v
[11.4 Implantação]
|
v
[11.5 Avaliação]
|
v
[11.6 Efeitos colaterais]
|
v
[11.7 Relato]
|
v
[Envolvimento das partes interessadas]
|
v
[Exemplo resolvido] --> [Exercício EX051]
Objetivos de aprendizagem
Você vai (1) conduzir um projeto aplicado de pós-graduação numa unidade pericial; (2) projetar, implantar e avaliar uma melhoria; (3) envolver as partes interessadas; (4) relatar os resultados à liderança.
11.1 Escolha do projeto
A partir da revisão do CF-21, Marta escolhe: "Reduzir o tempo da detecção até a preservação pericial dos hosts significativos de uma mediana de 3,5 horas para menos de 1 hora." A meta é específica e mensurável e vem diretamente das falhas do CF-21: dois servidores reconstruídos antes da preservação e horas perdidas antes da captura de memória. A mediana de 3,5 horas significava que a evidência mais necessária muitas vezes já tinha desaparecido. Reduzi-la para menos de uma hora tornaria realista o limite de 90 minutos da barreira pericial. Marta redige o objetivo com o COO e com os líderes de TI e do SOC antes de o projeto começar.
11.2 Linha de base
Os registros do CF-21 e de três incidentes menores dão a linha de base: mediana de 3,5 horas, máximo de 7 horas, dois hosts perdidos para a reconstrução. A linha de base se apoia em quatro incidentes, e não só no CF-21, o que dá mais de um ponto de dados. Ela registra a mediana, o tempo mais longo e os dois hosts perdidos, para que a melhoria possa ser mostrada em relação aos três. O mesmo método de medição é usado depois da implantação, para que a comparação seja justa. Os registros da linha de base e o método usado para cronometrar cada preservação ficam no arquivo do projeto para revisão.
11.3 Projeto
Coleta de memória e de triagem pré-implantada nos servidores e nas estações de administração; snapshot automático de VM em alertas de alta severidade; escala pericial de plantão; barreira pericial no processo de mudanças da TI. Cada elemento remove um atraso que a linha do tempo do CF-21 mostrou. As ferramentas pré-implantadas evitam esperar pela instalação de software, os snapshots automáticos eliminam a corrida contra a TI, a escala de plantão garante que alguém possa agir à noite, e a barreira no processo de mudanças da TI impede reconstruções de hosts significativos. Juntos, eles atacam tanto a mediana quanto os hosts perdidos.
11.4 Implantação
As mudanças são implantadas ao longo de oito semanas com a TI e o SOC. Cada mudança tem um teste: um alerta simulado deve disparar o snapshot em até cinco minutos. As oito semanas permitem que cada mudança passe pelo controle de mudanças normal e seja testada antes da seguinte. O teste do snapshot em cinco minutos é executado em cada cluster, e as falhas voltam para a equipe responsável. Implantar aos poucos também significa que um problema pode ser rastreado até uma única mudança. Cada resultado de teste fica com o chamado da mudança, para que a avaliação possa citá-lo.
11.5 Avaliação
Dois exercícios técnicos e um incidente real de pequeno porte após a implantação: mediana de 40 minutos até a preservação; nenhum host significativo reconstruído antes da preservação. Uma mediana de 40 minutos supera a meta de menos de uma hora, e a contagem de hosts perdidos caiu de dois para zero. A base de evidências é pequena, três eventos, por isso Marta relata o resultado como promissor, e não como comprovado. A medição continua ao longo dos incidentes reais, e o número será atualizado no próximo relatório ao conselho. Os três eventos são listados individualmente no arquivo do projeto, para que a mediana possa ser conferida.
11.6 Efeitos colaterais
O armazenamento de snapshots cresceu 30%; uma regra de retenção apaga após 14 dias os snapshots não ligados a casos. O crescimento do armazenamento foi um custo real que o conselho precisava ver ao lado do benefício. Sem a regra dos 14 dias, os snapshots automáticos se acumulariam a cada alerta de alta severidade, inclusive os falsos positivos. Os snapshots ligados a um caso ficam, em vez disso, sob a retenção desse caso. A regra dos 14 dias é testada como as outras mudanças, conferindo que um snapshot sem caso com mais de 14 dias é removido e que um snapshot de caso é mantido. Marta trata o crescimento do armazenamento como um número a continuar acompanhando.
11.7 Relato
Um relatório de duas páginas ao conselho: problema, mudança, resultados, custos, limites. As duas páginas trazem a linha de base de 3,5 horas, as mudanças, a mediana de 40 minutos em três eventos, o crescimento de 30% no armazenamento e a falha de permissões no cluster. Os limites incluem o pequeno número de eventos e a ausência de um incidente grande desde a implantação. Os conselheiros recebem o suficiente para julgar o investimento sem ler o arquivo completo do projeto. O teste de snapshot que falhou é descrito com sua causa e sua correção. O conselho pode ver que a equipe encontrou o problema por meio dos próprios testes.
Envolvimento das partes interessadas
As operações de TI e o SOC são coproprietários do projeto. Seus líderes participam do planejamento e da avaliação, e cada mudança é aprovada pelo controle de mudanças normal. Marta dá crédito às equipes deles no relatório; o projeto funcionou porque as pessoas que reconstroem os sistemas ajudaram a projetar a barreira que às vezes as atrasa. Uma breve pesquisa após a implantação registra a visão delas sobre o novo processo, ao lado dos dados de tempo.
Exemplo resolvido
Durante o segundo exercício, o snapshot automático falha num cluster por causa de uma mudança de permissões feita por outra equipe. O teste detecta a falha; a permissão é restaurada e uma verificação de monitoramento é acrescentada. Marta relata a falha e a correção no documento ao conselho, e não apenas o resultado principal.
Caso sintético. O projeto é inventado.
Erros e limites
Três eventos após a implantação são poucos; continue medindo ao longo dos incidentes reais.
Exercícios
- EX051 — Objetivo. Enuncie o objetivo do projeto com a linha de base. Rubrica: 3 = mediana de 3,5 h para menos de 1 h; 2 = parcial; 1 = vago; 0 = nada.
- EX052 — Elementos do projeto. Liste três elementos do projeto. Rubrica: 3 = coleta pré-implantada, snapshot automático, escala de plantão, barreira pericial (quaisquer três); 2 = dois; 1 = um; 0 = nada.
- EX053 — Resultado. O que a avaliação mostrou? Rubrica: 3 = mediana de 40 min; nenhuma reconstrução prematura; 2 = um; 1 = vago; 0 = nada.
- EX054 — Efeito colateral. Que efeito colateral ocorreu e como foi gerido? Rubrica: 3 = crescimento de 30% no armazenamento; regra de exclusão em 14 dias; 2 = um; 1 = vago; 0 = nada.
- EX055 — Relatar a falha. Por que incluir a falha do snapshot no relatório ao conselho? Rubrica: 3 = honestidade; mostra que os testes funcionam; visibilidade do risco; 2 = parcial; 1 = omitir; 0 = nada.
Síntese
Projetos aplicados precisam de linhas de base, mudanças testadas, avaliação honesta e atenção aos efeitos colaterais.
Continue estudando — capítulo 11 de 12
← Capítulo 10 (rascunho) · Índice de capítulos do curso · Capítulo 12 (rascunho) →