ES2716029T3 - Recuperación y escalada automáticas en aplicaciones complejas distribuidas - Google Patents

Abstract

Un procedimiento para ser ejecutado, al menos en parte, en un dispositivo informático para la recuperación automatizada y la escalada de alertas en sistemas distribuidos, comprendiendo el procedimiento : detectar, por un motor de monitorización (103), un problema asociado con al menos uno de entre un dispositivo y una aplicación de software dentro de un sistema distribuido; transmitir, por el motor de monitorización (103), una alerta (113) basada en el problema detectado, a un motor de automatización (102); recibir la alerta asociada con un problema detectado desde el motor de monitorización (103) en el motor de automatización (102); el procedimiento comprende además los siguientes pasos realizados por el motor de automatización (102); recoger información de diagnóstico asociada con el problema detectado; tratar de mapear la alerta a una acción de recuperación, en la que el motor de automatización (102) realiza una búsqueda de caracteres comodín de una base de datos de resolución de problemas para determinar múltiples acciones de recuperación en respuesta a la alerta recibida, almacenando la base de datos de resolución de problemas los perfiles de alertas que coinciden con acciones de recuperación adicionales clasificados por dispositivo o programas de software; si la alerta está mapeada a una acción de recuperación, realizar la acción de recuperación, en la que, si la alerta coincide con varias asignaciones de caracteres comodín, solo se aplicará el mapeo más específico; de lo contrario, escalar (111) la alerta a una persona designada (101) junto con la información de diagnóstico recopilada; y actualizar, mediante el empleo de la información de diagnóstico recopilada, los registros asociados con la alerta - mapeo de acciones de recuperación; el procedimiento comprende además recibir por el motor de monitorización (103) una respuesta de retroalimentación de un dispositivo o programa de software después de la ejecución de la acción de recuperación y pasar la respuesta al motor de automatización (102); en respuesta, el motor de automatización (102) actualiza la base de datos de resolución de problemas.

Description

DESCRIPCIÓN

Recuperación y escalada automáticas en aplicaciones complejas distribuidas

Antecedentes

En los actuales entornos de comunicación en red, muchos servicios que solían ser proporcionados por aplicaciones ejecutadas localmente se proporcionan a través de servicios distribuidos. Por ejemplo, los servicios de correo electrónico, los servicios de calendario / programación y otros comparables se proporcionan a través de complejos sistemas en red que involucran varios servidores físicos y virtuales, instalaciones de almacenamiento y otros com­ ponentes que sobrepasan los límites geográficos. Incluso sistemas organizativos, tales como redes empresariales, pueden ser implementados a través de parques de servidores físicamente separados, etc.

Aunque los servicios distribuidos facilitan la gestión de la instalación, la actualización y el mantenimiento de las apli­ caciones (es decir, en lugar de instalar, actualizar y mantener cientos, si no miles de aplicaciones locales, un servicio gestionado centralmente puede encargarse de estas tareas), tales servicios todavía involucran un número de aplica­ ciones ejecutadas en múltiples servidores. Al gestionar continuamente aplicaciones distribuidas a gran escala, es de esperar que se produzcan una variedad de problemas. Los fallos de hardware, los problemas de software y otros defectos inesperados pueden ocurrir con regularidad. Intentar gestionar y recuperar estos problemas manualmente puede requerir un número de ingenieros de operaciones dedicados y conocedores del dominio con costo prohibitivo. Para proporcionar algunos ejemplos, el documento US 2005/0015678 muestra una base de datos que contiene entradas con código ejecutable que puede hacer uso de los servicios para monitorizar, diagnosticar y resolver pro­ blemas específicos. Cada entrada en la base de datos aborda un problema específico. El código ejecutable está diseñado para aislar y reconocer el problema y a continuación implementar un ajuste o una solución alternativa para ese problema. El código ejecutable está diseñado para automatizar completamente todo el proceso de detección y resolución del problema. Además, se puede emplear la intervención manual para completar el diagnóstico o la solu­ ción.

Además, el documento US 2002/016871 muestra un sistema y un procedimiento que gestionan automáticamente un grupo de ordenadores mediante la recopilación automática de datos, el almacenamiento de los datos, el análisis de los datos almacenados para identificar las condiciones especificadas y el inicio de acciones automatizadas para responder a las condiciones detectadas. El objeto de la presente memoria descriptiva, que se denominará en la presente memoria descriptiva y en lo que sigue "SYSTEMWatch AI - L", comprende un cliente SYSTEMWatch AI - L que convierte un ordenador en un ordenador gestionado, una consola SYSTEMWatch AI - L, que convierte un orde­ nador en un ordenador de monitorización, una instalación de envío SYSTEMWatch AI - L que permite a un adminis­ trador del sistema enviar comandos a varios clientes de SYSTEMWatch AI - L a través de la consola SYSTEMWatch AI - L, y una instalación de informes SYSTEMWatch AI - L que permite al administrador del sistema consultar la información recogida y procesada por los clientes de SYSTEMWatch AI - L y las consolas SYSTEMWatch AI - L. El documento WO 2006/0200094 proporciona un medio para la resiliencia mediante (a) la redirección de la ejecución del programa en respuesta a un fallo en las rutas de código conocidas que representan guardar y / o salir del pro­ grama, (b) la suspensión del programa y la restauración después de que el fallo haya sido reparado, y (c) realizar una instantánea del estado de la aplicación para la restauración después del fallo de la aplicación.

