Porque ela não serve para apagar incêndios agora
Deformação profissional: quando o trabalho forma maus hábitos
Já escrevi que, na área de TI, com centenas de mudanças diárias, não são os hábitos domésticos que definem a abordagem ao trabalho — é o contrário: o trabalho nos forma para resolver problemas de forma imediata, muitas vezes sem análise adequada das consequências.
Encontrei para você alguns exemplos de como as pessoas cedem ao apelo do resultado imediato, usando o exemplo da compra impulsiva. Infelizes, no momento do pedido, acreditavam que comprar em um clique seria o único passo para resolver o problema.
E quem fez isso?Imagine que CTOs e PMs de grandes empresas agem exatamente assim. Eles encomendam às equipes DevOps “soluções prontas”. Ao receberem a esperada “caixa” com as mais recentes tecnologias (Apache Kafka, armazenamento objeto S3, banco de dados shardado, busca semântica), eles nem percebem a desagradável verdade: o produto não vem com instruções de instalação, configuração e operação. Não há scripts de implantação, nem capacidade de escalabilidade, monitoramento de desempenho. E o mais importante — ninguém avisou a equipe DevOps de que essas tecnologias seriam realmente implementadas.
Passam três meses desde o pedido, mas, em vez de alívio esperado, o líder enfrenta um novo ciclo de problemas. Seu desapontamento pode ser expresso com as palavras: “Chegou a caixa… mas, três meses depois da entrega, esqueci por que a ordenei”. A busca por vitórias rápidas se transforma em caos operacional, e a ausência de planejamento estratégico transforma as tecnologias em fonte de inúmeros problemas.## Nós precisamos da Kafka para o próximo lançamento
Alguém dos tech leads leu um artigo no Habr sobre “transmissão de eventos em tempo real”, acenou e disse que precisamos da Kafka. Sem pedidos de propostas. Sem revisão de arquitetura. Sem envolvimento do DevOps. Conhecido?
Sim, a Kafka é de código aberto. Sim, ela escala. Mas pergunte a qualquer equipe que a operou em clusters: a maturidade da Kafka é não linear — é uma função em degraus.
- 0–6 meses: “Tudo funciona!” — Desbalanceamento oculto de partições, carga desigual nos brokers, latência não controlada
- 6–12 meses: “Por que as latências estão aumentando?” — Rebalanceamento manual, apagamento de incêndios, responsabilidade fragmentada
- 12+ meses: “Quem é responsável por isso? Como desligamos isso mesmo?” — “Nascimento de zumbis” com custos não contabilizados de suporte externo
Sem automação, observabilidade e gestão de ciclo de vida da ecossistema Kafka, não temos fluxos de dados — temos fluxos de alertas no Telegram.## Armazenamento compatível com S3? Ótimo. Agora proteja-o
A equipe do Ozon gastou meses para reestruturar o Lusca para um armazenamento compatível com S3 — não porque o S3 seja complexo, mas porque implementar consistência forte sobre uma arquitetura baseada em eventos, gerenciar processos em segundo plano da base de dados e restaurar terabytes de dados são tarefas que exigem expertise profunda e tempo.
Pior ainda: se você implantar isso dentro de contêineres sem higiene DevSecOps — sem varredura de imagens, sem armazenamento de segredos, sem políticas de rede L7 — você não criará um armazenamento. Você criará um vetor de vulnerabilidade e um \u003cdel\u003edéficit técnico\u003c/del\u003e.Incêndio.
Sharding de BD: ponto de não retorno
Shard somente após esgotar o escalonamento vertical, otimização de consultas, níveis de cache e réplicas para leitura. É o último recurso.
Fazer isso de forma incorreta resultará em “shards quentes”, latência de replicação e falhas de requisições entre shards. Especialmente se a chave de sharding for escolhida de forma inadequada. Fazer isso sem ferramentas DevOps para backup, monitoramento e redistribuição - trocaremos escalabilidade por resiliência.
O ponto é que não conseguiremos “des-shardar”. Uma vez implementado, não é possível voltar sem um sofrimento enorme.
E agora vem o problema real — não técnico, mas organizacional
Nenhum benchmark dirá que o gargalo mais crítico no DevOps moderno não são recursos mentais, memória ou velocidade de execução. Porque isso é — atraso na tomada de decisões devido a problemas com a roadmap.Em algumas empresas, não existe roadmap de DevOps. Em outras, simplesmente não existe. Porque a estratégia é entregue às vendas de soluções de “coluna” (demo).
O que leva uma cultura de execução reativa?
- Após o CTO assinar o pedido de desenvolvimento, os engenheiros recebem, em vez de especificações, um “automatize isso em 100 servidores” — sem documentação, sem arquitetura clara, sem cobertura de testes.
- E três meses depois: “Por que é tão lento? E por que construímos isso no primeiro lugar?”
Isso não é liderança. É evasão de responsabilidade.
As equipes DevOps em organizações reativas esgotam sua boa vontade, correndo atrás de fantasmas nos logs e gráficos, corrigindo o que nunca projetaram e defendendo o que nunca possuíram.E quando algo quebra? A culpa recai sobre as pessoas, não sobre os processos. Isso não é DevOps, é uma equipe de “YasnoOps” — videntes. Uma cultura DevOps madura não pergunta quem errou. Ela pergunta o que causou o falha e corrige o sistema, e não busca o culpado. No seu caso, o sistema é a ausência de uma roadmap e a falta de envolvimento do DevOps na fase de tomada de decisão.
Contexto russo: velocidade contra estabilidade
Nos anos de 2023-2024, o mercado SaaS na Rússia cresceu para vários trilhões de rublos, mas isso não é um mercado estável e previsível, é uma panela de pressão. A corrida por parecer moderno destrói as bases necessárias para ser moderno.Nós deveríamos estar nos movendo na direção definida pelo GosTeh. Para logística padronizada, APIs certificadas, monitoramento, requisitos da FSTEC e integridade da cadeia de suprimentos. Mas como incorporar padrões em uma arquitetura construída com pressa e decisões impulsivas? Como garantir segurança se as equipes DevOps não estiverem envolvidas no design?
Essa empresa ainda considera a infraestrutura como um assunto secundário. Isso não é um fracasso de engenharia. É um fracasso de gestão de expectativas.
Como mudar essa situação?
A solução está na mudança de perspectiva:
- De “Vamos construir isso agora para vender” → “Estamos prontos para possuir isso no curto prazo?”
- De velocidade de entrega de funcionalidades → para resiliência da plataforma
- De DevOps como equipe de emergência → para DevOps como co-arquitetoGrandes empresas já fizeram esse caminho. Elas publicam seus roadmaps. Elas adiam lançamentos em prol da estabilidade. Elas medem a operacionalidade, e não apenas as datas de lançamento.
Elas compreendem a simples verdade: velocidade sem controle não é flexibilidade. É deriva. E isso é especialmente inaceitável em software corporativo, onde estão em jogo segredos de Estado.
Para sair da crise, é necessário um transição
- Do gerenciamento reativo para planejamento proativo – desenvolvimento de roadmap DevOps, envolvimento de todas as partes interessadas nas fases iniciais.
- Dos executantes para parceiros estratégicos – reconhecimento do DevOps como parte indispensável do desenvolvimento de produtos.
- Da implementação caótica para transformação planejada – implantação gradual de tecnologias com pilotos e identificação iterativa de lacunas.
- E então, o botão “Comprar” deixará de ser clicado automaticamente
Porque, nos cenários atuais, especialmente sob condições do Gostech, ignorar a maturidade operacional não é apenas um risco, mas um erro estratégico.