Ao solucionar um problema complexo, há uma razão para usar uma metodologia de solução de problemas de aditivo versus subtrativa

Question

TLDR: Estou interessado em descobrir se há um motivo para selecionar uma abordagem aditiva para solucionar problemas de uma abordagem subtrativa, ou vice-versa, ao tentar solucionar um problema com muitas variáveis. / p>

Visão geral do problema:

Estou trabalhando com um grupo de pessoas que tenta solucionar um problema de impacto intermitente, mas de alto impacto, em um sistema de teste que está nos impedindo de entrar em operação com essa nova configuração.

Temos um servidor de aplicativos Citrix XenApp em execução em uma infraestrutura virtualizada que atende aplicativos a clientes em execução em sites remotos em uma WAN. Existem vários dispositivos de criptografia / segurança / firewall no topo da rede entre a WAN e os servidores físicos que hospedam os servidores virtualizados.

Então, basicamente, temos um problema com muitas variáveis e estamos tentando resolvê-lo. Até agora, começamos com uma abordagem subtrativa - tentar remover uma coisa do sistema de cada vez e tentar descartar uma coisa se o problema desaparecer. Nós não estamos tendo muita sorte com essa abordagem. Eu estava pensando em sugerir uma abordagem aditiva na qual começamos o mínimo de componentes do sistema no qual o aplicativo funcionará e começamos a adicionar coisas em várias combinações.

Com base em sua experiência, há razões para preferir a solução de problemas de aditivas a subtrativas ou vice-versa?

    

Answer 1

Eu realmente prefiro uma abordagem de depuração iterativa: você analisa usando sintomas, arquivos de log, capturas de rede, comparação de melhores práticas e / ou intenção projetada versus o ambiente construído, etc, para tentar encontrar o problema real. Você encontrará, em muitos casos, que não há apenas uma causa de um problema de desempenho relatado. Pode haver mais de um gargalo ou o problema pode estar ocorrendo devido à interação de vários componentes.

Acho que isso funciona melhor do que remover cegamente as coisas ou criar um novo ambiente apenas para solução de problemas. Embora a última abordagem seja excelente para planejar e testar com antecedência: chamaríamos isso de um ambiente "dev", "test" ou "staging", dependendo de como ela se encaixa na arquitetura geral. Isso requer que você realmente planeje e teste IN ADVANCE, no entanto, e nem toda organização tem os recursos para fazer isso corretamente.