Aún más, "Un sistema experto en tiempo real continuo para operaciones informáticas" por R. L. Ennis et al trata del sistema YES / MVS, su dominio de aplicación y los problemas que surgen en el diseño y desarrollo de un sistema experto que se ejecuta continuamente en tiempo real.

Sumario

Este sumario se proporciona para introducir una selección de conceptos en una forma simplificada que se describen a continuación en la Descripción detallada. Este sumario no tiene la intención de identificar exclusivamente las ca­ racterísticas clave o características esenciales de la materia reivindicada, ni pretende ser una ayuda para determinar el alcance de la materia reivindicada.

Las realizaciones están dirigidas al mapeo de alertas detectadas para acciones de recuperación para resolver au­ tomáticamente problemas en un entorno de comunicación en red. Las alertas no mapeadas pueden ser escaladas a individuos designados por medio de un procedimiento de escalada cíclico que incluye un aviso de entrega de con­ firmación de transferencia del individuo designado. De acuerdo con algunas realizaciones, la información recopilada para cada alerta, así como las soluciones a través del proceso de escalada, se pueden registrar para ampliar la base de conocimientos de resolución automatizada.

Estas y otras características y ventajas serán evidentes a partir de la lectura de la descripción detallada que sigue y de una revisión de los dibujos asociados. Se debe entender que tanto la descripción general anterior como la des­ cripción detallada que sigue son explicativas y no restringen aspectos reivindicados.

Breve descripción de los dibujos

La figura 1 es un diagrama conceptual que ilustra un entorno ejemplar en el que la detección de una alerta puede conducir a una acción de reparación o la escalada de la alerta;

la figura 2 es un diagrama de acción que ilustra acciones durante la escalada de una alerta;

la figura 3 es otro diagrama conceptual que ilustra la gestión de alertas en un entorno multirregional;

la figura 4 es un entorno en red, en el que se puede implementar un sistema de acuerdo con realizaciones; la figura 5 es un diagrama de bloques de un entorno operativo informático ejemplar, en el que se pueden implementar realizaciones; y

la figura 6 ilustra un diagrama de flujo lógico para la gestión automatizada de alertas en un entorno de co­ municación en red de acuerdo con realizaciones.

Descripción detallada

Como se ha descrito brevemente más arriba, las alertas en un sistema en red pueden ser gestionadas por medio de un proceso de escalada / acción automatizada que utiliza acciones mapeadas en alertas y / o escaladas para la resolución manual al tiempo que expande una base de conocimiento para la porción de acción automatizada y pro­ porciona información recopilada a individuos designados encargados de abordar los problemas. En la descripción detallada que sigue, se hacen referencias a los dibujos adjuntos que forman una parte de la presente memoria des­ criptiva, y en los cuales se muestran a modo de realizaciones específicas o ejemplos ilustrativos. Estos aspectos pueden combinarse, pueden utilizarse otros aspectos y pueden realizarse cambios estructurales sin apartarse del alcance de la presente divulgación. Por lo tanto, la descripción detallada que sigue no se debe tomar en un sentido limitativo, y el alcance de la presente invención está definido por las reivindicaciones independientes que se acom­ pañan 1, 7 y 12.

Aunque las realizaciones se describirán en el contexto general de los módulos de programa que se ejecutan junto con un programa de aplicación que se ejecuta en un sistema operativo en un ordenador personal, los expertos en la técnica reconocerán que los aspectos también pueden ser implementados en combinación con otros módulos de programas.

En general, los módulos de programa incluyen rutinas, programas, componentes, estructuras de datos y otros tipos de estructuras que realizan tareas particulares o implementan tipos de datos abstractos particulares. Además, los expertos en la materia apreciarán que las realizaciones pueden ser practicadas con otras configuraciones de siste­ mas informáticos, incluidos dispositivos portátiles, sistemas multiprocesador, electrónica de consumo programable o basada en microprocesador, miniordenadores, ordenadores centrales y dispositivos informático comparables. Las realizaciones también pueden ser practicadas en entornos informáticos distribuidos en los que las tareas se realizan mediante dispositivos de procesamiento remoto que están vinculados a través de una red de comunicaciones. En un entorno informático distribuido, los módulos de programa pueden estar situados en dispositivos de almacenamiento de memoria local así como remota.

Las realizaciones pueden ser implementadas como un proceso (procedimiento) implementado por ordenador, un sistema informático, o como un artículo manufacturado, tal como un producto de programa de ordenador o un medio legible por ordenador. El producto de programa informático puede ser un medio de almacenamiento informático legible por un sistema informático y que codifica un programa informático que comprende instrucciones para hacer que un ordenador o sistema informático realice procesos ejemplares. El medio de almacenamiento legible por orde­ nador se puede implementar, por ejemplo, por medio de una o más de una memoria volátil de ordenador, una me­ moria no volátil, un disco duro, una unidad flash, un disquete o un disco compacto y otros medios similares. El pro­ ducto de programa informático también puede ser una señal propagada en un portador (por ejemplo, una señal mo­ dulada en frecuencia o en fase) o un medio que puede ser leído por un sistema informático y que codifica un pro­ grama informático de instrucciones para ejecutar un proceso informático.

