Tere, Habr! Olen Highload IT-süsteeme toetanud kümme aastat. Ma ei kirjuta selles artiklis probleemidest, mis on seotud nginxi seadistamisega režiimis 1000+ RPS või muudest tehnilistest asjadest. Jagan oma tähelepanekuid probleemidest protsessides, mis selliste süsteemide toetamisel ja toimimisel tekivad.
Jälgimine
Tehniline tugi ei oota, kuni saabub päring sisuga "Mis miks... sait ei tööta jälle?" Minuti jooksul pärast saidi kokkujooksmist peaks tugiteenus juba probleemi nägema ja seda lahendama hakkama. Kuid sait on jäämäe tipp. Selle kättesaadavus on üks esimesi, mida jälgitakse.
Mida teha olukorraga, kui e-poe järelejäänud kaup ei jõua enam ERP-süsteemist? Või on klientidele allahindlusi arvutav CRM-süsteem reageerimise lõpetanud? Näib, et sait töötab. Tingimuslik Zabbix saab oma 200 vastuse. Töövahetus pole jälgijatelt ühtegi teadet saanud ja vaatab mõnuga Troonide mängu uue hooaja esimest episoodi.
Jälgimine piirdub sageli ainult mälu, RAM-i ja serveriprotsessori koormuse mõõtmisega. Kuid äri jaoks on palju olulisem saada veebisaidil toodete kättesaadavus. Klastris oleva ühe virtuaalmasina tingimuslik rike toob kaasa asjaolu, et liiklus lakkab sinna minema ja teiste serverite koormus suureneb. Ettevõte ei kaota raha.
Seetõttu peate lisaks operatsioonisüsteemide tehniliste parameetrite jälgimisele serverites konfigureerima ärimõõdikud. Raha otseselt mõjutavad mõõdikud. Erinevad interaktsioonid väliste süsteemidega (CRM, ERP ja teised). Tellimuste arv teatud perioodiks. Edukad või ebaõnnestunud kliendi autoriseerimised ja muud mõõdikud.
Suhtlemine väliste süsteemidega
Iga veebisait või mobiilirakendus, mille aastakäive on üle miljardi rubla, suhtleb väliste süsteemidega. Alustades eelpool mainitud CRM-ist ja ERP-st ning lõpetades müügiandmete edastamisega välisesse Big Data süsteemi ostude analüüsimiseks ja kliendile toote pakkumiseks, mida ta kindlasti ostab (tegelikult mitte). Igal sellisel süsteemil on oma tugi. Ja sageli põhjustab nende süsteemidega suhtlemine valu. Eriti kui probleem on globaalne ja seda on vaja analüüsida erinevates süsteemides.
Mõned süsteemid pakuvad oma administraatoritele telefoninumbrit või telegrammi. Kusagil peate juhtidele kirju kirjutama või minema nende väliste süsteemide veajälgijate juurde. Isegi ühe suure ettevõtte kontekstis töötavad erinevates rakenduste arvestussüsteemides sageli erinevad süsteemid. Mõnikord muutub rakenduse oleku jälgimine võimatuks. Saate taotluse ühes tingimuslikus Jiras. Seejärel panite selle esimese Jira kommentaaridesse lingi teise Jira probleemile. Rakenduse teises Jiras kirjutab keegi juba kommentaari, et probleemi lahendamiseks peate helistama tingimuslikule administraatorile Andreile. Ja nii edasi.
Selle probleemi parim lahendus oleks luua suhtluseks ühtne ruum, näiteks Slackis. Kõigi välissüsteemide käitamise protsessis osalejate kutsumine liituma. Ja ka üks jälgija, et mitte rakendusi dubleerida. Rakendusi tuleks jälgida ühest kohast alates teadete jälgimisest kuni vealahenduste väljundini tulevikus. Ütlete, et see on ebareaalne ja ajalooliselt on juhtunud, et meie töötame ühes jälgijas ja nemad teises. Ilmusid erinevad süsteemid, neil olid oma autonoomsed IT-meeskonnad. Nõustun ja seetõttu tuleb probleem lahendada ülalt CIO või tooteomaniku tasandil.
Iga süsteem, millega suhtlete, peaks pakkuma tuge teenusena, millel on selge SLA, et lahendada probleemid prioriteedi alusel. Ja mitte siis, kui tingimuslikul administraatoril Andreil on teie jaoks minut aega.
Pudelikaela mees
Kas igal projektil (või tootel) on inimene, kelle puhkusele minek tekitab ülemustes krampe? See võib olla devopsi insener, analüütik või arendaja. Ainult devopsi insener teab ju, millistele serveritele millised konteinerid on paigaldatud, kuidas konteinerit probleemi korral taaskäivitada ja üldiselt ei saa ilma temata ühtegi keerulist probleemi lahendada. Analüütik on ainus, kes teab, kuidas teie keeruline mehhanism töötab. Millised andmevood kuhu lähevad. Milliste teenuste päringu parameetrite alusel saame vastused.
Kes saab kiiresti aru, miks logides on vigu ja parandab kiiresti toote kriitilise vea? Muidugi sama arendaja. On ka teisi, aga millegipärast saab ainult tema aru, kuidas süsteemi erinevad moodulid töötavad.
Selle probleemi juur on dokumentide puudumine. Lõppude lõpuks, kui kõik teie süsteemi teenused oleksid kirjeldatud, oleks probleemiga võimalik toime tulla ilma analüütikuta. Kui devops võttis paar päeva oma tihedast ajakavast välja ja kirjeldas kõiki servereid, teenuseid ja juhiseid tüüpiliste probleemide lahendamiseks, siis saaks probleemi tema puudumisel lahendada ka ilma temata. Te ei pea puhkuse ajal rannas õlut kiiresti lõpetama ja probleemi lahendamiseks WiFi-ühendust otsima.
Abipersonali pädevus ja vastutustunne
Suurprojektide puhul ei hoia ettevõtted arendajate palkadega kokku. Nad otsivad sarnastest projektidest kalleid keskastmeid või pensionäre. Toetusega on olukord veidi erinev. Neid kulusid püütakse igal võimalikul viisil vähendada. Ettevõtted palkavad odavaid eilseid Enikey töötajaid ja lähevad julgelt lahingusse. See strateegia on võimalik, kui räägime Zelenogradis asuva tehase visiitkaardi veebisaidist.
Kui me räägime suurest veebipoest, siis iga seisakutund maksab rohkem kui Enikey administraatori kuupalk. Võtame lähtepunktiks 1 miljard rubla aastakäibest. See on iga veebipoe minimaalne käive reitingust . Jagage see summa tundide arvuga aastas ja saate rohkem kui 100 000 rubla puhaskahju. Ja kui te ei arvesta öötunde, võite selle summa julgelt kahekordistada.
Aga raha pole ju peamine, eks? (ei, muidugi peaasi) On ka mainekaotusi. Tuntud veebipoe allakäik võib tekitada nii arvustuste laine sotsiaalvõrgustikes kui ka publikatsioone temaatilises meedias. Ja sõprade vestlusi köögis stiilis “Ära osta sealt midagi, nende koduleht on alati maas” ei saa üldse mõõta.
Nüüd vastutuse juurde. Minu praktikas oli juhus, kui valves olnud administraator ei vastanud õigeaegselt seiresüsteemi teatele saidi kättesaamatuse kohta. Mõnusal suvisel reedeõhtul lebas vaikselt ühe Moskva tuntud veebipoe koduleht. Laupäeva hommikul ei saanud selle saidi tootejuht aru, miks sait ei avanenud ning Slacki tugi- ja kiireloomuliste teadete vestlustes valitses vaikus. Selline viga läks meile maksma kuuekohalise summa ja sellele korrapidajale oma töökoha.
Vastutus on raskesti arenev oskus. Kas inimesel on see või mitte. Seetõttu proovin intervjuude käigus tuvastada selle olemasolu erinevate küsimustega, mis näitavad kaudselt, kas inimene on harjunud vastutust võtma. Kui inimene vastab, et valis ülikooli sellepärast, et vanemad nii ütlesid, või vahetab töökohta, kuna naine ütles, et ta ei teeni piisavalt, siis on parem selliste inimestega mitte suhelda.
Suhtlemine arendusmeeskonnaga
Kui kasutajatel tekib tootega töötamise ajal lihtsaid probleeme, lahendab tugi need ise. Püüab probleemi reprodutseerida, analüüsib logisid jne. Aga mida teha, kui tootes ilmneb viga? Sel juhul määrab tugi ülesande arendajatele ja siit algab lõbu.
Arendajad on pidevalt ülekoormatud. Nad loovad uusi funktsioone. Müügiga seotud vigade parandamine pole just kõige huvitavam tegevus. Järgmise sprindi läbimise tähtaeg läheneb. Ja siis tulevad ebameeldivad tugiisikud ja ütlevad: "Lõpetage kohe kõik, meil on probleeme." Selliste ülesannete prioriteet on minimaalne. Eriti kui probleem pole kõige kriitilisem ja saidi põhifunktsionaalsus töötab ning kui väljalaskehaldur ei jookse punnis silmadega ringi ega kirjuta: "Lisage see ülesanne kiiresti järgmisele väljalasele või kiirparandusele."
Tavalise või madala prioriteediga probleemid teisaldatakse väljalaskest väljalasele. Küsimusele "Millal ülesanne täidetakse?" saate vastused stiilis: "Vabandust, praegu on palju ülesandeid, küsige oma meeskonna juhtidelt või vabastamisjuhilt."
Tootlikkuse probleemid on olulisemad kui uute funktsioonide loomine. Halvad arvustused ei lase end kaua oodata, kui kasutajad komistavad pidevalt vigade otsa. Kahjustatud mainet on raske taastada.
Arenduse ja toe koostoime probleemid lahendab DevOps. Seda lühendit kasutatakse sageli konkreetse isiku kujul, kes aitab luua arenduseks testkeskkondi, koostab CICD torujuhtmeid ja toob testitud koodi kiiresti tootmisse. DevOps on lähenemine tarkvaraarendusele, kui kõik protsessis osalejad suhtlevad üksteisega tihedalt ning aitavad kiiresti tarkvaratooteid ja teenuseid luua ja värskendada. Pean silmas analüütikuid, arendajaid, testijaid ja tuge.
Selle lähenemisviisi puhul ei ole tugi ja arendus erinevad osakonnad, millel on oma eesmärgid ja eesmärgid. Areng on seotud toimimisega ja vastupidi. Levinud meeskondade kuulus fraas: “Probleem pole minu poolel” ei ilmu vestlustes enam nii sageli ja lõppkasutajad muutuvad veidi õnnelikumaks.
Allikas: www.habr.com