Përshëndetje, Habr! Gjatë dhjetë viteve kam mbështetur sistemet IT Highload. Nuk do shkruaj në këtë artikull për problemet e konfigurimit të nginx në regjimin 1000+ RPS ose gjëra të tjera teknike. Do ndaj vëzhgimet e mia mbi problemet në proceset që ndodhin gjatë mbështetjes dhe operimit të këtyre sistemeve.
Monitorimi
Stafi i mbështetjes nuk pret derisa të mbërrijë një kërkesë me përmbajtjen ‘Pse … faqja përsëri nuk funksionon?’. Mbështetja duhet të shohë problemin dhe të fillojë zgjidhjen e tij menjëherë pas rënies së faqes. Por faqja është maja e ajsbergut.Disponueshmëria e saj monitorohet si një nga prioritetet e para.
Si të veprosh kur stoku i produkteve në një dyqan online ka ndaluar së ardhuri nga sistemi ERP? Ose kur sistemi CRM, që llogarit zbritjet për klientë, ka ndaluar së përgjiguri? Faqja duket se funksionon. Një sistem si Zabbix merr përgjigjen e tij 200. Dita e zakonshme nuk ka marrë njoftime nga monitorimi dhe kënaqësisht shikon episodin e parë të sezonit të ri ‘Lojërat e Fronit’.
Shpesh monitorimi kufizohet vetëm në matjen e gjendjes së memories, RAM-it dhe ngarkesës së procesorëve. servera. Por për biznesin, është shumë më e rëndësishme të sigurohet disponueshmëria e produkteve në faqen e tij. Rënia e një makinerie virtuale në klaster do të çonte në një rënie të trafikimit në të dhe do të rritej ngarkesa mbi serverat e tjerë. Kompania nuk do të humbasë para.
Prandaj, përveç monitorimit të parametrave teknikë të sistemeve operative në servera, është e nevojshme të konfigurohen metrika biznesi. Metrika që ndikojnë drejtpërdrejt në financa. Ndërveprimi i ndryshëm me sistemet e jashtme (CRM, ERP dhe të tjerë). Numri i porosive për një periudhë të caktuar. Autorizime të suksesshme ose dështuar të klientëve dhe metrika të tjera.
Ndërveprimi me sistemet e jashtme.
Çdo faqe ose aplikacion mobil me një xhiro vjetore më shumë se një miliard rubla ndërvepron me sisteme të jashtme. Duke filluar nga CRM dhe ERP të përmendura më lart e deri te transferimi i të dhënave për shitjet në një sistem të jashtëm Big Data për analizën e blerjeve dhe ofrimin e produkteve për klientin, që ai me siguri do t'i blejë (në të vërtetë jo). Çdo sistem i tillë ka mbështetje të vetën. Dhe shpesh të folurit me këto sisteme shkakton shqetësim. Sidomos kur problemi është global dhe duhet të analizohet në sisteme të ndryshme.
Disa sisteme ofrojnë telefon ose telegram të adminëve të tyre. Diku duhet të shkruash letra menaxherëve ose të shkelesh në bug trackerat e këtyre sistemeve të jashtme. Edhe brenda një kompanie të madhe, sistemi të ndryshëm shpesh punojnë në sisteme të ndryshme të menaxhimit të kërkesave. Të gjurmohet statusi i kërkesës ndonjëherë bëhet e pamundur. Merrni një kërkesë në një Jira të caktuar. Pastaj në komentet e asaj Jira të parë vendosni një lidhje te një detyrë në Jira tjetër. Në Jira të dytë, dikush tashmë po shkruan një koment që duhet të telefonosh adminin e quajtur Andrei për të zgjidhur këtë çështje. Dhe kështu me radhë.
Zgjidhja optimale për këtë problem do të ishte krijimi i një hapësire të përbashkët për komunikim, për shembull në Slack. Ftesa në të për të gjithë pjesëmarrësit e procesit të operimit të sistemeve të jashtme. Po ashtu, një tracker të vetëm, për të mos duplikuar kërkesat. Kërkesat duhet të gjurmohen në një vend, duke filluar nga njoftimi i monitorimit deri te zgjidhja e gabimeve në prodhim. Mund të thoni se kjo është e pamundur dhe historikisht ka ndodhur që ne punojmë në një tracker, ndërsa ata në një tjetër. Sistemet e ndryshme shfaqen dhe ato kanë ekipet e tyre autonome IT. E pranoj dhe prandaj problemi duhet të zgjidhet nga lart, në nivelin e CIO ose pronarit të produktit.
Çdo sistem me të cilin ndërveproni duhet të ofrojë mbështetje si një shërbim me një SLA të qartë për zgjidhjen e problemeve sipas prioriteteve. E jo kur admini i quajtur Andrei të ketë një minutë për ju.
Njeriu si shishka e butelës.
Çdo projekt (ose produkt) ka një person të tillë, largimi i të cilit në pushim shkakton shqetësim te shefat? Ky mund të jetë një inxhinier devops, analist ose zhvillues. Vetëm inxhinieri devops e di se në cilat serverë janë instaluar cilat kontejnerë, si të rimbushë një kontejner në rast problemi dhe në përgjithësi çdo problem i komplikuar nuk zgjidhet pa të. Analisti është ai që e di si funksionon mekanizmi juaj i komplikuar. Çfarë rrjedhjesh të dhënash shkojnë ku, në cilat parametra pyetjesh në cilat shërbime, çfarë përgjigjesh do të marrim.
Kush do të kuptojë shpejt pse ka gabime në regjistra dhe do ta riparojë shpejt një gabim kritik në prodhim? Sigurisht ai zhvilluesi i famshëm. Ka dhe të tjerë, por për çudinë time, vetëm ai e kupton si janë të organizuara modul të ndryshme të sistemit.
Kjo problematikë rrjedh nga mungesa e dokumentacionit.. Sepse, nëse të gjitha shërbimet e sistemit tuaj do të ishin të dokumentuara, do të ishte e mundur të kuptonit problemin edhe pa një analist. Po të kishte ndarë devops disa ditë nga grafiku i tij i ngjeshur për të përshkruar të gjitha serverët, shërbimet dhe udhëzimet për zgjidhjen e problemeve tipike, atëherë problemi që erdhi nga mungesa e tij do të mund të zgjidhej edhe pa të. Nuk është e nevojshme të shpejtoni së paku për të pirë birrën tuaj në plazh dhe të kërkoni wi-fi për të zgjidhur ndonjë problem.
Kompedenca dhe përgjegjësia e punonjësve të mbështetjes
Në projektet e mëdha, kompanitë nuk kursejnë në pagat për zhvilluesit. Ata kërkojnë mjaftueshëm të shtrenjtë mid-level ose seniorë nga projekte të ngjashme. Situata me mbështetje është pak ndryshe. Këto shpenzime përpiqen të reduktohen. Kompanitë punësojnë njerëz të rinj të papërvojë dhe shkojnë në betejë pa hezitim. Kjo strategji bëhet e mundur, nëse flasim për një faqe vizitë të ndonjë fabrike në Zelenograd.
Nëse flasim për një dyqan të madh online, çdo orë qëndrese kushton më shumë se paga mujore e një tekniku të thjeshtë. Le të marrim si pikë referimi 1 miliard rubla xhiro vjetore. Kjo është xhiro minimale për çdo dyqan online nga lista e . E ndarë këtë shumë me numrin e orëve në vit, ne marrim më shumë se 100,000 rubla humbje të pastër. Dhe nëse nuk llogarisim orët e natës, atëherë mund ta dyfishojmë këtë shifër.
Por paratë nuk janë të gjitha, apo jo? (jo, natyrisht që janë të gjitha) Ka gjithashtu humbje reputacioni. Një orë qëndrese e një dyqani të njohur online mund të nxjerrë një valë komentesh në rrjetet sociale, si dhe botime në median e specializuar. Dhe bisedat e miqve në kuzhinë në stilin "Mos blini asgjë atje, ata kanë një сайт që nuk punon asnjëherë" nuk mund të matet fare.
Tani për përgjegjësinë. Në praktikën time ka pasur një rast kur një administrator i natës nuk reagoi në kohë ndaj njoftimit të sistemit të monitorimit për papjeshmërinë e faqes. Në një mbrëmje të këndshme verore të premten, faqja e një dyqani të njohur online në Moskë ndaloi së funksionuari. Në mëngjesin e së shtunës, produkti i kësaj faqeje nuk e kuptoi pse faqja nuk hapet, dhe në bisedat e mbështetjes dhe njoftimet urgjente në Slack nuk kishte asgjë. Kjo gabim na kushtoi një shifër me gjashtë shifra, dhe ndihmën e administratorit.
Përgjegjësia është një aftësi e vështirë për t'u zhvilluar. Ajo ose e ka njeri, ose nuk e ka. Prandaj, gjatë intervistave, përpiqem të zbuloj praninë e saj përmes pyetjeve të ndryshme që tregojnë indirekt nëse personi është mësuar të marrë përgjegjësinë mbi vete. Nëse personi përgjigjet se zgjodhi universitetin, sepse kështu thonin prindërit ose ndërron punë sepse gruaja tha se merr shumë pak, atëherë është më mirë të mos lidhemi me këta njerëz.
Bashkëveprimi me ekipin e zhvillimit
Kur në prodhim, gjatë përdorimit, përdoruesit hasin probleme të thjeshta, mbështetja i zgjidh ato me forcat e saj. Mundohen të riprodhojnë problemin, analizojnë logjet etj. Por çfarë të bëjmë kur një defekt shfaqet në prodhim? Në këtë rast, mbështetja hap një detyrë për zhvilluesit dhe këtu fillon e gjithë historia interesante.
Zhvilluesit janë vazhdimisht të ngarkuar. Ata janë të angazhuar në krijimin e veçorive të reja. Të riparosh defekte në prodhim është thënë se nuk është detyra më emocionuese. Afatet për të përfunduar sprintin e radhës janë të ngushta. Dhe këtu vijnë njerëz jo të këndshëm nga mbështetja dhe thonë: "Bëni urgjentisht gjithçka, kemi probleme". Prioriteti i këtyre detyrave është minimal. Sidomos kur problemi nuk është shumë kritik dhe funksionaliteti themelor i faqes po funksionon, dhe kur menaxheri i lëshimit nuk po vrapon me sytë përjashtues dhe nuk shkruan: "Bëjërini urgjentisht këtë detyrë në lëshimin e ardhshëm ose hotfix."
Detyrat me prioritet normal ose të ulët kalojnë nga një lëshim në një tjetër. Në pyetjen "Kur do të përfundohen detyrat?" do të merrni përgjigje si: "Më fal, tani kemi shumë detyra, pyetni liderët e ekipit ose menaxherin e lëshimit."
Problemet në prodhim kanë prioritet më të lartë se krijimi i veçorive të reja. Komentet negative nuk do të vonojnë, nëse përdoruesit vazhdojnë të hasin defekte. Rregullimi i reputacionit të prishur është i vështirë.
Problemet e bashkëveprimit të zhvillimit dhe mbështetjes i zgjidh DevOps. Kjo akronim shpesh përdoret si një person i caktuar që ndihmon në krijimin e mjediseve testuese për zhvillimin, ndërtimin e CICD pipeline-ve dhe nxjerrjen e shpejtë të kodit të provuar në prodhim. DevOps është një qasje për zhvillimin e softuerit, ku të gjithë pjesëmarrësit e procesit bashkëveprojnë ngushtësisht dhe ndihmojnë në krijimin dhe përmirësimin më të shpejtë të produkteve dhe shërbimeve softuerike. Kam parasysh analistët, zhvilluesit, testuesit dhe mbështetjen.
Mbështetja dhe zhvillimi në këtë qasje nuk janë departamente të ndryshme me qëllime dhe detyra të veçanta. Zhvillimi është i angazhuar në operim dhe anasjelltas. Shprehja famëkeqe e kolektiveve të shpërndara: "Problemi nuk është në anën time" tashmë nuk përmendet aq shpesh në biseda, dhe përdoruesit fundor po bëhen pak më të lumtur.
Burimi: habr.com