A lo largo de esta memoria descriptiva, se hacen referencias a servicios. Un servicio como se usa en la presente memoria descriptiva describe cualquier aplicación o aplicaciones en red / en línea que pueda recibir una alerta como parte de sus operaciones regulares y procesar / almacenar / enviar esa información. Estas aplicaciones pueden ejecutarse en un único dispositivo informático, en múltiples dispositivos informáticos de una manera distribuida, etc. Las realizaciones también pueden implementarse en un servicio alojado ejecutado sobre una pluralidad de servido­ res o sistemas comparables. El término "servidor" generalmente se refiere a un dispositivo informático que ejecuta uno o más programas de software típicamente en un entorno de red. Sin embargo, un servidor también puede im­ plementarse como un servidor virtual (programas de software) ejecutado en uno o más dispositivos informáticos vistos como un servidor en la red. Más detalles sobre estas tecnologías y operaciones ejemplar se proporcionan a continuación.

Haciendo referencia a la figura 1, el diagrama conceptual 100 ilustra un entorno ejemplar en el que la detección de una alerta puede llevar a una acción de reparación o escalada de la alerta. Como se ha mencionado brevemente más arriba, las realizaciones abordan la complejidad de los servicios de soporte técnico mediante la automatización de las acciones de reparación y la escalada de alertas. Por ejemplo, en un sistema de servicios de soporte técnico distribuidos, el motor de monitorización 103 puede enviar una alerta 113 a un motor de automatización 102 al detec­ tar un problema de hardware, software o una combinación de hardware / software en el sistema distribuido. El motor de automatización 102 puede intentar mapear la alerta 113 a una acción de reparación 112. Si el motor de automati­ zación 102 asigna con éxito la alerta 113 a la acción de reparación 112, entonces el motor de automatización 102 puede ejecutar la acción de reparación 112, que puede incluir un conjunto de instrucciones para abordar el problema detectado.

El problema puede estar asociado con uno o más dispositivos 104 en la localización del servicio distribuido geográfi­ camente 105. Los dispositivos pueden incluir cualquier dispositivo informático, tal como un ordenador de escritorio, un servidor, un teléfono inteligente, un ordenador portátil y otros similares. Los dispositivos 104 pueden incluir además dispositivos adicionales de acceso remoto tales como monitores, equipos de audio, aparatos de televisión, dispositivos de captura de video y otros dispositivos similares.

La alerta 113 puede incluir información de estado del dispositivo o programa asociado con el problema detectado, como el contenido de la memoria del dispositivo, las lecturas del sensor, las últimas instrucciones ejecutadas y otros. La alerta 113 puede incluir además una descripción del problema, tal como qué instrucción no se ejecutó, qué ejecu­ ciones indican resultados más allá de los límites predefinidos y otros similares.

El motor de automatización 102 puede intentar mapear la alerta 113 a una acción de reparación 112 mediante la búsqueda de una base de datos de resolución de problemas 114. La base de datos de resolución de problemas 114 puede almacenar perfiles de alertas coincidentes con acciones de reparación clasificadas por dispositivo o progra­ mas de software. Una implementación ejemplar puede ser una alerta "sin conexión" de un dispositivo de comunica­ ción que coincida con una acción de reparación de reinicio de la interfaz de red del dispositivo de comunicación. Se pueden mapear una o más acciones de reparación a cada alerta. Además, una o más alertas puede estar mapeada a una única acción de reparación.

Si el motor de automatización 102 determina múltiples acciones de reparación para una alerta, una prioridad de ejecución puede depender de una prioridad predefinida de las acciones de reparación. Por ejemplo, una acción de reparación primaria en el escenario que se ha explicado más arriba puede ser el reinicio de la interfaz de red segui­ do por una acción de reparación secundaria de reiniciar el dispositivo de comunicación. La prioridad predefinida de las acciones de reparación puede ser introducida manualmente en la base de datos de resolución de problemas 114 o determinarse automáticamente en función de un esquema de evaluación de éxito de la acción de reparación des­ pués de una corrección con éxito del problema.

De acuerdo con algunas realizaciones, la acción de reparación 112 puede incluir la recopilación de información de diagnóstico adicional del dispositivo y / o del programa de software asociado con el problema. La información de diagnóstico adicional puede ser transmitida al motor de monitorización como una alerta que reinicia el ciclo automa­ tizado de acuerdo con otras realizaciones. En respuesta a una alerta, también se puede recopilar y almacenar infor­ mación de diagnóstico adicional en el sistema. La información almacenada puede ser usada para capturar el estado del problema y proporcionar el contexto cuando la alerta es escalada a la persona o equipo designado (por ejemplo, 101)

Si no se encuentra una acción de reparación mapeada en la base de datos de resolución de problemas114 por el motor de automatización 102, la alerta 113 puede escalarse a una persona o equipo designado 101. La persona o equipo designado 101 puede ser notificada incluso si se encuentra una acción mapeada y es ejecutada con propósi­ tos informativos. La transmisión de la alerta 113 a la persona o equipo 101designada se puede determinar a partir de una convención de denominación de alerta 113. La convención de denominación de alerta puede indicar a qué per­ sonal de soporte se debe escalar la alerta, tal como un equipo de soporte de hardware, un equipo de soporte de software, y otros comparables. El esquema de convención de denominación también se puede utilizar para mapear alertas a acciones de recuperación. Por ejemplo, las alertas pueden ser nombradas en un esquema jerárquico (es decir, el nombre del sistema / componente / alerta) y las acciones de recuperación pueden ser mapeadas a cualquier lugar desde todas las alertas para un sistema (sistema / *) a una acción de recuperación especial para una alerta específica. De acuerdo con algunas realizaciones, cada alerta específica puede tener un equipo designado asocia­ do, aunque ese equipo puede tener por defecto un valor predeterminado para un componente completo. La determi­ nación de a qué miembro del equipo enviar la alerta puede depender de un algoritmo de mapeo predeterminado que reside dentro del motor de automatización para conocer los horarios del equipo de soporte. El algoritmo de mapeo predeterminado puede ser actualizado manual o automáticamente mediante sistemas de programación integrados o externos.

