Quando discutimos resiliência em arquitetura de software, normalmente pensamos em disponibilidade, redundância, tolerância a falhas e recuperação de serviços. Investimos em infraestrutura distribuída, automação, observabilidade e mecanismos que permitem manter o funcionamento dos sistemas mesmo diante da indisponibilidade de componentes críticos.
Entretanto, existe uma dimensão da resiliência que nem sempre recebe a mesma atenção: a capacidade das equipes de compreender, operar e evoluir os sistemas pelos quais são responsáveis.
Uma aplicação pode possuir mecanismos sofisticados de recuperação e, ainda assim, depender de um único profissional para investigar determinados incidentes, executar procedimentos operacionais ou modificar regras de negócio críticas. Nesses casos, a infraestrutura pode estar preparada para falhas, mas a continuidade das atividades de engenharia permanece condicionada à disponibilidade de conhecimento específico.
Essa dependência não representa necessariamente um problema de competência ou de organização individual. Sistemas complexos naturalmente produzem especialização, e profissionais experientes acumulam conhecimento que seria inviável distribuir integralmente entre todos os membros de uma equipe.
O risco aparece quando esse conhecimento se torna indispensável para atividades recorrentes ou críticas, sem que existam mecanismos capazes de preservar a continuidade durante a ausência de seus principais detentores.
A resiliência de um sistema também depende da capacidade da organização de operá-lo e modificá-lo sem depender permanentemente das mesmas pessoas.
Quando a especialização se transforma em dependência crítica
Considere uma plataforma financeira com um serviço de conciliação responsável por identificar divergências entre transações internas e registros de parceiros externos. O serviço possui processamento assíncrono, filas persistentes, mecanismos de retry e monitoramento adequado para detectar inconsistências.
Do ponto de vista técnico, a arquitetura contempla diversos cenários de falha. Entretanto, parte das regras de conciliação foi desenvolvida ao longo de vários anos por um engenheiro que conhece profundamente as particularidades dos parceiros, as exceções históricas e os procedimentos necessários para corrigir determinadas divergências.
Quando um processamento apresenta comportamento inesperado, a equipe consegue identificar o incidente por meio da observabilidade, mas encontra dificuldades para determinar a ação correta. Reprocessar o lote pode gerar duplicidades, enquanto realizar uma compensação inadequada pode introduzir inconsistências financeiras.
O problema não está necessariamente na ausência de documentação técnica. O código pode estar bem estruturado e o procedimento de execução pode estar descrito. A dificuldade está em compreender as condições que tornam determinada operação segura e as decisões de negócio que fundamentam esse comportamento.
Esse exemplo ilustra uma distinção importante entre conhecimento sobre implementação e conhecimento sobre comportamento.
Compreender como um componente funciona não significa necessariamente compreender todas as razões pelas quais ele funciona daquela maneira. Parte dessas razões está associada a decisões arquiteturais, regras contratuais, incidentes anteriores e restrições que nem sempre permanecem evidentes no código.
Quando essas informações ficam concentradas, a organização pode desenvolver uma dependência difícil de perceber nos indicadores tradicionais de engenharia. O serviço está disponível, os testes passam e os deploys continuam acontecendo, mas determinadas mudanças permanecem condicionadas à participação de um profissional específico.
Bus Factor e a distribuição do conhecimento
O conceito de Bus Factor é frequentemente utilizado na engenharia de software para representar o número mínimo de pessoas cuja indisponibilidade comprometeria significativamente a continuidade de um projeto.
Embora seja uma métrica informal e imperfeita, ela ajuda a compreender um aspecto importante da resiliência organizacional: a distribuição do conhecimento necessário para manter o trabalho em andamento.
Um estudo apresentado na ICSE 2022, Bus Factor in Practice, investigou essa questão por meio de uma pesquisa com 269 profissionais e da análise de projetos desenvolvidos na JetBrains. Um dos resultados relevantes é que a distribuição de conhecimento não pode ser compreendida apenas pelo histórico de contribuições ao código. Revisões, reuniões e outras formas de colaboração também participam da construção e disseminação do conhecimento técnico.
Essa distinção é importante porque uma equipe pode possuir vários desenvolvedores contribuindo para o mesmo repositório e, ainda assim, concentrar decisões relevantes em uma única pessoa.
Também devemos evitar interpretar o Bus Factor como uma exigência de conhecimento uniforme. Uma equipe não precisa transformar todos os profissionais em especialistas de todos os componentes. Isso aumentaria a carga cognitiva e poderia reduzir a profundidade técnica necessária em determinados domínios.
O objetivo é estabelecer níveis adequados de redundância para as capacidades que realmente exigem continuidade.
Uma equipe pode manter um especialista principal em determinado subsistema, desde que outras pessoas possuam condições de realizar diagnósticos iniciais, executar procedimentos seguros e implementar alterações de menor complexidade. Decisões excepcionais podem continuar exigindo conhecimento especializado, desde que a organização reconheça essa dependência e tenha alternativas proporcionais ao risco envolvido.
Portanto, o problema não é a concentração de expertise em si, mas a concentração de capacidades essenciais sem mecanismos adequados de continuidade.
Como identificar dependências de conhecimento
Essas dependências nem sempre aparecem em organogramas, matrizes de responsabilidade ou diagramas de arquitetura. Frequentemente, tornam-se visíveis apenas quando determinada pessoa está ausente ou quando uma mudança precisa atravessar um componente pouco conhecido pela equipe.
Um caminho mais útil do que tentar mapear todo o conhecimento organizacional é começar pelas capacidades críticas do sistema.
Considere as atividades necessárias para manter uma aplicação funcionando: resposta a incidentes, recuperação de dados, deploy e rollback, evolução de contratos, alterações em regras financeiras e diagnóstico de integrações externas. Para cada capacidade, a equipe pode avaliar quem consegue executá-la com segurança e quais informações são necessárias.
Uma avaliação inicial pode ser organizada da seguinte forma:
| Capacidade | Dependência identificada | Medida de continuidade |
|---|---|---|
| Recuperação de processamento financeiro | Apenas um especialista conhece as condições de reprocessamento | Runbook validado e treinamento supervisionado |
| Deploy e rollback de serviço legado | Execução depende de comandos conhecidos por uma pessoa | Automação e execução por outro responsável |
| Evolução de regras de elegibilidade | Decisões históricas não estão registradas | Documentação de invariantes e decisões arquiteturais |
| Diagnóstico de integração externa | Conhecimento concentrado no autor da integração | Investigação colaborativa e compartilhamento de ownership |
Essa avaliação não precisa se transformar em um processo formal extenso. Seu valor está em identificar quais ausências podem comprometer uma operação importante e quais medidas oferecem a melhor relação entre esforço e redução de risco.
A partir daí, a organização consegue tratar essas dependências com a mesma racionalidade utilizada na priorização de melhorias técnicas: considerando criticidade, probabilidade de ocorrência, impacto e custo de mitigação.
Distribuir conhecimento exige mais do que documentação
Uma resposta comum à concentração de conhecimento é solicitar que os especialistas documentem seus sistemas. Embora necessária, essa medida raramente é suficiente.
Documentação consegue preservar contratos, decisões, procedimentos e restrições importantes, mas não reproduz automaticamente a experiência necessária para interpretar situações inesperadas. Um runbook pode descrever como reprocessar uma mensagem, mas sua utilidade depende de explicar também quando a operação é apropriada, quais efeitos colaterais precisam ser considerados e como validar o resultado.
Por isso, a qualidade da documentação deve ser observada a partir de sua utilização, não apenas de sua existência.
Uma prática simples é solicitar que alguém menos familiarizado com determinado processo execute um procedimento em ambiente controlado, utilizando apenas as orientações disponíveis. As dúvidas e dificuldades encontradas revelam quais conhecimentos permanecem implícitos.
A mesma lógica se aplica às decisões arquiteturais. Registros de decisão, conhecidos como Architecture Decision Records (ADRs), ajudam a preservar o contexto de escolhas importantes, incluindo alternativas consideradas, restrições e consequências. Seu valor não está apenas em informar qual decisão foi tomada, mas em permitir que outras pessoas compreendam por que ela fazia sentido naquele contexto.
Entretanto, a distribuição de conhecimento também depende de experiência prática.
Pair programming, revisões colaborativas e execução acompanhada de atividades críticas permitem compartilhar raciocínio, critérios de decisão e estratégias de diagnóstico. Uma abordagem particularmente útil é fazer com que o profissional menos experiente conduza uma alteração, enquanto o especialista acompanha e orienta quando necessário.
Esse formato evita que a colaboração se limite à observação passiva. O conhecimento começa a ser exercitado por quem precisará utilizá-lo futuramente.
O Google SRE descreve práticas semelhantes na preparação de profissionais para atuar em operações críticas, incluindo acompanhamento de plantões, exercícios de diagnóstico e simulações de incidentes. A proposta é desenvolver capacidade operacional antes que a pessoa precise utilizá-la em uma situação real de alta pressão.
O princípio é aplicável a equipes de engenharia em geral: conhecimento crítico precisa ser compartilhado por meio de documentação, colaboração e experiências progressivas de responsabilidade.
A arquitetura também pode reduzir dependências humanas
Nem toda dependência de conhecimento precisa ser resolvida por treinamento.
Em alguns casos, a própria arquitetura ou o processo operacional exige conhecimento especializado desnecessariamente. Um deploy depende de uma sequência manual de comandos; uma integração exige alterar configurações pouco documentadas; uma regra de negócio está distribuída entre componentes que não possuem responsabilidades bem delimitadas.
Nessas situações, compartilhar conhecimento ajuda, mas pode não resolver a causa estrutural da dependência.
Automatizar procedimentos, melhorar contratos, explicitar invariantes e reduzir acoplamento entre componentes são formas de diminuir a quantidade de conhecimento necessária para executar determinadas atividades com segurança.
Considere novamente o serviço de conciliação financeira. Se a recuperação de um lote exige que alguém analise manualmente diversas condições antes de decidir pelo reprocessamento, parte dessas verificações pode ser incorporada ao próprio sistema.
O serviço poderia identificar operações já processadas, verificar condições de idempotência, impedir reprocessamentos inseguros e apresentar informações suficientes para orientar a decisão operacional.
Isso não elimina todos os cenários excepcionais, mas reduz a dependência de conhecimento individual nas situações recorrentes.
Esse exemplo revela uma relação importante entre arquitetura técnica e resiliência organizacional. Quanto mais decisões operacionais relevantes estiverem representadas por contratos, invariantes e mecanismos verificáveis, menor será a necessidade de recorrer continuamente ao conhecimento implícito de especialistas.
A distribuição de conhecimento continua necessária, mas a arquitetura passa a reduzir parte do esforço exigido para manter a autonomia da equipe.
O papel da liderança na continuidade técnica
A concentração de conhecimento também está relacionada à forma como o trabalho é distribuído e valorizado.
É natural que profissionais experientes sejam acionados para resolver problemas complexos. Eles conhecem o histórico dos sistemas, conseguem identificar riscos rapidamente e frequentemente possuem maior capacidade de tomar decisões sob incerteza.
Entretanto, quando todas as atividades relevantes continuam sendo direcionadas às mesmas pessoas, a organização reforça a dependência que deveria reduzir.
Esse comportamento pode ocorrer mesmo em equipes que valorizam colaboração. Diante de prazos curtos, atribuir uma tarefa ao profissional que já domina o assunto costuma parecer a decisão mais eficiente. No curto prazo, frequentemente é. No longo prazo, porém, a equipe deixa de desenvolver alternativas e passa a depender ainda mais daquele especialista.
A liderança precisa equilibrar eficiência imediata e desenvolvimento de capacidade coletiva.
Isso exige reservar oportunidades para que outras pessoas assumam responsabilidades progressivamente, mesmo quando a execução inicial demande mais acompanhamento. Também exige reconhecer que orientar profissionais, melhorar ferramentas e documentar decisões são contribuições relevantes de engenharia, e não atividades secundárias que só devem acontecer quando o roadmap permite.
Um engenheiro sênior gera valor não apenas pela capacidade de resolver problemas complexos, mas também por sua contribuição para tornar a equipe mais preparada para enfrentá-los.
Ao mesmo tempo, distribuir conhecimento não deve significar sobrecarregar os especialistas com responsabilidades adicionais de treinamento sem ajustar prioridades. A construção dessa autonomia precisa fazer parte do planejamento normal do trabalho.
Resiliência organizacional precisa ser verificada
Na infraestrutura, não consideramos suficiente declarar que um serviço possui redundância. Testes de recuperação, simulações de falhas e exercícios operacionais ajudam a verificar se os mecanismos funcionam nas condições esperadas.
A continuidade das equipes também pode ser avaliada dessa maneira, respeitando as diferenças entre sistemas técnicos e organizações humanas.
Uma ausência planejada, por exemplo, oferece uma oportunidade para observar se operações essenciais conseguem continuar sem a intervenção do profissional que normalmente as conduz. O objetivo não é criar dificuldades artificiais nem exigir que todas as decisões sejam tomadas imediatamente. Trata-se de identificar quais atividades realmente precisam de continuidade e quais ainda dependem de conhecimento não compartilhado.
Se uma operação não puder ser realizada, a equipe pode investigar se o problema está na documentação, nas permissões, na ausência de treinamento ou no próprio desenho do procedimento. Cada causa exige uma resposta diferente.
A avaliação também deve considerar a capacidade de evolução, não apenas de operação. Uma equipe que consegue responder a incidentes, mas não consegue modificar uma regra importante sem consultar seu criador, ainda possui uma dependência relevante.
Ao longo do tempo, o resultado das iniciativas de compartilhamento de conhecimento deve aparecer em comportamentos concretos: mais pessoas conseguem executar operações críticas, alterações comuns deixam de depender exclusivamente de especialistas e decisões anteriores podem ser compreendidas sem reconstruir todo o seu contexto.
Essas evidências são mais úteis do que simplesmente contar documentos produzidos ou sessões de treinamento realizadas.
Resiliência é uma responsabilidade técnica e organizacional
A engenharia de software desenvolveu um repertório amplo para lidar com falhas: redundância, isolamento, recuperação, automação e redução de dependências críticas. Esses princípios continuam fundamentais para construir sistemas confiáveis.
Mas a capacidade de manter esses sistemas funcionando e evoluindo depende também da organização que os desenvolve.
Conhecimento especializado continuará existindo, e isso é desejável. O desafio é impedir que capacidades essenciais permaneçam condicionadas à disponibilidade permanente de indivíduos específicos.
Distribuir experiências, preservar decisões, automatizar procedimentos e desenvolver responsabilidades compartilhadas são investimentos que reduzem esse risco. Também melhoram a capacidade de manutenção, facilitam a entrada de novos profissionais e tornam as equipes mais autônomas diante de mudanças.
O objetivo não é eliminar a importância dos especialistas, mas ampliar o alcance de seu conhecimento e reduzir dependências que poderiam ser evitadas.
Uma engenharia resiliente não é aquela em que todas as pessoas sabem tudo. É aquela em que o conhecimento necessário para manter e evoluir sistemas críticos não depende exclusivamente de quem o adquiriu primeiro.
Referências
- Bus Factor in Practice — ICSE 2022 / JetBrains Research. Estudo sobre distribuição de conhecimento e dependências de pessoas em projetos de software.
- Accelerating SREs to On-Call and Beyond — Google SRE. Formação operacional, transferência de conhecimento e exercícios práticos para equipes.
- Architecture Decision Record — Martin Fowler. Registro de decisões arquiteturais, contexto e consequências para facilitar a compreensão futura.
- Being On-Call — Google SRE. Práticas para manter a operação de sistemas complexos de maneira sustentável.
