Lo primero que se debe hacer ante una condición anómala es tomar el pulso a todo el sistema en general y valorar qué parte del sistema sigue siendo operativa y qué parte ha quedado "fuera de servicio" debido a cualquier estímulo externo que haya provocado esta condición.
Determine si el sistema sigue siendo operativo. Con frecuencia el sistema sigue siendo operativo, pero a causa de la sobrecarga o del ajuste inapropiado o por ambos motivos, no puede completar las tareas rápidamente y/o intenta realizar tareas que en realidad contienen errores.
La prueba de cada una de estas preguntas será específica de la naturaleza de la solución desplegada.
Si existe una gran cantidad de reintento automatizado y diferentes lógicas de soporte, la propia aplicación puede generar errores al manifestar el operador TI.
El equipo de recuperación debe conocer y documentar estas condiciones para futuras referencias.
¿Ve el ID de proceso u obtiene una respuesta positiva del gestor de despliegue a través de la consola administrativa?
¿Puede realizar alguna operación sencilla de SELECT, en datos no bloqueados en una cantidad razonable de tiempo?
Si la base de datos no funciona correctamente, la recuperación de ésta (para poder, como mínimo, liberar los bloqueos y efectuar selecciones sencillas) es vital para la recuperación del sistema.
Si el sistema de mensajería no funciona correctamente, la recuperación del subsistema de mensajería para poder, como mínimo, visualizarlo y gestionarlo, es vital para la recuperación del sistema.
A partir de estos procedimientos básicos y de estas actividades de comprobación, ahora debemos empezar a buscar situaciones específicas. Se describirán los patrones y se proporcionarán detalles y perspectivas sobre lo que sucede.
Tenga en cuenta que este análisis de la situación es una actividad de sólo lectura. Aunque proporciona información vital a partir de la cual se determinan las acciones de recuperación apropiadas, no debe cambiar el estado del sistema que se revisa. Es imposible predecir y proporcionar acciones prescriptivas para todas las causas posibles de una parada del sistema. Por ejemplo, considere el árbol de decisión siguiente:
Pueden investigarse muchas categorías en caso de que se produzca una parada no planificada. Estas categorías tendrán subcategorías, etc. La definición de acciones prescriptivas para cada nodo y el nodo posterior dependerá de los resultados de cada investigación. Como este tipo de relación es difícil de trasladar en forma de documento, se recomienda la utilización de una herramienta de soporte como IBM® Guided Activity Assist que le orientará de forma interactiva a través del proceso de investigación y de toma de decisiones. A medida que se progresa desde la parte superior hasta cada nodo hijo, es importante realizar el nivel apropiado de análisis de la situación.