Við hugsuðum um að búa til eftirlitskerfi á því stigi að mynda vöruteymi. Það varð ljóst að viðskipti okkar - hagnýting - falla ekki í þessi lið. Afhverju er það?
Staðreyndin er sú að öll okkar teymi eru byggð upp í kringum einstök upplýsingakerfi, örþjónustur og svið, þannig að teymin sjá ekki heildarheilbrigði alls kerfisins í heild. Til dæmis vita þeir kannski ekki hvernig einhver lítill hluti í djúpa bakendanum hefur áhrif á framendann. Áhugasvið þeirra takmarkast við þau kerfi sem kerfi þeirra er samþætt við. Ef lið og þjónusta þess A hafa nánast engin tengsl við þjónustu B, þá er slík þjónusta nánast ósýnileg teyminu.
Teymið okkar vinnur aftur á móti með kerfi sem eru mjög sterk samþætt hvert við annað: það eru margar tengingar á milli þeirra, þetta er mjög stór innviði. Og rekstur netverslunarinnar fer eftir öllum þessum kerfum (sem við höfum, við the vegur, gríðarlega mikið af).
Svo kemur í ljós að deildin okkar tilheyrir ekki neinu liði heldur er hún staðsett aðeins til hliðar. Í allri þessari sögu er verkefni okkar að skilja ítarlega hvernig upplýsingakerfi virka, virkni þeirra, samþættingu, hugbúnað, netkerfi, vélbúnað og hvernig allt þetta tengist hvert öðru.
Vettvangurinn sem netverslanir okkar starfa á lítur svona út:
- framan
- milliskrifstofa
- bakvinnslu
Sama hversu mikið við viljum, það gerist ekki að öll kerfi virki snurðulaust og gallalaust. Aðalatriðið er aftur fjöldi kerfa og samþættinga - með eitthvað eins og okkar eru sum atvik óumflýjanleg, þrátt fyrir gæði prófana. Þar að auki, bæði innan sérstakrar kerfis og hvað varðar samþættingu þeirra. Og þú þarft að fylgjast með ástandi alls pallsins ítarlega, en ekki bara einstaka hluta hans.
Helst ætti heilsuvöktun alls staðar að vera sjálfvirk. Og við komum að eftirliti sem óumflýjanlegur hluti af þessu ferli. Upphaflega var það aðeins smíðað fyrir framlínuhlutann, á meðan netsérfræðingar, hugbúnaðar- og vélbúnaðarstjórar höfðu og hafa enn sín eigin lag-fyrir-lag eftirlitskerfi. Allt þetta fólk fylgdist aðeins með eftirlitinu á sínu stigi, enginn hafði heldur yfirgripsmikinn skilning.
Til dæmis, ef sýndarvél hrynur, veit í flestum tilfellum aðeins stjórnandinn sem ber ábyrgð á vélbúnaðinum og sýndarvélin um það. Í slíkum tilfellum sá framlínuteymið staðreyndina um hrun forritsins, en það hafði ekki gögn um hrun sýndarvélarinnar. Og stjórnandinn getur vitað hver viðskiptavinurinn er og haft grófa hugmynd um hvað er í gangi núna á þessari sýndarvél, að því tilskildu að þetta sé einhvers konar stórt verkefni. Hann veit líklegast ekki um litlu börnin. Allavega þarf stjórnandinn að fara til eigandans og spyrja hvað hafi verið á þessari vél, hvað þarf að endurheimta og hverju þarf að breyta. Og ef eitthvað virkilega alvarlegt bilaði fóru þeir að hlaupa í hringi - því enginn sá kerfið í heild sinni.
Að lokum hafa slíkar ólíkar sögur áhrif á allan framenda, notendur og kjarnastarfsemi okkar - sölu á netinu. Þar sem við erum ekki hluti af teymi, heldur tökum þátt í rekstri allra netverslunarforrita sem hluti af netverslun, tókum við að okkur að búa til alhliða eftirlitskerfi fyrir netverslunarvettvanginn.
Kerfisuppbygging og stafla
Við byrjuðum á því að bera kennsl á nokkur vöktunarlög fyrir kerfin okkar, þar sem við þyrftum að safna mælingum. Og allt þetta þurfti að sameina, sem er það sem við gerðum á fyrsta stigi. Nú á þessu stigi erum við að leggja lokahönd á hágæða safn mæligilda yfir öll lögin okkar til að byggja upp fylgni og skilja hvernig kerfi hafa áhrif á hvert annað.
Skortur á alhliða eftirliti á fyrstu stigum ræsingar forritsins (síðan við byrjuðum að byggja það þegar flest kerfin voru í framleiðslu) leiddi til þess að við áttum verulegar tæknilegar skuldir til að setja upp vöktun á öllu pallinum. Við höfðum ekki efni á því að einbeita okkur að því að setja upp vöktun fyrir eina IS og vinna ítarlega vöktun fyrir því, þar sem restin af kerfunum yrði skilin eftir án vöktunar í einhvern tíma. Til að leysa þetta vandamál fundum við lista yfir nauðsynlegustu mælikvarða til að meta stöðu upplýsingakerfisins fyrir lag og byrjuðum að innleiða það.
Því ákváðu þeir að borða fílinn í köflum.
Kerfið okkar samanstendur af:
- vélbúnaður;
- stýrikerfi;
- hugbúnaður;
- HÍ hlutar í vöktunarforritinu;
- viðskiptamælingar;
- samþættingarforrit;
- upplýsingaöryggi;
- netkerfi;
- umferðarjafnvægi.
Miðpunktur þessa kerfis er að fylgjast með sjálfu sér. Til að skilja almennt ástand alls kerfisins þarftu að vita hvað er að gerast með forritum á öllum þessum lögum og yfir allt forritasettið.
Svo, um bunkann.
Við notum opinn hugbúnað. Í miðstöðinni erum við með Zabbix, sem við notum fyrst og fremst sem viðvörunarkerfi. Allir vita að það er tilvalið fyrir eftirlit með innviðum. Hvað þýðir þetta? Nákvæmlega þessar lágu mælikvarðar sem hvert fyrirtæki sem heldur úti eigin gagnaveri hefur (og Sportmaster er með eigin gagnaver) - hitastig netþjóns, minnisstaða, raid, mæligildi fyrir nettæki.
Við höfum samþætt Zabbix við Telegram Messenger og Microsoft Teams, sem eru virkir notaðir í teymum. Zabbix nær yfir lagið af raunverulegu netkerfi, vélbúnaði og einhverjum hugbúnaði, en það er engin töfralausn. Við auðgum þessi gögn frá sumum öðrum þjónustum. Til dæmis, á vélbúnaðarstigi, tengjumst við beint í gegnum API við sýndarvæðingarkerfið okkar og söfnum gögnum.
Hvað annað. Auk Zabbix notum við Prometheus, sem gerir okkur kleift að fylgjast með mælingum í kraftmiklu umhverfisforriti. Það er að segja, við getum tekið á móti mæligildum forrita í gegnum HTTP endapunkt og ekki haft áhyggjur af því hvaða mælikvarða á að hlaða inn í hann og hverjar ekki. Byggt á þessum gögnum er hægt að þróa greiningarfyrirspurnir.
Gagnaheimildum fyrir önnur lög, til dæmis viðskiptamælingar, er skipt í þrjá þætti.
Í fyrsta lagi eru þetta ytri viðskiptakerfi, Google Analytics, við söfnum mæligildum úr annálum. Frá þeim fáum við gögn um virka notendur, viðskipti og allt annað sem tengist fyrirtækinu. Í öðru lagi er þetta eftirlitskerfi HÍ. Því skal lýst nánar.
Einu sinni byrjuðum við á handvirkum prófunum og það óx í sjálfvirkar prófanir á virkni og samþættingu. Úr þessu gerðum við vöktun, skildum aðeins eftir helstu virknina og treystum á merki sem eru eins stöðug og mögulegt er og breytast ekki oft með tímanum.
Nýja teymisskipanin þýðir að öll forritastarfsemi er bundin við vöruteymi, svo við hættum að gera hreinar prófanir. Þess í stað gerðum við UI-vöktun úr prófunum, skrifuð í Java, Selenium og Jenkins (notað sem kerfi til að ræsa og búa til skýrslur).
Við tókum fullt af prófum, en á endanum ákváðum við að fara á þjóðveginn, efsta stigið. Og ef við höfum mikið af sérstökum prófum verður erfitt að halda gögnunum uppfærðum. Hver síðari útgáfa mun brjóta verulega allt kerfið og allt sem við gerum er að laga það. Þess vegna lögðum við áherslu á mjög grundvallaratriði sem breytast sjaldan og fylgjumst aðeins með þeim.
Að lokum, í þriðja lagi, er gagnagjafinn miðstýrt skógarhöggskerfi. Við notum Elastic Stack fyrir logs og þá getum við dregið þessi gögn inn í eftirlitskerfið okkar fyrir viðskiptamælingar. Til viðbótar við allt þetta höfum við okkar eigin Vöktunar API þjónustu, skrifuð í Python, sem leitar í allar þjónustur í gegnum API og safnar gögnum frá þeim inn í Zabbix.
Annar ómissandi eiginleiki eftirlits er sjónræn. Okkar byggir á Grafana. Það sker sig úr meðal annarra sjónrænnar kerfa að því leyti að það gerir þér kleift að sjá mælingar frá mismunandi gagnaveitum á mælaborðinu. Við getum safnað efstu mælingum fyrir netverslun, til dæmis fjölda pantana sem hafa verið gerðar á síðustu klukkustund frá DBMS, árangursmælingar fyrir stýrikerfið sem þessi netverslun keyrir á frá Zabbix og mælikvarða fyrir tilvik þessa forrits frá Prometheus. Og allt þetta verður á einu mælaborði. Skýrt og aðgengilegt.
Leyfðu mér að athuga um öryggi - við erum núna að leggja lokahönd á kerfið, sem við munum síðar samþætta við alþjóðlega eftirlitskerfið. Að mínu mati eru helstu vandamálin sem rafræn viðskipti standa frammi fyrir á sviði upplýsingaöryggis tengd bottum, parsers og brute force. Við þurfum að fylgjast með þessu, því allt getur þetta haft gagnrýnin áhrif á bæði rekstur forrita okkar og orðspor okkar frá viðskiptalegu sjónarmiði. Og með völdum stafla náum við þessum verkefnum með góðum árangri.
Annar mikilvægur punktur er að umsóknarlagið er sett saman af Prometheus. Sjálfur er hann líka samþættur Zabbix. Og við erum líka með sitespeed, þjónustu sem gerir okkur kleift að skoða færibreytur eins og hleðsluhraða síðunnar okkar, flöskuhálsa, flutning síðunnar, hleðslu forskrifta osfrv., hún er líka API samþætt. Þannig að mælingum okkar er safnað í Zabbix og í samræmi við það látum við líka vita þaðan. Allar tilkynningar eru sem stendur sendar til helstu sendingaraðferða (í augnablikinu er það tölvupóstur og símskeyti, MS Teams hefur einnig nýlega verið tengt). Það eru áform um að uppfæra viðvörun í það ástand að snjallbottar virki sem þjónusta og veiti öllum áhugasömum vöruteymum vöktunarupplýsingar.
Fyrir okkur eru mælikvarðar ekki aðeins mikilvægir fyrir einstök upplýsingakerfi heldur einnig almennar mælikvarðar fyrir allan innviði sem forrit nota: klasa af líkamlegum netþjónum sem sýndarvélar keyra á, umferðarjafnarar, netálagsjafnarar, netkerfið sjálft, nýting samskiptaleiða. . Auk mælikvarða fyrir okkar eigin gagnaver (við erum með nokkrar þeirra og innviðirnir eru frekar stórir).
Kostir eftirlitskerfisins okkar eru að með hjálp þess sjáum við heilsufar allra kerfa og getum metið áhrif þeirra hvert á annað og á sameiginleg auðlind. Og að lokum gerir það okkur kleift að taka þátt í auðlindaáætlun, sem er líka ábyrgðarsvið okkar. Við höfum umsjón með netþjónaauðlindum - safni innan rafrænna viðskipta, temjum og tekjum nýjan búnað í notkun, kaupum nýjan viðbótarbúnað, gerum úttekt á auðlindanýtingu o.fl. Á hverju ári skipuleggja teymi ný verkefni, þróa kerfin sín og það er mikilvægt fyrir okkur að útvega þeim fjármagn.
Og með hjálp mælikvarða sjáum við þróunina í auðlindanotkun upplýsingakerfa okkar. Og út frá þeim getum við skipulagt eitthvað. Á sýndarvæðingarstigi söfnum við gögnum og sjáum upplýsingar um tiltækt magn auðlinda eftir gagnaverum. Og þegar inni í gagnaverinu geturðu séð endurvinnslu, raunverulega dreifingu og neyslu auðlinda. Þar að auki, bæði með sjálfstæða netþjóna og sýndarvélar og klasa af líkamlegum netþjónum sem allar þessar sýndarvélar snúast kröftuglega um.
Horfur
Núna erum við með kjarna kerfisins í heild tilbúinn en það er enn margt sem þarf að vinna í. Að minnsta kosti er þetta upplýsingaöryggislag, en það er líka mikilvægt að ná til netsins, þróa viðvörun og leysa vandamálið um fylgni. Við erum með mörg lög og kerfi og á hverju lagi eru miklu fleiri mælikvarðar. Það reynist vera matryoshka að því marki sem matryoshka.
Verkefni okkar er að lokum að gera réttar viðvaranir. Til dæmis, ef það var vandamál með vélbúnaðinn, aftur, með sýndarvél, og það var mikilvægt forrit og þjónustan var ekki afrituð á nokkurn hátt. Við komumst að því að sýndarvélin er dáin. Þá munu viðskiptamælingar láta þig vita: notendur hafa horfið einhvers staðar, engin umbreyting er, notendaviðmótið í viðmótinu er ekki tiltækt, hugbúnaður og þjónusta hafa einnig dáið.
Í þessum aðstæðum munum við fá ruslpóst frá áminningum og þetta passar ekki lengur inn í viðeigandi eftirlitskerfi. Spurningin um fylgni vaknar. Þess vegna ætti eftirlitskerfið okkar helst að segja: „Krakkar, líkamlega vélin þín hefur dáið, og ásamt þessu forriti og þessum mælingum,“ með hjálp einnar viðvörunar, í stað þess að sprengja okkur í heift með hundrað viðvörunum. Það ætti að tilkynna aðalatriðið - orsökina, sem hjálpar til við að útrýma vandamálinu fljótt vegna staðsetningar þess.
Tilkynningakerfið okkar og viðvörunarvinnsla er byggð upp í kringum XNUMX-tíma símaþjónustu. Þangað eru sendar allar áminningar sem teljast nauðsynlegar og eru á gátlistanum. Hver viðvörun verður að hafa lýsingu: hvað gerðist, hvað það þýðir í raun, hvaða áhrif það hefur. Og einnig tengill á mælaborðið og leiðbeiningar um hvað á að gera í þessu tilfelli.
Þetta snýst allt um kröfurnar til að búa til viðvörun. Þá getur ástandið þróast í tvær áttir - annaðhvort er vandamál og þarf að leysa eða bilun hefur orðið í eftirlitskerfinu. En í öllum tilvikum þarftu að fara og finna út úr því.
Að meðaltali fáum við nú um hundrað viðvaranir á dag, að teknu tilliti til þess að fylgni viðvarana hefur ekki enn verið rétt stillt. Og ef við þurfum að framkvæma tæknilega vinnu, og við slökkum valdi á einhverju, eykst fjöldi þeirra verulega.
Auk þess að fylgjast með þeim kerfum sem við rekum og safna mælingum sem eru taldar mikilvægar af okkar hálfu, gerir eftirlitskerfið okkur kleift að safna gögnum fyrir vöruteymi. Þær geta haft áhrif á samsetningu mæligilda innan upplýsingakerfa sem við fylgjumst með.
Samstarfsmaður okkar gæti komið og beðið um að bæta við einhverju mæligildi sem mun nýtast bæði okkur og teymið. Eða, til dæmis, getur teymið ekki nóg af grunnmælingum sem við höfum; þeir þurfa að fylgjast með einhverjum sérstökum. Í Grafana búum við til pláss fyrir hvert lið og veitum stjórnandaréttindi. Einnig, ef teymi þarf mælaborð, en það sjálft getur/veitt ekki hvernig á að gera það, hjálpum við þeim.
Þar sem við erum utan flæðis verðmætasköpunar liðsins, útgáfur þeirra og áætlanagerðar, erum við smám saman að komast að þeirri niðurstöðu að útgáfur allra kerfa eru óaðfinnanlegar og hægt er að rúlla út daglega án samhæfingar við okkur. Og það er mikilvægt fyrir okkur að fylgjast með þessum útgáfum, því þær gætu hugsanlega haft áhrif á virkni forritsins og brotið eitthvað, og þetta er mikilvægt. Til að stjórna útgáfum notum við Bamboo, þaðan sem við fáum gögn í gegnum API og getum séð hvaða útgáfur hafa verið gefnar út í hvaða upplýsingakerfum og stöðu þeirra. Og það mikilvægasta er á hvaða tíma. Við setjum útgáfumerki ofan á helstu mikilvægu mælikvarðana, sem er sjónrænt mjög leiðbeinandi ef vandamál koma upp.
Þannig getum við séð fylgni milli nýrra útgáfur og vandamála sem koma upp. Meginhugmyndin er að skilja hvernig kerfið virkar á öllum lögum, staðsetja vandamálið fljótt og laga það jafn fljótt. Þegar öllu er á botninn hvolft gerist það oft að það sem tekur mestan tíma er ekki að leysa vandamálið, heldur að leita að orsökinni.
Og á þessu sviði í framtíðinni viljum við leggja áherslu á frumkvæði. Helst myndi ég vilja vita um vandamál sem er að nálgast fyrirfram, en ekki eftir á, svo að ég geti komið í veg fyrir það frekar en að leysa það. Stundum koma upp rangar viðvaranir eftirlitskerfisins, bæði vegna mannlegra mistaka og vegna breytinga á forritinu. Og við vinnum að þessu, kemba það og reynum að vara notendur sem nota það með okkur við þessu áður en eftirlitskerfið er meðhöndlað. , eða framkvæma þessar aðgerðir í tækniglugganum.
Þannig að kerfið hefur verið opnað og hefur virkað með góðum árangri síðan í byrjun vors... og sýnir mjög raunverulegan hagnað. Auðvitað er þetta ekki endanleg útgáfa þess; við munum kynna marga fleiri gagnlega eiginleika. En núna, með svo mörgum samþættingum og forritum, er sjálfvirkni vöktunar í raun óhjákvæmileg.
Ef þú fylgist líka með stórum verkefnum með umtalsverðum fjölda samþættinga skaltu skrifa í athugasemdirnar hvaða silfurkúlu þú fannst fyrir þetta.
Heimild: www.habr.com