{"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\/da\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","title":{"rendered":"Finder anomalier og forudser fejl med neurale netv\u00e6rk","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Finder<\/p>\n

<\/p>\n

Industriel udvikling af softwaresystemer kr\u00e6ver stor opm\u00e6rksomhed p\u00e5 den endelige produkts fejltolerance samt hurtig reaktion p\u00e5 fejl og nedbrud, hvis de skulle opst\u00e5. Overv\u00e5gning hj\u00e6lper naturligvis med at reagere p\u00e5 fejl og nedbrud mere effektivt og hurtigere, men det er ikke tilstr\u00e6kkeligt. For det f\u00f8rste er det meget sv\u00e6rt at holde styr p\u00e5 et stort antal servere \u2013 der kr\u00e6ves en stor m\u00e6ngde folk. For det andet er det n\u00f8dvendigt at have en god forst\u00e5else af, hvordan applikationen fungerer, for at kunne forudsige dens tilstand. F\u00f8lgelig kr\u00e6ves der mange personer, der har en god forst\u00e5else af de systemer, vi udvikler, deres indikatorer og karakteristika. Antag, at det er muligt at finde et tilstr\u00e6kkeligt antal folk, der \u00f8nsker at besk\u00e6ftige sig med dette, s\u00e5 kr\u00e6ves der stadig en god m\u00e6ngde tid til at uddanne dem.<\/p>\n

<\/p>\n

Hvad skal vi s\u00e5 g\u00f8re? Her kommer kunstig intelligens os til hj\u00e6lp. Denne artikel handler om pr\u00e6diktiv vedligeholdelse<\/a><\/noindex> (predictive maintenance). Denne tilgang vinder aktivt frem. Der er skrevet et stort antal artikler, herunder p\u00e5 Habr\u00e9. Store virksomheder bruger allerede denne tilgang til at st\u00f8tte deres serveres driftssikkerhed. Efter at have gennemg\u00e5et et stort antal artikler, besluttede vi os for at pr\u00f8ve at anvende denne tilgang. Hvad kom der ud af det? <\/p>\n

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

Introduktion<\/h2>\n

<\/p>\n

Det udviklede softwaresystem g\u00e5r f\u00f8r eller siden i drift. Det er vigtigt for brugeren, at systemet fungerer uden nedbrud. Hvis en n\u00f8dsituation alligevel opst\u00e5r, skal den rettes med minimale forsinkelser. <\/p>\n

<\/p>\n

For at forenkle den tekniske support af softwaresystemet, is\u00e6r n\u00e5r der er mange servere, anvendes der normalt overv\u00e5gningsprogrammer, der indsamler m\u00e5linger fra det k\u00f8rende softwaresystem, giver mulighed for at diagnosticere dets tilstand og hj\u00e6lper med at bestemme, hvad der pr\u00e6cist for\u00e5rsagede nedbruddet. Denne proces kaldes overv\u00e5gning af softwaresystemet.<\/p>\n

\n\"Finder<\/p>\n

Figur 1. Interface til overv\u00e5gning grafana<\/em><\/p>\n

Metrikker er forskellige m\u00e5lemetoder for software-systemet, omgivelserne det k\u00f8rer i, eller den fysiske computerenhed, som systemet er hostet p\u00e5, med et tidsstempel for det tidspunkt, hvor m\u00e5lingerne blev indsamlet. I den statiske analyse kaldes m\u00e5lingsdataene for tidsserier. For at overv\u00e5ge tilstanden af software-systemet pr\u00e6senteres metrikkerne i grafisk form: med tid p\u00e5 X-aksen og v\u00e6rdier p\u00e5 Y-aksen (figur 1). Et fungerende software-system kan generere flere tusinde metrikker (fra hver node). De danner et metrikrum (flerdimensionale tidsserier). <\/p>\n

<\/p>\n

Da komplekse software-systemer genererer et stort antal metrikker, bliver manuel overv\u00e5gning en udfordrende opgave. For at reducere m\u00e6ngden af data, som administratoren skal analysere, indeholder overv\u00e5gningsv\u00e6rkt\u00f8jer funktioner til automatisk at opdage mulige problemer. For eksempel kan man indstille en trigger, der aktiveres, n\u00e5r det ledige diskplads falder til et angivet niveau. Man kan ogs\u00e5 automatisk diagnosticere serverstop eller kritisk nedsat servicerate. I praksis klarer overv\u00e5gningsv\u00e6rkt\u00f8jer sig godt med at opdage allerede indtrufne fejl eller identificere enkle symptomer p\u00e5 fremtidige fejl, men generelt forbliver forudsigelsen af mulige nedbrud en stor udfordring for dem. Forudsigelse gennem manuel analysere af metrikker kr\u00e6ver kvalificerede specialister og er ineffektiv. De fleste potentielle fejlfunktioner kan forblive uopdagede.<\/p>\n

<\/p>\n

For tiden vinder den s\u00e5kaldte predictive maintenance af software-systemer stadig mere popularitet blandt store IT-virksomheder, der udvikler software. Essensen af denne tilgang er at finde problemer, der f\u00f8rer til systemdegradering p\u00e5 et tidligt stadium, f\u00f8r det fejler, ved hj\u00e6lp af kunstig intelligens. Denne tilgang udelukker ikke fuldst\u00e6ndig manuel overv\u00e5gning af systemet, men fungerer som et supplement til den overordnede overv\u00e5gningsproces. <\/p>\n

<\/p>\n

Hovedv\u00e6rkt\u00f8jet til implementering af predictive maintenance er opgaven med at finde anomalier i tidsserier, da n\u00e5r der opst\u00e5r en anomali<\/strong> i dataene, er der stor sandsynlighed for, at der efter noget tid der vil opst\u00e5 en fejl eller nedbrud<\/strong>. En anomali er en afvigelse i indikatorerne for det softwarebaserede system, s\u00e5som opdageren af nedgang i responstiden for en bestemt type foresp\u00f8rgsel eller et fald i det gennemsnitlige antal h\u00e5ndterede anmodninger ved et konstant niveau af kundesessioner.<\/p>\n

<\/p>\n

Opgaven med at finde anomalier i softwarebaserede systemer har sin egen specifik. I teorien kr\u00e6ver hver softwarebaseret system udvikling eller tilpasning af de eksisterende metoder, da anomalidetektering er meget afh\u00e6ngig af de data, hvori den udf\u00f8res, og dataene for softwarebaserede systemer varierer meget afh\u00e6ngigt af implementeringsv\u00e6rkt\u00f8jerne, helt ned til hvilken beregningsmaskine den k\u00f8rer p\u00e5.<\/p>\n

<\/p>\n

Metoder til opdagelse af anomalier ved forudsigelse af fejl i softwarebaserede systemer<\/h2>\n

<\/p>\n

F\u00f8rst og fremmest er det v\u00e6rd at n\u00e6vne, at ideen om forudsigelse af fejl blev inspireret af artiklen \u00abMaskinl\u00e6ring i IT-overv\u00e5gning\u00bb<\/a><\/noindex>. For at teste effektiviteten af tilgangen med automatisk anomaliopdagelse blev det softwarebaserede system \u00abWeb-Konsolidering\u00bb valgt, som er et af projekterne fra NPO \u00abKrista\u00bb. Tidligere blev der udf\u00f8rt manuel overv\u00e5gning baseret p\u00e5 de modtagne metrikker. Da systemet er ret komplekst, indsamles der et stort antal metrikker for det: JVM-metrikker (garbage collection-belastning), OS-metrikker, hvorunder koden udf\u00f8res (virtuel hukommelse, % CPU-belastning), netv\u00e6rksmetrikker (netv\u00e6rksbelastning), serverens egne metrikker (CPU- og hukommelsesbelastning), wildfly-metrikker og egne applikationsmetrikker i alle kritiske undersystemer. <\/p>\n

<\/p>\n

Alle metrikker indsamles fra systemet ved hj\u00e6lp af graphite. Oprindeligt blev whisper-database brugt som standardl\u00f8sning til grafana, men med v\u00e6ksten af kundebasen kunne graphite ikke l\u00e6ngere klare det og udt\u00f8mte diskens I\/O kapacitet. Derefter blev der truffet beslutning om at finde en mere effektiv l\u00f8sning. Valget faldt p\u00e5 graphite+clickhouse<\/a><\/noindex>, hvilket gjorde det muligt at reducere belastningen p\u00e5 diskens subsystem med en orden og reducere det optagne diskplads med fem til seks gange. Nedenfor pr\u00e6senteres diagrammet for mekanismen til indsamling af metrikker med brug af graphite+clickhouse (figur 2).<\/p>\n

\n\"Finder
\n<\/p>\n

Figur 2. Diagram for indsamling af metrikker<\/em><\/p>\n

Diagrammet er hentet fra intern dokumentation. Den viser dataudvekslingen mellem grafana (brugergr\u00e6nsefladen til overv\u00e5gning, som vi bruger) og graphite. Indhentning af metrikker fra applikationen udf\u00f8res af et separat software \u2013 jmxtrans<\/a><\/noindex>. Det leverer ogs\u00e5 dataene til graphite.
\nSystemet \"Web-Konsolidering\" har en r\u00e6kke s\u00e6rlige kendetegn, der skaber problemer for fejlprognoser:<\/p>\n

<\/p>\n

    \n
  1. der sker ofte en \u00e6ndring i tendenserne. For dette software system frigives der forskellige versioner. Hver version medf\u00f8rer \u00e6ndringer i den softwarem\u00e6ssige del af systemet. F\u00f8lgelig kan udviklerne direkte p\u00e5virke metrikkerne for dette system og for\u00e5rsage \u00e6ndringer i tendenserne; <\/li>\n
  2. den specifikke implementering samt m\u00e5l for anvendelse fra kunderne af dette system medf\u00f8rer ofte anomalier uden forudg\u00e5ende nedgang; <\/li>\n
  3. procentdelen af anomalier i forhold til hele datasettet er lav (< 5%); <\/li>\n
  4. der kan opst\u00e5 afbrydelser i dataindsamlingen fra systemet. I nogle korte tidsintervaller kan overv\u00e5gningssystemet ikke indhente metrikker. For eksempel, hvis serveren er overbelastet. Dette er kritisk for at tr\u00e6ne neurale netv\u00e6rk. Der opst\u00e5r behov for at fylde hullerne syntetisk;<\/li>\n
  5. Sager med anomalier er ofte relevante kun for et specifikt tal\/m\u00e5ned\/tid (s\u00e6sonbestemt). Dette system har klare retningslinjer for brug fra dets brugere. F\u00f8lgelig er metrikkerne kun relevante for et bestemt tidspunkt. Systemet kan ikke bruges konstant, men kun i nogle m\u00e5neder: selektivt afh\u00e6ngigt af \u00e5ret. Der opst\u00e5r situationer, hvor den samme metrikadf\u00e6rd i et tilf\u00e6lde kan f\u00f8re til fejl i software systemet, mens det i et andet ikke g\u00f8r.
    \nF\u00f8rst blev metoderne til at opdage anomalier i overv\u00e5gningsdata for software systemer analyseret. I artikler om dette emne, n\u00e5r anomalierne udg\u00f8r en lav procentdel af det \u00f8vrige datas\u00e6t, foresl\u00e5s det oftest at bruge neurale netv\u00e6rk. <\/li>\n<\/ol>\n

    <\/p>\n

    Den prim\u00e6re logik til at finde anomalier ved hj\u00e6lp af data fra neurale netv\u00e6rk er skildret i figur 3:<\/p>\n

    \n\"Finder
    \n<\/p>\n

    Figur 3. S\u00f8gning efter anomalier ved hj\u00e6lp af et neuralt netv\u00e6rk<\/em><\/p>\n

    I resultatet af prognosen eller gendannelsen af vinduet for den aktuelle str\u00f8m af metrics beregnes afvigelsen fra de v\u00e6rdier, der er opn\u00e5et fra det fungerende softwaresystem. I tilf\u00e6lde af store forskelle mellem de indsamlede metrics fra softwaresystemet og den neurale netv\u00e6rk kan man konkludere, at den aktuelle datasektion er unormal. Der opst\u00e5r en r\u00e6kke problemer ved brugen af neurale netv\u00e6rk:<\/p>\n

    <\/p>\n

      \n
    1. for at fungere korrekt i streamingtilstand skal dataene til tr\u00e6ningen af neurale netv\u00e6rksmodeller kun inkludere \"normale\" data; <\/li>\n
    2. det er n\u00f8dvendigt at have en aktuel model for korrekt opdagelse. Skift i trends og s\u00e6sonbetonede variationer i metrics kan for\u00e5rsage et stort antal falske positiver fra modellen. For at opdatere modellen er det n\u00f8dvendigt pr\u00e6cist at bestemme tidspunktet, hvor modellen er for\u00e6ldet. Hvis modellen opdateres for sent eller for tidligt, vil det sandsynligvis resultere i mange falske positiver.
      \nMan m\u00e5 heller ikke glemme at finde og forhindre hyppig opst\u00e5en af falske positiver. Det forventes, at de oftest vil opst\u00e5 i us\u00e6dvanlige situationer. Men de kan ogs\u00e5 v\u00e6re et resultat af fejl i det neurale netv\u00e6rk p\u00e5 grund af utilstr\u00e6kkelig tr\u00e6ning. Det er n\u00f8dvendigt at minimere antallet af falske positiver. Ellers vil falske prognoser spilde meget tid for administratoren, der er beregnet til at overv\u00e5ge systemet. F\u00f8r eller siden vil det ende med, at administratoren simpelthen vil stoppe med at reagere p\u00e5 det \"paranoide\" overv\u00e5gningssystem.<\/li>\n<\/ol>\n

      <\/p>\n

      Recurrent Neural Network<\/h2>\n

      <\/p>\n

      For at opdage anomalier i tidsserier kan man anvende et recurrent neural network <\/a><\/noindex>med LSTM-hukommelse. Problemet er blot, at det kun kan anvendes til forudsigelige tidsserier. I vores tilf\u00e6lde er ikke alle metrics forudsigelige. Fors\u00f8get p\u00e5 at anvende RNN LSTM til tidsserien er pr\u00e6senteret i figur 4.<\/p>\n

      \n\"Finder
      \n<\/p>\n

      Figur 4. Eksempel p\u00e5 arbejdet med et recurrent neural network med LSTM-hukommelsesceller<\/em><\/p>\n

      Som det fremg\u00e5r af figur 4, var RNN LSTM i stand til at h\u00e5ndtere anomalidetektion p\u00e5 dette tidsafsnit. Der, hvor resultatet har en h\u00f8j prognosefejl (medianfejl), opstod der faktisk en anomali i m\u00e5lingerne. At bruge kun \u00e9n RNN LSTM vil \u00e5benlyst v\u00e6re utilstr\u00e6kkeligt, da den kun kan anvendes til et begr\u00e6nset antal m\u00e5linger. Den kan bruges som en supplerende metode til anomalidetektion. <\/p>\n

      <\/p>\n

      Autokoderen til fejlfrekvensprognoser<\/h2>\n

      <\/p>\n

      Autokoder<\/a><\/noindex> \u2013 er i sin essens et kunstigt neuralt netv\u00e6rk. Indgangslaget \u2013 encoder, udgangslaget \u2013 decoder. Ulempen ved alle neurale netv\u00e6rk af denne type er, at de d\u00e5rligt lokaliserer anomalier. Arkitekturen af en synkron autokoder blev valgt.<\/p>\n

      \n\"Finder
      \n<\/p>\n

      Figur 5. Eksempel p\u00e5 autokoderen i funktion<\/em><\/p>\n

      Autokodere tr\u00e6nes p\u00e5 normale data og finder derefter anomalier i de data, der behandles af modellen. Dette er pr\u00e6cis det, vi har brug for til denne opgave. Det er kun n\u00f8dvendigt at v\u00e6lge, hvilken autokoder der passer til denne opgave. Den arkitektonisk mest simple form for autokoder er en direkte, irreversible neuralt netv\u00e6rk, der minder meget om et multilag-perceptron<\/a><\/noindex> (multilayer perceptron, MLP), med et indgangsniveau, et udgangsniveau samt en eller flere skjulte lag, der forbinder dem.
      \nForskellene mellem autokodere og MLP ligger dog i, at i autokoderen har udgangsniveauet samme antal noder som indgangsniveauet, og at i stedet for at l\u00e6re at forudsige en m\u00e5lv\u00e6rdi Y, givet indgang X, l\u00e6rer autokoderen at rekonstruere sine egne X. Derfor er autokodere ikke-overv\u00e5gede l\u00e6ringsmodeller. <\/p>\n

      <\/p>\n

      Opgaven for autokoderen er at finde tidsindekserne r0 \u2026 rn, der svarer til de anomale elementer i indgangsvektoren X. Denne effekt opn\u00e5s ved at s\u00f8ge efter kvadratiske fejl.<\/p>\n

      \n\"Finder <\/p>\n

      Figur 6. Synkron autokoder<\/em><\/p>\n

      For autokoderen blev der valgt en synkron arkitektur<\/a><\/noindex>. Dens fordele: mulighed for at anvende streamingbehandling og relativt f\u00e6rre parametre i det neurale netv\u00e6rk sammenlignet med andre arkitekturer.<\/p>\n

      <\/p>\n

      Mekanismen til at minimere falske alarmer<\/h2>\n

      <\/p>\n

      Da der der opst\u00e5r forskellige unormale situationer, og der muligvis er situationer med utilstr\u00e6kkelig tr\u00e6ning af neurale netv\u00e6rk, blev der truffet beslutning om n\u00f8dvendigheden af at udvikle en mekanisme til at minimere falske alarmer for den udviklede model til opdagelse af anomalier. Denne mekanisme er baseret p\u00e5 en skabelondatabase, som klassificeres af administratoren. <\/p>\n

      <\/p>\n

      Algoritmen til dynamisk transformation af tidslinjerne<\/a><\/noindex> (DTW-algoritmen, fra engelsk dynamic time warping) g\u00f8r det muligt at finde optimal korrespondance mellem tidssekvenser. Den blev f\u00f8rste gang anvendt i talegenkendelse: det blev brugt til at bestemme, hvordan to taleoptagelser repr\u00e6senterer den samme udtalte s\u00e6tning. Senere blev det fundet anvendelse i andre omr\u00e5der.<\/p>\n

      <\/p>\n

      Hovedprincippet for at minimere falske alarmer er at indsamle en database af standarder ved hj\u00e6lp af en operat\u00f8r, som klassificerer mist\u00e6nkelige tilf\u00e6lde opdaget ved hj\u00e6lp af neurale netv\u00e6rk. Herefter sammenlignes den klassificerede standard med det tilf\u00e6lde, som systemet har opdaget, og der drages konklusioner om, hvorvidt tilf\u00e6ldet tilh\u00f8rer de falske eller f\u00f8rer til en fejl. Det er netop til sammenligning af to tidsserier, at DTW-algoritmen anvendes. Det prim\u00e6re v\u00e6rkt\u00f8j til minimisering er dog klassificering. Det antages, at efter indsamlingen af et stort antal standardiserede tilf\u00e6lde, vil systemet sp\u00f8rge operat\u00f8ren mindre p\u00e5 grund af ligheden mellem de fleste tilf\u00e6lde og fremkomsten af lignende.<\/p>\n

      <\/p>\n

      Som resultat af de beskrevne metoder til neurale netv\u00e6rk er der blevet udviklet et eksperimentelt program til forudsigelse af fejl i systemet \"Web-Konsolidering\". Form\u00e5let med dette program var at vurdere effektiviteten af denne tilgang til vores software-systemer ved at bruge den eksisterende overv\u00e5gningsdataarkiv og information om allerede opst\u00e5ede fejl. Programmet er beskrevet nedenfor i figur 7.<\/p>\n

      \n\"Finder <\/p>\n

      Figur 7. Diagram for forudsigelse af fejl baseret p\u00e5 analyse af metricsrum<\/em><\/p>\n

      I diagrammet kan der skelnes mellem to hovedblokke: s\u00f8gning efter anomale tidssegmenter i dataoverv\u00e5gningsstr\u00f8mmen (metrics) og mekanismen til at minimere falske alarmer. Note: Til eksperimentelle form\u00e5l hentes dataene gennem JDBC-forbindelsen fra den database, hvor de gemmes i graphite.
      \nHer pr\u00e6senteres brugergr\u00e6nsefladen for det udviklede overv\u00e5gningssystem (figur 8).<\/p>\n

      \n\"Finder<\/p>\n

      Figur 8. Brugergr\u00e6nseflade for det eksperimentelle overv\u00e5gningssystem<\/em><\/p>\n

      P\u00e5 brugergr\u00e6nsefladen vises procentdelen af anomalier baseret p\u00e5 de modtagne m\u00e5linger. I vores tilf\u00e6lde simuleres indhentningen. Vi har allerede data for flere uger og indl\u00e6ser dem gradvist for at kontrollere en situation med en anomali, der f\u00f8rer til svigt. I den nederste statuslinje vises den samlede procentdel af anomalier for de aktuelle data, som bestemmes ved hj\u00e6lp af en autoencoder. Derudover vises en separat procentdel for de forudsigte m\u00e5linger, som beregnes af RNN LSTM.<\/p>\n

      <\/p>\n

      Eksempel p\u00e5 anomaliopdagelse for CPU-m\u00e5linger ved hj\u00e6lp af RNN LSTM (figur 9).<\/p>\n

      \n\"Finder<\/p>\n

      Figur 9. Opdagelse med RNN LSTM<\/em><\/p>\n

      Et ret simpelt tilf\u00e6lde, faktisk en almindelig outlier, men som f\u00f8rer til systemfejl, blev med succes identificeret ved hj\u00e6lp af RNN LSTM. Anomaliprocenten i dette tidsinterval var 85 \u2013 95%, alt, der er over 80% (gr\u00e6nsen blev fastsat eksperimentelt), betragtes som en anomali.
      \nEksempel p\u00e5 anomaliopdagelse, n\u00e5r systemet ikke kunne starte efter en opdatering. Denne situation detekteres af autoencoderen (figur 10).<\/p>\n

      \n\"Finder<\/p>\n

      Figur 10. Eksempel p\u00e5 opdagelse af autoencoder<\/em><\/p>\n

      Som det ses i figuren, hang PermGen p\u00e5 et niveau. Autoencoderen fandt det us\u00e6dvanligt, da den tidligere ikke havde set noget lignende. Her holdes anomalien konstant p\u00e5 100% indtil systemet igen bliver operationelt. Anomalien vises for alle m\u00e5linger. Som n\u00e6vnt tidligere kan autoencoderen ikke lokalisere anomalier. Operat\u00f8ren er ansvarlig for at udf\u00f8re denne funktion i disse situationer.<\/p>\n

      <\/p>\n

      Konklusion<\/h2>\n

      <\/p>\n

      PC 'Web-Konsolidering' er blevet udviklet i flere \u00e5r. Systemet er i en tilstr\u00e6kkelig stabil tilstand, og antallet af registrerede h\u00e6ndelser er begr\u00e6nset. Ikke desto mindre har det v\u00e6ret muligt at finde anomalier, der f\u00f8rte til svigt 5 \u2013 10 minutter f\u00f8r svigtet opstod. I nogle tilf\u00e6lde ville forudsigelserne om svigt have hjulpet med at spare den planlagte tid, der er afsat til 'reparations'-arbejde.<\/p>\n

      <\/p>\n

      P\u00e5 de eksperimenter, der er blevet udf\u00f8rt, er det stadig for tidligt at drage endelige konklusioner. I \u00f8jeblikket er resultaterne modstridende. P\u00e5 den ene side viser det sig, at algoritmer baseret p\u00e5 neurale netv\u00e6rk er i stand til at finde \"nyttige\" anomalier. P\u00e5 den anden side er der stadig en stor procentdel af falske positiver, og ikke alle anomalier, der identificeres af en kvalificeret specialist, kan det neurale netv\u00e6rk opdage. En ulempe er ogs\u00e5, at neurale netv\u00e6rk i \u00f8jeblikket kr\u00e6ver supervisioneret l\u00e6ring for at fungere optimalt.<\/p>\n

      <\/p>\n

      For at videreudvikle systemet til fejlfinding og bringe det til en tilfredsstillende tilstand kan flere veje overvejes. Det inkluderer en mere detaljeret analyse af tilf\u00e6lde med anomalier, der f\u00f8rer til fejl, ved at udvide listen over vigtige metrikker, der har stor indflydelse p\u00e5 systemets tilstand, og fjerne de un\u00f8dvendige, der ikke p\u00e5virker det. Derudover, hvis man f\u00f8lger denne retning, kan der g\u00f8res fors\u00f8g p\u00e5 at specialisere algoritmer konkret til vores tilf\u00e6lde med anomalier, der f\u00f8rer til fejl. Der er ogs\u00e5 en anden vej. Det er forbedringen af arkitekturer for neurale netv\u00e6rk og derved \u00f8ge n\u00f8jagtigheden af opdagelser med kortere tr\u00e6ningstid.<\/p>\n

      <\/p>\n

      Jeg vil gerne takke kollegerne, der har hjulpet mig med at skrive og holde denne artikel aktuel: Viktor Verbitsky<\/a><\/noindex> og Sergey Finogenov.<\/p>\n

      Kilde: 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\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\udd47Vi s\u00f8ger anomalier og forudsiger fejl med neurale netv\u00e6rk | ProHoster","description":"Industriel udvikling.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/ishhem-anomalii-i-predskazyvaem-sboi-s-pomoshhyu-nejrosetej","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/53531","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=53531"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/53531\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=53531"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=53531"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=53531"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}