Tere, Habr! Kümme aastat olen toetanud Highload IT-süsteeme. Ma ei hakka selles artiklis kirjutama probleeme nginx'i seadistamisest 1000+ RPS režiimis või teistest tehnilistest asjadest. Jagame tähelepanekuid probleemidest protsessides, mis tekivad selliste süsteemide hooldamisel ja kasutamisel.
Jälgimine
Tehniline tugi ei oota, kuni saabub päring sisu "Miks… sait jälle ei tööta?". Tugi peab nägema probleemi ja hakkama seda lahendama minut pärast saidi kukkumist. Kuid sait on jäämäe tipp.. Selle kättesaadavust jälgitakse esimesena.
Kuidas käituda olukorras, kus internetipoe kaubad on lakanud ERP-süsteemist tulemast? Või CRM-süsteem, mis arvutab soodustusi klientidele, on lakatanud vastamast? Sait paistab ju töötavat. Tinglik Zabbix saab oma 200 vastuse. Valveva vahetuse meeskond ei ole jälgimisest mingeid teateid saanud ja rõõmsalt vaatab "Troonide mängu" uue hooaja esimest osa.
Tihti piiratakse jälgimist ainult mälu, operatiivmäluga ja protsessorite koormuse mõõtmisega. serverid. Kuid äri jaoks on kordades olulisem saada juurdepääs kauba olemasolule saidil. Tinglik ühe virtuaalse masina kukkumine klastri sees toob kaasa selle, et liiklus ei suundu enam sinna ja teistel serveritel koormus suureneb. Raha ettevõte ei kaota.
Seetõttu tuleb tehniliste parameetrite jälgimise kõrval seadistada ka äri-metriid. Metriid, mis mõjutavad otseselt raha. Erinevad interaktsioonid väliste süsteemidega (CRM, ERP jne). Tellimuste arv teatud aja jooksul. Klientide edukad või ebaõnnestunud autentimised ja teised metriid.
Koostöö väliste süsteemidega
Iga veebisait või mobiilirakendus, mille aastane käive ületab ühe miljardi rubla, suhtleb väliste süsteemidega. Alates eespool mainitud CRM-ist ja ERP-st kuni andmete edastamiseni müükidest välisele Big Data analüüsisüsteemile, et pakkuda kliendile toodet, mille ta kindlasti ostab ( tegelikult mitte ). Igal sellisel süsteemil on oma tugi. Ja sageli suheldes nende süsteemidega tekib valu. Eriti kui probleem on globaalne ja seda tuleb analüüsida erinevates süsteemides.
Mõned süsteemid annavad oma administraatorite telefoninumbrid või Telegrami kontaktid. Mõnes kohas tuleb kirjutada kirju juhtidele või käia nende väliste süsteemide viga jälgimistarkvaras. Isegi ühes suuremas ettevõttes töötavad erinevad süsteemid tihti erinevates taotluste haldamise süsteemides. Taotluse staatuse jälgimine muutub mõnikord võimatuks. Sa saad taotluse ühes oletatavas Jiras. Seejärel paned selle esimese Jira kommentaaris lingi teise Jira ülesande peale. Teises Jiras kirjutab keegi juba kommentaari, et on vaja helistada oletatavale administraatorile Andreile, et küsimus lahendada. Ja nii edasi.
Optimaalne lahendus sellisele probleemile oleks luua ühtne suhtluskeskkond, näiteks Slackis. Kõigi väliste süsteemide haldamise protsessis osalejate kutsumine sinna. Samuti ühtne jälgimissüsteem, et mitte topelt taotlusi esitada. Taotlusi tuleks jälgida ühes kohas, alates seire teavitamisest kuni vigade lahendamise viimiseni tootmisse. Te ütlete, et see pole reaalne ja teil on ajalooline traditsioon, et teie töötate ühes jälgimissüsteemis, samas kui nemad teises. Ilmusid erinevad süsteemid, igaühel olid oma autonoomsed IT-meeskonnad. Olen nõus, ja seetõttu tuleb probleem lahendada ülevalt, CIO või toote omanikku tasemel.
Iga süsteem, millega te koostööd teete, peaks pakkuma tuge teenusena, millel on selge SLA probleemide lahendamiseks prioriteetide järgi. Mitte siis, kui oletatav administraator Andreil juhtub olema teie jaoks minut aega.
Inimene- pudeli kael
Igal projektil (või tootmisel) on see inimene, kelle puhkusele minek tekitab juhtkonnas krampide tekkimise? See võib olla devops insener, analüütik või arendaja. Ainult devops insener teab, millistel serveritel on millised konteinerid, kuidas konteinerit probleemi korral taaskäivitada, ja igasugused keerulised probleemid lahendatakse ilma temata. Analüütik teab ainus, kuidas teie keeruline mehhanism töötab. Millised andmevood kuhugi suunduvad. Milliste päringute parameetrite korral millistesse teenustesse, millised vastused me saame.
Kes mõistab kiiresti, miks logides on vead ja lahendab kiiresti kriitilise vea tootmises? Loomulikult see arendaja. On ka teisi, kuid miks just tema mõistab, kuidas erinevad süsteemi moodulid töötavad.
Selle probleemi juureks on dokumentatsiooni puudumine.Sest kui kõik teie süsteemi teenused oleksid kirja pandud, oleks probleemiga võimalik tegeleda ka ilma analüütikuta. Kui devops võtaks oma tihedast ajakavast paar päeva, et kirja panna kõik serverid, teenused ja juhised tüüpiliste probleemide lahendamiseks, saaks probleemi tema puudumisel samuti lahendada. Puudub vajadus puhkuse ajal kiiresti oma õlut rannas joobes otsida wi-fi'd, et probleemiga tegeleda.
Toetuse töötajate kompetents ja vastutus
Suurtel ettevõtte projektidel ei kitsita arendajate palkadega. Jahtides kallis mudeleid või vanemaid töötajaid analoogsetelt projektidelt. Toetuse puhul on olukord veidi erinev. Need kulud püütakse igati vähendada. Ettevõtted palkavad odavaid eilseid tehnikud ja lähevad julgelt lahingusse. Selline strateegia on võimalik, kui teema on näiteks mõne tehase visiitkaart veebis Zelenogradis.
Kui jutt käib suurest e-poest, siis iga seisak tunneb end rohkem kui haldustöötaja kuupalk. Võtame aluseks 1 miljard rubla aastas käivet. See on minimaalne käive igasugustes e-poodides TOP-100 nimekirja 2018. aastast. . Jagame selle summa aastas töötunde ja saame üle 100 000 rubla puhtaid kaotusi. Ja kui mitte arvestada öötunde, siis saab summat julgelt kahekordistada.
Aga raha pole ju peamine, eks? (ei, loomulikult on peamine) On veel mainekaotusi. Tuntud e-poe tunni langemine võib tekitada nii laine tagasisidet sotsiaalmeedias kui ka artikleid erialastes väljaannetes. Ja sõbrad köögis räägivad stiilis „Ära osta seal midagi, nende veebisait on pidevalt maas”, on sõnasõnalt mõõtmata.
Nüüd vastutuse juurde. Minu praktikas oli juhtum, kui valveadministraator ei reageerinud õigel ajal süsteemi jälgimise teavitamisele veebisaidi kättesaamatuse kohta. Ilus suvine reedeõhtu ja tuntud internetipood Moskvas oli vaikselt maas. Laupäeva hommikul ei saanud selle saidi tootejuht aru, miks veebisait ei avane, ja tosupport ja Slacki hädaabiturgude jututoa vaikimine. Selline viga maksis meile kuuekohalise summa ja sellele valveadministraatorile tööd.
Vastus - oskus, mida on raske arendada. Kas inimesel on see või ei ole. Seetõttu püüan tööintervjuudel selgitada, kas see on olemas, esitades erinevaid küsimusi, mis kaudselt näitavad, kas inimene on harjunud vastutust enda peale võtma. Kui inimene vastab, et valis ülikooli, kuna vanemad nii ütlesid, või vahetab tööd, kuna naine ütles, et ta teenib liiga vähe, siis nende inimestega pole parem tegeleda.
Koostöö arendusmeeskonnaga
Kui tootmises tekivad kasutajatel lihtsalt probleeme, lahendab tugi need oma jõududega. Nad proovivad probleemi reproduceerida, analüüsivad logisid ja nii edasi. Aga mida teha, kui tootmises ilmneb viga? Sellisel juhul loob tugi arendajatele ülesande ja siin hakkab kõige huvitavam osa.
Arendajad on pidevalt ülekoormatud. Nad tegelevad uute funktsioonide loomisega. Vigade parandamine tootmises ei ole just kõige huvitavam tegevus. Tootmise sprintide tähtaegadega on hõivatud. Ja siis tulevad ebameeldivad inimesed toest ja ütlevad: "Häda, jäta kõik meelest, meil on probleemid." Selliste ülesannete prioriteet on minimaalne. Eriti kui probleem ei ole kõige kriitilisem ja veebilehe põhifunktsionaalsus töötab, ning kui väljaandmise juhendaja ei jookse ringi laienevate silmadega ja ei kirjuta: "Häda, pane see ülesanne järgmistesse väljaannetes või kuumfixiisse."
Tavalise või madala prioriteediga ülesanded lähevad väljaandest väljaandesse. Küsimusele "Millal ülesanne täidetakse?" saad vastuseid stiilis: "Vabandust, praegu on palju ülesandeid, küsi tiimijuhtidelt või väljaande juhendajalt."
Tootmisprobleemid on suurema prioriteediga kui uute funktsioonide loomine. Halvad arvustused ei lase end kaua oodata, kui kasutajad pidevalt vigadega kokku puutuvad. Rikkunud maine taastamine on keeruline.
Arenduse ja toe koostöö küsimusi lahendab DevOps. Seda lühendit kasutatakse sageli konkreetse inimesena, kes aitab luua arenduseks katsekeskkondi, ehitab CICD torujuhtmeid ja viib kiiresti katsetatud koodi tootmisse. DevOps on lähenemine tarkvaraarendusele, kus kõik protsessi osalised suhtlevad tihedalt üksteisega ning aitavad kiiremini luua ja uuendada tarkvaratooteid ja teenuseid. Ma mõtlen analüütikute, arendajate, testijate ja toe peale.
Toetamine ja arendamine ei ole erinevad osakonnad oma eesmärkide ja ülesannetega. Arendus on kaasatud käitamise protsessidesse ja vastupidi. Kuulus lause hajutatud meeskondades: "Probleem ei ole minu poolel" ei ilmu enam nii tihti vestlustesse ning lõppkasutajad tunnevad end veidi õnnelikumalt.
Allikas: habr.com
