Como você aborda erros intermitentes?




Cenário



Você tem vários relatórios de bugs todos mostrando o mesmo problema. Eles são todos enigmático com contos semelhantes de como o problema ocorreu. Você segue os passos, mas não reproduzir de forma confiável o problema. Depois de algumas investigações e buscas web, você suspeitar que pode estar acontecendo e você é certeza que você pode corrigi-lo.


Problema



Infelizmente, sem uma maneira confiável para reproduzir o problema original, você não pode verificar se ele realmente resolve o problema ao invés de ter qualquer efeito ou exacerbando e mascarando o problema real. Você simplesmente não pode corrigi-lo até que se torne reprodutível de cada vez, mas é um grande erro e não corrigi-lo causaria a seus usuários uma série de outros problemas.


Questão



Como é que você vai verificar sua mudança?


Acho que este é um cenário muito familiar para quem projetou software, então eu tenho certeza que há uma infinidade de abordagens e as melhores práticas para lidar com erros como este. No momento, estamos olhando para um desses problemas em nosso projeto onde eu ter passado algum tempo determinar o problema, mas foram incapazes de confirmar as minhas suspeitas. Um colega é tomar banhos de testar a minha correção na esperança de que um dia de execução sem um crash equivale a é fixo. No entanto, eu prefiro uma abordagem mais confiável e eu percebi que há uma riqueza de experiência aqui no SO.
Erros que são difíceis de reproduzir é o único mais difícil de resolver. O que você precisa ter certeza de que você encontrou a raiz do problema, mesmo que o problema não pode ser reproduzido com sucesso.


Os erros intermitentes mais comuns são causados ​​por raça-condições - ao eliminar a raça, ou garantir que um lado ganha sempre de ter eliminado a raiz do problema, mesmo se você não pode confirmá-la com sucesso, testando os resultados. A única coisa que você pode testar é que a causa não precisa se repetir.


fixação, por vezes, o que é visto como a raiz de fato resolve um problema, mas não o caminho certo - não há como evitar isso. A melhor maneira de evitar erros intermitentes é ser cuidadoso e metódico com o projeto do sistema e arquitetura.
<p>o que significa "o tempo todo"? se acontecer uma vez por dia, eu escreveria um pequeno roteiro para testar os serviços para o estado de execução para descobrir se eles param em um horário específico. então tente descobrir o que mais está acontecendo ao mesmo tempo.</p><p>se acontecer a cada poucos minutos, monitoraria os processos com o 'monitor de processo' do sysinternal para descobrir quais arquivos/threads são acessados ​​por último antes de cair.</p> você consegue entrar na área de logs do roteador e procurar por possíveis erros. outra maneira de tentar encontrar um problema é ir mapeando (via mensagens mesmo), quais blocos o usuário entrou, assim você consegue saber em qual ele não saiu e aí tentar encontrar o problema.

deve ser alguma coisa s… olá paulo,  

  

eu preciso ver o problema para saber realmente o que está acontecendo para poder prover uma solução.  

