A notificação apareceu às 03:12 da manhã: um pequeno ponto vermelho no ecrã que, na prática, queria dizer que muita gente estava prestes a ficar irritada. Algures entre a página do carrinho e uma API de pagamentos, os números desceram. O tempo de resposta duplicou. Mil utilizadores invisíveis começaram a esperar um pouco mais do que o aceitável. Fiquei sentado na penumbra da sala, com a luz azul do portátil a bater-me na cara, a ver gráficos em vez de dormir. É isto que é a monitorização de desempenho quando se tira a camada de jargão: não é um folheto brilhante de tecnologia - sou eu, um portátil, uma sweatshirt com capuz e três painéis abertos.
Recebo 66 800 dólares por ano para reparar em problemas antes de outras pessoas sequer perceberem que existem.
Há dias em que isso parece um superpoder. Noutros, parece um segredo que ninguém entende verdadeiramente.
O que significa, na prática, receber 66 800 dólares por ano em monitorização de desempenho
Quando as pessoas ouvem o meu salário e o cargo, imaginam-me a olhar para um único ecrã a piscar enquanto bebo café com gelo. Em parte, acertam. Mas “desempenho”, neste contexto, não tem nada a ver com produtividade pessoal. Tem a ver com a rapidez - e a harmonia - com que dezenas de sistemas “respiram” em conjunto.
A maior parte do meu tempo é passada a ler padrões. Pequenas variações no uso de CPU, um aumento lento na taxa de erros, um pico discreto de latência logo a seguir a uma implementação de código. São sussurros que me dizem que algo não está bem, muito antes de existir um apagão comentado nas redes sociais ou uma cadeia de e-mails furiosa vinda da gestão.
Numa terça-feira à tarde, por exemplo, vi o nosso serviço de autenticação passar de verde “saudável” para um amarelo ansioso em menos de dez minutos. Não foi um salto enorme - apenas alguns pedidos de início de sessão a demorarem 1,8 segundos em vez de 0,9. Sem pager, sem alerta oficial.
Mas eu sabia que, em horas de pico, aquele atraso aparentemente pequeno ia transformar-se numa bola de neve: sessões abandonadas, queixas ao suporte, conversões a cair. Contactei a equipa de desenvolvimento, enviei uma captura de ecrã e recuámos uma alteração mínima de configuração. Ninguém fora da nossa bolha reparou. Sem “relatório de incidente”. Sem drama. Apenas muito dinheiro invisível, poupado em silêncio.
A estranheza deste trabalho é precisamente essa: quando faço bem, não acontece nada. Sem manchetes, sem aplausos - apenas o “normal” a continuar.
O meu ordenado de 66 800 dólares é, no fundo, uma recompensa por evitar desastres que nunca chegam a virar história. É como ser a pessoa que verifica o paraquedas antes do salto e depois vê o paraquedista receber toda a glória. O mundo adora heróis que consertam coisas partidas. A minha função é evitar que partam, e esse tipo de sucesso não vira tendência no LinkedIn.
Como é, de facto, o trabalho por trás dos painéis
O centro do meu dia é uma rotina que, vista de fora, parece aborrecida, mas por dentro tem algo de estranhamente satisfatório. Começo por varrer os painéis da noite: CPU, memória, carga da base de dados, taxas de erro, tempos de resposta do utilizador. Não estou apenas a olhar para números - estou à procura de histórias.
Picos depois de uma campanha de marketing? Normal. Latência às segundas-feiras de manhã? Também normal. Um padrão que aparece às 02:17 três noites seguidas? Isso já não é ruído - é uma pista. O meu trabalho é seguir essa pista antes de se transformar numa indisponibilidade a sério.
A parte mais difícil não é interpretar gráficos. Ferramentas como Datadog, New Relic, Prometheus e Grafana ajudam - e muito. O complicado é decidir que alertas interessam e quais são apenas dramatização de fundo.
No início, cometi o erro clássico: ligar alertas para tudo. Utilização de disco, falhas de cache, contagens de threads, consultas DNS. O telemóvel vibrava como uma colmeia. Dormia mal. E a verdade simples é esta: ninguém aguenta viver assim e manter a sanidade. Hoje, trato alertas como alarmes de incêndio - poucos, bem escolhidos e altos o suficiente para que, quando um toca, eu me mexa de facto.
Há uma competência silenciosa por trás desse filtro. Saber que métricas observar é metade conhecimento técnico, metade juízo humano.
Aprendi a fazer perguntas muito básicas: - Isto afecta um utilizador real? - Se correr mal, custa dinheiro a sério? - Já existe alguém responsável por isto?
Quando a resposta é “sim”, essa métrica ganha um lugar no meu “muro” de ecrãs. Quando é “não”, deixo passar. Toda a gente já viveu aquele momento em que tenta controlar tudo e acaba por não controlar nada. A monitorização de desempenho castiga esse impulso rapidamente.
Monitorização de desempenho com SLIs/SLOs: quando “bom” é mensurável
Uma coisa que mudou a forma como trabalho foi começar a pensar menos em “perfeição” e mais em objectivos claros. Em muitas equipas, isto traduz-se em SLIs (indicadores) e SLOs (objectivos): por exemplo, percentis de latência, taxa de sucesso de transacções e disponibilidade percebida pelo utilizador. Quando estes alvos estão definidos, os alertas deixam de ser sobre “qualquer subida” e passam a ser sobre quebrar expectativas reais.
Na prática, isto também facilita conversas difíceis: em vez de “está lento”, consigo dizer “o percentil 95 passou de 900 ms para 1 800 ms após a última implementação, e isso empurra-nos para fora do nosso objectivo”. A discussão muda de opinião para evidência - e as decisões ficam mais rápidas.
Dinheiro, mentalidade e o conforto estranho de ser “quem vigia”
Falemos dos 66 800 dólares. Para um cargo de nível intermédio fora dos maiores centros tecnológicos, é um valor razoável. Não vivo num loft de luxo, mas as contas estão pagas e a poupança não é uma miragem. O que troco por esse salário é atenção: foco como serviço.
Um método que protege a minha cabeça - e, indirectamente, o meu ordenado - é aquilo a que chamo “micro-rondas”. Em horas de pico, faço passagens curtas e intensas pelos painéis a cada 20–30 minutos. Nada de ficar a olhar eternamente. Nada de vigiar gráficos por desgraça. É uma verificação rápida e uma decisão imediata: estável, a desviar, ou crítico. “Estável” significa voltar ao trabalho de projecto. “A desviar” significa tomar notas e acompanhar. “Crítico” significa falar com pessoas - depressa.
Se te sentes puxado para esta área, há uma armadilha sobre a qual deixo um aviso gentil: prender a tua auto-estima a cada oscilação num painel. Sistemas falham. Implementações comportam-se de forma estranha. Fornecedores de cloud têm soluços. Podes ser excelente e, mesmo assim, ter dias em que tudo parece vermelho e os canais de chat soam a campo de batalha.
Isso não quer dizer que és mau nisto. Quer apenas dizer que trabalhas no mundo real, não num estudo de caso perfeito. As pessoas mais saudáveis que conheci em monitorização aprendem a separar “falhei um pico de latência” de “eu sou um fracasso”. Ajustam limiares, refinam alertas, melhoram a instrumentação e seguem em frente. Aqui, a compaixão por ti próprio não é “soft skill”. É sobrevivência.
Há uma conversa que repito com colegas e amigos:
“O teu trabalho é literalmente preocupar-te para viver”, disse-me um programador uma vez, a brincar a meio.
“Não”, respondi. “O meu trabalho é reparar. Preocupar-me é opcional.”
E reparar bem exige algumas guardas de segurança:
- Escolhe 5–10 métricas nucleares que definem, de facto, o que é “saudável” nos teus sistemas.
- Define limiares de alerta que correspondam a dor real do utilizador, não a uma perfeição teórica.
- Escreve, em linguagem humana, como é o “normal” antes de um incidente.
- Depois de um incidente, regista o que gostavas de ter acompanhado - e adiciona mesmo isso.
- Marca tempo de descanso real em que não estás de prevenção, nem no corpo nem na cabeça.
No papel, parecem detalhes. Levados a sério, são a diferença entre um trabalho sustentável de 66 800 dólares e um esgotamento em câmara lenta.
Comunicação e pós-incidente: a parte invisível da monitorização de desempenho
Outra dimensão que raramente aparece nos painéis é a comunicação. Quando algo degrada, o que digo - e como o digo - pode evitar pânico e acelerar resolução. Mensagens curtas, factuais e orientadas a acção (o que mudou, quando mudou, impacto observado, próximos passos) valem mais do que parágrafos de especulação.
E depois há o pós-incidente: registos claros, revisões sem caça às bruxas e melhorias concretas (runbooks, automatismos, instrumentação). A qualidade desse “depois” determina se o mesmo problema volta - e, na prática, define grande parte do valor de quem trabalha em monitorização.
A história escondida por trás de um “bom” salário na área tecnológica
Quando me perguntam se a monitorização de desempenho “compensa”, normalmente estão a perguntar pelo salário: 66 800 dólares chegam para o stress? Chegam para as noites de prevenção, os alertas ao fim-de-semana, a pressão silenciosa de saber que, se falhares, milhares de utilizadores pagam o preço?
Acho que a pergunta melhor é outra: este tipo de trabalho encaixa na forma como o teu cérebro e as tuas emoções gostam de funcionar? Há quem adore construir funcionalidades do zero. Eu gosto de proteger o que já existe. Há quem ganhe energia com dias de lançamento. Eu ganho energia com dias silenciosos, em que ninguém faz ideia de quão perto esteve de um abrandamento que teria destruído a taxa de conversão.
| Ponto-chave | Detalhe | Valor para o leitor |
|---|---|---|
| A monitorização de desempenho é, na maioria, prevenção | O sucesso tem a forma de “não aconteceu nada”, porque os problemas são apanhados cedo | Ajuda-te a perceber se aceitas um papel com baixa visibilidade e alta responsabilidade |
| Os alertas devem ser curados, não maximizados | Notificações a mais causam fadiga e fazem passar despercebidos os problemas reais | Dá-te uma mentalidade prática para evitar burnout em funções centradas em monitorização |
| Os 66 800 dólares trocam dinheiro por atenção focada | A remuneração está ligada a consciência constante e decisões calmas sob pressão | Permite avaliar se a carga mental combina com os teus objectivos financeiros |
Perguntas frequentes (FAQ)
66 800 dólares é um salário típico em monitorização de desempenho?
É bastante comum para uma função de nível intermédio numa cidade de custo médio, sobretudo fora dos grandes gigantes tecnológicos. Em zonas de custo elevado, funções semelhantes podem pagar mais; em empresas pequenas ou em sectores fora da tecnologia, podem pagar menos.É preciso saber programar para trabalhar em monitorização de desempenho?
Não tens de ser programador a tempo inteiro, mas ajuda muito saber ler logs, compreender APIs e escrever scripts ou consultas simples. Quanto melhor entenderes como os sistemas são construídos, mais depressa consegues identificar o que está a falhar.O trabalho é stressante por causa das prevenções (on-call)?
Pode ser. As semanas de prevenção são mais pesadas, sobretudo quando os alertas fazem muito ruído ou os sistemas são frágeis. Equipas que investem em boas ferramentas, runbooks claros e descanso real tornam o stress muito mais gerível.Que ferramentas são mais comuns nesta área?
É frequente usar ferramentas de APM (monitorização do desempenho de aplicações) como Datadog, New Relic ou AppDynamics, além de pilhas de métricas e registos como Prometheus, Grafana, ELK ou Splunk. Os painéis do fornecedor de cloud também fazem parte da rotina diária.A monitorização de desempenho pode ser uma rampa para outras funções?
Sim. Muita gente transita para SRE, DevOps, engenharia de infra-estruturas ou liderança técnica. Ganha-se uma visão ampla e prática do comportamento dos sistemas, algo valioso em quase toda a tecnologia.
Comentários
Ainda não há comentários. Seja o primeiro!
Deixar um comentário