É incômodo quando o sistema “funciona”, mas, sempre que olho com mais atenção, percebo um desconforto no ar. Não é fácil de explicar para outros times, muito menos para quem está fora do dia a dia técnico. É só um cheiro. Algo familiar para quem já teve que acudir produção de madrugada, sem nunca aparecer na newsletter da empresa.
Com meus anos de experiência, já notei: muitos ignoram esses sinais. Preferem pensar que é só uma fase, que “quando der tempo” vão resolver. E quando o alerta finalmente acende, o foco quase sempre vai para o ponto errado.
A dependência oculta dos “heróis” é o tipo de problema que só vira crise quando a sorte acaba.
Quando algo funciona, mas incomoda?
Passei por cenários onde o sistema entregava valor. As métricas estavam verdes, a disponibilidade parecia alta. Mas era tudo frágil. Bastava um nome específico estar de férias para o medo se espalhar. Quem já viveu isso sabe: a arquitetura falha silenciosamente muito antes da primeira pane.
Ninguém quer admitir, mas times acostumam-se a ignorar sinais de dependência. O time acha que o problema é “automatizar mais”, documentar ou criar alertas. Só que tudo volta para o mesmo ciclo: resolver rápido, tratar sintomas, torcer para passar a tempestade sem perda real.
A análise equivocada da equipe
Minha experiência mostra que a interpretação comum é sempre superficial.
- A equipe vê incômodos como “falta de documentação”.
- Pensa que testando mais, tudo vai passar a ser previsível.
- Discute se falta monitoramento.
Essas são abordagens legítimas, mas tratam só a camada visível do problema.
O problema real (e invisível no início)
O que realmente faz sistemas dependerem de heróis invisíveis? Eu diria que são três raízes:
- Falhas de contrato e clareza
- Suposições implícitas
- Ausência de critérios testáveis
Quando envolve sistemas distribuídos, tudo piora. O que era um detalhe vira efeito dominó. Cada micro decisão acumulada ao longo do tempo vai pedindo resgate urgente de um especialista.
Falhas de contrato: o primeiro sinal
Já observei que os contratos mal definidos, seja API, interação entre módulos ou até acordos entre times, contribuem para um ambiente frágil. Muitos falam de “acordos”, mas depois, na produção, cada um interpreta do seu jeito.
Quando contratos não são claros, a confiança recai sempre no herói que entendeu o real funcionamento, não na especificação.
Verifique se há especificações que sobrevivem a troca de profissionais. Se só uma pessoa consegue explicar nuances, já temos um candidato a herói invisível.
Suposições implícitas: veneno sutil
São aquelas verdades não ditas, mas presentes em todo o código. Dificilmente estão documentadas. O sistema roda porque alguém lembra do “detalhe crucial” que, um dia, pode se perder.
Suposições escondidas fluem do time para o sistema – e vice-versa.
Critérios testáveis ausentes
Na minha experiência, times maduros buscam certezas mensuráveis. Onde falta isso, impera o empirismo. Código funciona porque o “fulano testou”. Sistemas ficam no limiar da confiança, sempre dependendo de testes informais ou daquele dev que sabe onde mexer.
Como isso aparece nos ambientes distribuídos?
Nos sistemas distribuídos, esses problemas ganham outra cara. Camadas separadas, times diferentes, ambientes sem coordenação direta. A ausência de critérios claros faz com que cada equipe evolua com base em seus “heróis”.
A dependência nesses cenários é uma preocupação real. No livro Release It!, Michael Nygard cataloga anti-patterns de estabilidade — falhas em cascata, pontos de integração frágeis, reações em cadeia — que transformam sistemas distribuídos em máquinas de gerar intervenção manual. O Google SRE Book reforça isso ao definir toil: trabalho manual, repetitivo e sem valor duradouro que escala linearmente — exatamente o que acontece quando especialistas precisam intervir constantemente para manter o sistema disponível.
Variabilidade e não determinismo
Outro grande problema: o sistema comporta-se bem na maioria das vezes, mas não sempre. A variabilidade, aquela sensação de que nem toda execução é igual, gera ansiedade. Não determinismo se revela quando bugs aparecem só às vezes, e nunca nos testes tradicionais.
Quando um bug só “vem à tona com o cenário certo”, a equipe começa a depender de quem já viu o problema uma vez na vida.
Efeitos colaterais tardios
Já vivi situações onde uma decisão tomada há meses explode como um bug estranho numa madrugada qualquer. Esses efeitos colaterais se manifestam quando horrores inesperados surgem porque ninguém previra o caminho alternativo naquele fluxo.
Um exemplo técnico: quando a dependência fica evidente
Quero compartilhar um trecho simplificado que já vi acontecer. Observe o seguinte código em C#:
public void ProcessaPedido(Pedido pedido)
{
if (pedido.Tipo == "Especial")
{
ServicoX.Trata(pedido);
}
else
{
ServicoY.Processa(pedido);
}
}
Parece simples. Mas só um dev sabe por que “Especial” vai para um serviço diferente. Nem nos testes, nem na documentação, essa decisão aparece. Quando esse nome some do contexto, o sistema vira refém do entendimento individual.
Código curto pode esconder regras críticas só conhecidas por quem o escreveu ou depurou em produção.
Artigos como os da categoria de arquitetura de software que produzo também reforçam essa necessidade de tornar contratos e regras claras, para quebrar o ciclo da dependência.
Armadilhas comuns
Equipe de TI tensa monitorando sistema com alerta vermelho. Armadilhas comuns
Times costumam repetir um padrão: copiar práticas que funcionaram no passado e aplicar cegamente. Isso inclui desde controles de exceção até monitoramentos feitos só para mostrar métricas para a diretoria. Em The Phoenix Project, Gene Kim ilustra exatamente esse ciclo com o personagem Brent — o herói que centraliza tanto conhecimento que se torna um single point of failure organizacional. A pesquisa do Accelerate (Forsgren, Humble & Kim) confirma com dados: times de alta performance distribuem conhecimento e eliminam dependências de indivíduos, enquanto times de baixa performance perpetuam a cultura de heróis.
Por que funciona até não funcionar?
É uma ilusão confortável. O sistema entrega valor, e toda vez que ameaça parar, há alguém pronto para corrigir. Mas, quando o acúmulo de decisões não revisitadas atinge o limite, a crise é inevitável.
O que times repetem sem perceber?
Na minha experiência, times caem nas mesmas armadilhas:
- Evitar revisitar decisões antigas porque “dá trabalho mexer no que está funcionando”.
- Confiar na memória ou intuição dos mais antigos no sistema.
- Ignorar sinais invisíveis até que o primeiro incidente grave aconteça.
Se você quer ir mais fundo nesse tema de diagnóstico e arquitetura, recomendo ver também o que já escrevi sobre evitar gargalos ligados a arquitetura e contexto e práticas para desacoplar microsserviços.
Conclusão
Não há checklist definitivo, nem solução mágica. Na verdade, sistemas que dependem de heróis invisíveis não são apenas frágeis, carregam dívida estrutural que cresce silenciosamente. O projeto Felipe Marciano existe justamente para ajudar líderes e engenheiros experientes a enxergar o que está sob a superfície, muito antes que vire uma crise.
Seu sistema “funciona”? Ou só não falhou… ainda?
Se você sente que está sempre caminhando sobre ovos, procure entender as raízes desse desconforto. Reduzir a dependência dos invisíveis é caminho de longo prazo, mas já começa quando você decide questionar o modelo atual.
Para quem encara a modernização e o diagnóstico de sistemas de verdade, vale também conferir o artigo sobre como migrar sistemas legados para a nuvem sem dores.
Continue me acompanhando e conecte-se comigo para discussões mais profundas e estratégias que ajudam a transformar tecnologia em valor real:
- LinkedIn: https://www.linkedin.com/in/felipe-santos-marciano/
- Instagram: https://www.instagram.com/felipemarcianodev/
- YouTube: https://www.youtube.com/@felipemarcianodev
- Facebook: https://www.facebook.com/felipesantos.marciano/
- TikTok: https://www.tiktok.com/@felipemarciano
Perguntas frequentes
O que são heróis invisíveis na empresa?
Heróis invisíveis são profissionais cuja atuação é fundamental para manter o sistema funcionando no dia a dia, mas cujo trabalho não fica evidente nos processos formais ou nas métricas. São aqueles que "apagam incêndios" silenciosamente, resolvem problemas não documentados e sustentam pontos críticos do sistema sem que a maioria perceba.
Como identificar dependência de heróis invisíveis?
A dependência aparece quando apenas algumas pessoas conhecem detalhes essenciais do funcionamento do sistema. Sintomas comuns são dúvidas recorrentes que só um responde, código com regras não escritas e decisões críticas baseadas em memória ou feeling, não em processo ou documentação clara.
Quais riscos existe ao depender de heróis?
Os principais riscos são a fragilidade operacional, aumento do tempo de resposta diante de incidentes, dificuldade de evolução do sistema e sobrecarga dessas pessoas. Se elas saem ou entram de férias, o risco de parada é alto.
Como evitar a dependência de heróis invisíveis?
É fundamental documentar decisões importantes, tornar critérios testáveis explícitos e revisar contratos frequentemente. Investir em processos robustos de arquitetura e operações, como sugiro nos conteúdos do projeto Felipe Marciano, diminui essa dependência e fortalece o sistema para o longo prazo.
Por que sistemas dependem de heróis invisíveis?
Sistemas passam a depender de heróis invisíveis normalmente por causa de decisões acumuladas sem revisão, contratos mal definidos e falta de clareza sobre como cada parte realmente funciona. Em ambientes distribuídos, onde o conhecimento se fragmenta, essa dependência só cresce.
Referências
Livros
- Gene Kim, Kevin Behr & George Spafford — The Phoenix Project — O personagem "Brent" como arquétipo do herói invisível e single point of failure organizacional.
- Nicole Forsgren, Jez Humble & Gene Kim — Accelerate — Pesquisa baseada em dados (DORA metrics) mostrando que times de alta performance distribuem conhecimento e eliminam dependências individuais.
- Michael Nygard — Release It! Second Edition — Stability anti-patterns e patterns (Circuit Breaker, Bulkhead, Timeouts) que substituem intervenção heroica por resiliência sistêmica.
- Sam Newman — Building Microservices, 2nd Edition — Information hiding, tipos de acoplamento e como fronteiras de serviço mal definidas criam dependências ocultas.
- Sam Newman — Monolith to Microservices — Padrões de migração: Strangler Fig, Branch by Abstraction, decomposição incremental.
- Eric Evans — Domain-Driven Design (2003) — Cap. 9: "Making Implicit Concepts Explicit" — como suposições não ditas no modelo de domínio se tornam fontes de acoplamento oculto. DDD Reference (PDF gratuito)
- Robert C. Martin (Uncle Bob) — Clean Architecture (2017) — SOLID, Dependency Inversion e como organizar dependências para evitar decay arquitetural.
Artigos e Referências Online
- Martin Fowler — Technical Debt — A metáfora original de Ward Cunningham e o custo do acúmulo de decisões não revisitadas.
- Martin Fowler — Technical Debt Quadrant — Taxonomia 2x2: deliberada vs. inadvertida, prudente vs. imprudente.
- Martin Fowler — Eradicating Non-Determinism in Tests — "Non-deterministic tests are a virulent infection that can completely ruin your entire test suite."
- Martin Fowler — Strangler Fig Application — Padrão para migração incremental de sistemas legados.
- Martin Fowler — Microservices — Artigo fundacional (com James Lewis) sobre arquitetura de microsserviços.
- Martin Fowler — How to Break a Monolith into Microservices — Guia prático de decomposição usando bounded contexts.
- Martin Fowler — Bounded Context — Padrão central de DDD para fronteiras explícitas entre domínios.
- Ian Robinson — Consumer-Driven Contracts — Contratos explícitos entre serviços para evolução independente.
- Uncle Bob — The Clean Architecture — Dependency Rule: dependências de código-fonte só podem apontar para dentro.
- Chris Richardson — Microservices Pattern Language — Catálogo completo de padrões para decomposição, comunicação e dados.
- Google — SRE Book: Eliminating Toil — Definição de toil e como engenharia de confiabilidade substitui heroísmo por sistema.
