Transformando o celular em uma caixa de ferramentas DevOps para troubleshooting remoto

Tem incidente que começa quando você está sentado na frente do notebook.

E tem incidente que começa na rua, no almoço ou longe da máquina que tem todos os seus aliases, scripts e chaves organizados.

Foi daí que nasceu a ideia: o celular não precisava substituir o notebook. Precisava me dar uma primeira resposta técnica boa o suficiente para entender o cenário sem sair executando comando no escuro.

O resultado foi um toolkit em Bash rodando no Termux, com menus em fzf, acesso SSH e diagnósticos voltados para operação real.

A parte interessante não é “rodar Linux no Android”. Isso é fácil.

O trabalho de verdade foi transformar um terminal pequeno em uma interface de plantão que reduz digitação, coleta evidência e evita que pressa vire mudança desnecessária.

O problema que eu queria resolver #

Em um alarme, normalmente eu preciso responder algumas perguntas antes de qualquer ação:

• o host está acessível?
• CPU, memória ou disco estão fora do normal?
• existe sinal de OOM?
• o serviço está nativo ou dentro de container?
• Nginx está válido?
• qual proxy_pass atende aquela aplicação?
• PostgreSQL tem query longa, lock ou espera?
• MySQL está respondendo?
• MongoDB tem operação presa?
• o container está reiniciando?
• o erro visto no monitoramento existe de verdade naquele momento?

Digitar toda essa investigação manualmente no teclado do celular não faz sentido.

Então o objetivo virou outro: selecionar o sintoma, escolher o host e receber uma coleta organizada.

O celular virou uma interface para os mesmos diagnósticos #

O toolkit cresceu em torno de menus fzf.

Em vez de decorar dezenas de funções, o fluxo pode ser algo próximo de:

1
2
3
4
5
6
7
8
9

Alarme / incidente
  ↓
Escolher o tipo de diagnóstico
  ↓
Selecionar o host
  ↓
Executar coleta read-only
  ↓
Gerar evidência + resumo

Isso parece detalhe de UX, mas em plantão muda bastante coisa.

Quando o alarme já diz “CPU alta”, eu não quero primeiro escolher um servidor e depois navegar por uma lista de possibilidades. Quero começar pelo problema que estou tentando validar.

Diagnóstico adaptativo: nativo, sudo ou Docker #

Uma das decisões que mais ajudou foi não presumir onde o serviço roda.

O mesmo ambiente pode ter PostgreSQL instalado no host em um servidor e dentro de Docker em outro. O diagnóstico precisa descobrir isso antes de montar o comando.

No toolkit, as rotinas de banco foram desenhadas com esse tipo de fallback:

1
2
3
4
5

serviço local
  ↓ se não encontrado
sudo / usuário do serviço
  ↓ se não encontrado
container Docker

A ideia não é esconder como o ambiente funciona. É tirar da cabeça do operador a necessidade de lembrar a topologia exata antes de começar a investigação.

Para PostgreSQL, por exemplo, a coleta pode olhar queries ativas, transações longas e locks. MySQL e MongoDB seguem o mesmo conceito adaptado às ferramentas de cada banco.

Nginx: primeiro validar, depois interpretar #

No diagnóstico web, o básico continua valendo.

Antes de discutir aplicação, CDN ou rede, eu quero saber se a configuração do Nginx é válida e para onde ele está enviando a requisição.

Uma coleta útil inclui coisas como:

1

nginx -t

listagem de vhosts, extração de proxy_pass e as últimas linhas relevantes do error log.

Não resolve todos os incidentes. Nem precisa.

Ele precisa responder rápido se o problema está perto da camada web ou se vale seguir para aplicação, container ou banco.

O fluxo de Zabbix ficou ligado ao diagnóstico #

Outro ganho foi ligar alerta e investigação.

Em vez de o Zabbix ser apenas o lugar que diz “tem problema”, o menu de plantão pode levar diretamente para a rotina compatível com o sintoma: CPU, memória, disco, API, PostgreSQL, Redis, RabbitMQ ou diagnóstico geral.

