Quando o sysadmin sai, a empresa descobre o preço do trabalho invisível

Tem empresa que só entende o que a operação fazia no dia em que a operação some.

Até lá, parece que estava tudo “rodando sozinho”. Login funciona, backup aparece, VPN conecta, alerta para de gritar, acesso é liberado, certificado renova, impressora volta a respirar e ninguém pergunta muito como aquilo continua de pé.

Aí um sysadmin sai, ou o time encolhe até sobrar uma pessoa só, e a ficha cai do pior jeito: não era estabilidade. Era dependência mal escondida.

Esse tipo de caso voltou a aparecer em discussão pública de comunidade técnica nos últimos dias. O relato muda um pouco, mas o roteiro é conhecido: alguém sai, quem fica herda acesso, incidente, projeto atrasado, suporte interno, fornecedor, documentação quebrada e ainda escuta que “agora precisa segurar as pontas”. Em geral, sem novo título, sem reforço de time e sem um plano sério de transição.

Não é exatamente uma história sobre heroísmo técnico. É mais sobre empresa que terceiriza a própria previsibilidade para a boa vontade de quem ainda não pediu demissão.

O problema não é a saída. É descobrir tarde demais que o bus factor era 1

Em engenharia de software, o termo bus factor mede quantas pessoas podem sumir antes de um projeto travar de verdade. Quando esse número é 1, a situação é simples de entender e péssima de administrar: uma única pessoa concentra contexto, acesso, histórico e improvisos que mantêm o ambiente funcionando.

Isso não acontece só em código legado. Acontece muito em infra, suporte interno, identidade, deploy, permissões, fornecedores, billing e todos aqueles cantos da operação que parecem invisíveis até falharem.

O erro de leitura mais comum é tratar esse cenário como prova de que o profissional era “indispensável demais”. Na prática, muitas vezes é o contrário: a empresa deixou conhecimento, acesso e responsabilidade se acumularem num único ponto porque isso parecia mais rápido no curto prazo.

É o atalho clássico:

• deixa com quem já conhece
• evita gastar tempo com documentação
• adia rotação de responsabilidade
• segura acesso centralizado “por segurança”
• resolve a urgência de hoje e empurra a fragilidade para amanhã

A conta chega quando alguém entra de férias, muda de time, pede demissão ou simplesmente não consegue mais sustentar tudo sozinho.

O trabalho invisível da TI quase nunca entra na planilha direito

Boa parte do valor operacional em TI não aparece como feature lançada.

Ninguém bate palma porque o restore funcionou no teste. Ninguém faz post no LinkedIn porque a renovação do certificado não quebrou nada. Quase nunca existe glamour em revisar permissão antiga, limpar acesso órfão, padronizar inventário, manter runbook utilizável ou documentar gambiarra antiga antes que ela vire folclore corporativo.

Mas é justamente esse trabalho que impede a empresa de virar refém do acaso.

Quando ele fica concentrado em uma pessoa, o time começa a depender de memória individual em vez de processo minimamente confiável. A operação passa a rodar no modo “pergunta para fulano”, que funciona até o dia em que fulano some do Slack.

Tem outro detalhe que piora tudo: quem segura esse tipo de operação costuma virar referência para incidentes, exceções, acessos urgentes e contexto histórico. Ou seja, não é só conhecimento técnico. É também conhecimento político, relacional e operacional. Sem isso, o substituto não herda um ambiente. Herda um quebra-cabeça.

Offboarding ruim não gera só desconforto. Gera risco real

Quando a saída de alguém é mal tratada, o prejuízo não fica só na produtividade do time.

Materiais recentes sobre offboarding de TI batem sempre nos mesmos riscos: credenciais esquecidas, contas ainda ativas, dispositivos não recolhidos, acessos compartilhados, handoff incompleto e informação crítica que ninguém sabe mais onde procurar. O problema não é só “perder uma pessoa boa”. É abrir buraco operacional e de segurança ao mesmo tempo.

Segundo análises recentes de mercado, processos manuais e improvisados de offboarding continuam gerando pontos cegos básicos: acesso que não foi revogado, conhecimento que não foi transferido e responsabilidade crítica sem backup real. É a combinação perfeita para incidente bobo virar crise cara.

No mundo ideal, desligamento de função crítica deveria acionar checklist técnico, rotação de acesso, mapa de dependências, transição de fornecedor, revisão de credenciais e documentação do que não pode ficar só na cabeça de alguém.

No mundo real, muita empresa ainda trata isso como detalhe de RH com um tempero de “a TI depois vê”.

É aí que nasce aquela situação absurda em que a pessoa sai e o resto do time descobre, em câmera lenta, quais sistemas só existiam de forma compreensível dentro de uma cabeça.

O sinal mais perigoso é quando a empresa chama isso de normal

Tem ambiente que normalizou tão bem a sobrecarga que já considera aceitável:

• uma pessoa tocar produção, suporte, acesso e fornecedor
• deploy crítico depender de memória informal
• documentação existir pela metade
• credencial compartilhada morar em anotação antiga
• onboarding novo começar por engenharia reversa
• férias virarem risco operacional

Quando isso acontece, o problema deixou de ser individual faz tempo. Virou modelo de gestão.

E quase sempre esse modelo vem embalado em frases que parecem pragmáticas, mas só escondem precariedade:

• “somos enxutos”
• “todo mundo faz um pouco de tudo”
• “não dá tempo de documentar agora”
• “quando precisar a gente organiza”
• “ele conhece esse ambiente como ninguém”

Se a operação depende demais de um herói, não existe maturidade ali. Existe apenas sorte acumulada.

O que dá para fazer antes do próximo susto

Não precisa transformar a empresa numa máquina burocrática para reduzir esse risco. Mas precisa sair do improviso.

O mínimo decente costuma incluir:

• mapear áreas em que só uma pessoa consegue agir sem ajuda
• definir pelo menos um backup real para cada zona crítica
• documentar o suficiente para outra pessoa conseguir operar sem ritual místico
• revisar acessos, contas compartilhadas e pontos de falha em offboarding
• rodar transição prática, não só repasse teórico em call corrida
• tratar férias, folga e troca de função como teste de resiliência

Se ninguém consegue assumir uma parte crítica por duas semanas sem caos, o problema já existe. Ele só ainda não estourou.

No fim, o recado é bem menos filosófico do que parece. Empresa madura não é a que nunca perde gente importante. É a que não descobre a própria fragilidade só depois que alguém sai.

E, em TI, esse tipo de fragilidade quase sempre atende pelo mesmo nome: trabalho invisível que ficou concentrado demais por tempo demais.

Fontes

• Relato público recente de comunidade: https://www.reddit.com/r/sysadmin/comments/1tb61du/lost_my_sysadmin_now_im_solo_could_use_some_advice/
• Bus Factor — Laws of Software Engineering: https://lawsofsoftwareengineering.com/laws/bus-factor/
• What is the bus factor? — Pragmatic Coders: https://www.pragmaticcoders.com/blog/what-is-the-bus-factor
• The hidden security risks of employee offboarding — BetterCloud: https://www.bettercloud.com/monitor/the-hidden-security-risks-of-employee-offboarding/