El motor de automatización 102 puede escalar la alerta 113 a una primera persona o equipo designado por medio de un correo electrónico, un mensaje instantáneo, un mensaje de texto, una página, un correo de voz o medios simila­ res. Las alertas pueden ser mapeadas a los nombres de los equipos, y el nombre de un equipo a un grupo de per­ sonas que están de guardia en intervalos predefinidos (por ejemplo, un día, una semana, etc.). Parte del mapeo se puede usar para identificar qué personas están disponibles en el intervalo. De esta manera, los mapeos de alerta pueden ser abstraídos de los miembros individuales del equipo, lo cual puede ser fluido. El motor de automatización 102 puede esperar entonces una notificación de transferencia a la primera persona o equipo designado. La notifica­ ción de entrega puede ser recibida por el motor de automatización 102 en la forma en que se envió la alerta o puede ser recibida por otros medios. Si el motor de automatización 102 no recibe el notificación de transferencia dentro de un período de tiempo predeterminado, puede escalar la alerta 113 a la siguiente persona o equipo designado en la rotación, de acuerdo con lo que determine un algoritmo de mapeo predefinido. El algoritmo de automatización puede continuar escalando la alerta a la siguiente persona o equipo designado en la rotación hasta que reciba una notifica­ ción de transferencia.

El motor de monitorización 103 puede recibir una respuesta de retroalimentación (por ejemplo, en forma de una acción) del dispositivo o programa de software después de la ejecución de la acción de reparación 112 pasando la respuesta al motor de automatización 102. El motor de automatización 102 puede actualizar entonces la base de datos de resolución de problemas 114. La información estadística, tal como el índice de éxito de las acciones de reparación, se puede utilizar para modificar la prioridad de ejecución de las acciones de reparación. Además, la respuesta de retroalimentación asociada con las acciones realizadas por una persona o equipo designado también se puede registrar en la base de datos de resolución de problemas 114, de manera que se pueda emplear un algo­ ritmo de aprendizaje automático o un mecanismo similar para ampliar la lista de acciones, mapear nuevas alertas a acciones existentes, mapear alertas existentes a nuevas acciones, etc. Las acciones del motor de automatización y las acciones de la persona designada pueden ser auditadas por el sistema de acuerdo con algunas realizaciones. El sistema puede mantener un registro de quién ejecutó una acción específica, cuándo y contra cual dispositivo o ser­ vidor. Posteriormente, los registros se pueden usar para solucionar problemas, rastrear cambios en el sistema y / o desarrollar nuevas respuestas de alerta automatizadas.

De acuerdo con realizaciones adicionales, el motor de automatización 102 puede realizar una búsqueda de caracte­ res comodín de la base de datos de resolución de problemas 114 y determinar múltiples acciones de reparación en respuesta a una alerta recibida. La ejecución de acciones individuales o de grupos de reparación puede depender de la prioridad predeterminada de las acciones de reparación. Los grupos de acciones de reparación también se pue­ den mapear a grupos de alertas. Si bien una alerta puede coincidir con varios mapeos de caracteres comodín, en la realidad puede aplicarse el mapeo más específico. Por ejemplo, el intercambio de alertas / transporte / cola de espe­ ra puede coincidir con el intercambio de mapeo / *, intercambio / transporte / * e intercambio / transporte / cola de espera. Sin embargo, el último puede ser el mapeo verdadero porque es el más específico.

La figura 2 ilustra acciones durante la escalada de la alerta en el diagrama 200. El motor de monitorización 202 pue­ de proporcionar un problema detectado como alerta (211) al motor de automatización 204. El motor de automatiza­ ción 204 puede verificar las acciones disponibles (212) del almacén de acciones 206 (solución de problemas de la base de datos 114 de la figura 1) y realizar la acción si hay una disponible (213). Si no hay acción disponible, el motor de automatización 204 puede escalar la alerta (214) al propietario del proceso 208. La alerta puede escalarse aún más (215) a otra persona designada 209. Como se ha explicado más arriba, la escalada también se puede rea­ lizar en paralelo a la ejecución de una acción determinada.

Al recibir una nueva acción que debe ser realizada (216, 217) del propietario del proceso 208 u otra persona desig­ nada 209, el motor de automatización 204 puede realizar la nueva acción (218) y actualizar los registros con la nue­ va acción (219) para uso futuro. Las interacciones ejemplares en el diagrama 200 ilustran un escenario limitado. Otras interacciones, tales como las transferencias con las personas designadas, las retroinformaciones de los dispo­ sitivos / software que informan el problema y otros similares también pueden incluirse en la operación de un sistema automatizado de recuperación y escalada de acuerdo con las realizaciones.

La figura 3 es un diagrama conceptual que ilustra la gestión de alertas en un entorno de múltiples regiones en el diagrama 300. En un sistema distribuido, la escalada de las alertas puede depender de una prioridad predetermina­ da de las regiones geográficas. Por ejemplo, una prioridad predeterminada puede escalar una alerta en una región en la que es de día y mantener una alerta en una región en la que es de noche cuando las escalas son gestionadas por un solo equipo de soporte para ambas regiones. De manera similar, las acciones de reparación de diferentes regiones se pueden priorizar en función de una prioridad predeterminada cuando las acciones de reparación de las diferentes regiones compiten por el mismo hardware, software y recursos de comunicación para abordar los proble­ mas detectados.

