{"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\/it\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","title":{"rendered":"Cerchiamo anomalie e prevediamo guasti utilizzando reti neurali","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Cerchiamo<\/p>\n

<\/p>\n

Lo sviluppo industriale di sistemi software richiede grande attenzione alla resilienza del prodotto finale, nonch\u00e9 una rapida reazione agli errori e ai guasti, se dovessero verificarsi. Il monitoraggio, naturalmente, aiuta a rispondere agli errori e ai guasti in modo pi\u00f9 efficiente e veloce, ma non \u00e8 sufficiente. Innanzitutto, \u00e8 molto difficile tenere traccia di un gran numero di server, servono molte persone. In secondo luogo, \u00e8 importante avere una buona comprensione di come \u00e8 strutturata l'applicazione, per poter prevedere il suo stato. Di conseguenza, ci vogliono molte persone con una buona comprensione dei sistemi che stiamo sviluppando, delle loro metriche e peculiarit\u00e0. Supponiamo che, anche se si trova un numero sufficiente di persone disposte a farlo, ci vorr\u00e0 anche molto tempo per addestrarli.<\/p>\n

<\/p>\n

Cosa fare allora? Qui ci viene in aiuto l'intelligenza artificiale. L'articolo parler\u00e0 di manutenzione predittiva<\/a><\/noindex> (predictive maintenance). Questo approccio sta guadagnando popolarit\u00e0. Sono stati scritti molti articoli, anche su Habr. Grandi aziende stanno gi\u00e0 utilizzando questo approccio per mantenere operativi i propri server. Dopo aver esaminato un gran numero di articoli, abbiamo deciso di provare ad applicare questo approccio. Cosa ne \u00e8 venuto fuori? <\/p>\n

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

Introduzione<\/h2>\n

<\/p>\n

Un sistema software sviluppato entrer\u00e0 in esercizio prima o poi. \u00c8 importante per l'utente che il sistema funzioni senza interruzioni. Se dovesse verificarsi una situazione straordinaria, deve essere risolta con il minimo ritardo. <\/p>\n

<\/p>\n

Per semplificare il supporto tecnico del sistema software, soprattutto se ci sono molti server, di solito si utilizzano programmi di monitoraggio, che raccolgono metriche dal sistema software in funzione, offrono la possibilit\u00e0 di diagnosticare il suo stato e aiutano a determinare cosa ha causato il guasto. Questo processo \u00e8 chiamato monitoraggio del sistema software.<\/p>\n

\n\"Cerchiamo<\/p>\n

Figura 1. Interfaccia per il monitoraggio grafana<\/em><\/p>\n

Le metriche sono vari indicatori di un sistema software, dell'ambiente in cui esegue o della macchina fisica su cui \u00e8 in esecuzione, con un timestamp che indica il momento in cui le metriche sono state acquisite. Nell'analisi statica, i dati metrici vengono denominati serie temporali. Per monitorare lo stato del sistema software, le metriche vengono visualizzate sotto forma di grafici: sull'asse X \u2013 il tempo, mentre sull'asse Y \u2013 i valori (figura 1). Un sistema software in funzione pu\u00f2 fornire diverse migliaia di metriche (da ogni nodo). Queste formano uno spazio metrico (serie temporali multidimensionali). <\/p>\n

<\/p>\n

Poich\u00e9 nei sistemi software complessi vengono registrate un gran numero di metriche, il monitoraggio manuale diventa un compito difficile. Per ridurre il volume dei dati analizzati dall'amministratore, gli strumenti di monitoraggio contengono strumenti per l'individuazione automatica di potenziali problemi. Ad esempio, \u00e8 possibile configurare un trigger che scatta nel caso in cui lo spazio libero su disco scenda al di sotto di una soglia specificata. \u00c8 anche possibile diagnosticare automaticamente un arresto del server o un rallentamento critico delle prestazioni. Nella pratica, gli strumenti di monitoraggio riescono a rilevare abbastanza bene i guasti gi\u00e0 verificatisi o a identificare sintomi semplici di guasti futuri, ma in generale la previsione di un possibile guasto rimane una sfida difficile. La previsione tramite analisi manuale delle metriche richiede l'intervento di specialisti qualificati ed \u00e8 poco produttiva. La maggior parte dei guasti potenziali pu\u00f2 rimanere inosservata.<\/p>\n

<\/p>\n

Negli ultimi tempi, tra le grandi aziende IT che sviluppano software, sta guadagnando sempre pi\u00f9 popolarit\u00e0 il cosiddetto servizio di manutenzione predittiva dei sistemi software. L'essenza di questo approccio consiste nell'individuare i malfunzionamenti che portano a una degradazione del sistema nelle fasi iniziali, prima che si verifichi un guasto, utilizzando l'intelligenza artificiale. Questo approccio non esclude completamente il monitoraggio manuale del sistema, ma lo considera un supporto al processo di monitoraggio nel complesso. <\/p>\n

<\/p>\n

Lo strumento principale per implementare la manutenzione predittiva \u00e8 il compito di ricerca di anomali nelle serie temporali, poich\u00e9 quando si verifica un'anomalia<\/strong> nei dati c'\u00e8 una grande probabilit\u00e0 che, dopo un certo tempo si verificher\u00e0 un errore o un guasto<\/strong>. Un'anomalia \u00e8 una deviazione nei parametri di un sistema software, come il riconoscimento di una degradazione della velocit\u00e0 di esecuzione di un tipo di richiesta o una diminuzione del numero medio di richieste gestite a fronte di un livello costante di sessioni client.<\/p>\n

<\/p>\n

Il compito di cercare anomalie nei sistemi software ha le sue peculiarit\u00e0. In teoria, per ogni sistema software \u00e8 necessaria la creazione o l'adattamento dei metodi esistenti, poich\u00e9 la ricerca di anomalie dipende molto dai dati in cui viene effettuata, e i dati dei sistemi software variano notevolmente a seconda degli strumenti di realizzazione, fino a che tipo di macchina di calcolo \u00e8 in uso.<\/p>\n

<\/p>\n

Metodi di ricerca di anomalie nella previsione dei guasti dei sistemi software<\/h2>\n

<\/p>\n

Prima di tutto, bisogna dire che l'idea della previsione dei guasti \u00e8 stata ispirata dall'articolo \u00abMachine Learning nel monitoraggio IT\u00bb<\/a><\/noindex>. Per testare l'efficacia dell'approccio di ricerca automatica delle anomalie \u00e8 stato scelto il sistema software \u00abWeb-Consolidation\u00bb, uno dei progetti dell'azienda NPO \u00abKrista\u00bb. In precedenza, per questo sistema era stato effettuato un monitoraggio manuale basato sui metriche ricevute. Poich\u00e9 il sistema \u00e8 piuttosto complesso, vengono estratte numerose metriche: parametri della JVM (carico del garbage collector), parametri del sistema operativo su cui viene eseguito il codice (memoria virtuale, % di utilizzo della CPU), parametri di rete (carico della rete), del server stesso (carico della CPU, della memoria), metriche di wildfly e metriche proprie dell'applicazione su tutti i sottosistemi critici. <\/p>\n

<\/p>\n

Tutte le metriche vengono estratte dal sistema tramite graphite. Inizialmente \u00e8 stato utilizzato il database whisper come soluzione standard per grafana, ma con la crescita della base clienti graphite ha smesso di essere sufficientemente performante, esaurendo la capacit\u00e0 del sistema di archiviazione del centro dati. Dopo ci\u00f2, \u00e8 stata presa la decisione di cercare una soluzione pi\u00f9 efficace. La scelta \u00e8 ricaduta su graphite+clickhouse<\/a><\/noindex>, il che ha permesso di ridurre notevolmente il carico sul sistema di archiviazione e di ridurre il volume di archiviazione occupato di cinque-sei volte. Di seguito viene presentato lo schema del meccanismo di raccolta delle metriche tramite graphite+clickhouse (figura 2).<\/p>\n

\n\"Cerchiamo
\n<\/p>\n

Figura 2. Schema di estrazione delle metriche<\/em><\/p>\n

Lo schema \u00e8 stato preso dalla documentazione interna. Mostra lo scambio di dati tra grafana (interfaccia utente per il monitoraggio che utilizziamo) e graphite. La raccolta delle metriche dall'applicazione \u00e8 effettuata da un software separato \u2013 jmxtrans<\/a><\/noindex>. Questo quindi le archivia in graphite.
\nIl sistema \u00abWeb-Consolidation\u00bb presenta una serie di caratteristiche che creano problemi nella previsione dei guasti:<\/p>\n

<\/p>\n

    \n
  1. c'\u00e8 spesso un cambiamento di trend. Per questo sistema software vengono rilasciate diverse versioni. Ognuna di esse comporta modifiche nella parte software del sistema. Pertanto, in questo modo gli sviluppatori influenzano direttamente le metriche di questo sistema e possono indurre un cambiamento di trend; <\/li>\n
  2. la peculiarit\u00e0 dell'implementazione, cos\u00ec come gli obiettivi di utilizzo da parte dei clienti di questo sistema, spesso evocano anomalie senza una precedente degradazione; <\/li>\n
  3. la percentuale di anomalie rispetto all'intero set di dati \u00e8 bassa (< 5%); <\/li>\n
  4. possono verificarsi interruzioni nella ricezione delle metriche dal sistema. In alcuni brevi intervalli di tempo, il sistema di monitoraggio non riesce a ottenere le metriche. Ad esempio, se il server \u00e8 sovraccarico. Per l'addestramento della rete neurale, questo \u00e8 critico. Si rende necessaria la sintesi per riempire i gap;<\/li>\n
  5. I casi di anomalie sono spesso rilevanti solo per un numero\/mese\/tempo specifico (stagionalit\u00e0). Questo sistema ha un regolamento chiaro per l'utilizzo da parte degli utenti. Pertanto, le metriche sono pertinenti solo per un periodo di tempo specifico. Il sistema pu\u00f2 non essere utilizzato in modo costante, ma solo in alcuni mesi: in modo selettivo a seconda dell'anno. Si presentano situazioni in cui lo stesso comportamento delle metriche in un caso pu\u00f2 portare al guasto del sistema software, mentre in un altro no.
    \nInizialmente, sono stati analizzati i metodi per la rilevazione delle anomalie nei dati di monitoraggio dei sistemi software. Negli articoli su questo tema, quando le anomalie rappresentano una bassa percentuale rispetto al resto del set di dati, si propone spesso di utilizzare reti neurali. <\/li>\n<\/ol>\n

    <\/p>\n

    La logica principale per la ricerca di anomalie tramite i dati delle reti neurali \u00e8 illustrata nella figura 3:<\/p>\n

    \n\"Cerchiamo
    \n<\/p>\n

    Figura 3. Ricerca di anomalie tramite rete neurale<\/em><\/p>\n

    Il risultato della previsione o del ripristino della finestra dell'attuale flusso di metriche calcola la deviazione rispetto ai dati ricevuti da un sistema software funzionante. In caso di grande differenza tra le metriche ricevute dal sistema software e la rete neurale, si pu\u00f2 concludere che esiste un'anomalia nel segmento dati attuale. Si presenta una serie di problemi per l'utilizzo delle reti neurali:<\/p>\n

    <\/p>\n

      \n
    1. per un corretto funzionamento in modalit\u00e0 streaming, i dati per l'addestramento dei modelli delle reti neurali devono includere solo dati \"normali\"; <\/li>\n
    2. \u00e8 necessario avere un modello attuale per una corretta rilevazione. Un cambiamento di trend e stagionalit\u00e0 nelle metriche pu\u00f2 causare un elevato numero di falsi positivi nel modello. Per aggiornarlo, \u00e8 necessario definire chiaramente il momento in cui il modello diventa obsoleto. Se il modello viene aggiornato troppo tardi o troppo presto, \u00e8 probabile che ci siano troppi falsi positivi.
      \nInoltre, non bisogna dimenticare di cercare e prevenire il verificarsi frequente di falsi positivi. Si presume che essi si verifichino pi\u00f9 spesso in situazioni anomale. Tuttavia, potrebbero anche dipendere da errori della rete neurale a causa di un'istruzione insufficiente. \u00c8 necessario minimalizzare il numero di falsi positivi nel modello. In caso contrario, le previsioni errate richiederanno molto tempo all'amministratore, destinato al controllo del sistema. Prima o poi, l'amministratore smetter\u00e0 di reagire a un sistema di monitoraggio \"paranoico\".<\/li>\n<\/ol>\n

      <\/p>\n

      Rete neurale ricorrente<\/h2>\n

      <\/p>\n

      Per rilevare anomalie nelle serie temporali \u00e8 possibile applicare una rete neurale ricorrente <\/a><\/noindex>con memoria LSTM. Il problema \u00e8 che essa pu\u00f2 essere utilizzata solo per le serie temporali prevedibili. Nel nostro caso, non tutte le metriche sono prevedibili. Il tentativo di applicare RNN LSTM a una serie temporale \u00e8 rappresentato nella figura 4.<\/p>\n

      \n\"Cerchiamo
      \n<\/p>\n

      Figura 4. Esempio di funzionamento di una rete neurale ricorrente con celle di memoria LSTM<\/em><\/p>\n

      Come si pu\u00f2 vedere dalla figura 4, la RNN LSTM \u00e8 riuscita a gestire la ricerca di anomalie in questo intervallo di tempo. L\u00ec dove il risultato ha un alto errore di previsione (errore medio), si \u00e8 effettivamente verificata un'anomalia nei dati. L'uso di una sola RNN LSTM sar\u00e0 chiaramente insufficiente, poich\u00e9 \u00e8 applicabile a un numero limitato di metriche. Si pu\u00f2 utilizzare come metodo ausiliario per la ricerca di anomalie. <\/p>\n

      <\/p>\n

      Autoencoder per la previsione dei guasti<\/h2>\n

      <\/p>\n

      Autoencoder<\/a><\/noindex> \u2013 in sostanza una rete neurale artificiale. Il livello di input \u2013 encoder, il livello di output \u2013 decoder. Lo svantaggio di tutte le reti neurali di questo tipo \u00e8 che localizzano male le anomalie. \u00c8 stata scelta un'architettura di autoencoder sincrono.<\/p>\n

      \n\"Cerchiamo
      \n<\/p>\n

      Figura 5. Esempio di funzionamento dell'autoencoder<\/em><\/p>\n

      Gli autoencoder si addestrano su dati normali e poi trovano qualcosa di anomalo nei dati forniti al modello. Proprio ci\u00f2 di cui abbiamo bisogno per questo compito. Resta solo da scegliere quale dei diversi autoencoder si adatti a questa esigenza. La forma architettonicamente pi\u00f9 semplice di un autoencoder \u00e8 una rete neurale feedforward che assomiglia molto a un percettrone multilivello<\/a><\/noindex> (multilayer perceptron, MLP), con un livello di input, un livello di output e uno o pi\u00f9 livelli nascosti che li collegano.
      \nTuttavia, le differenze tra gli autoencoder e il MLP consistono nel fatto che nell'autoencoder il livello di output ha lo stesso numero di nodi del livello di input e che invece di essere addestrato per prevedere il valore target Y dato l'input X, l'autoencoder viene addestrato a ricostruire i propri X. Pertanto, gli autoencoder sono modelli di apprendimento non supervisionato. <\/p>\n

      <\/p>\n

      Il compito dell'autoencoder \u00e8 quello di trovare gli indici temporali r0 \u2026 rn corrispondenti agli elementi anomali nel vettore di input X. Questo effetto si ottiene attraverso la ricerca dell'errore quadratico.<\/p>\n

      \n\"Cerchiamo <\/p>\n

      Figura 6. Autoencoder sincrono<\/em><\/p>\n

      Per l'autoencoder \u00e8 stata scelta un'architettura sincrona<\/a><\/noindex>. I suoi vantaggi: possibilit\u00e0 di utilizzare la modalit\u00e0 di elaborazione in streaming e un numero relativamente inferiore di parametri della rete neurale rispetto ad altre architetture.<\/p>\n

      <\/p>\n

      Il meccanismo di minimizzazione dei falsi allarmi<\/h2>\n

      <\/p>\n

      A causa del verificarsi di diverse situazioni straordinarie, cos\u00ec come della possibilit\u00e0 di un'adeguata formazione della rete neurale, \u00e8 stata presa la decisione di sviluppare un meccanismo per minimizzare i falsi allarmi per il modello di rilevamento delle anomalie in fase di sviluppo. Questo meccanismo si basa su una base di modelli che viene classificata dall'amministratore. <\/p>\n

      <\/p>\n

      Algoritmo di trasformazione dinamica della scala temporale<\/a><\/noindex> (algoritmo DTW, dall'inglese dynamic time warping) consente di trovare la corrispondenza ottimale tra sequenze temporali. \u00c8 stato applicato per la prima volta nel riconoscimento vocale: utilizzato per determinare come due segnali vocali rappresentano la stessa frase pronunciata. In seguito, \u00e8 stato trovato impiego in altri settori.<\/p>\n

      <\/p>\n

      Il principio fondamentale per minimizzare i falsi allarmi \u00e8 raccogliere una base di riferimenti attraverso l'operatore, che classifica i casi sospetti individuati tramite reti neurali. Successivamente, si confronta il modello classificato con il caso rilevato dal sistema, e si trae una conclusione sulla sua appartenenza a un falso allerta o a un guasto. Proprio per il confronto di due serie temporali si utilizza l'algoritmo DTW. Lo strumento principale per la minimizzazione rimane comunque la classificazione. Si presume che dopo aver raccolto un gran numero di casi di riferimento, il sistema inizier\u00e0 a richiedere meno l'intervento dell'operatore a causa della somiglianza della maggior parte dei casi e della ricorrenza di situazioni affini.<\/p>\n

      <\/p>\n

      Alla fine, sulla base dei metodi descritti sopra, \u00e8 stato sviluppato un programma sperimentale per la previsione dei guasti del sistema \"Web-Consulenza\". L'obiettivo di questo programma era valutare l'efficacia di questo approccio per i nostri sistemi software utilizzando l'archivio di dati di monitoraggio esistente e le informazioni sui guasti gi\u00e0 avvenuti. Lo schema di funzionamento del programma \u00e8 mostrato di seguito nella figura 7.<\/p>\n

      \n\"Cerchiamo <\/p>\n

      Figura 7. Schema di previsione dei guasti basato sull'analisi dello spazio delle metriche<\/em><\/p>\n

      Nello schema si possono distinguere due blocchi principali: la ricerca di segmenti temporali anomali nel flusso di dati di monitoraggio (metriche) e il meccanismo di minimizzazione dei falsi allarmi. Nota: per scopi sperimentali, i dati vengono ottenuti tramite connessione JDBC da un database in cui vengono salvati tramite graphite.
      \nDi seguito \u00e8 presentata l'interfaccia del sistema di monitoraggio sviluppato (figura 8).<\/p>\n

      \n\"Cerchiamo<\/p>\n

      Figura 8. Interfaccia del sistema di monitoraggio sperimentale<\/em><\/p>\n

      Nell'interfaccia viene visualizzata la percentuale di anomalia per le metriche ricevute. Nel nostro caso, il ricevimento \u00e8 simulato. Abbiamo gi\u00e0 tutti i dati di diverse settimane e li carichiamo gradualmente per verificare un caso di anomalia che porta a un guasto. Nella barra di stato in basso viene mostrata la percentuale complessiva di anomalia dei dati in quel momento, che \u00e8 determinata tramite un auto-codificatore. Inoltre, per le metriche previste viene visualizzata una percentuale separata, calcolata da RNN LSTM.<\/p>\n

      <\/p>\n

      Esempio di rilevamento di anomalia nei parametri della CPU utilizzando la rete neurale RNN LSTM (figura 9).<\/p>\n

      \n\"Cerchiamo<\/p>\n

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

      Un caso piuttosto semplice, essenzialmente un comune outlier, ma che porta a un guasto del sistema, \u00e8 stato calcolato con successo utilizzando RNN LSTM. Il valore di anomalia in questo intervallo di tempo \u00e8 compreso tra l'85 e il 95%; tutto ci\u00f2 che supera l'80% (soglia stabilita sperimentalmente) \u00e8 considerato un'anomalia.
      \nEsempio di rilevamento di anomalia, quando il sistema non \u00e8 riuscito a caricarsi dopo un aggiornamento. Questa situazione viene rilevata dall'auto-codificatore (figura 10).<\/p>\n

      \n\"Cerchiamo<\/p>\n

      Figura 10. Esempio di rilevamento da parte dell'auto-codificatore<\/em><\/p>\n

      Come si pu\u00f2 vedere dalla figura, PermGen \u00e8 rimasto a un livello costante. L'auto-codificatore ha considerato questo strano, poich\u00e9 non aveva mai visto nulla di simile in precedenza. Qui, l'anomalia rimane al 100% fino al ritorno del sistema in uno stato operativo. L'anomalia si riflette su tutte le metriche. Come detto in precedenza, l'auto-codificatore non \u00e8 in grado di localizzare le anomalie. L'operatore \u00e8 incaricato di svolgere questa funzione in queste situazioni.<\/p>\n

      <\/p>\n

      Conclusione<\/h2>\n

      <\/p>\n

      Il PC \"Web-Consolidazione\" \u00e8 in fase di sviluppo da diversi anni. Il sistema \u00e8 in uno stato sufficientemente stabile e il numero di incidenti registrati \u00e8 ridotto. Tuttavia, \u00e8 stato possibile individuare anomalie che portano a guasti da 5 a 10 minuti prima dell'insorgere del guasto. In alcuni casi, il preavviso di guasto avrebbe potuto aiutare a risparmiare tempo programmato, dedicato alle operazioni di \"riparazione\".<\/p>\n

      <\/p>\n

      Per gli esperimenti condotti, \u00e8 ancora prematuro trarre conclusioni definitive. Al momento, i risultati sono contraddittori. Da un lato, \u00e8 evidente che gli algoritmi basati su reti neurali sono in grado di identificare anomalie \"utili\". Dall'altro lato, persiste un alto tasso di falsi positivi, e non tutte le anomalie individuate da un esperto qualificato possono essere rilevate dalla rete neurale. Tra i punti negativi si pu\u00f2 anche menzionare che attualmente la rete neurale richiede un apprendimento supervisionato per funzionare correttamente.<\/p>\n

      <\/p>\n

      Per lo sviluppo futuro del sistema di previsione dei guasti e per portarlo a uno stato soddisfacente, si possono prevedere diverse strade. Un'analisi pi\u00f9 dettagliata dei casi di anomalie che portano a un guasto, che consente di ampliare l'elenco delle metriche importanti che influenzano notevolmente lo stato del sistema, scartando quelle superflue, \u00e8 una di queste. Inoltre, perseguendo questa direzione, si possono tentare specializzazioni degli algoritmi specificamente per i nostri casi di anomalie che portano ai guasti. C'\u00e8 anche un'altra possibilit\u00e0: migliorare le architetture delle reti neurali e aumentare cos\u00ec la precisione delle rilevazioni riducendo i tempi di apprendimento.<\/p>\n

      <\/p>\n

      Esprimo la mia gratitudine ai colleghi che mi hanno assistito nella scrittura e nell'aggiornamento di questo articolo: Viktor Verbitskiy<\/a><\/noindex> e Sergey Finogenov.<\/p>\n

      Fonte: 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\udd47Cerchiamo anomalie e prevediamo guasti con le reti neurali | ProHoster","description":"Sviluppo industriale.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/53531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=53531"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/53531\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=53531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=53531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=53531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}