O ponto aqui não é automatizar a correção.

É automatizar a coleta repetitiva que vem antes da decisão.

Isso reduz o tempo gasto copiando comando e aumenta a chance de dois incidentes parecidos serem investigados do mesmo jeito.

Relatório completo e resumo são coisas diferentes #

No começo é tentador jogar tudo para o clipboard e mandar no grupo.

Não funciona bem.

Um diagnóstico técnico pode ter dezenas ou centenas de linhas. Quem está acompanhando o incidente normalmente precisa de outra coisa:

1
2
3
4
5

Status
Sintoma
Achados principais
Ação recomendada
Referência para a evidência completa

Por isso o desenho evoluiu para dois artefatos:

Evidência completa: saída técnica com comandos, métricas e logs necessários para continuar a análise.

Resumo operacional: poucas linhas para comunicar o que foi encontrado sem despejar terminal na conversa.

Essa separação parece pequena, mas melhora muito a comunicação durante incidente.

Mas tem um problema sério: evidência também pode vazar infraestrutura #

Quando comecei a exportar o toolkit para revisão, apareceu um risco que vale um artigo sozinho.

Mesmo sem copiar senha ou chave privada, um pacote de troubleshooting pode carregar:

• FQDNs internos;
• hostnames de clientes;
• usernames de SSH;
• IPs públicos e privados;
• endereços de interfaces de gerenciamento;
• nomes de projetos;
• topologia suficiente para identificar um ambiente.

Então “não tem senha” não significa “está seguro para compartilhar”.

Um export público ou enviado para análise precisa de sanitização própria.

No meu caso, uma das rotinas já mascara variáveis de ambiente cujo nome indica PASS, TOKEN, SECRET ou KEY. A evolução natural é aplicar o mesmo princípio a hostnames, IPs, usernames e arquivos que nem deveriam entrar no pacote.

O maior problema do toolkit não era falta de recurso #

Depois de um tempo, o problema deixou de ser “o que falta adicionar?”.

Virou “quantas versões da mesma função existem?”.

O crescimento por arquivos de override criou redefinições silenciosas de funções de menu e diagnóstico. Em Bash, a última definição carregada vence.

Isso significa que uma alteração aparentemente inocente pode fazer um menu antigo voltar a ser o menu ativo.

É o tipo de bug que não aparece quando você salva o arquivo. Aparece quando está no plantão.

A lição foi clara: toolkit operacional também precisa de arquitetura.

O caminho de evolução é quebrar responsabilidades em módulos — AWS, diagnósticos, SSH, menus, relatórios — e reduzir override usado como mecanismo permanente de manutenção.

O que eu não automatizaria no celular #

Ter um menu fácil não é licença para colocar ação destrutiva atrás de dois cliques.

O uso mais valioso do Termux aqui é:

• inventário;
• coleta;
• consulta;
• validação;
• acesso rápido;
• geração de evidência;
• preparação de uma decisão.

Restart, limpeza, alteração de banco, mudança de firewall ou qualquer ação com blast radius relevante continua pedindo contexto e confirmação.

Quanto mais fácil a interface, mais importante fica separar diagnóstico de mudança.

O que ficou de aprendizado #

O celular funciona muito bem como console de primeira resposta quando três coisas estão resolvidas:

1. os comandos repetitivos já viraram funções confiáveis;
2. o fluxo começa pelo sintoma e não pela memória do operador;
3. o resultado vira evidência reaproveitável, não só texto que some no terminal.

Não substitui uma workstation para investigação longa.

Mas para validar um alarme, localizar a camada provável, coletar dados e decidir se preciso abrir o notebook imediatamente, ele resolve muito mais do que eu imaginava no começo.

No fim, o ganho não veio de colocar mais comandos no celular.

Veio de diminuir o número de decisões pequenas que eu preciso tomar antes de começar a investigar o problema de verdade.