Alta disponibilidade e recuperação de desastres Software antipadrões

Question

Se você teve para auditar um aplicativo Java para piores práticas quando se trata de alta disponibilidade e recuperação de desastres, você provavelmente procurar endereços IP codificadas e caching suboptimal de alças de vinculação. O que mais deve ser considerado?

Answer 1

Falta de registro de ação / estado.

Um aplicativo Java deve ser capaz de retomar onde estava quando caiu.
Isso significa que deve haver um mecanismo capaz de gravar o que já fez (a fim de não fazer tudo de novo na próxima execução).

Isso significa também um programa Java deve sempre alcançar o mesmo estado após o mesma conjunto de ações. (Fazer algo duas vezes resultaria no mesmo resultado, e as ações já realizadas não deve ser feito novamente, mas simplesmente ignorados)

Esse registro pode levar muitos formulário (arquivo, banco de dados, metadados em um repositório de tipo, ...), mas o ponto é: um aplicativo Java disposto a recuperar o mais rápido possível deve saber o que ele já fez <. / p>

Answer 2

A falta de instalações de monitoramento. Mais cedo ou mais tarde, todas as aplicações irá falhar. Quando isso acontece, você vai querer saber sobre ele antes de mais ninguém faz.

Answer 3

Falta de registro. Se você não consegue encontrar o que matou a sua aplicação, é realmente difícil para corrigi-lo. Isto é particularmente desagradável quando você tem falhas muito intermitentes que têm casos de difícil repro.

Answer 4

Desde acompanhamento adequado já é mencionado, gostaria de acrescentar que tem um plano de contingência no lugar. Pode ser algo tão simples como: se isso acontecer, então fazemos isso, se essa outra coisa acontece, então fazemos isso. Em seguida, quando ocorrem problemas basta seguir o plano (previamente testado) em vez de ter todos pânico e tomar decisões rápidas.

Answer 5

A meu ver, existem aspectos fundamentais par ao que você está perguntando. Eu não acho que ele é específico da linguagem, e você usou um aplicativo java como um exemplo, então eu espero que você não se importa que eu não falando especificamente sobre Java.

Failover / HA : Isto é onde você identificar o seu SPOF - Pontos únicos de falha. Os exemplos incluem endereços hardcoded como você mencionou, mas também aplicações que armazenam dados em meios não-replicáveis, como um disco local. Outros itens podem ser cache pesquisas de DNS para "demasiado longo", não re-estabelecer conexões cortadas, à procura de informações sobre o hardware específico (como endereços MAC, CPUIDs, dongles, rótulos de partição, MB ou unidade números de série, etc.). Eu vi tudo isso como problemas que levam a soluções desnecessárias para obter BCP / DR funcional.

Integridade dos Dados : Como são os dados armazenados? Ele usa um formato personalizado / estrutura? Se assim há uma "dump e restaurar" mecanismo? Será que a necessidade de serviço para parar de atender aos clientes, ou ele degradá-la de serviço para fazer backups? Será que gravar dados em um dispositivo de forma assíncrona e se assim como muitas vezes é "lavada" para o disco (às vezes isso é até o aplicativo, outras nem tanto)? bloqueio de arquivos, memória-a-persistente prazos de armazenamento e capacidades também fazem parte desta.

Essencialmente olhar para o que faria com que você tem que trabalhar em torno. Então olha para como isso aconteceu abut e você provavelmente vai começar a desenvolver duas partes importantes do conhecimento: Padrões de usar para melhorar BCP / DR, e como você mencionou, antipadrões que causam problemas. Injetar esses tipos de perguntas no processo de desenvolvimento, tão cedo quanto for possível irá ajudar seus desenvolvedores derivar os padrões e anti-padrões que você está procurando. Muitas vezes, apenas fazer as perguntas evita os problemas.

Answer 6

A melhor coisa a fazer é agendar algum tempo para baixo e testá-lo. Você vai encontrar muitos mais problemas ao fazer isso. Depois de ter tudo documentado, peça a alguém para fazê-lo sem a sua ajuda. ;)