Tere, Habr! Kümme aastat olen toetanud Highload IT süsteeme. Ei hakka selles artiklis kirjutama nginx-i seadistamise probleemidest töötamises 1000+ RPS režiimis või muudest tehnilistest teemadest. Jagame tähelepanekuid probleemidest protsessides, mis tekivad selliste süsteemide toetamisel ja kasutamisel.
Jälgimine
Tehniline tugi ei oota, kuni tuleb pilet tekstiga "Miks... veebileht ei tööta jälle?". Tugi peaks nägema probleemi minut pärast veebilehe langemist ja hakkama seda lahendama. Aga veebileht on jäämäe tipp.Selle kättesaadavust jälgitakse esmajärjekorras.
Kuidas käituda olukorras, kus internetipoe kaupade jäägid ei tule enam ERP süsteemist? Või CRM süsteem, mis arvutab klientide allahindlusi, ei vasta? Veebileht näeb välja, et töötab. Oletame, et Zabbix saab oma 200 vastuse. Valvegrupp ei saanud jälgimisest mingeid teateid ja vaatab rõõmsalt esimest osa uue hooaja "Troonide mängust".
Tihti piirduvad jälgimised ainult mälu, RAM-i ja protsessorite koormuse mõõtmisega. serverite. Kuid ettevõttele on palju tähtsam saada teavet toote kättesaadavuse kohta veebilehel. Oletatav ühe virtuaalmasina langemine klastris toob kaasa selle, et liiklus lõpetab sinna minemise ja koormus teistel serveritel suureneb. Raha ettevõte ei kaota.
Seetõttu tuleb SERVERITE OPERATSIOONISÜSTEEMIDE tehniliste parameetrite jälgimise kõrval seadistada ka äri metrikad. Metrikad, mis mõjutavad otse raha. Erinevad interaktsioonid väliste süsteemidega (CRM, ERP jne). Tellimuste arv teatud ajavahemikul. Edukad või ebaõnnestunud klientide autoriseerimised ja muud metrikad.
Interaktsioon väliste süsteemidega
Igal veebilehel või mobiilirakendusel, mille aastane käive ületab miljard rubla, on interaktsioon väliste süsteemidega. Alates eelmainitud CRM-ide ja ERP-de tegemisest kuni müügiandmete edastamise nii-öelda Big Data analüüsisüsteemile, et pakkuda kliendile toodet, mida ta kindlasti ostab (mille puhul tegelikult on see vale). Igal sellisel süsteemil on oma tugi. Ja tihti nendega suhtlemine põhjustab valu. Eriti siis, kui probleem on suur ja seda tuleb analüüsida erinevates süsteemides.
Mõned süsteemid annavad telefoni või telegrammi oma administraatorite jaoks. Teistes tuleb kirjutada kirju juhtidele või käia nende väliste süsteemide veaparandusregistrites. Isegi ühe suure ettevõtte raames töötavad erinevad süsteemid sageli erinevates piletihaldussüsteemides. Taotluse staatuse jälgimine muutub mõnikord võimatuks. Sa saad taotluse ühe niisuguse Jira-s. Siis paned selle esimese Jira kommentaari link teise Jira ülesande juurde. Teises Jiras kirjutab keegi ülesande kommenteerimisel, et tuleb helistada nii-öelda administraatorile Andreile, et probleemi lahendada. Ja nii edasi.
Optimaalne lahendus sellele probleemile oleks luua ühtne suhtluspind, näiteks Slackis. Kõigi väliste süsteemide kasutuselevõtu osaliste kaasamine sinna. Ja ka ühtne tracker, et taotlusi ei dubleeritaks. Taotlusi tuleks jälgida ühes kohas, alustades jälgimise teavitamisest kuni veaparanduste rakendamiseni. Te ütlete, et see pole teostatav, ja teie ajaloos on nii, et me töötame ühes trackeris, samas kui nemad on teises. On olnud erinevaid süsteeme, nendel on olnud oma iseseisvad IT meeskonnad. Olen nõus, ja seetõttu tuleb probleem lahendada kõrgelt, CIO või toote omaniku tasemel.
Iga süsteem, millega te suhtlete, peab osutama tuge teenusena, millel on selged SLA-d probleemide lahendamiseks prioriteetide kohaselt. Mitte siis, kui niisugune administraator Andr poolt leidub teile minut.
Inimene - pudelikael
Igal projektil (või tootel) on selline inimene, kelle puhkusele minek tekitab ülemustes krampimist? See võib olla devops insener, analüütik või arendaja. Sest just devops insener teab, millistel serveritel on millised konteinerid, kuidas konteinerit probleemi korral taaskäivitada, ja igasugused keerulised probleemid ei lahene ilma temata. Analüütik on ainus, kes teab, kuidas teie keeruline mehhanism töötab. Millised andmevood kuhu lähevad. Milliste päringute parameetritel, millistelt teenustelt me vastuseid saame.
Kes mõistab kiiresti, miks logides on vigu ja kiiresti parandab kriitilise vea tootmises? Loomulikult see sama arendaja. On ka teisi, kuid kuidagi ainult tema mõistab, kuidas erinevad süsteemi moodulid on üles ehitatud.
Selle probleemi juureks on dokumentatsiooni puudumine.. Sest juhul, kui kõik teie süsteemi teenused oleksid dokumenteeritud, saaks probleemi lahendamiseks hakkama ka ilma analüütikuta. Kui devops võtaks oma tihedast ajakavast paar päeva ja dokumenteeriks kõik serverid, teenused ja tüüpiliste probleemide lahendamise juhised, oleks tema puudumisel probleemi võimalik lahendada ka ilma temata. Ei ole vaja puhkusel kiiresti oma õlut randa juua ja otsida wi-fi-d probleemide lahendamiseks.
Toetuse töötajate pädevus ja vastutus
Suurtel ettevõtteprojektidel ei peeta palgarahas kokkuhoidmist ratsionaalseks. Otsitakse kallimaid kesk- ja vanema taseme spetsialiste sarnastelt projektidelt. Toetuse osas on olukord veidi erinev. Nende kulutustega üritatakse igati kokku hoida. Ettevõtted palkavad odavaid eelmise päeva IT-töötajaid ja suunduvad julgelt lahingusse. Selline strateegia on võimalik, kui on tegu mõne tehase visiitkaardisaidiga Zelenogradis.
Kui räägime suurest veebipoest, siis iga seiskumise tund maksab rohkem kui adminni eelarve kuu palk. Võtame aluseks 1 miljard rubla aastase tulu. See on minimaalne käive igasugusel veebipoel, mis on TOP-100 edetabelis 2018. aastal. . Jagame selle summa aastas töötundide arvu ja saame üle 100 000 rubla puhtaid kaotusi. Ja kui arvesse ei võeta öiseid tunde, võib summat julgelt kahekordistada.
Aga raha ei ole ju kõige olulisem, eks? (ei, loomulikult on see peamine) On veel ka maine kaotused. Ühe tuntud veebipoe tõrkumine võib põhjustada nii sotsiaalmeedia arvustuste laine kui ka artiklite avaldamise spetsiaalsetes meediakanalites. Ja sõbrad köögis arutlemas stiilis "Ära osta seal midagi, nende saidil on pidevad probleemid" on mõõdetamatud.
Nüüd vastutuse juurde. Minu praktikas oli juhtum, kus valveadministraator ei reageerinud õigeaegselt süsteemi jälgimise teavitusele saidi kättesaamatuse osas. Kenal suvisel reedel oli üks tuntud veebipood Moskvas vaikse tõrke hetkeks. Laupäeva hommikul ei saanud saidi tootja aru, miks sait ei avane, ja tugikõnedes ja Slacki kiirteavitustes valitses vaikus. Selline viga maksis meile kuuekohalise summa ja sellele valvele tööd.
Vastus on oskus, mida on raske arendada. See kas on inimese omadus või ei. Seetõttu püüan tööintervjuudel avastada selle olemasolu erinevate küsimustega, mis kaudselt näitavad, kas inimene on harjunud vastutust enda peale võtma. Kui inimene vastab, et valis ülikooli, kuna vanemad ütlesid, või vahetab tööd, sest naine ütles, et ta teenib vähe, siis tasub nendega suheldes ettevaatlik olla.
Koostöö arendustiimiga
Kui tootmisprotsessis on kasutajatel kergeid probleeme, lahendab tugiteenus need omal jõul. Nad püüavad probleemi reprodutseerida, analüüsivad logisid ja nii edasi. Kuid mis juhtub, kui tootmisse ilmub bug? Sellisel juhul loob tugiteenus arendajatele ülesande ja just seal algavad kõige huvitavamad sündmused.
Arendajad on pidevalt ülekoormatud. Nad loovad uusi funktsioone. Veebipoe vigade parandamine ei ole just kõige huvitavam tegevus. Tähtaegu oodatakse järgmise sprinti lõpetamiseks. Ja siis tulevad ebasoovitavad inimesed tugiteenusest ja ütlevad: "Ära kõhkle, meil on probleemid". Selliste ülesannete prioriteet on minimaalne. Eriti kui probleem ei ole kõige kriitilisem ja saidi põhifunktsioon töötab ning kui väljalaskejuht ei jookse ringi ja ei ütle: "Sisesta see ülesanne lähimasse väljaandmise või hotfixi".
Tavapärased või madala prioriteediga ülesanded liiguvad uude väljaannet. Küsimusele "Millal ülesanne valmib?" saad vastuseid stiilis: "Kahjuks on meil praegu palju ülesandeid, küsige tiimijuhilt või väljaandmisjuhtidelt."
Probleemid tootmises on suurema prioriteediga kui uute funktsioonide loomine. Halvad arvustused ei lase end oodata, kui kasutajad pidevalt oma vigadega kokku puutuvad. Rikkunud reputatsiooni taastamine on keeruline.
Arenduse ja toetuse koostöö küsimusi lahendab DevOps. Seda akronüümi kasutatakse sageli konkreetse inimesena, kes aitab luua arendusele katsetamiseks keskkondi, ehitab CICD torujuhti ja toob testitud koodi kiiresti tootmisse. DevOps on lähenemine tarkvara arendusele, kus kõik osalised töötavad tihedalt koos ja aitavad kiiremalt luua ja ajakohastada arvutitooteid ja teenuseid. Ma mõtlen analüütikute, arendajate, testijate ja tugiteenuse peale.
Toetamine ja arendus sellises lähenemises ei ole erinevad osakonnad oma eesmärkide ja ülesannetega. Arendus on kaasatud tegevusse ja vastupidi. Kuulus fraas jaotatud meeskondade seas: „Probleem ei ole minu poolel” ei ilmu enam nii tihti vestlustesse ja lõppkasutajad on natuke õnnelikumad.
Allikas: habr.com
