Ti Trabalha Com O Que

O que o pessoal de TI realmente faz no dia a dia

A pergunta ti trabalha com o que é mais comum do que parece, e a resposta nem sempre é a primeira coisa que vem à cabeça. Muita gente acha que TI é só consertar impressora e reinstalar Windows. A realidade é bem mais ampla e, Honestamente, bem mais fragmentada. Tecnologia da informação se divide em camadas. Tem a parte de infraestrutura, que cuida de servidores, rede, storages e data centers. Tem desenvolvimento, que constrói software e sistemas. Tem segurança, que tenta impedir que alguém entre onde não deveria. Tem suporte, que lida com o usuário final quando algo quebra. Tem governança e gestão, que tentam alinhar tudo isso com o que a empresa realmente precisa.

ti trabalha com o que na prática

Na prática, um profissional de TI típico em uma empresa de médio porte acaba usando cerca de 60 a 70 por cento do tempo em coisas que não têm nada a ver com tecnologia pura. Reunião de alinhamento, documentação, compliance, treinamento de usuários, justificativas de orçamento. O resto do tempo é dividido entre resolver problemas que já aconteceram e tentar fazer coisas que vão funcionar para frente. Eu em infraestrutura há anos. Uma coisa que ninguém te conta é que a maior parte do trabalho técnico real acontece em situações muito específicas, não no dia a dia comum. Eu lembre de uma vez que um cliente de storage SAN começou a apresentar latência intermitente. O monitoramento mostrava tudo dentro da curva normal. O problema era um firmware desatualizado em um dos switches de fibra que causava colisão de frames em horários de pico. Demorou três semanas para isolar. A solução foi um roll back controlado do firmware com janela de manutenção de quatro horas no sábado de manhã. Isso é o tipo de coisa que não está em nenhum tutorial básico.

Outro exemplo: integração entre sistemas legados e cloud. Você ouve muito falar em migração para nuvem, mas a realidade é que muitas empresas ainda rodam ERPs antigos que não foram feitos para containerização. Eu já vi equipe inteira gastar dois meses adaptando uma API de comunicação entre um sistema em COBOL e uma aplicação moderna em Docker. O workaround foi criar uma camada de tradução com um script Python que fazia polling de uma tabela intermediária em SQL Server. Não é bonito, mas funciona e evita refatorar um sistema que ninguém mais entende. As divisões internas são importantes de entender.

DevOps é uma dessas áreas que todo mundo fala e poucos entendem direito. Não é só colocar Jenkins num servidor e chamar de pipeline. É cultura, automação, responsabilidade compartilhada. Um time de DevOps maduro consegue fazer deploy várias vezes ao dia com validação automática. Um time que apenas copiou ferramentas sem adaptar processos acaba criando um novo gargalo na forma de pipelines que travam por erros de configuração mal documentados. Segurança da informação segue lógica parecida. Firewall não é segurança. Autenticação multifator não é segurança. O que existe é uma combinação de controles que, quando bem desenhados, elevam o custo para um eventual atacante até o ponto em que vale mais a pena desistir. A maioria das empresas para no primeiro passo e acha que está protegida.

As limitações existem e precisam ser ditas claramente. TI não resolve tudo. Um dos maiores equívocos das organizações é achar que contratar um departamento de tecnologia é sinônimo de resolver problemas de negócio. Se um processo é ruim, automatizar esse processo ruim só vai gerar resultados ruins mais rápido. Isso acontece com frequência. Eu já vi projeto de automação de aprovações financeiras que reduziu o tempo de processamento de três dias para seis horas, mas aumentou o número de erros em 40 por cento porque a regra de negócio subjacente estava errada.

Outro ponto: a dependência de terceirizados. Muita empresa transfere a responsabilidade técnica para uma SLA e perde visibilidade do que realmente acontece. Quando o contrato prevê tempo de resposta de oito horas para incidentes críticos, a empresa fica vulnerável durante essa janela. Existem alternativas, como contratos com penais por tempo de inatividade e cláusulas de transparência de logs, mas a maioria dos gestores não conhece essas opções. O mercado tem áreas com demanda real e áreas saturadas.

Desenvolvimento web generalista está saturado. Todo mundo aprende React e acha que vai conseguir emprego fácil. A realidade é que vagas para desenvolvedor fullstack júnior recebem em média cento e cinquenta currículos por posição nas grandes cidades. Por outro lado, profissionais com experiência em bancos de dados distribuídos, arquitetura de microsserviços com traçabilidade completa, ou segurança ofensiva aplicada a infraestrutura cloud ainda têm negociação favorável. Administração de sistemas tradicionais, aqueles que só sabiam Windows Server e Active Directory, estão vendo o valor de mercado cair. A migração para ambientes híbridos exige novas habilidades: Kubernetes, Terraform, monitoramento com Prometheus, gerenciamento de identidade com SAML e OAuth. Quem não atualizar nos próximos dois a três anos vai enfrentar dificuldade crescente de posicionamento.

