~ / blog / linux
16 set 2026linux11 min de leitura

Runbook Linux: o checklist de um servidor pronto para produção

Um roteiro de entrega para unir identidade, SSH, systemd, firewall, logs, backup e rollback em uma operação reproduzível.

LinuxDevOpsrunbook

1. O que significa pronto

Um servidor pronto não é apenas um servidor que responde. Outra pessoa precisa conseguir entender suas portas, reiniciar serviços, localizar logs e recuperar dados sem depender da memória de quem o configurou.

2. Identidade e acesso

  • Usuário operacional nominal
  • SSH por chave
  • Root desabilitado
  • Privilégio mínimo
  • Registro de acessos

3. Serviço e observabilidade

systemctl --failed
systemctl is-enabled irn-worker
journalctl -u irn-worker --since today
ss -lntp

Documente a unidade, dependências, variáveis e comportamento esperado. Defina o que é alerta e o que é apenas informação.

4. Rede e backup

sudo ufw status numbered
sudo fail2ban-client status sshd
restic snapshots

Liste cada porta liberada com sua justificativa. O backup deve ter destino externo, retenção e restauração ensaiada.

5. Rollback e evidências

Registre a versão implantada, arquivos alterados, comando de rollback e responsável pela mudança. Guarde evidências do healthcheck e do último restore.

DICA DE OPERAÇÃO O runbook deve ser executável por alguém que não participou da instalação. Se uma etapa depende de contexto oral, ainda falta documentação.

6. Checklist de entrega

  • Acesso validado
  • Firewall revisado
  • Serviço reinicia sozinho
  • Logs consultáveis
  • Backup restaurado
  • Rollback testado

7. Operação contínua

O runbook deve ser revisado após incidentes, upgrades e mudanças de arquitetura. Inclua contatos, janela de manutenção, dependências externas e critérios para escalar o problema.

# coleta rápida de evidências
hostnamectl
uptime
systemctl --failed
df -h
free -h

8. Comandos explicados

ComandoO que faz
systemctl --failedLista as units do systemd que falharam. Se não listar nada, está tudo bem.
systemctl is-enabled irn-workerDiz se o serviço inicia no boot (enabled) ou não (disabled).
journalctl -u irn-worker --since todayMostra os logs do serviço desde a meia-noite.
ss -lntpLista as portas TCP em escuta e o processo dono de cada uma.
sudo ufw status numberedMostra as regras do firewall numeradas, o que facilita removê-las com ufw delete N.
sudo fail2ban-client status sshdMostra a jail do SSH e os IPs bloqueados.
restic snapshotsLista os backups existentes, com data e caminhos.
hostnamectlMostra nome do servidor, sistema operacional e versão do kernel.
uptimeMostra há quanto tempo o servidor está ligado e a carga média de 1, 5 e 15 minutos.
df -hMostra o espaço em disco de cada partição, em unidades legíveis (-h).
free -hMostra o uso de memória e de swap.

9. Como ler a coleta rápida de evidências

O bloco final do artigo (hostnamectl, uptime, systemctl --failed, df -h, free -h) serve para registrar o estado do servidor. Veja o que observar em cada saída:

ComandoO que observarSinal de alerta
uptimecarga média comparada ao número de CPUscarga muito acima do número de CPUs por muito tempo
df -hcoluna Use%, principalmente em /partição perto de 100%
free -hmemória disponível (available) e swapswap em uso crescente
systemctl --failedunits listadasqualquer serviço na lista

10. Modelo de registro de mudança

O artigo pede versão implantada, arquivos alterados, comando de rollback e responsável. Uma forma prática de preencher (os valores são ilustrativos):

CampoExemplo
Versão implantadav1.4.2 (commit 3f2a91c)
Arquivos alterados/etc/systemd/system/irn-worker.service
Comando de rollbackgit checkout v1.4.1 && sudo systemctl restart irn-worker
Responsável e datanome e data da mudança
Evidênciasaída do healthcheck e do systemctl status após a mudança

Quer aplicar isso ao seu contexto?

Se esse problema existe na sua operação, podemos analisar o cenário em um diagnóstico gratuito de 30 minutos.

solicitar diagnóstico gratuito →

Leia também