Os três scripts que toda equipe de operação tem — e que, juntos, formam o toolkit que vocês vão entregar como projeto final.
Coringas, busca, redirecionamento, variáveis, condições, laços, funções e código de saída.
Aplicar tudo isso a três problemas reais de operação — e receber o enunciado do projeto final.
Backup que nunca foi restaurado é só um arquivo ocupando espaço — e uma falsa sensação de segurança.
Deploy manual é uma sequência de passos que alguém executa de memória, sob pressão, às vezes de madrugada. Automatizar não é preguiça — é eliminar a chance de pular um passo.
Reparem: cada um desses itens é um if com um código de saída, exatamente o que vocês escreveram no Encontro 13.
Todo mundo sabe que precisa de backup. O que separa um backup real de um teatro de backup são três perguntas simples.
| Pergunta | O que ela revela |
|---|---|
| Com que frequência? | Quanto trabalho você aceita perder — se é diário, você aceita perder um dia |
| Onde fica guardado? | Backup no mesmo disco do original não protege contra falha de disco |
| Já foi restaurado? | A mais importante — e a que quase ninguém responde |
Era essa a resposta do slide 2: se nunca foi restaurado, você não tem backup — tem esperança.
Vocês já construíram um monitor de disco no Encontro 13. Agora dá pra generalizar: monitorar é medir algo periodicamente, comparar com um limite e agir quando ele for ultrapassado.
Todas as métricas que interessam vocês já sabem coletar: free, df, docker ps, docker stats — Unidade IV inteira.
Um script de monitoramento que você precisa lembrar de executar não monitora nada. O cron é o serviço do Linux que executa comandos em horários definidos.
| Linha no crontab | Quando executa |
|---|---|
| 0 3 * * * | Todo dia às 3h da manhã |
| */15 * * * * | A cada 15 minutos |
| 0 2 * * 0 | Todo domingo às 2h |
Os cinco campos são: minuto, hora, dia do mês, mês, dia da semana. Edita-se com crontab -e e lista-se com crontab -l.
Scripts de automação frequentemente precisam de privilégios — e é justamente por isso que merecem cuidado redobrado. Um script mal escrito rodando como root pode destruir um sistema.
Rodar tudo como root "porque é mais fácil"; dar permissão 777 a scripts; usar caminhos relativos em tarefas agendadas.
Menor privilégio necessário; caminhos absolutos no cron; validar variáveis antes de usá-las em rm; testar em ambiente descartável.
O clássico rm -rf "$DIR"/* com $DIR vazio vira rm -rf /* e apaga tudo o que houver na raiz. Por isso a regra das aspas e da validação, do Encontro 13, não é preciosismo.
Container é o objeto ideal para automatizar: ele nasce, morre e renasce de forma previsível. Todos os conceitos do semestre convergem aqui.
docker build, docker run, docker ps, docker stats e volumes — tudo já praticado.
Diagnosticar o que o container consome, onde grava, e por que às vezes morre — Unidades III e IV.
A partir de hoje, o trabalho de vocês é construir um toolkit de automação que opere um serviço em container: deploy, backup e monitoramento, com scripts próprios e documentação.
Scripts funcionais, um README explicando o uso, e o container que eles operam.
Timebox de ~10 minutos por equipe, com demonstração real do toolkit funcionando.
O enunciado completo, com requisitos e critérios, está no documento próprio do projeto — leiam com atenção ainda esta semana.
| Encontro | O que acontece |
|---|---|
| 14 (hoje) | Lançamento, formação das equipes e início do desenvolvimento |
| 15 | Desenvolvimento em aula, com o professor circulando como mentor |
| 16 | Finalização e ensaio da apresentação — também é o encontro amortecedor |
| 17 | Apresentação final — N2 da 2ª etapa |
São três encontros de trabalho antes da entrega. Equipes que começarem só no Encontro 16 não terão tempo suficiente.
Script com log, compactação, destino separado — e agendado no cron para executar sem ninguém presente.
Cada uma dessas linhas vira um passo do roteiro de laboratório de hoje.
Script de backup com log, teste de restauração, e agendamento no cron.
Definir o serviço que será operado e dividir as responsabilidades do toolkit.
O que vocês construírem hoje pode ser aproveitado diretamente no projeto final.
Referência direta para os scripts do toolkit — o conteúdo do slide 7. p. 62–69 e 81–89
Documento próprio, com requisitos, entregáveis e critérios. Leitura obrigatória para todas as equipes.
Aprofundamento sobre a organização do sistema de arquivos. p. 182–197
O quiz da semana verifica essa leitura e recolhe suas observações da prática — tudo no mesmo instrumento.