Linux de sysadmin para dev: o que muda quando você passa de roteador para aplicação

Uso Linux desde 2011 — KDE no desktop, Kubuntu na época. Profissionalmente desde 2013.

Roteador é Linux. Qualquer engenheiro de redes sabe disso. Cisco IOS, MikroTik RouterOS, firmware de equipamento de telecom — todos construídos em cima de kernel Linux. Quando você configura rota estática ou regra de firewall num roteador, você está operando Linux sem GUI há décadas.

O que mudou em 2019, quando comecei a operar servidores de aplicação na POA Software, não foi o sistema operacional. Foi a natureza do que estava rodando em cima.

Roteador falha: rede cai, clientes reclamam do ISP. Aplicação falha: dados de lead são perdidos, sistema de vendas para, cliente específico liga pra você.

Essa proximidade com o impacto do software mudou como eu operava o servidor.

O que muda quando tem consequência

Em desktop, log de sistema é curiosidade. Em servidor, log é a primeira coisa que você abre quando algo dá errado.

tail -f /var/log/nginx/error.log
journalctl -u myapp.service -f
journalctl --since "1 hour ago" | grep ERROR

Aprendi a ler log com atenção — não só procurar o erro, mas entender o contexto antes do erro. O que estava acontecendo quando o problema apareceu? Qual requisição veio imediatamente antes? Tem padrão de horário?

Em desktop, um crash é inconveniência. Em servidor, um crash às 3h da manhã é incidente. A diferença de postura ativa um conjunto diferente de hábitos.

Systemd: o que realmente importa saber

No homelab comecei a usar systemd de verdade. Não só systemctl start/stop — entender o que um service unit file significa:

[Unit]
Description=My App
After=network.target postgresql.service

[Service]
Type=simple
User=myapp
WorkingDirectory=/opt/myapp
ExecStart=/opt/myapp/venv/bin/python app.py
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

After=postgresql.service garante que o banco sobe antes da aplicação. Restart=always com RestartSec=5 reinicia automaticamente em caso de crash com 5 segundos de espera.

Isso parece detalhe. Quando o servidor reinicia às 3h por atualização de kernel e sua aplicação não sobe porque o banco ainda está inicializando, você lembra do After=.

Bash scripting como ferramenta de operação

Desktop: você faz tarefas manuais. Servidor: você automatiza tarefas manuais.

Primeiro script que escrevi para produção era backup:

#!/bin/bash
set -e  # para em qualquer erro

DATE=$(date +%Y%m%d_%H%M%S)
BACKUP_FILE="/backups/db_${DATE}.sql.gz"

pg_dump mydb | gzip > "$BACKUP_FILE"
echo "Backup criado: $BACKUP_FILE"

# mantém só os últimos 7 dias
find /backups -name "db_*.sql.gz" -mtime +7 -delete

set -e é a linha mais importante. Sem ela, o script continua mesmo com erro — você pode deletar backups antigos sem ter criado o novo. Com ela, para no primeiro erro.

O find -mtime +7 -delete parecia simples. Testei em pasta vazia antes de usar em produção. Sempre testa comandos destrutivos antes.

O que aprendi sobre permissões em produção

Desktop: você roda tudo como usuário principal. Servidor: cada serviço roda como usuário dedicado com permissões mínimas.

Nginx roda como www-data. PostgreSQL roda como postgres. Minha aplicação rodava como myapp.

Por quê? Se alguém explorar uma vulnerabilidade na aplicação, o processo comprometido tem acesso apenas ao que myapp pode acessar — não ao sistema inteiro.

Na prática: criar usuário de sistema sem shell de login, dar permissão só nos diretórios necessários, nunca rodar serviço como root.

Isso vinha de prática de segurança que eu tinha visto na Oi — princípio de menor privilégio. Aplicar em servidor Linux profissional foi natural, mas exigiu disciplina que o ambiente de desktop não força.

Cron vs systemd timers

Em 2019 ainda usava cron para agendamento. Funciona. Mas tem ciladas:

Cron não tem as variáveis de ambiente do seu shell. Use caminhos absolutos.
Cron não é integrado ao journald. Logs vão para /var/log/syslog ou para onde você redirecionar.
Se o servidor estava desligado quando o cron devia rodar, o job não executa.

# Funciona (caminho absoluto):
0 3 * * * /usr/bin/python3 /opt/myapp/backup.py >> /var/log/backup.log 2>&1

# Não funciona (python3 não no PATH do cron):
0 3 * * * python3 /opt/myapp/backup.py

Parece detalhe. É o tipo de falha silenciosa que você descobre quando precisa do backup e não tem.

Desktop Linux te dá conforto com CLI. Servidor Linux te ensina rigor.

Rigor em automação — testa o script antes de colocar em produção. Rigor em permissões — menor privilégio por padrão. Rigor em logs — se não está logando, você não vai saber o que aconteceu. Rigor em backup — teste de restore, não só de criação.

Essas práticas não vêm de tutorial. Vêm de errar em produção e aprender o custo do descuido.

Essa semana: pega um script que você usa regularmente e adiciona set -e no começo. Depois testa o que acontece quando um dos comandos falha. Vai aprender algo sobre o comportamento atual que provavelmente não sabia.