será que poderia enviar um print do problema? quando se trata de jogos o melhor seria passa os jogos pra verifica se alguém já conseguiu faze ele roda no linux ou no caso vocês pode pesquisar mesmo ai já pode aprende a como tira sua dúvida em jogos que queira joga. <p>não consigo replicar os problemas que você está detalhando - isso parece muito estranho para mim (e estou falando sobre o nível de testes em várias máquinas. isso provavelmente pode ser algo específico em sua configuração.</p><p>aqui estão algumas coisas que podem contribuir para um pior desempenho em uma máquina:</p><ul> <li><strong>instalação limpa v várias atualizações</strong>: eu tive um problema semelhante em uma estação de trabalho que tinha sido atualizada ao longo dos anos de 5.10 a 9.04 a área de trabalho reiniciaria aleatoriamente em intervalos ímpares sem aviso - e sem entradas de log. acabei fazendo uma instalação limpa e o problema foi embora. não é o melhor cenário em que o troubleshooting triunfou, mas um exemplo de como configurações mais antigas podem causar problemas estranhos.</li> <li><strong>hardware</strong>: muito menos provável - mas pode ser apenas um problema com o lançamento do firefox e sua configuração (drivers, configuração, etc) pode ser conflitante - o que explicaria porque swiftfox (um derivativo do firefox que visa aumentar desempenho da ferramenta mozilla para linux) também está respondendo mal.</li> </ul><p>eu procuraria por pessoas que exibissem problemas semelhantes com o firefox em configurações semelhantes à sua (você não forneceu nada, então não posso realmente ajudá-lo), mas pode ser um problema de configuração, compilação.</p> <p>cada teste retorna imediatamente após concluir que a validação falha, isso torna a execução mais otimizada já que nem todos os testes são executados caso um deles venha a falhar .</p> <p>bom dia brenda. tudo bem.</p>
<p>perdão a demora para responder, eu vi o problema, reportei para a equipe para eles darem uma olhada no que pode estar ocorrendo. </p>
<p>mas acabei me confundido e achei que tinha lhe respondido, 8( perdão. </p>
<p>mas qualquer feedback que me passem lhe repasso ok. até lá caso isso aconteça, tende dar o curso como concluido manualmente que ele fecha certinho se nao me engano ^^</p>
<p>um abraço</p> bem...nem o arquivo disponibilizado no site do fabricante é 100%, pois pode sofrer um ataque de um cracker e se tornar uma "ameaça"....rs...


agora...primeiro que tudo que vc baixar de terceiros, podem ou nao ser alterados....vai da sua conciência e sorte...não tem como garantir nada..... sites como mega, rapidshare, ou mesmo torrents, etc.... vc não sabe quem disponibilizou ou o interresse de disponibilizar......instalar ou não vai da conciência de cada um.....


segundo que programas crackeados não tem garantia nenhuma.... imagine.... o cara cria um "programa" (crackeador) que ilegalmente lhe permitirá usar o programa sem pagar....se é ilegal...que garantia quem fez o crack pode lhe dar?..... é tão "sinistro" que vc tem que desativar o antivirus para usar o crack...portanto, tb é "sorte"....e se dar qualquer erro o "problema" é todo seu....


então vc pode baixar e usar qualquer programa "ilegal"....mas caso der errado o problema é todo seu....assim como se der certo a sorte é sua.....não tem como ninguém aqui lhe garantia nada....e não adianta passar o antivirus, pois os antivirus detectam o crack como nocivo e remove e vc não poderá usar o programa.... <p>a substituição do controle de um usuário pelo computador sempre será uma interrupção e, muitas vezes, será percebida como uma invasão do fluxo de trabalho desse usuário. o site "não deveria" ter o controle de nossos computadores, portanto, exercer esse controle será pelo menos um pouco alarmante.</p><p>dito isso, você aborda um tópico realmente importante, sendo a importância de informar ao usuário que sua entrada é inválida antes de preencher um conjunto inteiro de campos e enviá-los.</p><p>a abordagem que eu achei menos intrusiva, mas que fornece a resposta mais rápida, é o fluxo abaixo.</p><p><img src="https://i.stack.imgur.com/vxahu.png" alt="alt text"></p><p>essencialmente, espere que eles preencham seu primeiro campo e, à medida que clicam/separam um novo campo (ou um campo que foi invalidado), verifique o campo que acabou de ser concluído. se o campo que acabou de ser preenchido for válido, imprima um ícone "bom" discreto ao lado dele (verde, marca de seleção, sorriso no rosto, você entendeu). se falhar nas regras de validação, imprima discretamente um ícone "ruim" (vermelho, "x" etc.) e uma linha curta sobre o que falhou.</p><p>mas lembre-se, não interrompa o fluxo de trabalho:</p><ul> <li>sem pop-ups</li> <li>sem sobreposições</li> </ul><p>quando terminarem o campo para o qual foram movidos, eles voltarão ao campo inválido ou seguirão em frente e voltarão mais tarde. de qualquer forma, eles verão que têm uma edição para fazer, mas podem fazê-lo em seu próprio tempo.</p><p>no final, eles terão um formulário completamente válido antes de enviá-lo, o que significa</p><ol> <li>eles só terão que enviar uma vez</li> <li>eles não perdem tempo ficando bravos ou frustrados quando a submissão "falha"</li> <li>eles vão gostar mais do seu site</li> <li>todo mundo vai ter bolo</li> </ol> Esta é a minha opinião, mas; assim como as classes de caso do, eu gostaria implementar um `copy`método de tipos na classe para fazer a modificação possível, mantendo a imutabilidade, mas existe alguns casos que eu não posso ajudar a tê-lo mutável; por exemplo, quando se espera algo para tornar a operação de cópia muito grande e lento para a classe; como quando a classe tem tantos membros freqüentemente modificados. E não se preocupe com milhares de casos flutuando na memória, porque eles são automaticamente GC'ed, então o problema mais real é o custo do tempo de copiar as instâncias da classe. Por favor, diga-me se minha opinião é de alguma forma errada :)