Certificações têm valor, mas com ressalvas importantes. Azul do Google Cloud, certificação AWS Solutions Architect, CISSP, PMP. Todas são reconhecidas, mas nenhuma garante emprego por si só. Eu vi certificado AWS em CV que não correspondia a experiência prática alguma. O candidato sabia decorar respostas de múltipla escolha, mas não conseguia explicar a diferença entre um bucket S3 com versionamento ativado e um sem versionamento quando questionado em entrevista técnica.

O valor real das certificações está em três situações: entrada no mercado para quem não tem experiência comprovada, validação de conhecimento para quem já atua e busca reconhecimento salarial, e exigência contractual em licitações públicas e privadas. Fora isso, a certificação sozinha não move currículo. Ferramentas que todo mundo recomenda e as que realmente funcionam.

Slack e Teams dominaram a comunicação interna, mas criaram um problema novo: fragmentação de informações. Decisões técnicas acontecem em canais paralelos que não deixam rastro. A solução que funcionou para mim foi exigir que qualquer definição técnica importante fosse documentada em umawikicontexto do projeto antes de ser implementada. Não é perfeito, mas reduziu em cerca de sessenta por cento os retrabalhos causados por interpretação equivocada do que havia sido combinado. Jira e Trello são as ferramentas de gestão mais usadas. Jira é poderoso mas pesado. Trello é simples mas insuficiente para projetos complexos. Para times pequenos, eu recomendo o Plane ou o Backlog. Para times maiores, o Azure DevOps ou o próprio Jira com configuração limpa, sem customizações excessivas que transformam o sistema em um obstáculo.

O que esperar nos primeiros anos de carreira. Os dois primeiros anos costumam ser de aprendizado acelerado e frustração controlada. Você vai resolver problemas que já foram resolvidos mil vezes, vai perder tempo com burocracia institucional, vai lidar com usuários que confundem hardware com software. Isso é normal. A curva melhora a partir do terceiro ano, quando você começa a reconhecer padrões e antecipar problemas antes que eles aconteçam.

Salários variam muito. Em São Paulo e Rio de Janeiro, um analista de suporte N1 ganha entre quatro mil e sete mil reais. Um engenheiro de infraestrutura Pleno, entre oito e quatorze mil. Um arquiteto de soluções sênior, entre dezoito e trinta e cinco mil. Essas faixas dependem muito do setor: banco e fintech pagam mais, indústria e varejo pagam menos. Remuneração em empresas de tecnologia puras tende a ser vinte a trinta por cento acima da média do mercado tradicional. Erros comuns que iniciantes cometem.

Achar que precisa saber tudo. Nenhum profissional de TI domina todos os campos. O importante é saber onde encontrar a resposta e quando pedir ajuda. O erro oposto também existe: pedir ajuda antes de tentar resolver. A regra prática é tentar por no máximo vinte minutos antes de buscar apoio. Se em vinte minutos você não chegou a nenhum resultado concreto, alguém com mais experiência vai resolver em cinco. Documentar tarde demais. Documentação feita após a implementação tende a ser incompleta ou desatualizada. O hábito de registrar decisões técnicas enquanto elas acontecem economiza horas de trabalho futuro. Eu uso um arquivo Markdown simples por projeto, atualizado semanalmente. Nada elaborada. Apenas o que foi decidido, o porquê e quem foi o responsável.

Não perguntar sobre custos. Projetos de TI muitas vezes superam o orçamento porque ninguém considerou custos ocultos: licenças de software, treinamento da equipe, tempo de indisponibilidade durante a migração, multas contratuais. Um projeto de migração de e-mail que eu vi orçado em cinquenta mil reais acabou custando cento e vinte mil quando incluímos a recuperação de dados de uma pasta oculta que ninguém sabia que existia. O futuro próximo da área.

Inteligência artificial generativa está mudando a forma como código é escrito, mas não substituindo o raciocínio de arquitetura. Ferramentas como GitHub Copilot e ChatGPT aceleram a escrita de código em cerca de quarenta por cento para tarefas rotineiras. O que não acelera é a decisão de qual padrão arquiteturar adotar, como garantir consistência em transações distribuídas, ou como lidar com fallback em sistemas críticos. A regulamentação de dados está tornando a privacidade uma exigência técnica, não apenas legal. LGPD e leis similares exigem que soluções sejam desenhadas com privacy by design desde o início. Empresas que implementaram isso tardiamente enfrentaram refações custosas em sistemas de CRM e ERP.

Infraestrutura como código já é padrão em empresas maduras. Quem ainda configura servidores manualmente está atrasado. Terraform, Ansible e CloudFormation reduzem drasticamente erros humanos em provisionamento, mas exigem disciplina de versionamento e revisão de código igual a qualquer outra entrega de software. O setor continua oferecendo oportunidades reais para quem se mantém atualizado. Não é fácil, não é glamouroso, e muitos dos problemas são repetitivos. Mas a margem para quem constrói competência consistente é ampla. A diferença entre um profissional mediano e um bom está quase sempre na capacidade de entender o problema real antes de propor a solução técnica.