Ohjelmistojärjestelmien teollinen kehittäminen vaatii suurta huomiota lopputuotteen vikasietoisuuteen sekä nopeaa reagointia häiriöihin ja häiriöihin, jos niitä ilmenee. Valvonta tietysti auttaa vastaamaan epäonnistumisiin ja häiriöihin tehokkaammin ja nopeammin, mutta ei tarpeeksi. Ensinnäkin on erittäin vaikea seurata suurta määrää palvelimia - tarvitaan suuri määrä ihmisiä. Toiseksi, sinulla on oltava hyvä käsitys sovelluksen toiminnasta, jotta voit ennustaa sen tilan. Siksi tarvitsemme paljon ihmisiä, jotka ymmärtävät hyvin kehittämiämme järjestelmiä, niiden suorituskykyä ja ominaisuuksia. Oletetaan, että vaikka löytäisit tarpeeksi ihmisiä, jotka haluavat tehdä tämän, heidän kouluttamiseen kuluu silti paljon aikaa.
Mitä tehdä? Tässä tekoäly tulee avuksemme. Artikkelissa puhutaan (ennakoiva huolto). Tämä lähestymistapa on saamassa aktiivisesti suosiota. On kirjoitettu suuri määrä artikkeleita, myös Habresta. Suuret yritykset hyödyntävät tätä lähestymistapaa täysimääräisesti ylläpitääkseen palvelimiensa suorituskykyä. Tutkittuamme useita artikkeleita päätimme kokeilla tätä lähestymistapaa. Mitä siitä tuli?
Esittely
Kehitetty ohjelmistojärjestelmä ottaa ennemmin tai myöhemmin käyttöön. Käyttäjälle on tärkeää, että järjestelmä toimii ilman vikoja. Jos hätätilanne sattuu, se tulee ratkaista mahdollisimman pienellä viiveellä.
Ohjelmistojärjestelmän teknisen tuen yksinkertaistamiseksi, varsinkin jos palvelimia on useita, käytetään yleensä valvontaohjelmia, jotka ottavat mittareita käynnissä olevasta ohjelmistojärjestelmästä, mahdollistavat sen kunnon diagnosoinnin ja auttavat määrittämään vian tarkan syyn. Tätä prosessia kutsutaan ohjelmistojärjestelmän valvonnaksi.
Kuva 1. Grafana-valvontaliittymä
Mittarit ovat erilaisia indikaattoreita ohjelmistojärjestelmästä, sen suoritusympäristöstä tai fyysisestä tietokoneesta, jossa järjestelmä toimii, ja niiden vastaanottohetken aikaleima. Staattisessa analyysissä näitä mittareita kutsutaan aikasarjoiksi. Ohjelmistojärjestelmän tilan seurantaa varten mittarit näytetään kaavioiden muodossa: aika on X-akselilla ja arvot Y-akselilla (kuva 1). Käynnissä olevasta ohjelmistojärjestelmästä voidaan ottaa useita tuhansia mittareita (jokaisesta solmusta). Ne muodostavat metriikan (moniulotteisen aikasarjan) avaruuden.
Koska monimutkaisista ohjelmistojärjestelmistä kerätään suuri määrä mittareita, manuaalisesta valvonnasta tulee vaikea tehtävä. Järjestelmänvalvojan analysoiman tiedon määrän vähentämiseksi seurantatyökalut sisältävät työkaluja, jotka tunnistavat automaattisesti mahdolliset ongelmat. Voit esimerkiksi määrittää liipaisimen käynnistymään, kun vapaa levytila putoaa tietyn kynnyksen alapuolelle. Voit myös diagnosoida automaattisesti palvelimen sammutuksen tai palvelun nopeuden kriittisen hidastumisen. Käytännössä valvontatyökalut pystyvät havaitsemaan jo tapahtuneita vikoja tai tunnistamaan yksinkertaisia oireita tulevista vioista, mutta yleensä mahdollisen vian ennustaminen on heille kova pähkinä. Ennustaminen mittareiden manuaalisen analyysin avulla edellyttää pätevien asiantuntijoiden osallistumista. Se on alhainen tuottavuus. Useimmat mahdolliset viat voivat jäädä huomaamatta.
Ohjelmistojärjestelmien niin sanottu ennakoiva ylläpito on viime aikoina yleistynyt suurten IT-ohjelmistokehitysyritysten keskuudessa. Tämän lähestymistavan ydin on keinoälyn avulla löytää ongelmat, jotka johtavat järjestelmän heikkenemiseen alkuvaiheessa, ennen kuin se epäonnistuu. Tämä lähestymistapa ei sulje kokonaan pois järjestelmän manuaalista valvontaa. Se on apuväline koko valvontaprosessille.
Ennakoivan ylläpidon toteuttamisen päätyökalu on tehtävä etsiä poikkeavuuksia aikasarjoista alkaen kun poikkeavuus tapahtuu tiedoissa on suuri todennäköisyys, että jonkin ajan kuluttua tulee epäonnistuminen tai epäonnistuminen. Poikkeama on tietty poikkeama ohjelmistojärjestelmän suorituskyvyssä, kuten yhden tyyppisen pyynnön suoritusnopeuden heikkenemisen tunnistaminen tai palveltujen pyyntöjen keskimääräisen määrän väheneminen asiakasistuntojen vakiotasolla.
Ohjelmistojärjestelmien poikkeavuuksien etsimisellä on omat erityispiirteensä. Teoriassa jokaiselle ohjelmistojärjestelmälle on tarpeen kehittää tai jalostaa olemassa olevia menetelmiä, koska poikkeamien etsintä on hyvin riippuvainen tiedoista, joissa se suoritetaan, ja ohjelmistojärjestelmien tiedot vaihtelevat suuresti riippuen järjestelmän toteuttamistyökaluista. , riippuen siitä, missä tietokoneessa se on käynnissä.
Menetelmät poikkeamien etsimiseen ohjelmistojärjestelmien vikoja ennakoitaessa
Ensinnäkin on syytä sanoa, että ajatus epäonnistumisten ennustamisesta sai inspiraationsa artikkelista . Testaamaan lähestymistavan tehokkuutta automaattisella poikkeamien haulla valittiin Web-Consolidation ohjelmistojärjestelmä, joka on yksi NPO Krista -yhtiön projekteista. Aiemmin sille tehtiin manuaalista seurantaa saatujen mittareiden perusteella. Koska järjestelmä on melko monimutkainen, sille otetaan suuri määrä mittareita: JVM-indikaattorit (roskakeräimen kuormitus), käyttöjärjestelmän indikaattorit, jossa koodi suoritetaan (virtuaalimuisti, käyttöjärjestelmän prosessorin kuormitus%), verkko-indikaattorit (verkon kuormitus) ), itse palvelin (suorittimen kuormitus, muisti), wildfly-mittarit ja sovelluksen omat mittarit kaikille kriittisille osajärjestelmille.
Kaikki mittarit on otettu järjestelmästä grafiitilla. Aluksi whisper-tietokantaa käytettiin grafanan vakioratkaisuna, mutta asiakaskunnan kasvaessa grafiitti ei enää jaksanut, koska DC-levyalijärjestelmän kapasiteetti oli käytetty loppuun. Tämän jälkeen päätettiin löytää tehokkaampi ratkaisu. Valinta tehtiin puolesta , joka mahdollisti levyalijärjestelmän kuormituksen vähentämisen suuruusluokkaa ja varattua levytilaa viidestä kuuteen kertaan. Alla on kaavio mekanismista, jolla mittareita kerätään grafiitti+clickhouse-toiminnolla (kuva 2).
Kuva 2. Kaavio mittareiden keräämiseksi
Kaavio on otettu sisäisestä dokumentaatiosta. Se näyttää tiedonsiirron grafanan (käytämme seurantakäyttöliittymän) ja grafiitin välillä. Mittareiden poistaminen sovelluksesta tehdään erillisellä ohjelmistolla - . Hän laittaa ne grafiittiin.
Web Consolidation -järjestelmässä on useita ominaisuuksia, jotka aiheuttavat ongelmia vikojen ennustamisessa:
- Trendi muuttuu usein. Tälle ohjelmistojärjestelmälle on saatavilla useita versioita. Jokainen niistä tuo muutoksia järjestelmän ohjelmistoosaan. Näin ollen kehittäjät vaikuttavat tällä tavalla suoraan tietyn järjestelmän mittareihin ja voivat aiheuttaa trendin muutoksen;
- toteutusominaisuus sekä tarkoitukset, joihin asiakkaat käyttävät tätä järjestelmää, aiheuttavat usein poikkeavuuksia ilman aikaisempaa huonontumista;
- poikkeamien prosenttiosuus koko tietojoukosta on pieni (< 5 %);
- Ilmaisimien vastaanottamisessa järjestelmästä voi olla aukkoja. Joissakin lyhyessä ajassa valvontajärjestelmä ei pysty saamaan mittareita. Esimerkiksi jos palvelin on ylikuormitettu. Tämä on kriittistä neuroverkon kouluttamisessa. Puutteet on täytettävä synteettisesti;
- Tapaukset, joissa on poikkeavuuksia, koskevat usein vain tiettyä päivämäärää/kuukautta/aikaa (kausiluonteisuus). Tällä järjestelmällä on selkeät säännökset käyttäjille. Näin ollen mittarit ovat merkityksellisiä vain tietylle ajalle. Järjestelmää ei voi käyttää jatkuvasti, vaan vain muutaman kuukauden: valikoivasti vuodesta riippuen. Tilanteita syntyy, kun sama metriikan käyttäytyminen yhdessä tapauksessa voi johtaa ohjelmistojärjestelmän vikaan, mutta ei toisessa.
Aluksi analysoitiin menetelmiä ohjelmistojärjestelmien seurantatiedon poikkeavuuksien havaitsemiseksi. Tätä aihetta käsittelevissä artikkeleissa, kun poikkeamien prosenttiosuus on pieni suhteessa muuhun tietosarjaan, ehdotetaan useimmiten hermoverkkojen käyttöä.
Peruslogiikka poikkeamien etsimiseen hermoverkkodatan avulla on esitetty kuvassa 3:
Kuva 3. Poikkeamien etsiminen hermoverkon avulla
Nykyisen mittausvirran ennusteen tai ikkunan palauttamisen tuloksen perusteella lasketaan poikkeama käynnissä olevasta ohjelmistojärjestelmästä saadusta. Jos ohjelmistojärjestelmästä ja hermoverkosta saatujen mittareiden välillä on suuri ero, voidaan päätellä, että nykyinen datasegmentti on poikkeava. Seuraavat ongelmat syntyvät hermoverkkojen käytössä:
- toimiakseen oikein suoratoistotilassa, neuroverkkomallien opetusdatan tulee sisältää vain "normaalia" dataa;
- oikeaa havaitsemista varten tarvitaan ajan tasalla oleva malli. Muuttuvat trendit ja kausivaihtelu mittareissa voivat aiheuttaa suuren määrän vääriä positiivisia tuloksia mallissa. Sen päivittämiseksi on tarpeen määrittää selkeästi aika, jolloin malli on vanhentunut. Jos päivität mallin myöhemmin tai aikaisemmin, todennäköisesti seuraa suuri määrä vääriä positiivisia.
Emme saa myöskään unohtaa väärien positiivisten tulosten etsimistä ja toistuvien esiintymisen estämistä. Niiden oletetaan esiintyvän useimmiten hätätilanteissa. Ne voivat kuitenkin olla myös seurausta hermoverkkovirheestä, joka johtuu riittämättömästä harjoittelusta. On tarpeen minimoida mallin väärien positiivisten tulosten määrä. Muuten väärät ennusteet hukkaavat paljon järjestelmänvalvojan aikaa, joka on tarkoitettu järjestelmän tarkistamiseen. Ennemmin tai myöhemmin järjestelmänvalvoja yksinkertaisesti lakkaa vastaamasta "paranoidiseen" valvontajärjestelmään.
Toistuva neuroverkko
Voit havaita poikkeavuuksia aikasarjoissa käyttämällä LSTM-muistilla. Ainoa ongelma on, että sitä voidaan käyttää vain ennustetuille aikasarjoille. Meidän tapauksessamme kaikki mittarit eivät ole ennustettavissa. Yritys soveltaa RNN LSTM:ää aikasarjaan on esitetty kuvassa 4.
Kuva 4. Esimerkki toistuvasta neuroverkosta, jossa on LSTM-muistisoluja
Kuten kuvasta 4 voidaan nähdä, RNN LSTM pystyi selviytymään poikkeavuuksien etsinnästä tällä ajanjaksolla. Jos tuloksessa on korkea ennustevirhe (keskimääräinen virhe), indikaattoreissa on todella tapahtunut poikkeama. Yhden RNN LSTM:n käyttö ei selvästikään riitä, koska se soveltuu pienelle määrälle mittareita. Voidaan käyttää apumenetelmänä poikkeavuuksien etsimiseen.
Autoencoder vian ennustamiseen
– pohjimmiltaan keinotekoinen hermoverkko. Tulokerros on kooderi, lähtökerros on dekooderi. Kaikkien tämäntyyppisten hermoverkkojen haittana on, että ne eivät paikanna poikkeavuuksia hyvin. Synkroninen autoenkooder-arkkitehtuuri valittiin.
Kuva 5. Esimerkki autoenkooderin toiminnasta
Autoenkooderit koulutetaan käyttämään normaalia dataa ja löytävät sitten jotain poikkeavaa malliin syötetyistä tiedoista. Juuri mitä tarvitset tähän tehtävään. Jäljelle jää vain valita, mikä automaattinen kooderi sopii tähän tehtävään. Autoenkooderin arkkitehtonisesti yksinkertaisin muoto on eteenpäin suuntautuva ei-paluu neuroverkko, joka on hyvin samanlainen kuin (multilayer perceptron, MLP), jossa on syöttökerros, tulostuskerros ja yksi tai useampi piilotettu kerros, jotka yhdistävät ne.
Autoenkooderien ja MLP:iden erot ovat kuitenkin siinä, että autoenkooderissa lähtökerroksessa on sama määrä solmuja kuin syöttökerroksessa, ja että sen sijaan, että sitä opetettaisiin ennustamaan tulon X antama tavoitearvo Y, autoenkooderi opetetaan. rekonstruoida omat X:nsä. Siksi autoenkooderit ovat valvomattomia oppimismalleja.
Autoenkooderin tehtävänä on löytää tulovektorin X poikkeavia elementtejä vastaavat aikaindeksit r0 ... rn. Tämä vaikutus saavutetaan etsimällä neliövirhettä.
Kuva 6. Synkroninen autoenkooderi
Autoenkooderille valittiin . Sen edut: kyky käyttää streaming-käsittelytilaa ja suhteellisen pienempi määrä hermoverkkoparametreja verrattuna muihin arkkitehtuureihin.
Mekanismi väärien positiivisten tulosten minimoimiseksi
Erilaisten epänormaalien tilanteiden ja hermoverkon mahdollisen riittämättömän harjoittelun vuoksi kehitettävän poikkeamien havaitsemismallin vuoksi päätettiin, että on tarpeen kehittää mekanismi väärien positiivisten tulosten minimoimiseksi. Tämä mekanismi perustuu mallipohjaan, jonka järjestelmänvalvoja on luokitellut.
(DTW-algoritmi, englanninkielisestä dynaamisesta aikavääristyksestä) antaa sinun löytää optimaalisen vastaavuuden aikajaksojen välillä. Käytettiin ensimmäisen kerran puheentunnistuksessa: käytetään määrittämään, kuinka kaksi puhesignaalia edustavat samaa alkuperäistä puhuttua lausetta. Myöhemmin sille löydettiin sovellus muilla aloilla.
Pääperiaate väärien positiivisten tulosten minimoimiseksi on standarditietokannan kerääminen operaattorin avulla, joka luokittelee hermoverkkojen avulla havaitut epäilyttävät tapaukset. Seuraavaksi luokiteltua standardia verrataan järjestelmän havaitsemaan tapaukseen ja tehdään johtopäätös siitä, onko tapaus väärä vai johtaako se epäonnistumiseen. DTW-algoritmia käytetään tarkasti kahden aikasarjan vertailuun. Tärkein minimointityökalu on edelleen luokittelu. On odotettavissa, että kun on kerätty suuri määrä viitetapauksia, järjestelmä alkaa kysyä operaattorilta vähemmän useimpien tapausten samankaltaisuuden ja samankaltaisten esiintymisen vuoksi.
Tuloksena yllä kuvattujen hermoverkkomenetelmien pohjalta rakennettiin kokeellinen ohjelma "Web-Consolidation"-järjestelmän vikojen ennustamiseksi. Tämän ohjelman tavoitteena oli olemassa olevan seurantatietojen ja aiempien vikojen tietojen arkiston avulla arvioida tämän lähestymistavan pätevyyttä ohjelmistojärjestelmiimme. Ohjelman kaavio on esitetty alla kuvassa 7.
Kuva 7. Metrinen avaruusanalyysiin perustuva vikojen ennustekaavio
Kaaviossa voidaan erottaa kaksi päälohkoa: poikkeavien ajanjaksojen etsiminen seurantatietovirrasta (metriikka) ja mekanismi väärien positiivisten minimoimiseksi. Huomautus: Kokeilutarkoituksiin tiedot saadaan JDBC-yhteyden kautta tietokannasta, johon grafiitti tallentaa ne.
Seuraavassa on kehittämisen tuloksena saatu valvontajärjestelmän rajapinta (kuva 8).
Kuva 8. Kokeellisen seurantajärjestelmän käyttöliittymä
Käyttöliittymä näyttää poikkeamien prosenttiosuuden vastaanotettujen mittareiden perusteella. Meidän tapauksessamme kuitti on simuloitu. Meillä on jo kaikki tiedot useiden viikkojen ajalta, ja lataamme niitä vähitellen tarkistaaksemme, onko virheeseen johtanut poikkeama. Alempi tilapalkki näyttää datapoikkeamien kokonaisprosenttiosuuden tietyllä hetkellä, joka määritetään automaattisen kooderin avulla. Lisäksi ennustetuille mittareille näytetään erillinen prosenttiosuus, jonka RNN LSTM laskee.
Esimerkki CPU:n suorituskykyyn perustuvasta poikkeamien havaitsemisesta käyttämällä RNN LSTM -hermoverkkoa (Kuva 9).
Kuva 9. RNN LSTM -etsintä
Melko yksinkertainen tapaus, olennaisesti tavallinen poikkeava, mutta järjestelmävikaan johtava tapaus, laskettiin onnistuneesti RNN LSTM:n avulla. Poikkeavuusindikaattori tällä ajanjaksolla on 85–95 %, kaikki yli 80 % (kynnys määritettiin kokeellisesti) katsotaan poikkeavuudeksi.
Esimerkki poikkeaman havaitsemisesta, kun järjestelmä ei voinut käynnistyä päivityksen jälkeen. Autoenkooderi havaitsee tämän tilanteen (kuva 10).
Kuva 10. Esimerkki autoenkooderin tunnistuksesta
Kuten kuvasta näkyy, PermGen on jumissa yhdellä tasolla. Autoencoder piti tätä outona, koska se ei ollut koskaan nähnyt mitään vastaavaa ennen. Tässä poikkeama pysyy 100 %, kunnes järjestelmä palaa toimintatilaan. Kaikille mittareille näytetään poikkeama. Kuten aiemmin mainittiin, autoenkooderi ei voi paikantaa poikkeavuuksia. Käyttäjää pyydetään suorittamaan tämä toiminto näissä tilanteissa.
Johtopäätös
PC "Web-Consolidation" on ollut kehitteillä useita vuosia. Järjestelmä on melko vakaassa tilassa ja tallennettujen tapausten määrä on pieni. Vikaan johtaneita poikkeavuuksia oli kuitenkin mahdollista löytää 5 - 10 minuuttia ennen vian ilmenemistä. Joissakin tapauksissa vian ilmoittaminen etukäteen auttaisi säästämään "korjaustöiden" suorittamiseen varattua aikataulua.
Tehtyjen kokeiden perusteella on liian aikaista tehdä lopullisia johtopäätöksiä. Toistaiseksi tulokset ovat ristiriitaisia. Toisaalta on selvää, että hermoverkkoihin perustuvat algoritmit pystyvät löytämään "hyödyllisiä" poikkeavuuksia. Toisaalta vääriä positiivisia tuloksia on edelleen suuri, eikä kaikkia pätevän asiantuntijan hermoverkossa havaitsemia poikkeavuuksia voida havaita. Haittapuolena on se, että nyt hermoverkko vaatii normaalia toimintaa varten koulutusta opettajan kanssa.
Vianennustejärjestelmän kehittämiseksi edelleen ja sen saattamiseksi tyydyttävään tilaan voidaan ajatella useita tapoja. Tämä on yksityiskohtaisempi analyysi tapauksista, joissa on virheisiin johtavia poikkeavuuksia, koska tämä lisäys tärkeiden mittareiden luetteloon, jotka vaikuttavat suuresti järjestelmän tilaan, ja tarpeettomien, jotka eivät vaikuta siihen, hylkäämisestä. Lisäksi, jos siirrymme tähän suuntaan, voimme yrittää erikoistaa algoritmeja erityisesti tapauksillemme, joissa poikkeavuuksia johtaa epäonnistumiseen. On toinenkin tapa. Tämä on parannus hermoverkkoarkkitehtuureihin ja siten lisää havaitsemistarkkuutta vähentämällä koulutusaikaa.
Kiitän kollegoitani, jotka auttoivat minua kirjoittamaan ja säilyttämään tämän artikkelin merkityksellisyyden: ja Sergei Finogenov.
Lähde: will.com