Runbooks que funcionam. Vamos falar de runbooks que realmente funcionam, de forma prática e aplicável. Vou estruturar para que você possa aplicar imediatamente em ambientes de TI, operações de servidores, cloud ou até DevOps.

1️⃣ O que é um Runbook

Um runbook é um guia passo a passo que descreve como executar tarefas operacionais ou reagir a incidentes.

Ele não é um documento teórico — ele é feito para ser seguido, rápido e confiável, mesmo em situações de pressão.

2️⃣ Características de um Runbook que Funciona

Para que um runbook seja realmente útil, ele precisa ter:

Clareza absoluta
- Cada passo deve ser direto, sem ambiguidades.
- Use comandos prontos, não apenas sugestões.
Ordem lógica
- Comece pelo diagnóstico, siga para mitigação, finalize com prevenção ou correção.
Testado e atualizado
- Um runbook desatualizado é perigoso.
- Ideal: revise pelo menos a cada 3–6 meses ou após mudanças críticas na infraestrutura.
Automatizável quando possível
- Sempre que um passo puder ser scriptado ou automatizado, faça isso.
Rápido de acessar
- Deve ser centralizado, fácil de buscar e acessar em crises.
- Ex.: Wiki interna, Notion, Confluence, GitOps, ou até pasta compartilhada com links diretos para scripts.
Contexto mínimo necessário
- Não precisa explicar conceitos, mas sim “como resolver agora”.
- Ex.: não explique o que é Docker, explique como reiniciar um serviço Docker que travou.

3️⃣ Estrutura de Runbook Eficiente

Um modelo testado de runbook:

Título: [Problema ou tarefa]

Objetivo: [O que o runbook resolve]

Pré-requisitos: [Acesso, permissões, ferramentas]

Passo 1: Diagnóstico rápido
    - Comando: <ex.: systemctl status nginx>
    - O que observar: <ex.: se Active: failed>

Passo 2: Mitigação imediata
    - Comando: <ex.: systemctl restart nginx>
    - Verificação: <ex.: curl localhost | grep 200>

Passo 3: Correção definitiva
    - Comando: <ex.: revisar logs / corrigir configuração>
    
Passo 4: Notificação / Registro
    - Documentar incidente
    - Informar stakeholders

Referências / Links úteis:
    - Link para KB, documentação, scripts

4️⃣ Dicas de Runbooks que Funcionam na Prática

Runbook de Incidente:
Ex.: servidor travou, DB inacessível, erro 500 no site.
Runbook de Manutenção:
Ex.: atualização de pacotes, backup de banco, rotação de logs.
Runbook de Recuperação:
Ex.: restore de backup, failover de cluster.
Runbook de Monitoramento:
Ex.: análise de alertas críticos, limpeza de discos, checagem de recursos.

5️⃣ Exemplo Prático (Linux + Apache)

Título: Reiniciar Apache quando travar

Objetivo: Restaurar rapidamente o serviço web Apache em produção

Pré-requisitos: Acesso root ou sudo

Passo 1 – Diagnóstico:

systemctl status apache2
journalctl -xe | tail -n 50

O que observar: Se Active: failed ou erros de porta ocupada.

Passo 2 – Mitigação imediata:

sudo systemctl restart apache2

Verificação:

curl -I localhost

Deve retornar HTTP/1.1 200 OK.

Passo 3 – Correção definitiva:

Verificar logs em /var/log/apache2/error.log
Corrigir conflito de porta ou configuração

Passo 4 – Notificação:

Registrar incidente no Jira/Confluence
Informar time de DevOps

💡 Regra de ouro: um runbook só funciona se alguém seguir e validar que funciona. Um runbook perfeito no papel, mas nunca testado, é inútil.

🛠️ Runbook Linux Completo para Operações Críticas

Objetivo: Ter um guia pronto para diagnosticar, mitigar e corrigir problemas comuns em servidores Linux de forma rápida e segura.