El diagrama 300 ilustra cómo las alertas de diferentes regiones pueden ser abordadas por un sistema de acuerdo con las realizaciones. De acuerdo con un escenario ejemplar, los motores de monitorización 303, 313 y 323 pueden ser responsables de monitorizar los problemas de hardware y / o software de las regiones 1, 2 y 3 (304, 314 y 324), respectivamente. Al detectar un problema, cada uno de los motores de monitorización puede transmitir alertas a los respectivos motores de automatización 302, 312 y 322, que pueden ser responsables de las regiones respectivas. La lógica de los motores de automatización se puede distribuir a cada región de la misma manera que la lógica de monitorización. De acuerdo con algunas realizaciones, la automatización puede ocurrir a través de las regiones, tal como un fallo y recuperación de todo el sitio. De acuerdo con otras realizaciones, un motor de automatización puede ser responsable de varias regiones. Del mismo modo, el objetivo de escalada también puede ser centralizado o distribuido. Por ejemplo, el sistema puede escalar a diferentes equipos en base a la hora del día. Los motores de monitorización 303, 313 y 323 pueden tener sus propias bases de datos regionales separadas para gestionar los procesos de monitorización. Los motores de automatización 302, 312 y 322 pueden consultar la base de datos de resolución de problemas (central o distribuida) para mapear alertas de acciones de reparación.

Si se encuentran la o las acciones de reparación correspondientes, los motores de automatización 302, 312 y 322 pueden ejecutar las acciones de reparación en los dispositivos y / o programas en las regiones 304, 314 y 324. Una base de datos de monitorización global 310 también puede ser implementada para todas las regiones. Si los moto­ res de automatización 302, 312 y 322 no pueden encontrar acciones de reparación coincidentes, pueden escalar las alertas a un equipo de soporte designado 301 de acuerdo con las prioridades regionales predefinidas, tales como la estructura organizativa. Por ejemplo, la región 304 puede ser la red corporativa de la compañía para una organiza­ ción empresarial, mientras que la región 324 es la red de soporte de documentación. Un problema detectado en la región 304 en este escenario, puede ser priorizado sobre un problema detectado en la región 324. De manera simi­ lar, se puede tener en consideración la diferencia de hora del día o día laborable / festivo entre las diferentes regio­ nes, y se pueden tomar en cuenta factores comparables al determinar las prioridades regionales.

De acuerdo con algunas realizaciones, se pueden asignar múltiples motores de automatización a diferentes regiones y la escalada y / o ejecución de prioridades de acciones de reparación se deciden a través de un algoritmo de con­ senso entre los motores de automatización como se ha mencionado más arriba. Alternativamente, un proceso que supervise los motores de automatización regionales puede proporcionar las decisiones de prioridad. Además, los motores de automatización 302, 312 y 322 pueden interactuar con las bases de datos de resolución de problemas regionales, que incluyen acciones de reparación personalizadas - mapeo de alertas para las distintas regiones. Aunque la automatización de los procesos de recuperación y escalada en sistemas distribuidos se ha explicado más arriba utilizando escenarios ejemplares, la ejecución de acciones de reparación específicas y la escalada de alertas en conjunto con las figuras 1, 2 y 3, las realizaciones no están limitadas a estas. El mapeo de alertas para las accio­ nes de reparación, la priorización de las acciones de reparación, la escalada de alertas y otros procesos pueden ser implementados empleando otras operaciones, prioridades, evaluaciones, etc., utilizando los principios que se han explicado en la presente memoria descriptiva.

La figura 4 es un ejemplo de entorno en red, en el que se pueden implementar realizaciones. El mapeo de una alerta para una acción de reparación puede implementarse a través de un software ejecutado en uno o más servidores 422, como un servicio alojado. El servidor 422 puede comunicarse con las aplicaciones cliente en dispositivos in­ formáticos individuales tales como un teléfono celular 411, un dispositivo informático móvil 412, un teléfono inteligen­ te 413, un ordenador portátil 414 y un ordenador de escritorio 415 (dispositivos cliente) a través de la o las redes 410. Las aplicaciones cliente en los dispositivos cliente 411 - 415 pueden facilitar las interacciones del usuario con el servicio ejecutado en los servidores 422, lo que permite la gestión automatizada de problemas de software y / o hardware asociados con el servicio. Los motores de automatización y monitorización pueden ejecutarse en cualquie­ ra de los servidores 422.

Los datos asociados con las operaciones, tales como el mapeo de la alerta a la acción de reparación, pueden ser almacenados en uno o más almacenes de datos (por ejemplo, el almacén de datos 425 o 426), que pueden ser gestionados por cualquiera de los servidores 422 o por el servidor de bases de datos 424. La recuperación automa­ tizada y la escalada de los problemas detectados de acuerdo con las realizaciones pueden activarse cuando el mo­ tor de monitorización detecta una alerta como se ha explicado en los ejemplos anteriores.

La red o las redes 410 pueden comprender cualquier topología de servidores, clientes, proveedores de servicios de Internet y medios de comunicación. Un sistema de acuerdo con realizaciones puede tener una topología estática o dinámica. La red o las redes 410 puede incluir una red segura, tal como una red empresarial, una red no segura, tal como una red abierta inalámbrica, o Internet. La red o las redes 410 proporcionan comunicación entre los nodos que se han descrito en la presente memoria descriptiva. A modo ejemplar, y no de limitación, la red o las redes 410 pue­ den incluir medios inalámbricos tales como medios acústicos, de RF, infrarrojos y otros medios inalámbricos.

