{"id":53531,"date":"2019-12-04T00:00:00","date_gmt":"2019-12-03T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej"},"modified":"2020-02-18T14:01:26","modified_gmt":"2020-02-18T11:01:26","slug":"ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","title":{"rendered":"Buscamos anomal\u00edas y predecimos fallos con redes neuronales","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Buscamos<\/p>\n

<\/p>\n

El desarrollo industrial de sistemas de software requiere una gran atenci\u00f3n a la resiliencia del producto final, as\u00ed como una r\u00e1pida reacci\u00f3n ante fallos y errores, si es que ocurren. La monitorizaci\u00f3n, por supuesto, ayuda a reaccionar a fallos y errores de manera m\u00e1s eficiente y r\u00e1pida, pero no es suficiente. En primer lugar, es muy dif\u00edcil rastrear un gran n\u00famero de servidores; se necesita un gran equipo de personas. En segundo lugar, es fundamental comprender bien c\u00f3mo funciona la aplicaci\u00f3n para prever su estado. Por lo tanto, se necesitan muchas personas que entiendan bien los sistemas que desarrollamos, as\u00ed como sus m\u00e9tricas y caracter\u00edsticas. Supongamos que, incluso si logramos encontrar un n\u00famero suficiente de personas dispuestas a hacer esto, se requerir\u00e1 mucho tiempo para capacitarlas.<\/p>\n

<\/p>\n

\u00bfQu\u00e9 hacer entonces? Aqu\u00ed es donde nos ayuda la inteligencia artificial. Este art\u00edculo hablar\u00e1 sobre el mantenimiento predictivo<\/a><\/noindex> (predictive maintenance). Este enfoque est\u00e1 ganando popularidad r\u00e1pidamente. Se han escrito muchos art\u00edculos al respecto, incluso en Habr. Las grandes empresas utilizan plenamente este enfoque para mantener la operatividad de sus servidores. Despu\u00e9s de estudiar una gran cantidad de art\u00edculos, decidimos probar este enfoque. \u00bfQu\u00e9 result\u00f3 de ello? <\/p>\n

<\/a><\/noindex><\/p>\n

Introducci\u00f3n<\/h2>\n

<\/p>\n

Un sistema de software, tarde o temprano, entra en operaci\u00f3n. Es importante para el usuario que el sistema funcione sin fallos. Si se llega a producir una situaci\u00f3n extraordinaria, debe resolverse con el m\u00ednimo de retrasos. <\/p>\n

<\/p>\n

Para simplificar el soporte t\u00e9cnico de un sistema de software, especialmente si hay muchos servidores, normalmente se utilizan programas de monitorizaci\u00f3n que capturan m\u00e9tricas del sistema operativo, permiten diagnosticar su estado y ayudan a determinar qu\u00e9 caus\u00f3 el fallo. Este proceso se conoce como monitorizaci\u00f3n del sistema de software.<\/p>\n

\n\"Buscamos<\/p>\n

Figura 1. Interfaz de monitorizaci\u00f3n grafana<\/em><\/p>\n

Las m\u00e9tricas son diversos indicadores de un sistema de software, el entorno de su ejecuci\u00f3n o la m\u00e1quina de computaci\u00f3n f\u00edsica en la que se ejecuta el sistema, marcando el momento en que se obtuvieron las m\u00e9tricas. En el an\u00e1lisis est\u00e1tico, los datos de las m\u00e9tricas se conocen como series temporales. Para observar el estado del sistema de software, las m\u00e9tricas se representan en forma de gr\u00e1ficos: en el eje X se encuentra el tiempo y en el eje Y los valores (Figura 1). Se pueden capturar varios miles de m\u00e9tricas de un sistema de software en funcionamiento (de cada nodo). Estas forman un espacio de m\u00e9tricas (series temporales multidimensionales). <\/p>\n

<\/p>\n

Dado que en sistemas de software complejos se capturan una gran cantidad de m\u00e9tricas, el monitoreo manual se convierte en una tarea compleja. Para reducir el volumen de datos analizados por el administrador, las herramientas de monitoreo incluyen instrumentos para detectar autom\u00e1ticamente problemas potenciales. Por ejemplo, se puede configurar un disparador que se active en caso de que el espacio libre en disco caiga por debajo de un umbral especificado. Tambi\u00e9n se puede diagnosticar autom\u00e1ticamente la detenci\u00f3n del servidor o una desaceleraci\u00f3n cr\u00edtica en la velocidad de servicio. En la pr\u00e1ctica, las herramientas de monitoreo son bastante efectivas en detectar fallos ya ocurridos o en identificar s\u00edntomas simples de fallos futuros, pero en general, prever un posible colapso sigue siendo un problema complicado para ellas. La predicci\u00f3n a trav\u00e9s del an\u00e1lisis manual de m\u00e9tricas requiere la participaci\u00f3n de especialistas calificados. Es poco productivo. La mayor\u00eda de los posibles fallos pueden pasar desapercibidos.<\/p>\n

<\/p>\n

Recientemente, entre las grandes empresas de TI dedicadas al desarrollo de software, ha ganado popularidad el llamado mantenimiento predictivo de sistemas de software. La esencia de este enfoque radica en identificar fallas que llevan a la degradaci\u00f3n del sistema en etapas tempranas, antes de su colapso, utilizando inteligencia artificial. Este enfoque no excluye por completo el monitoreo manual del sistema. Es complementario al proceso de monitoreo en general. <\/p>\n

<\/p>\n

La herramienta principal para implementar el mantenimiento predictivo es la tarea de b\u00fasqueda de anomal\u00edas en las series temporales, ya que al ocurrir una anomal\u00eda<\/strong> en los datos, es probable que despu\u00e9s de un tiempo ocurrir\u00e1 un error o fallo<\/strong>. Una anomal\u00eda es un desv\u00edo en las m\u00e9tricas de un sistema program\u00e1tico, como la detecci\u00f3n de la degradaci\u00f3n de la velocidad de ejecuci\u00f3n de un tipo de solicitud o la disminuci\u00f3n del n\u00famero medio de solicitudes atendidas con un nivel constante de sesiones de clientes.<\/p>\n

<\/p>\n

La tarea de buscar anomal\u00edas en sistemas program\u00e1ticos tiene su propia especificidad. En teor\u00eda, para cada sistema program\u00e1tico es necesaria la elaboraci\u00f3n o mejora de los m\u00e9todos existentes, ya que la b\u00fasqueda de anomal\u00edas depende en gran medida de los datos en los que se lleva a cabo, y los datos de los sistemas program\u00e1ticos var\u00edan considerablemente seg\u00fan las herramientas de implementaci\u00f3n del sistema, hasta el tipo de m\u00e1quina computacional en la que se ejecute.<\/p>\n

<\/p>\n

M\u00e9todos de b\u00fasqueda de anomal\u00edas en la predicci\u00f3n de fallos de sistemas program\u00e1ticos<\/h2>\n

<\/p>\n

Primero que nada, es importante mencionar que la idea de predecir fallos fue inspirada por un art\u00edculo \u00abAprendizaje autom\u00e1tico en la supervisi\u00f3n de TI\u00bb<\/a><\/noindex>. Para comprobar la efectividad del enfoque de b\u00fasqueda autom\u00e1tica de anomal\u00edas, se eligi\u00f3 el sistema program\u00e1tico \u00abWeb-Consolidaci\u00f3n\u00bb, que es uno de los proyectos de la empresa NPO \u00abKrista\u00bb. Anteriormente, se realizaba una supervisi\u00f3n manual basada en las m\u00e9tricas obtenidas. Dado que el sistema es bastante complejo, se recopilan muchas m\u00e9tricas: indicadores de JVM (carga del recolector de basura), indicadores del sistema operativo en el que se ejecuta el c\u00f3digo (memoria virtual, % de carga de la CPU del SO), indicadores de red (carga de red), del propio servidor (carga de la CPU, memoria), m\u00e9tricas de wildfly y m\u00e9tricas espec\u00edficas de la aplicaci\u00f3n en todos los subsistemas cr\u00edticos. <\/p>\n

<\/p>\n

Todas las m\u00e9tricas se recopilan del sistema utilizando graphite. Inicialmente, se utiliz\u00f3 la base whisper como soluci\u00f3n est\u00e1ndar para grafana, pero con el crecimiento de la base de clientes, graphite dej\u00f3 de ser eficaz, agoteando la capacidad de la subsistema de disco del centro de datos. Despu\u00e9s de eso, se tom\u00f3 la decisi\u00f3n de buscar una soluci\u00f3n m\u00e1s efectiva. Se eligi\u00f3 graphite+clickhouse<\/a><\/noindex>, lo que permiti\u00f3 reducir significativamente la carga en el subsistema de discos y disminuir entre cinco y seis veces el volumen de disco ocupado. A continuaci\u00f3n se presenta un esquema del mecanismo de recopilaci\u00f3n de m\u00e9tricas utilizando graphite+clickhouse (figura 2).<\/p>\n

\n\"Buscamos
\n<\/p>\n

Figura 2. Esquema de recopilaci\u00f3n de m\u00e9tricas<\/em><\/p>\n

El diagrama se obtuvo de la documentaci\u00f3n interna. Muestra el intercambio de datos entre grafana (la interfaz de usuario para monitoreo que utilizamos) y graphite. La obtenci\u00f3n de m\u00e9tricas de la aplicaci\u00f3n es realizada por un software separado \u2013 jmxtrans<\/a><\/noindex>. Este tambi\u00e9n las almacena en graphite.
\nEl sistema 'Web-Consolidaci\u00f3n' tiene una serie de caracter\u00edsticas que crean problemas para la previsi\u00f3n de fallas:<\/p>\n

<\/p>\n

    \n
  1. frecuentemente se produce un cambio de tendencia. Para este sistema de software se emiten diferentes versiones. Cada una de ellas conlleva cambios en la parte program\u00e1tica del sistema. En consecuencia, de esta manera, los desarrolladores influyen directamente en las m\u00e9tricas de este sistema y pueden provocar un cambio de tendencia; <\/li>\n
  2. la particularidad de la implementaci\u00f3n, as\u00ed como los objetivos de uso por parte de los clientes de este sistema, a menudo provocan anomal\u00edas sin una degradaci\u00f3n previa; <\/li>\n
  3. el porcentaje de anomal\u00edas con respecto al conjunto de datos total es bajo (< 5%); <\/li>\n
  4. pueden producirse interrupciones en la obtenci\u00f3n de m\u00e9tricas del sistema. En algunos cortos intervalos de tiempo, el sistema de monitoreo no puede recibir m\u00e9tricas. Por ejemplo, si el servidor est\u00e1 sobrecargado. Para entrenar la red neuronal, esto es cr\u00edtico. Surge la necesidad de llenar los vac\u00edo de manera sint\u00e9tica;<\/li>\n
  5. Los casos con anomal\u00edas suelen ser relevantes solo para un n\u00famero\/mes\/tiempo espec\u00edfico (estacionalidad). Este sistema tiene un reglamento claro sobre su uso por parte de los usuarios. En consecuencia, las m\u00e9tricas son relevantes solo para un tiempo espec\u00edfico. El sistema puede no utilizarse de forma continua, sino solo en ciertos meses: selectivamente dependiendo del a\u00f1o. Surgen situaciones en las que el mismo comportamiento de las m\u00e9tricas en un caso puede llevar a una falla del sistema de software, mientras que en otro no.
    \nPara comenzar, se analizaron los m\u00e9todos de detecci\u00f3n de anomal\u00edas en los datos de monitoreo de sistemas de software. En los art\u00edculos sobre este tema, con bajos porcentajes de anomal\u00edas en relaci\u00f3n con el resto del conjunto de datos, se suele recomendar el uso de redes neuronales. <\/li>\n<\/ol>\n

    <\/p>\n

    La l\u00f3gica principal para buscar anomal\u00edas utilizando datos de redes neuronales se ilustra en la figura 3:<\/p>\n

    \n\"Buscamos
    \n<\/p>\n

    Figura 3. B\u00fasqueda de anomal\u00edas mediante una red neuronal<\/em><\/p>\n

    En el resultado de la predicci\u00f3n o recuperaci\u00f3n de la ventana del flujo actual de m\u00e9tricas, se calcula la desviaci\u00f3n de lo obtenido con el sistema de software en funcionamiento. Si hay una gran diferencia entre las m\u00e9tricas obtenidas del sistema de software y de la red neuronal, se puede concluir sobre la anomal\u00eda del segmento de datos actual. Surge una serie de problemas para el uso de redes neuronales:<\/p>\n

    <\/p>\n

      \n
    1. Para un funcionamiento correcto en modo de flujo, los datos para entrenar modelos de redes neuronales deben incluir \u00fanicamente datos \"normales\"; <\/li>\n
    2. es necesario tener un modelo actualizado para una detecci\u00f3n precisa. El cambio de tendencia y estacionalidad en las m\u00e9tricas puede provocar un gran n\u00famero de activaciones falsas del modelo. Para su actualizaci\u00f3n, es necesario determinar claramente cu\u00e1ndo el modelo es obsoleto. Si actualiza el modelo demasiado tarde o demasiado pronto, es probable que se produzcan muchas activaciones falsas.
      \nTambi\u00e9n hay que tener en cuenta la b\u00fasqueda y prevenci\u00f3n de la aparici\u00f3n frecuente de activaciones falsas. Se supone que aparecer\u00e1n con mayor frecuencia en situaciones an\u00f3malas. Sin embargo, tambi\u00e9n pueden ser consecuencia de un error de la red neuronal debido a la insuficiencia de su entrenamiento. Es necesario minimizar la cantidad de activaciones falsas del modelo. De lo contrario, las falsas predicciones consumir\u00e1n mucho tiempo del administrador, destinado a la verificaci\u00f3n del sistema. Tarde o temprano, esto acabar\u00e1 con que el administrador simplemente dejar\u00e1 de reaccionar a un sistema de monitoreo \"paranoico\".<\/li>\n<\/ol>\n

      <\/p>\n

      Red neuronal recurrente<\/h2>\n

      <\/p>\n

      Para la detecci\u00f3n de anomal\u00edas en series temporales, se puede aplicar una red neuronal recurrente <\/a><\/noindex>con memoria LSTM. El problema es que solo se puede aplicar a series temporales pronosticables. En nuestro caso, no todas las m\u00e9tricas son pronosticables. Se presenta un intento de aplicar RNN LSTM a la serie temporal en la figura 4.<\/p>\n

      \n\"Buscamos
      \n<\/p>\n

      Figura 4. Ejemplo de funcionamiento de una red neuronal recurrente con celdas de memoria LSTM<\/em><\/p>\n

      Como se puede ver en la figura 4, RNN LSTM logr\u00f3 detectar la anomal\u00eda en este per\u00edodo de tiempo. Donde el resultado tiene un alto error de pron\u00f3stico (error medio), realmente ocurri\u00f3 una anomal\u00eda en las m\u00e9tricas. Usar solo RNN LSTM claramente no ser\u00e1 suficiente, ya que se aplica a un n\u00famero limitado de m\u00e9tricas. Se puede utilizar como un m\u00e9todo auxiliar para la detecci\u00f3n de anomal\u00edas. <\/p>\n

      <\/p>\n

      Auto-codificador para la predicci\u00f3n de fallos<\/h2>\n

      <\/p>\n

      Auto-codificador<\/a><\/noindex> \u2013 esencialmente una red neuronal artificial. La capa de entrada es el encoder, la capa de salida es el decoder. La desventaja de todas las redes neuronales de este tipo es que localizan deficiente las anomal\u00edas. Se eligi\u00f3 la arquitectura de un auto-codificador s\u00edncrono.<\/p>\n

      \n\"Buscamos
      \n<\/p>\n

      Figura 5. Ejemplo de funcionamiento del auto-codificador<\/em><\/p>\n

      Los auto-codificadores se entrenan con datos normales y luego encuentran algo an\u00f3malo en los datos que se ingresan al modelo. Justo lo que se necesita para esta tarea. Solo queda elegir cu\u00e1l de los auto-codificadores es adecuado para esta tarea. La forma arquitect\u00f3nica m\u00e1s simple de un auto-codificador es una red neuronal directa y no reversible, que se asemeja mucho a un perceptr\u00f3n multicapa<\/a><\/noindex> (multilayer perceptron, MLP), con una capa de entrada, una capa de salida y una o varias capas ocultas que las conectan.
      \nSin embargo, las diferencias entre los auto-codificadores y los MLP son que en el auto-codificador la capa de salida tiene el mismo n\u00famero de nodos que la de entrada, y que en lugar de entrenarse para predecir un valor objetivo Y dado por una entrada X, el auto-codificador se entrena para reconstruir sus propios X. Por lo tanto, los auto-codificadores son modelos de aprendizaje no supervisados. <\/p>\n

      <\/p>\n

      La tarea del auto-codificador radica en encontrar los \u00edndices temporales r0 \u2026 rn que corresponden a elementos an\u00f3malos en el vector de entrada X. Este efecto se logra mediante la b\u00fasqueda del error cuadr\u00e1tico.<\/p>\n

      \n\"Buscamos <\/p>\n

      Figura 6. Auto-codificador s\u00edncrono<\/em><\/p>\n

      Se eligi\u00f3 una arquitectura s\u00edncrona<\/a><\/noindex>. Sus ventajas: la posibilidad de utilizar modo de procesamiento en flujo y un n\u00famero relativamente menor de par\u00e1metros de la red neuronal en comparaci\u00f3n con otras arquitecturas.<\/p>\n

      <\/p>\n

      Mecanismo para minimizar falsos positivos<\/h2>\n

      <\/p>\n

      Debido a que surgen diversas situaciones no est\u00e1ndar, as\u00ed como la posibilidad de una capacitaci\u00f3n insuficiente de la red neuronal, se ha tomado la decisi\u00f3n de desarrollar un mecanismo para minimizar las falsas alarmas en el modelo de detecci\u00f3n de anomal\u00edas en desarrollo. Este mecanismo se basa en una base de patrones, que clasifica el administrador. <\/p>\n

      <\/p>\n

      Algoritmo de transformaci\u00f3n din\u00e1mica de la l\u00ednea de tiempo<\/a><\/noindex> (El algoritmo DTW, por sus siglas en ingl\u00e9s dynamic time warping) permite encontrar la correspondencia \u00f3ptima entre secuencias temporales. Se aplic\u00f3 por primera vez en el reconocimiento de voz: se utiliz\u00f3 para determinar c\u00f3mo dos se\u00f1ales de voz representan la misma frase pronunciada. Posteriormente, se encontr\u00f3 aplicaci\u00f3n en otras \u00e1reas.<\/p>\n

      <\/p>\n

      El principio b\u00e1sico de minimizaci\u00f3n de falsas alarmas es la recopilaci\u00f3n de una base de est\u00e1ndares mediante un operador que clasifica los casos sospechosos detectados por redes neuronales. Luego, se compara el est\u00e1ndar clasificado con el caso que ha detectado el sistema, y se llega a una conclusi\u00f3n sobre si el caso es una falsa alarma o un verdadero fallo. El algoritmo DTW se utiliza precisamente para comparar dos series temporales. Sin embargo, la clasificaci\u00f3n sigue siendo la herramienta principal de minimizaci\u00f3n. Se supone que, despu\u00e9s de recopilar un gran n\u00famero de casos est\u00e1ndar, el sistema comenzar\u00e1 a preguntar menos al operador debido a la similitud de la mayor\u00eda de los casos y la aparici\u00f3n de casos similares.<\/p>\n

      <\/p>\n

      Como resultado de los m\u00e9todos descritos anteriormente, se construy\u00f3 un programa experimental para la predicci\u00f3n de fallos del sistema \"Web-Consolidaci\u00f3n\". El objetivo de este programa era, utilizando el archivo existente de datos de monitoreo y la informaci\u00f3n sobre fallos que ya han ocurrido, evaluar la eficacia de este enfoque para nuestros sistemas de software. El esquema de funcionamiento del programa se presenta a continuaci\u00f3n, en la figura 7.<\/p>\n

      \n\"Buscamos <\/p>\n

      Figura 7. Esquema de predicci\u00f3n de fallos basado en el an\u00e1lisis del espacio de m\u00e9tricas<\/em><\/p>\n

      En el esquema se pueden identificar dos bloques principales: la b\u00fasqueda de segmentos an\u00f3malos en el flujo de datos de monitoreo (m\u00e9tricas) y el mecanismo de minimizaci\u00f3n de falsas alarmas. Nota: con fines experimentales, los datos se obtienen a trav\u00e9s de una conexi\u00f3n JDBC de la base de datos, en la que se almacenan con graphite.
      \nA continuaci\u00f3n se presenta la interfaz del sistema de monitoreo desarrollado (figura 8).<\/p>\n

      \n\"Buscamos<\/p>\n

      Figura 8. Interfaz del sistema de monitoreo experimental<\/em><\/p>\n

      En la interfaz se muestra el porcentaje de anormalidad basado en las m\u00e9tricas obtenidas. En nuestro caso, la obtenci\u00f3n est\u00e1 siendo simulada. Ya tenemos todos los datos de varias semanas y los estamos cargando gradualmente para verificar el caso de anormalidad que conduce a la falla. En la barra de estado inferior se muestra el porcentaje total de anormalidad de los datos en este momento, que se determina mediante un auto-codificador. Adem\u00e1s, para las m\u00e9tricas pronosticadas se muestra un porcentaje separado, calculado por una RNN LSTM.<\/p>\n

      <\/p>\n

      Ejemplo de detecci\u00f3n de anormalidad en los indicadores de CPU mediante una red neuronal RNN LSTM (figura 9).<\/p>\n

      \n\"Buscamos<\/p>\n

      Figura 9. Detecci\u00f3n RNN LSTM<\/em><\/p>\n

      Un caso bastante simple, en esencia un desecho normal, pero que conduce a la falla del sistema, fue detectado con \u00e9xito por la RNN LSTM. El indicador de anormalidad en este per\u00edodo es del 85 al 95 %, todo lo que est\u00e9 por encima del 80 % (umbral definido experimentalmente) se considera una anormalidad.
      \nEjemplo de detecci\u00f3n de anormalidad cuando el sistema no pudo iniciarse despu\u00e9s de la actualizaci\u00f3n. Esta situaci\u00f3n es detectada por el auto-codificador (figura 10).<\/p>\n

      \n\"Buscamos<\/p>\n

      Figura 10. Ejemplo de detecci\u00f3n por el auto-codificador<\/em><\/p>\n

      Como se puede ver en la figura, PermGen se qued\u00f3 en un solo nivel. El auto-codificador consider\u00f3 esto extra\u00f1o, ya que no hab\u00eda visto nada parecido anteriormente. Aqu\u00ed, la anormalidad se mantiene al 100 % hasta que el sistema vuelve a un estado operativo. La anormalidad se refleja en todas las m\u00e9tricas. Como se mencion\u00f3 anteriormente, el auto-codificador no puede localizar anomal\u00edas. Se espera que el operador realice esta funci\u00f3n en estas situaciones.<\/p>\n

      <\/p>\n

      Conclusi\u00f3n<\/h2>\n

      <\/p>\n

      El PC \"Web-Consolidaci\u00f3n\" se ha estado desarrollando durante varios a\u00f1os. El sistema se encuentra en un estado bastante estable y el n\u00famero de incidentes registrados es bajo. Sin embargo, se han logrado identificar anomal\u00edas que llevan a fallas de 5 a 10 minutos antes de que ocurra la falla. En algunos casos, la alerta de falla de manera anticipada podr\u00eda haber ayudado a ahorrar el tiempo programado destinado a la realizaci\u00f3n de trabajos de \"reparaci\u00f3n\".<\/p>\n

      <\/p>\n

      En los experimentos que se han podido realizar, a\u00fan es pronto para llegar a conclusiones definitivas. En este momento, los resultados son contradictorios. Por un lado, se puede ver que los algoritmos basados en redes neuronales son capaces de encontrar anomal\u00edas '\u00fatiles'. Por otro lado, sigue existiendo un gran porcentaje de falsos positivos, y no todas las anomal\u00edas que un especialista calificado identifica pueden ser detectadas por la red neuronal. Entre las desventajas se puede mencionar que, en este momento, la red neuronal requiere aprendizaje supervisado para funcionar adecuadamente.<\/p>\n

      <\/p>\n

      Para el desarrollo futuro del sistema de predicci\u00f3n de fallos y para llevarlo a un estado satisfactorio, se pueden prever varias v\u00edas. Un an\u00e1lisis m\u00e1s detallado de los casos con anomal\u00edas que conducen a fallos, complementando as\u00ed la lista de m\u00e9tricas importantes que afectan significativamente el estado del sistema y eliminando las que no tienen impacto en \u00e9l. Adem\u00e1s, si seguimos esta direcci\u00f3n, se pueden hacer intentos de especializar los algoritmos espec\u00edficamente para nuestros casos de anomal\u00edas que conducen a fallos. Tambi\u00e9n hay otro camino: la mejora de las arquitecturas de las redes neuronales y, gracias a ello, el aumento de la precisi\u00f3n de las detecciones con una reducci\u00f3n del tiempo de aprendizaje.<\/p>\n

      <\/p>\n

      Quiero expresar mi agradecimiento a los colegas que me ayudaron con la redacci\u00f3n y el mantenimiento de la actualidad de este art\u00edculo: V\u00edctor Verbitsky<\/a><\/noindex> y Sergey Finogenov.<\/p>\n

      Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

      \u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c \u0442\u0440\u0435\u0431\u0443\u0435\u0442 \u0431\u043e\u043b\u044c\u0448\u043e\u0433\u043e \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044f \u043a \u043e\u0442\u043a\u0430\u0437\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0441\u0442\u0438 \u043a\u043e\u043d\u0435\u0447\u043d\u043e\u0433\u043e \u043f\u0440\u043e\u0434\u0443\u043a\u0442\u0430, \u0430 \u0442\u0430\u043a\u0436\u0435 \u0431\u044b\u0441\u0442\u0440\u043e\u0433\u043e \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438, \u0435\u0441\u043b\u0438 \u043e\u043d\u0438 \u0432\u0441\u0435-\u0442\u0430\u043a\u0438 \u0441\u043b\u0443\u0447\u0430\u044e\u0442\u0441\u044f. \u041c\u043e\u043d\u0438\u0442\u043e\u0440\u0438\u043d\u0433, \u043a\u043e\u043d\u0435\u0447\u043d\u043e \u0436\u0435, \u043f\u043e\u043c\u043e\u0433\u0430\u0435\u0442 \u0440\u0435\u0430\u0433\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u043d\u0430 \u043e\u0442\u043a\u0430\u0437\u044b \u0438 \u0441\u0431\u043e\u0438 \u044d\u0444\u0444\u0435\u043a\u0442\u0438\u0432\u043d\u0435\u0435 \u0438 \u0431\u044b\u0441\u0442\u0440\u0435\u0435, \u043d\u043e \u043d\u0435\u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e. \u0412\u043e-\u043f\u0435\u0440\u0432\u044b\u0445, \u043e\u0447\u0435\u043d\u044c \u0441\u043b\u043e\u0436\u043d\u043e \u0443\u0441\u043b\u0435\u0434\u0438\u0442\u044c \u0437\u0430 \u0431\u043e\u043b\u044c\u0448\u0438\u043c \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e\u043c \u0441\u0435\u0440\u0432\u0435\u0440\u043e\u0432 \u2013 \u043d\u0435\u043e\u0431\u0445\u043e\u0434\u0438\u043c\u043e \u0431\u043e\u043b\u044c\u0448\u043e\u0435 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u043e \u043b\u044e\u0434\u0435\u0439. \u0412\u043e-\u0432\u0442\u043e\u0440\u044b\u0445, \u043d\u0443\u0436\u043d\u043e \u0445\u043e\u0440\u043e\u0448\u043e \u043f\u043e\u043d\u0438\u043c\u0430\u0442\u044c, \u043a\u0430\u043a […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53531","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Buscamos anomal\u00edas y predecimos fallos con redes neuronales | ProHoster","description":"Desarrollo industrial.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0418\u0449\u0435\u043c \u0430\u043d\u043e\u043c\u0430\u043b\u0438\u0438 \u0438 \u043f\u0440\u0435\u0434\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u0435\u043c \u0441\u0431\u043e\u0438 \u0441 \u043f\u043e\u043c\u043e\u0449\u044c\u044e \u043d\u0435\u0439\u0440\u043e\u0441\u0435\u0442\u0435\u0439 | ProHoster","og:description":"\u041f\u0440\u043e\u043c\u044b\u0448\u043b\u0435\u043d\u043d\u0430\u044f \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0430.","og:url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-12-03T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:26+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53531","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 07:46:24","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:23:55","updated":"2026-01-24 07:46:24","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/53531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=53531"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/53531\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=53531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=53531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=53531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}