Pohdimme seurantajärjestelmän luomista tuoteryhmien muodostamisen vaiheessa. Kävi selväksi, että liiketoimintamme - hyväksikäyttö - ei kuulu näihin ryhmiin. Miksi niin?
Tosiasia on, että kaikki tiimimme on rakennettu yksittäisten tietojärjestelmien, mikropalvelujen ja rintamien ympärille, joten tiimit eivät näe koko järjestelmän yleistä kuntoa kokonaisuutena. He eivät esimerkiksi ehkä tiedä, kuinka jokin pieni osa syvässä taustassa vaikuttaa käyttöliittymään. Heidän kiinnostuksen kohteensa rajoittuu järjestelmiin, joihin heidän järjestelmänsä on integroitu. Jos tiimillä ja sen palvelulla A ei ole juuri mitään yhteyttä palvelun B kanssa, niin tällainen palvelu on tiimille lähes näkymätön.
Tiimimme puolestaan työskentelee järjestelmien kanssa, jotka ovat erittäin vahvasti integroituja toisiinsa: niiden välillä on monia yhteyksiä, tämä on erittäin laaja infrastruktuuri. Ja verkkokaupan toiminta riippuu kaikista näistä järjestelmistä (joita meillä on muuten valtava määrä).
Joten käy ilmi, että osastomme ei kuulu mihinkään joukkueeseen, vaan sijaitsee hieman sivussa. Koko tässä tarinassa tehtävämme on ymmärtää kokonaisvaltaisesti tietojärjestelmien toiminta, niiden toimivuus, integraatiot, ohjelmistot, verkko, laitteistot ja miten tämä kaikki liittyy toisiinsa.
Alusta, jolla verkkokauppamme toimivat, näyttää tältä:
- etuosa
- keskimmäinen toimisto
- takakonttori
Vaikka kuinka haluaisimme, ei tapahdu, että kaikki järjestelmät toimivat sujuvasti ja virheettömästi. Pointti on jälleen järjestelmien ja integraatioiden määrä - meidän kaltaisissa tapauksissa jotkut tapaukset ovat väistämättömiä testauksen laadusta huolimatta. Lisäksi sekä erillisen järjestelmän sisällä että niiden integroinnin kannalta. Ja sinun on seurattava koko alustan tilaa kattavasti, ei vain sen yksittäistä osaa.
Ihannetapauksessa koko alustan kattava terveydentilan seuranta tulisi automatisoida. Ja tulimme valvontaan väistämättömäksi osaksi tätä prosessia. Aluksi se rakennettiin vain etulinjalle, kun taas verkkoasiantuntijoilla, ohjelmisto- ja laitteistopäälliköillä oli ja on edelleen omat kerros-kerrokseen perustuvat valvontajärjestelmät. Kaikki nämä ihmiset seurasivat seurantaa vain omalla tasollaan, eikä kenelläkään ollut kattavaa ymmärrystä.
Jos esimerkiksi virtuaalikone kaatuu, useimmissa tapauksissa vain laitteistosta ja virtuaalikoneesta vastaava järjestelmänvalvoja tietää siitä. Tällaisissa tapauksissa etulinjan tiimi näki itse sovelluksen kaatumisen, mutta sillä ei ollut tietoja virtuaalikoneen kaatumisesta. Ja ylläpitäjä voi tietää, kuka asiakas on, ja hänellä on karkea käsitys siitä, mitä tällä virtuaalikoneella tällä hetkellä on käynnissä, edellyttäen, että kyseessä on jonkinlainen suuri projekti. Hän ei todennäköisesti tiedä pienistä. Joka tapauksessa järjestelmänvalvojan on mentävä omistajan luo ja kysyttävä, mitä tässä koneessa oli, mitä on palautettava ja mitä on muutettava. Ja jos jotain todella vakavaa meni rikki, he alkoivat juosta ympyrää - koska kukaan ei nähnyt järjestelmää kokonaisuutena.
Loppujen lopuksi tällaiset erilaiset tarinat vaikuttavat koko käyttöliittymään, käyttäjiin ja ydinliiketoimintaamme - verkkomyyntiin. Koska emme ole osa tiimiä, vaan olemme mukana kaikkien verkkokauppasovellusten toiminnassa osana verkkokauppaa, otimme tehtäväksi luoda kattavan seurantajärjestelmän verkkokauppaalustalle.
Järjestelmän rakenne ja pino
Aloitimme tunnistamalla järjestelmillemme useita valvontakerroksia, joista meidän pitäisi kerätä mittareita. Ja kaikki tämä piti yhdistää, mitä teimme ensimmäisessä vaiheessa. Tässä vaiheessa viimeistelemme korkealaatuista mittauskokoelmaa kaikilla tasoillamme rakentaaksemme korrelaation ja ymmärtääksemme, kuinka järjestelmät vaikuttavat toisiinsa.
Kattavan valvonnan puute sovelluksen julkaisun alkuvaiheessa (koska aloimme rakentaa sitä, kun suurin osa järjestelmistä oli tuotannossa) johti siihen, että meillä oli huomattavaa teknistä velkaa koko alustan valvonnan järjestämisestä. Meillä ei ollut varaa keskittyä yhden IS:n valvonnan asettamiseen ja sen tarkkailun laatimiseen, koska muut järjestelmät jäisivät ilman valvontaa joksikin aikaa. Tämän ongelman ratkaisemiseksi tunnistimme luettelon tarpeellisimmista mittareista tietojärjestelmän tilan arvioimiseksi kerroksittain ja aloimme toteuttaa sitä.
Siksi he päättivät syödä norsun osissa.
Järjestelmämme koostuu:
- laitteisto;
- käyttöjärjestelmä;
- ohjelmisto;
- UI osat valvontasovelluksessa;
- liiketoiminnan mittarit;
- integraatiosovellukset;
- tietoturva;
- verkot;
- liikenteen tasapainottaja.
Tämän järjestelmän keskiössä on itsensä valvonta. Ymmärtääksesi yleisesti koko järjestelmän tilan, sinun on tiedettävä, mitä sovelluksille tapahtuu kaikilla näillä tasoilla ja koko sovellusjoukossa.
Siis pinosta.
Käytämme avoimen lähdekoodin ohjelmistoja. Keskuksessa on Zabbix, jota käytämme ensisijaisesti hälytysjärjestelmänä. Kaikki tietävät, että se on ihanteellinen infrastruktuurin valvontaan. Mitä tämä tarkoittaa? Juuri ne matalan tason mittarit, joita jokaisella omaa konesalia ylläpitävällä yrityksellä on (ja Sportmasterilla on omat datakeskukset) - palvelimen lämpötila, muistin tila, raid, verkkolaitteiden mittarit.
Olemme integroineet Zabbixin Telegram Messengeriin ja Microsoft Teamsiin, joita käytetään aktiivisesti tiimeissä. Zabbix kattaa varsinaisen verkon kerroksen, laitteiston ja osan ohjelmistoista, mutta se ei ole ihmelääke. Rikastamme näitä tietoja joistakin muista palveluista. Esimerkiksi laitteistotasolla muodostamme suoran yhteyden API:n kautta virtualisointijärjestelmäämme ja keräämme tietoja.
Mitä muuta. Zabbixin lisäksi käytämme Prometheusta, jonka avulla voimme seurata mittareita dynaamisessa ympäristösovelluksessa. Toisin sanoen voimme vastaanottaa sovellusmittauksia HTTP-päätepisteen kautta, emmekä ole huolissamme siitä, mitkä mittarit ladataan siihen ja mitä ei. Näiden tietojen perusteella voidaan kehittää analyyttisiä kyselyitä.
Muiden tasojen tietolähteet, esimerkiksi liiketoimintamittarit, on jaettu kolmeen osaan.
Ensinnäkin nämä ovat ulkoisia yritysjärjestelmiä, Google Analyticsia, keräämme mittareita lokeista. Heiltä saamme dataa aktiivisista käyttäjistä, tuloksista ja kaikesta muusta liiketoimintaan liittyvästä. Toiseksi tämä on käyttöliittymän valvontajärjestelmä. Sitä pitäisi kuvata tarkemmin.
Aikoinaan aloitimme manuaalisella testauksella ja se kasvoi automaattisiksi toiminnallisuuden ja integraatioiden testauksiksi. Tästä teimme seurannan jättäen vain päätoiminnot ja luotimme mahdollisimman vakaisiin merkitsimiin, jotka eivät usein muutu ajan myötä.
Uusi tiimirakenne tarkoittaa, että kaikki sovellustoiminnot rajoittuvat tuoteryhmiin, joten lopetimme pelkän testauksen. Sen sijaan teimme Java-, Selenium- ja Jenkins-kielillä kirjoitetuista testeistä käyttöliittymäseurannan (käytetään raporttien käynnistämiseen ja luomiseen).
Meillä oli paljon testejä, mutta lopulta päätimme mennä päätielle, huipputason mittariin. Ja jos meillä on paljon erityisiä testejä, tietojen pitäminen ajan tasalla on vaikeaa. Jokainen myöhempi julkaisu rikkoo merkittävästi koko järjestelmän, ja me vain korjaamme sen. Siksi keskityimme hyvin perustavanlaatuisiin asioihin, jotka harvoin muuttuvat, ja vain seuraamme niitä.
Lopuksi, kolmanneksi, tietolähde on keskitetty lokijärjestelmä. Käytämme Elastic Stackia lokeihin, ja sitten voimme vetää nämä tiedot seurantajärjestelmäämme liiketoiminnan mittareille. Kaiken tämän lisäksi meillä on oma Pythonissa kirjoitettu Monitoring API -palvelu, joka kyselee mitä tahansa palveluita API:n kautta ja kerää niistä dataa Zabbixiin.
Toinen seurannan välttämätön ominaisuus on visualisointi. Meidän pohjamme on Grafana. Se erottuu muista visualisointijärjestelmistä siinä, että sen avulla voit visualisoida mittareita eri tietolähteistä kojelaudassa. Voimme kerätä verkkokaupan huipputason mittareita, esimerkiksi viimeisen tunnin aikana tehtyjen tilausten määrän DBMS:stä, suorituskykymittareita käyttöjärjestelmälle, jolla tämä verkkokauppa toimii, Zabbixista ja mittareita tämän sovelluksen esiintymistä. Prometheuksesta. Ja kaikki tämä on yhdellä kojelaudalla. Selkeä ja helposti saatavilla.
Huomautan turvallisuudesta - viimeistelemme parhaillaan järjestelmää, jonka integroimme myöhemmin globaaliin valvontajärjestelmään. Mielestäni suurimmat ongelmat, joita verkkokauppa kohtaa tietoturva-alalla, liittyvät boteihin, jäsentäjiin ja raakaan voimaan. Meidän on pidettävä tätä silmällä, sillä kaikki tämä voi vaikuttaa kriittisesti sekä sovelluksiemme toimintaan että maineeseemme liiketoiminnan näkökulmasta. Ja valitulla pinolla katamme onnistuneesti nämä tehtävät.
Toinen tärkeä seikka on, että Prometheus kokoaa levityskerroksen. Hän itse on myös integroitu Zabbixiin. Ja meillä on myös sitespeed, palvelu, jonka avulla voimme tarkastella parametreja, kuten sivumme latausnopeutta, pullonkauloja, sivun renderöintiä, skriptien latausta jne., se on myös API-integroitu. Joten mittarimme kerätään Zabbixissa, ja sen mukaisesti myös hälytämme sieltä. Kaikki hälytykset lähetetään tällä hetkellä tärkeimpiin lähetystapoihin (toistaiseksi se on sähköposti ja sähke, myös MS Teams on hiljattain yhdistetty). Hälytykset on tarkoitus päivittää sellaiseen tilaan, että älybotit toimivat palveluna ja tarjoavat seurantatietoa kaikille kiinnostuneille tuoteryhmille.
Meille mittaukset eivät ole tärkeitä vain yksittäisille tietojärjestelmille, vaan myös yleiset mittarit koko sovellusten käyttämälle infrastruktuurille: fyysisten palvelimien klusterit, joissa virtuaalikoneet toimivat, liikenteen tasapainottimet, verkon kuormituksen tasaajat, itse verkko, viestintäkanavien käyttö . Plus mittarit omille konesaleillemme (meillä on niitä useita ja infrastruktuuri on melko suuri).
Valvontajärjestelmämme etuja ovat, että sen avulla näemme kaikkien järjestelmien terveydentilan ja voimme arvioida niiden vaikutusta toisiinsa ja yhteisiin resursseihin. Ja viime kädessä se antaa meille mahdollisuuden osallistua resurssien suunnitteluun, mikä on myös meidän vastuullamme. Hallitsemme palvelinresursseja - verkkokaupan poolia, otamme käyttöön ja poistamme käytöstä uusia laitteita, ostamme uusia laitteita, teemme resurssien käytön auditoinnin jne. Joka vuosi tiimit suunnittelevat uusia projekteja, kehittävät järjestelmiään, ja meille on tärkeää tarjota heille resursseja.
Ja mittareiden avulla näemme tietojärjestelmiemme resurssien kulutuksen trendin. Ja niiden perusteella voimme suunnitella jotain. Virtualisointitasolla keräämme dataa ja näemme tietoja käytettävissä olevista resursseista konesalikohtaisesti. Ja jo konesalin sisällä näet resurssien kierrätyksen, varsinaisen jakelun ja kulutuksen. Lisäksi sekä erillisillä palvelimilla että virtuaalikoneiden ja fyysisten palvelimien klustereilla, joissa kaikki nämä virtuaalikoneet pyörivät voimakkaasti.
Tulevaisuudennäkymät
Nyt meillä on järjestelmän ydin kokonaisuudessaan valmis, mutta vielä on paljon asioita, joita on vielä työstettävä. Tämä on ainakin tietoturvakerros, mutta on myös tärkeää päästä verkkoon, kehittää hälytyksiä ja ratkaista korrelaatiokysymys. Meillä on monia tasoja ja järjestelmiä, ja jokaisessa tasossa on paljon enemmän mittareita. Se osoittautuu matryoshkaksi matryoshkan asteiseksi.
Tehtävämme on viime kädessä tehdä oikeat hälytykset. Esimerkiksi jos laitteistossa oli ongelma, taas virtuaalikoneen kanssa ja siellä oli tärkeä sovellus, eikä palvelua varmuuskopioitu millään tavalla. Saamme selville, että virtuaalikone on kuollut. Silloin bisnesmittarit varoittavat: käyttäjät ovat kadonneet jonnekin, konversiota ei ole, käyttöliittymä ei ole käytettävissä, ohjelmistot ja palvelut ovat myös kuolleet.
Tässä tilanteessa saamme roskapostia hälytyksistä, ja tämä ei enää sovi asianmukaisen valvontajärjestelmän muotoon. Herää kysymys korrelaatiosta. Siksi ihannetapauksessa valvontajärjestelmämme pitäisi sanoa: "Kaverit, fyysinen koneenne on kuollut ja sen mukana tämä sovellus ja nämä mittarit" yhden hälytyksen avulla sen sijaan, että pommittaisimme meitä raivokkaasti sadalla hälytyksellä. Sen tulisi raportoida pääasia - syy, joka auttaa poistamaan ongelman nopeasti sen lokalisoinnin vuoksi.
Ilmoitusjärjestelmämme ja hälytyskäsittelymme on rakennettu XNUMX tunnin hotline-palvelun ympärille. Kaikki hälytykset, joita pidetään pakollisina ja jotka sisältyvät tarkistuslistaan, lähetetään sinne. Jokaisessa hälytyksessä on oltava kuvaus: mitä tapahtui, mitä se todella tarkoittaa, mihin se vaikuttaa. Ja myös linkki kojelautaan ja ohjeet mitä tehdä tässä tapauksessa.
Tämä koskee hälytyksen rakentamisen vaatimuksia. Silloin tilanne voi kehittyä kahteen suuntaan - joko on ongelma ja se on ratkaistava, tai valvontajärjestelmässä on ollut vika. Mutta joka tapauksessa sinun täytyy mennä ja selvittää se.
Saamme nyt keskimäärin noin sata hälytystä päivässä, kun otetaan huomioon se, että hälytysten korrelaatiota ei ole vielä konfiguroitu oikein. Ja jos meidän on suoritettava teknisiä töitä ja sammutamme jotain väkisin, niiden määrä kasvaa merkittävästi.
Sen lisäksi, että valvomme käyttämiämme järjestelmiä ja keräämme puolellamme tärkeitä mittareita, seurantajärjestelmä mahdollistaa tietojen keräämisen tuotetiimeille. Ne voivat vaikuttaa mittareiden koostumukseen valvomiemme tietojärjestelmien sisällä.
Kollegamme saattaa tulla ja pyytää lisäämään joitain mittareita, joista on hyötyä sekä meille että tiimille. Tai esimerkiksi tiimillä ei ehkä ole tarpeeksi perusmittareita, joita meillä on, heidän on seurattava joitain tiettyjä mittareita. Grafanassa luomme jokaiselle joukkueelle tilan ja myönnämme järjestelmänvalvojan oikeudet. Lisäksi, jos tiimi tarvitsee kojelautaa, mutta se ei itse osaa/ei osaa tehdä sitä, autamme heitä.
Koska olemme tiimin arvonluonnin, niiden julkaisujen ja suunnittelun ulkopuolella, tulemme vähitellen siihen tulokseen, että kaikkien järjestelmien julkaisut ovat saumattomia ja ne voidaan ottaa käyttöön päivittäin ilman koordinointia kanssamme. Ja on tärkeää, että seuraamme näitä julkaisuja, koska ne voivat mahdollisesti vaikuttaa sovelluksen toimintaan ja rikkoa jotain, mikä on kriittistä. Julkaisujen hallintaan käytämme Bamboota, josta saamme dataa API:n kautta ja voimme nähdä mitkä julkaisut on julkaistu missä tietojärjestelmissä ja niiden tilan. Ja tärkeintä on, mihin aikaan. Asetamme julkaisumarkkereita tärkeimpien kriittisten mittareiden päälle, mikä on visuaalisesti erittäin suuntaa-antava ongelmatilanteissa.
Näin voimme nähdä korrelaation uusien julkaisujen ja esiin tulevien ongelmien välillä. Pääideana on ymmärtää järjestelmän toiminta kaikilla tasoilla, paikallistaa ongelma nopeasti ja korjata se yhtä nopeasti. Usein nimittäin käy niin, ettei ongelman ratkaiseminen vie eniten aikaa, vaan syyn etsiminen.
Ja tällä alueella haluamme jatkossa keskittyä proaktiivisuuteen. Ihannetapauksessa haluaisin tietää lähestyvästä ongelmasta etukäteen, en jälkikäteen, jotta voin ehkäistä sen ennemmin kuin ratkaista sen. Joskus valvontajärjestelmästä tulee vääriä hälytyksiä, sekä inhimillisistä virheistä että sovelluksen muutoksista. Ja me työskentelemme tämän parissa, teemme virheenkorjauksen ja yritämme varoittaa käyttäjiä, jotka käyttävät sitä kanssamme ennen valvontajärjestelmän manipulointia. , tai suorita nämä toiminnot teknisessä ikkunassa.
Joten järjestelmä on käynnistetty ja se on toiminut menestyksekkäästi kevään alusta lähtien... ja näyttää todella todellisia voittoja. Tämä ei tietenkään ole sen lopullinen versio, vaan esittelemme monia muita hyödyllisiä ominaisuuksia. Mutta juuri nyt, kun on niin monia integraatioita ja sovelluksia, valvontaautomaatio on todella väistämätöntä.
Jos seuraat myös suuria projekteja, joissa on huomattava määrä integraatioita, kirjoita kommentteihin, minkä hopealuotin löysit tähän.
Lähde: will.com