Se pueden emplear muchas otras configuraciones de dispositivos informáticos, aplicaciones, fuentes de datos y sistemas de distribución de datos para implementar un sistema para automatizar la gestión de problemas de siste­ mas distribuidos de acuerdo con las realizaciones. Además, los entornos en red que se explican en la figura 4 son sólo para fines ilustrativos. Las realizaciones no se limitan a las aplicaciones, módulos o procesos ejemplares.

La figura 5 y la explicación asociada pretende proporcionar una breve descripción general de un entorno informático adecuado en el que se pueden implementar las realizaciones. Con referencia a la figura 5, se ilustra un diagrama de bloques de un ejemplo de entorno operativo informático para una aplicación de servicio de acuerdo con realizacio­ nes, tal como el dispositivo informático 500. En una configuración básica, el dispositivo informático 500 puede ser un servidor en un sistema de servicio alojado e incluir al menos una unidad de procesamiento 502 y la memoria del sistema 504. El dispositivo informático 500 también puede incluir una pluralidad de unidades de procesamiento que cooperan en la ejecución de programas. Dependiendo de la configuración exacta y el tipo de dispositivo informático, la memoria del sistema 504 puede ser volátil (como RAM), no volátil (como ROM, memoria flash, etc.) o alguna combinación de las dos. La memoria del sistema 504 generalmente incluye un sistema operativo 505 adecuado para controlar el funcionamiento de la plataforma, tal como los sistemas operativos WINDOWS® de MICROSOFT COR­ PORATION de Redmond, Washington. La memoria del sistema 504 también puede incluir uno o más módulos de programa 506, el motor de automatización 522 y el motor de supervisión 524.

Los motores de automatización y supervisión 522 y 524 pueden ser aplicaciones separadas o módulos integrales de un servicio alojado que maneja las alertas del sistema como se ha explicado más arriba. Esta configuración básica se ilustra en la figura 5 por esos componentes dentro de la línea de trazos 508.

El dispositivo informático 500 puede tener características o funcionalidades adicionales. Por ejemplo, el dispositivo informático 500 también puede incluir dispositivos de almacenamiento de datos adicionales (removibles y / o no removibles) como, por ejemplo, discos magnéticos, discos ópticos o cintas. Un almacenamiento adicional de este tipo se ilustra en la figura 5 por el almacenamiento removible 509 y el almacenamiento no removible 510. Los me­ dios de almacenamiento legibles por ordenador pueden incluir medios volátiles y no volátiles, removibles y no remo­ vibles implementados en cualquier procedimiento o tecnología para el almacenamiento de información, tales como instrucciones legibles por ordenador, estructuras de datos, módulos de programas, u otros datos. La memoria del sistema 504, el almacenamiento removible 509 y el almacenamiento no removible 510 son ejemplos de medios de almacenamiento legibles por ordenador. Los medios de almacenamiento legibles por ordenador incluyen, pero no se limitan a, RAM, ROM, EEPROM, memoria flash u otra tecnología de memoria, c D - ROM, discos versátiles digitales (DVD) u otro almacenamiento óptico, casetes magnéticos, cinta magnética, almacenamiento en disco magnético o otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para almacenar la infor­ mación deseada y al que se pueda acceder por medio del dispositivo informático 500. Cualquier medio de almace­ namiento legible por ordenador puede ser parte del dispositivo informático 500. El dispositivo informático 500 tam­ bién puede tener un dispositivo o dispositivos de entrada 512 como teclado, ratón, lápiz, dispositivo de entrada de voz, dispositivo de entrada táctil y dispositivos de entrada comparables. Los dispositivos de salida 514, tales como una pantalla, altavoces, impresora y otros tipos de dispositivos de salida también pueden ser incluidos. Estos dispo­ sitivos son bien conocidos en la técnica y no necesitan ser explicados en detalle aquí.

El dispositivo informático 500 también puede contener conexiones de comunicación 516 que permiten que el disposi­ tivo se comunique con otros dispositivos 518, tal como a través de una red inalámbrica en un entorno informático distribuido, un enlace satelital, un enlace celular y mecanismos comparables. Otros dispositivos 518 pueden incluir dispositivos informáticos que ejecutan aplicaciones distribuidas y realizan operaciones similares. Las conexiones de comunicación 516 son un ejemplo de medios de comunicación. Los medios de comunicación pueden incluir en los mismos instrucciones legibles por ordenador, estructuras de datos, módulos de programa u otros datos en una señal de datos modulada, tal como una onda portadora u otro mecanismo de transporte, e incluye cualquier medio de entrega de información. El término "señal de datos modulada" significa una señal que tiene una o más de sus carac­ terísticas configuradas o modificadas de tal manera que codifican información en la señal. A modo ejemplar, y no de limitación, los medios de comunicación incluyen medios cableados, tales como una red cableada o conexión directa, y medios inalámbricos, tales como acústicos, RF, infrarrojos y otros medios inalámbricos.

Ejemplos de realización también incluyen procedimientos. Estos procedimientos se pueden implementar de varias formas, incluidas las estructuras descritas en la presente memoria descriptiva. Una de esas formas es por operacio­ nes de la máquina, de dispositivos del tipo que se ha descrito en la presente memoria descriptiva.

