Capítulo 17 — Laboratório controlado II
Mapa da aula
Aula 17 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["17.1 Layout do laboratório"]
N1["17.2 Cenários"]
N2["17.3 Tempos"]
N3["17.4 Debriefing"]
N4["17.5 Caso resolvido"]
N5["17.6 Atividade prática"]
N6["17.7 Trabalhando em dupla"]
N7["17.9 Registrando o exercício"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["17.1 Layout do laboratório"]
N1["17.2 Cenários"]
N2["17.3 Tempos"]
N3["17.4 Debriefing"]
N4["17.5 Caso resolvido"]
N5["17.6 Atividade prática"]
N6["17.7 Trabalhando em dupla"]
N7["17.9 Registrando o exercício"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX049"]
[17.1 Layout do laboratório]
|
v
[17.2 Cenários]
|
v
[17.3 Tempos]
|
v
[17.4 Debriefing]
|
v
[17.5 Caso resolvido]
|
v
[17.6 Atividade prática]
|
v
[17.7 Trabalhando em dupla]
|
v
[17.9 Registrando o exercício]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem
Você vai (1) executar um laboratório de múltiplos saltos com monitoramento; (2) injetar e diagnosticar falhas; (3) praticar runbooks sob pressão de tempo; e (4) fazer o debriefing e melhorar os documentos.
17.1 Layout do laboratório
Cliente → proxy reverso → servidor web, mais um servidor SSH, todos capazes de híbrido; um parser de logs alimentando um painel simples; um cliente "legado"; e um proxy que pode ser configurado para descartar primeiras mensagens grandes.
Monte-o a partir do laboratório do Capítulo 12, acrescentando o proxy, o parser de logs e o painel. Registre todas as versões. O proxy que descarta mensagens grandes reproduz com segurança o problema do Summit do HHG. Tire um snapshot do laboratório funcionando, para poder restaurá-lo entre os cenários. Rotule claramente cada host de laboratório como laboratório.
17.2 Cenários
O instrutor (ou um colega de equipe) injeta uma falha de cada vez: reordenar os grupos no proxy; restringir o buffer do proxy; remover o fallback clássico no SSH; substituir o certificado do servidor por um emitido por uma raiz de laboratório não confiável. Você diagnostica com logs e ferramentas e corrige usando os runbooks.
Cada cenário corresponde a um modo de falha do Capítulo 8: fallback silencioso, mensagem grande descartada, nenhum grupo compartilhado e falha de certificado. Registre os sintomas que você vê, o runbook que usou e se ele funcionou. Restaure o laboratório à sua linha de base antes do cenário seguinte.
17.3 Tempos
Registre o tempo para detectar, o tempo para diagnosticar e o tempo para corrigir. O objetivo não é a velocidade em si, mas descobrir quais passos do runbook o atrasaram.
Meça desde o momento em que a falha foi injetada até quando você a percebeu, depois até quando você soube a causa, depois até quando o serviço foi restaurado e verificado. Um tempo de diagnóstico longo costuma significar uma verificação ausente ou um passo confuso no runbook. Compare os tempos entre as sessões. Anote qual passo levou mais tempo.
17.4 Debriefing
Após cada cenário: o que aconteceu, o que você fez, o que ajudou, o que mudar no runbook ou no painel. Atualize os documentos imediatamente.
No HHG, o debriefing após o cenário do buffer do proxy acrescentou um passo e um painel de visualização. Mantenha os debriefings curtos e sem culpados, com foco nos documentos e nas ferramentas, e não em quem foi lento. Registre cada mudança com o cenário que a causou. Teste cada runbook atualizado na sessão seguinte para confirmar que ele ajuda. Compartilhe as mudanças com a equipe.
17.5 Caso resolvido
Cenário 2 (buffer do proxy): detecção em 3 minutos (timeouts nos logs), diagnóstico em 11 minutos (o operador suspeitou primeiro do servidor), correção em 2 minutos (configuração do proxy restaurada). Debriefing: acrescentar ao runbook "verificar o proxy antes do servidor quando aparecerem timeouts num único caminho"; acrescentar ao painel visualizações por caminho.
O debriefing transformou um diagnóstico de 11 minutos em duas melhorias concretas. O operador suspeitou primeiro do servidor, o que custou tempo; o novo passo do runbook e as visualizações por caminho fazem do proxy a primeira coisa verificada. Registre os tempos, para que as sessões seguintes possam mostrar se as mudanças ajudaram.
17.6 Atividade prática
Execute os quatro cenários; registre os tempos e as notas do debriefing.
Execute os quatro cenários em sequência: grupos reordenados no proxy, buffer do proxy restrito, fallback clássico removido no SSH e uma raiz de laboratório não confiável no servidor. Para cada um, registre os tempos para detectar, diagnosticar e corrigir, o runbook usado e o que o atrasou. Restaure o laboratório entre os cenários. Termine com uma lista de mudanças nos runbooks ou no painel e faça-as antes da sessão seguinte. Compartilhe a lista com o seu instrutor.
17.7 Trabalhando em dupla
Pratique em duplas: um operador conduz, o outro lê o runbook e registra os tempos e as observações. Troquem os papéis a cada cenário. O trabalho em dupla expõe rapidamente os passos pouco claros e espelha a forma como os incidentes são tratados nas escalas reais de plantão.
Registre no debriefing as observações dos dois papéis. Quem lê deve seguir o runbook exatamente como está escrito, para que os passos pouco claros ou ausentes fiquem visíveis, em vez de serem completados de memória. Combinem antes de cada cenário quem conduz e quem lê, e registrem qualquer passo que o leitor teve de explicar.
17.8 Erros comuns e limites
- Pular os debriefings.
- Corrigir sem diagnosticar.
- Não atualizar os documentos após as lições.
Cada erro desperdiça o exercício. Pular os debriefings significa que os mesmos passos vão atrasá-lo da próxima vez. Corrigir sem diagnosticar, por exemplo restaurar a configuração do proxy sem conferir os logs, não ensina nada e pode esconder uma segunda falha. Não atualizar os documentos deixa a lição na sua cabeça em vez de no runbook, onde o turno da noite precisa dela. Confira cada sessão quanto aos três. Corrija o que encontrar. Anote o que você mudou em cada runbook após a sessão.
17.9 Registrando o exercício
Mantenha um registro curto de cada sessão de laboratório — data, cenários, tempos, ações do debriefing e quem participou — no repositório da equipe. Ao longo de várias sessões, o registro mostra se os tempos de detecção e de correção estão melhorando e quais runbooks mudaram em consequência. Ele também é evidência, para supervisores e auditores, de que a equipe pratica os seus procedimentos em vez de apenas escrevê-los.
Mantenha o registro factual e breve. Revise-o a cada trimestre. Compartilhe um resumo com a equipe após cada sessão, para que as lições cheguem aos operadores que não participaram.
Exercícios
- EX049 — Plano de cenário. Projete um quinto cenário para o laboratório. Rubrica: 3 = injeção realista, sintoma esperado, correção.
- EX050 — Análise dos tempos. No caso resolvido, qual fase levou mais tempo e como você a encurtaria? Rubrica: 3 = diagnóstico; ordem do runbook/visualizações.
- EX051 — Cenário de certificado. Que sintoma e que correção você espera no cenário da raiz de laboratório não confiável? Rubrica: 3 = erro de verificação; acrescentar a raiz ou restaurar o certificado confiável.
Síntese
Laboratórios de múltiplos saltos com falhas injetadas e prática de runbooks cronometrada e com debriefing formam operadores capazes de encontrar e corrigir problemas rapidamente e de melhorar as suas ferramentas.
Continue estudando — capítulo 17 de 18
← Capítulo 16 · Índice de capítulos do curso · Capítulo 18 →
Siga para a próxima lição escrita.