Pré-requisitos:

Acesso root ou sudo
SSH funcional
Ferramentas básicas: systemctl, journalctl, htop, netstat ou ss, df, du, curl, mysql/psql se necessário
Scripts e backups automatizados configurados

1️⃣ Diagnóstico Rápido de Saúde do Servidor

a) Recursos do sistema

# Uso de CPU e memória
htop
free -h

# Espaço em disco
df -h
du -sh /var/log/*

# Inodes
df -i

b) Serviços críticos

# Verificar status de serviços principais
systemctl status nginx apache2 mysql php-fpm

# Verificar logs recentes do serviço
journalctl -u nginx --no-pager -n 50

c) Conexões de rede

# Portas abertas
ss -tulnp

# Conexões ativas
netstat -antp

d) Logs gerais de erros

# Últimos logs do sistema
journalctl -xe --no-pager | tail -n 100

2️⃣ Mitigação Imediata

Se serviço travou ou caiu:

# Reiniciar serviço
sudo systemctl restart nginx
sudo systemctl restart php-fpm
sudo systemctl restart mysql

Se servidor está com alta memória ou CPU:

# Identificar processos pesados
ps aux --sort=-%mem | head -n 10
ps aux --sort=-%cpu | head -n 10

# Matar processo travado (se necessário)
kill -9 <PID>

Se disco cheio:

# Limpar cache do sistema
sudo sync; sudo echo 3 > /proc/sys/vm/drop_caches

# Limpar logs antigos
sudo find /var/log -type f -name "*.log" -mtime +30 -exec truncate -s 0 {} \;

3️⃣ Correção Definitiva

Configurações quebradas ou serviço instável:

# Validar configuração Apache/Nginx
apachectl configtest
nginx -t

# Reiniciar serviço depois de ajustes
sudo systemctl restart nginx
sudo systemctl restart apache2

Banco de dados:

# Testar conexão e status
mysqladmin ping
mysql -e "SHOW DATABASES;"

# Para PostgreSQL
psql -c "\l"

Verificar permissões de arquivos críticos:

ls -l /var/www/html

4️⃣ Monitoramento Preventivo

Espaço em disco crítico:

df -h | awk '$5>80 {print $0}'

Uso de memória crítico:

free -h | awk '/Mem:/ {if($3/$2 > 0.9) print "Memória crítica"}'

Serviços caindo:

systemctl list-units --failed

Alertas automáticos (exemplo básico):

# Script para alertar via e-mail quando MySQL cair
systemctl is-active --quiet mysql || echo "MySQL caiu em $(hostname)" | mail -s "Alerta Servidor" admin@dominio.com

5️⃣ Registro e Notificação

Documentar incidentes imediatamente em Jira, Confluence ou planilha interna
Informar equipe e stakeholders
Atualizar runbook se algum passo novo foi descoberto durante a resolução

✅ Checklist de Execução Rápida

Passo	Comando/Verificação
Diagnóstico CPU/Mem	`htop`, `free -h`
Diagnóstico Disco	`df -h`, `du -sh /var/log/*`
Diagnóstico Serviços	`systemctl status nginx mysql php-fpm`
Logs recentes	`journalctl -xe -n 50`
Reiniciar serviço travado	`systemctl restart <serviço>`
Limpar logs antigos	`find /var/log -type f -mtime +30 -exec truncate -s 0 {} \;`
Monitoramento	`df -h
Notificação	`systemctl is-active –quiet mysql

Vamos para a versão 2.0 do Runbook Linux automatizado, com diagnóstico avançado de serviços web, bancos de dados, cache e containers, totalmente pronto para produção. Ele vai fazer tudo em um comando, gerar relatórios detalhados, reiniciar serviços travados e até alertar sobre problemas críticos.

🛠️ Runbook Linux 2.0 – Full Stack

#!/bin/bash
# ============================================
# Runbook Linux Full Stack – Versão 2.0
# Autor: Germano Ferreira
# Objetivo: Diagnóstico + Mitigação + Relatório completo
# Inclui: Linux, Apache/Nginx, PHP-FPM, MySQL/Postgres, Redis, Docker
# ============================================

# CONFIGURAÇÕES
EMAIL_ADMIN="admin@dominio.com"
LOG_DIR="/var/log/runbook_logs"
mkdir -p $LOG_DIR
REPORT="$LOG_DIR/runbook_full_$(date +%Y%m%d_%H%M%S).log"

# CABEÇALHO
echo "============================================" | tee $REPORT
echo "Runbook Linux Full Stack 2.0" | tee -a $REPORT
echo "Data: $(date)" | tee -a $REPORT
echo "Host: $(hostname)" | tee -a $REPORT
echo "============================================" | tee -a $REPORT

# 1️⃣ Diagnóstico Geral do Sistema
echo -e "\n[+] Diagnóstico CPU/Memória" | tee -a $REPORT
free -h | tee -a $REPORT
top -b -n1 | head -n 15 | tee -a $REPORT

echo -e "\n[+] Diagnóstico Disco e Inodes" | tee -a $REPORT
df -h | tee -a $REPORT
df -i | tee -a $REPORT

# 2️⃣ Serviços Críticos (Web, DB, Cache)
SERVICOS=("nginx" "apache2" "php-fpm" "mysql" "postgresql" "redis-server")

echo -e "\n[+] Verificando serviços críticos" | tee -a $REPORT
for svc in "${SERVICOS[@]}"; do
    systemctl is-active --quiet $svc
    STATUS=$?
    if [ $STATUS -eq 0 ]; then
        echo "$svc: ✅ Ativo" | tee -a $REPORT
    else
        echo "$svc: ❌ Inativo, tentando reiniciar..." | tee -a $REPORT
        systemctl restart $svc
        sleep 2
        systemctl is-active --quiet $svc && echo "$svc: ✅ Reiniciado" | tee -a $REPORT || echo "$svc: ❌ Falha ao reiniciar" | tee -a $REPORT
    fi
done

# 3️⃣ Logs Críticos Recentes
echo -e "\n[+] Últimos logs críticos (50 linhas)" | tee -a $REPORT
for svc in "${SERVICOS[@]}"; do
    LOG_FILE=""
    case $svc in
        nginx) LOG_FILE="/var/log/nginx/error.log" ;;
        apache2) LOG_FILE="/var/log/apache2/error.log" ;;
        php-fpm) LOG_FILE="/var/log/php-fpm/error.log" ;;
        mysql) LOG_FILE="/var/log/mysql/error.log" ;;
        postgresql) LOG_FILE="/var/log/postgresql/postgresql-*.log" ;;
        redis-server) LOG_FILE="/var/log/redis/redis-server.log" ;;
    esac
    if [ -f $LOG_FILE ]; then
        echo -e "\n--- $svc ---" | tee -a $REPORT
        tail -n 50 $LOG_FILE | tee -a $REPORT
    fi
done

# 4️⃣ Diagnóstico de Containers Docker
if command -v docker &> /dev/null; then
    echo -e "\n[+] Diagnóstico Docker Containers" | tee -a $REPORT
    docker ps -a --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" | tee -a $REPORT
    # Reiniciar containers parados
    for container in $(docker ps -a -q -f "status=exited"); do
        echo "Container $container parado ❌ Reiniciando..." | tee -a $REPORT
        docker start $container && echo "✅ Reiniciado $container" | tee -a $REPORT
    done
fi

# 5️⃣ Processos Pesados
echo -e "\n[+] Processos com maior uso de memória" | tee -a $REPORT
ps aux --sort=-%mem | head -n 10 | tee -a $REPORT

echo -e "\n[+] Processos com maior uso de CPU" | tee -a $REPORT
ps aux --sort=-%cpu | head -n 10 | tee -a $REPORT

# 6️⃣ Rede: portas e conexões
echo -e "\n[+] Portas abertas e processos associados" | tee -a $REPORT
ss -tulnp | tee -a $REPORT

# 7️⃣ Alertas críticos
echo -e "\n[+] Alertas críticos" | tee -a $REPORT
MEM_UTIL=$(free | awk '/Mem:/ {printf "%.0f", $3/$2*100}')
[ $MEM_UTIL -ge 90 ] && echo "⚠️ ALERTA: Memória crítica ($MEM_UTIL%)" | tee -a $REPORT
df -h | awk '$5+0>80 {print "⚠️ ALERTA: Disco cheio -> "$6" "$5}' | tee -a $REPORT
systemctl list-units --failed | tee -a $REPORT

# 8️⃣ Limpeza de logs antigos (>30 dias)
echo -e "\n[+] Limpando logs antigos" | tee -a $REPORT
find /var/log -type f -name "*.log" -mtime +30 -exec truncate -s 0 {} \;
echo "✅ Logs antigos truncados" | tee -a $REPORT

# 9️⃣ Relatório Final e Envio
echo -e "\n[+] Runbook finalizado. Relatório salvo em: $REPORT" | tee -a $REPORT
if command -v mail &> /dev/null; then
    mail -s "Runbook Full Stack Report $(hostname)" $EMAIL_ADMIN < $REPORT
fi

echo -e "\n============================================"
echo "✅ Runbook Full Stack concluído"
echo "============================================"

✅ Funcionalidades Avançadas da Versão 2.0

Diagnóstico completo de:
- CPU, memória, disco, inodes
- Serviços críticos: web, banco, cache
- Containers Docker
- Processos pesados e rede
Mitigação automática:
- Reinicia serviços travados
- Reinicia containers parados
- Trunca logs antigos
Alertas críticos:
- Memória > 90%
- Disco > 80%
- Serviços falhando
Relatório pronto para auditoria:
- Salvo em /var/log/runbook_logs
- Pode ser enviado por e-mail
Plug and Play:
- Basta salvar, tornar executável e rodar com sudo ./runbook_full.sh

FAQ

O que é um runbook?

Um runbook é um guia passo a passo para executar tarefas operacionais ou reagir a incidentes em TI, permitindo ações rápidas e padronizadas.

Por que alguns runbooks não funcionam?

Runbooks falham quando são desatualizados, confusos ou não testados. Um runbook eficaz precisa ser claro, direto e testado em produção.

Como criar runbooks que realmente funcionam?

Foque em: passos claros, ordem lógica, pré-requisitos, comandos prontos, mitigação de falhas, automação sempre que possível e documentação de incidentes.

Quais tipos de runbooks existem?

Incidentes: resolução rápida de falhas
Manutenção: atualizações e backup
Recuperação: restore de backups ou failover
Monitoramento: checagem de recursos e alertas

Quais ferramentas ajudam na execução de runbooks?

Wikis corporativas, Confluence, Notion, scripts automatizados em Bash ou Python, integrações com Slack/Teams para alertas e ferramentas de monitoramento como Zabbix, Grafana ou Prometheus.

Qual a vantagem de runbooks automatizados?

Eles reduzem erros humanos, aceleram a resolução de incidentes, padronizam procedimentos e permitem gerar relatórios de auditoria automaticamente.

Veja Mais: Backup de todos os bancos de dados mysql em um servidor Linux
Veja Mais: Como Usar htop, iotop e Glances para Diagnóstico Rápido de Servidores Linux
Veja Mais: Principais comandos Linux que todo sysadmin deve conhecer (Guia Completo)
Veja Mais: Como instalar o CENTMIN MOD no Almalinux 8
Veja Mais: Como Interpretar Logs do Linux: Guia Completo para Sysadmins