Otra forma opcional es que una o más de las operaciones individuales de los procedimientos se realicen junto con uno o más operadores humanos que realizan alguna de ellas. No es necesario que estos operadores humanos estén juntos, sino que cada uno puede estar solo con una máquina que realiza una parte del programa.

La figura 6 ilustra un diagrama de flujo lógico 600 para automatizar la gestión de un problema de recuperación y escalada en sistemas distribuidos de acuerdo con realizaciones. El proceso 600 puede ser implementado en un servidor como parte de un servicio alojado o en una aplicación cliente para interactuar con un servicio como los que se han descrito más arriba.

El proceso 600 comienza con la operación 602, en la que un motor de automatización detecta una alerta enviada por un motor de monitorización en respuesta a un problema de aplicación de software y / o dispositivo dentro del siste­ ma. En la operación 604, el motor de automatización que ha recibido la alerta del motor de monitorización, puede comenzar a recopilar información asociada con la alerta. Esto puede ser seguido por un intento de mapear la alerta a una o más acciones de reparación en la operación 606.

Si se encuentra una acción explícita asignada a la alerta en la operación de decisión 608, la acción (o acciones) puede ejecutarse en la operación posterior 610. Si no se determina una acción explícita durante el proceso de mapeo, la alerta puede escalarse a una persona designada o equipo en la operación 614. La operación 614 puede ir seguida de las operaciones opcionales 616 y 618, en las que se puede recibir una nueva acción de la persona o equipo designado y realizarla. En la operación 612, los registros pueden actualizarse con la acción realizada (mapeada o nueva) de modo que la base de datos de mapeo se pueda expandir o la información estadística asociada con las tasas de éxito se pueda usar para futuras tareas de monitorización y respuesta automática.

Las operaciones incluidas en el proceso 600 tienen fines ilustrativos. La recuperación automatizada y la escalada de problemas en aplicaciones distribuidas complejas pueden implementarse mediante procesos similares con menos pasos o adicionales, así como en diferentes orden de operaciones utilizando los principios que se han descrito en la presente memoria descriptiva.

La especificación, los ejemplos y los datos anteriores proporcionan una descripción completa de la fabricación y el uso de la composición de las realizaciones. Aunque el tema se ha descrito en un lenguaje específico para caracterís­ ticas estructurales y / o actos metodológicos, se debe entender que el tema definido en las reivindicaciones adjuntas no está necesariamente limitado a las características o actos específicos que se han descritos más arriba. Más bien, las características y los actos específicos que se han descrito más arriba se describen como formas ejemplares de implementación de las reivindicaciones y realizaciones.

Claims (14)

REIVINDICACIONES

1. Un procedimiento para ser ejecutado, al menos en parte, en un dispositivo informático para la recuperación automatizada y la escalada de alertas en sistemas distribuidos, comprendiendo el procedimiento :

detectar, por un motor de monitorización (103), un problema asociado con al menos uno de entre un dispo­ sitivo y una aplicación de software dentro de un sistema distribuido;

transmitir, por el motor de monitorización (103), una alerta (113) basada en el problema detectado, a un motor de automatización (102);

recibir la alerta asociada con un problema detectado desde el motor de monitorización (103) en el motor de automatización (102);

el procedimiento comprende además los siguientes pasos realizados por el motor de automatización (102); recoger información de diagnóstico asociada con el problema detectado;

tratar de mapear la alerta a una acción de recuperación, en la que el motor de automatización (102) realiza una búsqueda de caracteres comodín de una base de datos de resolución de problemas para determinar múltiples acciones de recuperación en respuesta a la alerta recibida, almacenando la base de datos de re­ solución de problemas los perfiles de alertas que coinciden con acciones de recuperación adicionales clasi­ ficados por dispositivo o programas de software;

si la alerta está mapeada a una acción de recuperación, realizar la acción de recuperación, en la que, si la alerta coincide con varias asignaciones de caracteres comodín, solo se aplicará el mapeo más específico; de lo contrario,

escalar (111) la alerta a una persona designada (101) junto con la información de diagnóstico recopilada; y actualizar, mediante el empleo de la información de diagnóstico recopilada, los registros asociados con la alerta - mapeo de acciones de recuperación;

el procedimiento comprende además

recibir por el motor de monitorización (103) una respuesta de retroalimentación de un dispositivo o progra­ ma de software después de la ejecución de la acción de recuperación y pasar la respuesta al motor de au­ tomatización (102);

en respuesta, el motor de automatización (102) actualiza la base de datos de resolución de problemas.

2. El procedimiento de la reivindicación 1, en el que la información de diagnóstico recopilada incluye al menos uno de entre un conjunto de: contenidos de la memoria de un dispositivo, lecturas del sensor, últimas instrucciones ejecutadas, instrucciones fallidas y resultados de fallos asociados con el problema detectado.

3. El procedimiento de la reivindicación 1, que comprende, además:

esperar una respuesta de transferencia de la persona designada después de escalar la alerta; y si la respuesta de transferencia no se recibe dentro de un período predefinido, pasar la alerta a otra perso­ na designada.

4. El procedimiento de la reivindicación 1, en el que la persona designada es determinada de una lista predefinida de personas designadas y una convención de denominación de alerta, y la persona designada incluye una per­ sona y un equipo.

5. El procedimiento de la reivindicación 1, en el que escalar la alerta incluye:

