Alta disponibilidad y recuperación de desastres Software AntiPatterns

Question

Si tuviera que auditar una aplicación Java para las peores prácticas en lo que respecta a la alta disponibilidad y la recuperación de desastres, probablemente buscaría las direcciones IP codificadas y el almacenamiento en caché subóptimo de los manejadores de enlace. ¿Qué más se debe considerar?

Answer 1

Falta de acción / registro de estado.

Una aplicación Java debería poder reanudarse donde estaba cuando se bloqueó.
Eso significa que debería haber un mecanismo capaz de registrar lo que ya ha hecho (para no volver a hacer todo en la próxima ejecución).

Eso también significa que un programa Java de este tipo siempre debe alcanzar el mismo estado después del conjunto de acciones same . (Hacer algo dos veces daría como resultado el mismo resultado, y las acciones ya realizadas no deberían hacerse nuevamente, sino simplemente omitirse)

Ese registro puede tomar muchas formas (archivo, base de datos, metadatos en un repositorio de clasificación, ...), pero el punto es: una aplicación Java que desea recuperarse lo más rápido posible debe saber lo que ya ha hecho.

Answer 2

Falta de instalaciones de monitoreo. Tarde o temprano, todas las aplicaciones fallarán. Cuando eso suceda, querrá saberlo antes que nadie más.

Answer 3

Falta de registro. Si no puede encontrar lo que mató a su aplicación, es realmente difícil solucionarlo. Esto es particularmente desagradable cuando tiene fallas muy intermitentes que tienen casos difíciles de reprobar.

Answer 4

Dado que ya se mencionó el monitoreo adecuado, agregaría tener un plan de contingencia establecido. Puede ser algo tan simple como: si esto sucede, entonces lo hacemos, si esto sucede, entonces lo hacemos. Luego, cuando surgen problemas, solo tienes que seguir el plan (previamente probado) en lugar de tener a todos en pánico y tomar decisiones rápidas.

Answer 5

Como lo veo, hay un par de aspectos clave de lo que estás preguntando. No creo que sea específico del idioma, y ??usaste una aplicación de Java como ejemplo, así que espero que no te importe que no hable específicamente sobre Java.

Conmutación por error / HA : Aquí es donde identifica su SPoF: puntos únicos de falla. Los ejemplos incluyen direcciones codificadas como mencionó, pero también aplicaciones que almacenan datos en medios no replicables, como un disco local. Otros elementos pueden estar almacenando en caché las búsquedas de DNS durante "demasiado tiempo", no restableciendo conexiones cortadas, buscando información de hardware específica (como direcciones MAC, CPUID, dongles, etiquetas de partición, MB o números de serie de unidades, etc.). He visto todo esto como problemas que conducen a soluciones innecesarias para que BCP / DR funcione.

Integridad de datos : ¿Cómo se almacenan los datos? ¿Utiliza un formato / estructura personalizado? Si es así, ¿hay un " volcado y restauración " ¿mecanismo? ¿El servicio necesita dejar de atender a los clientes, o lo degrada para hacer copias de seguridad? ¿Escribe datos en un dispositivo de forma asincrónica y, de ser así, con qué frecuencia se enjuaga? a disco (a veces esto depende de la aplicación, otros no tanto)? El bloqueo de archivos, los plazos y las capacidades de almacenamiento de memoria a persistentes también son parte de esto.

Esencialmente, mire lo que causaría que tuviera que trabajar alrededor. Luego, observe cómo surgió y probablemente comenzará a desarrollar dos partes importantes de conocimiento: los patrones que se utilizarán para mejorar BCP / DR y, como mencionó, los antipatrones que causan problemas. Inyectar este tipo de preguntas en el proceso de desarrollo, tan pronto como sea posible, ayudará a sus desarrolladores a derivar los patrones y anti-patrones que está buscando. A menudo, solo hacer las preguntas evita los problemas.

Answer 6

Lo mejor que puede hacer es programar un tiempo de inactividad y probarlo. Encontrarás muchos más problemas haciendo esto. Una vez que tenga todo documentado, haga que alguien más lo haga sin su ayuda. ;)