transmitir la alerta a la persona designada por al menos uno de un conjunto de: un correo electrónico, un mensaje instantáneo, un mensaje de texto, una página y un mensaje de voz.

6. El procedimiento de la reivindicación 1, que comprende además:

actualizar un registro de índice de éxito asociado con la acción de recuperación.

7. Un sistema para la recuperación automatizada y la escalada de alertas en sistemas distribuidos, comprendiendo el sistema :

un servidor que ejecuta un motor de monitorización (103) y un motor de automatización (102), en el que el motor de monitorización está configurado para:

detectar un problema asociado con al menos uno de un dispositivo y una aplicación de software dentro de un sistema distribuido; y

transmitir una alerta (113) basada en el problema detectado; y

el motor de automatización (102) está configurado para:

recibir la alerta (113);

recopilar información de diagnóstico asociada con el problema detectado;

tratar de mapear la alerta (113) a una acción de recuperación, en la que el motor de automatiza­ ción (102) realiza una búsqueda de caracteres comodín de una base de datos de resolución de problemas para determinar múltiples acciones de recuperación en respuesta a la alerta recibida, la base de datos de resolución de problemas almacena los perfiles de alertas coincidentes con accio­ nes de recuperación clasificadas además por dispositivo o programas de software; si la alerta se asigna a una acción de recuperación, realizar la acción de recuperación, en la que, si la alerta coincide con varias asignaciones de caracteres comodín, solo se aplicará el mapeo más específica; de lo contrario, intensificar (111) la alerta a una persona designada (101) junto con la información de diagnóstico recopilada; y

actualizar los registros en la base de datos de resolución de problemas empleando la información de diagnóstico recopilada;

el motor de monitorización (103) está configurado además para recibir una respuesta de retroalimentación desde un dispositivo o programa de software después de la ejecución de la acción de recuperación y pasar la respuesta al motor de automatización (102);

el motor de automatización está configurado además para actualizar la base de datos de resolución de pro­ blemas.

8. El sistema de la reivindicación 7, que comprende además una pluralidad de motores de monitorización, estando configurado cada motor de monitorización para monitorizar una región geográfica distinta en base a la escala del sistema para cada región geográfica dentro del sistema distribuido y transmitir alertas basadas en problemas detectados en sus respectivas regiones, en el que el motor de automatización está configurado además para:

realizar una acción de recuperación mapeada y escalar a las alertas designadas desde diferentes regiones en función de una prioridad regional.

9. El sistema de la reivindicación 7, en el que la prioridad regional se determina adicionalmente en base a la dis­ ponibilidad de al menos uno de un conjunto de: un equipo de soporte designado, un recurso de hardware, un recurso de software y un recurso de comunicación.

10. El sistema de la reivindicación 7, en el que la alerta es mapeada a una pluralidad de acciones de recuperación, y las acciones de recuperación se ejecutan de acuerdo con una prioridad de ejecución predefinida.

11. El sistema de la reivindicación 7, en el que el dispositivo incluye uno de entre: un ordenador de escritorio, un ordenador portátil, un ordenador de mano, un servidor, un teléfono inteligente, un monitor, equipo de audio, un televisor y un dispositivo de captura de video.

12. Un medio de almacenamiento legible por ordenador con instrucciones almacenadas en el mismo para la recupe­ ración automatizada y la escalada de alertas en sistemas distribuidos, que, cuando son ejecutadas por un sis­ tema informático, hacen que el sistema informático realice un procedimiento que comprende:

detectar, mediante un motor de monitorización (103), un problema asociado con al menos uno de entre un dispositivo y una aplicación de software dentro de un sistema distribuido;

transmitir, mediante el motor de monitorización (103), una alerta (113) en base al problema detectado a un motor de automatización (102);

recibir la alerta (113) asociada con un problema detectado del motor de monitorización (103) en el motor de automatización (102);

el procedimiento comprende además los siguientes pasos realizados por el motor de automatización (102); recopilar información de diagnóstico asociada con el problema detectado;

tratar de mapear la alerta (113) a una acción de recuperación, en el que el motor de automatización realiza una búsqueda de caracteres comodín de una base de datos de resolución de problemas para determinar múltiples acciones de recuperación en respuesta a la alerta recibida, la base de datos de resolución de pro­ blemas almacena perfiles de alertas que coinciden con acciones de recuperación adicionales clasificadas por un dispositivo o programas de software;

si la alerta se mapea a una acción de recuperación, realizar la acción de recuperación, en la que, si la alerta coincide con varias asignaciones de caracteres comodín, solo se aplicará el mapeo más específico; de otra manera, escalar (111) la alerta a una persona designada (101) junto con la información de diagnóstico re­ copilada; y

actualizar, mediante el empleo de la información de diagnóstico recopilada, los registros asociados con la alerta - mapeo de acciones de recuperación;

el procedimiento comprende además el motor de monitorización (103) que recibe una respuesta de reali­ mentación de un dispositivo o programa de software después de la ejecución de la acción de recuperación y pasa la respuesta al motor de automatización (102);

en respuesta, el motor de automatización (102) actualiza la base de datos de resolución de problemas.

13. El medio de almacenamiento legible por ordenador de la reivindicación 12, en el que la acción de recuperación se mapea a uno de entre: una única alerta y un grupo de alertas.

14. El medio de almacenamiento legible por ordenador de la reivindicación 12, en el que la persona designada es determinada a partir de una de las convenciones de denominación de alerta y un algoritmo de rotación basado en la disponibilidad del personal de soporte.