Përshëndetje, Habr! Dhjetë vjet kam mbështetur sistemet Highload IT. Nuk do të shkruaj në këtë artikull mbi problemet e konfigurimit të nginx për të punuar në modin 1000+ RPS ose gjërat e tjera teknike. Do të ndaj vëzhgimet mbi problemet në proceset që shfaqen në mbështetje dhe funksionimin e këtyre sistemeve.
Monitorimi
Support-i nuk pret derisa të vije një kërkesë me përmbajtjen "Pse... faqeja përsëri nuk funksionon?". Mbështetja duhet të shohë problemin dhe të fillojë ta zgjidhë atë një minutë pas rënies së faqes. Por faqja është maja e ajsbergut.. Disponueshmëria e saj monitorohet si një nga të parat.
Si të veprohet në situatën kur mbetjet e mallrave në dyqanin online kanë ndaluar së ardhuri nga sistemi ERP? Ose sistemi CRM, i cili llogarit zbritjet për klientët, ka ndaluar së përgjiguri? Faqja në dukje funksionon. Zabbix merr përgjigjen e tij 200. Ndërrimi i rojes nuk ka marrë ndonjë njoftim nga monitorimi dhe me gëzim po shikon serinë 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. serverësh. Por për biznesin është shumë më e rëndësishme të marrë disponueshmërinë e mallrave në faqen. Një rënie e ndërsjellë e një makine virutale në grup do të çojë në faktin që trafiku do të ndalojë duke u drejtuar atij dhe ngarkesa do të rritet në serverët 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 metrikat e biznesit. Metrikat që ndikojnë drejtpërdrejt në para. Ndryshimet e ndryshme me sistemet e jashtme (CRM, ERP dhe të tjera). Numri i porosive për një periudhë të caktuar kohe. Autorizimet e suksesshme ose jo të klientëve dhe metrika të tjera.
Ndërveprimi me sistemet e jashtme.
Çdo faqe ose aplikacion mobil me një qarkullim vjetor më shumë se një miliard rubla ndërvepron me sisteme të jashtme. Duke filluar nga CRM dhe ERP të përmendura më sipër dhe përfunduar me transmetimin e të dhënave mbi shitjet në një sistem të jashtëm Big Data për analizimin e blerjeve dhe ofertën për klientin e një produkti që ai gjithmonë do të blejë (në të vërtetë, jo). Çdo sistem i tillë ka mbështetje të tij. Dhe shpesh komunikimi me këto sisteme shkakton dhimbje. Sidomos kur problemi është global dhe duhet të analizohet në sisteme të ndryshme.
Disa disa sisteme ofrojnë telefon apo telegram menaxherëve të tyre. Disa herë duhet të dërgosh email menaxherëve ose të shkuash në sistemet e gjurmimit të këtyre sistemeve të jashtme. Edhe brenda një kompanie të madhe, sisteme të ndryshme shpesh funksionojnë në sisteme të ndryshme për regjistrimin e kërkesave. Të ndjekësh statusin e një kërkese herë pas here bëhet e pamundur. Merrni një kërkesë në një Jira të përgjithshme. Pastaj, në komentet e asaj Jira të parë vendosni një lidhje me një detyrë në një Jira tjetër. Në Jira të dytë, dikush tashmë shkruan një koment se duhet të telefononi administratorin e supozuar Andrey për të zgjidhur problemin. Dhe kështu me radhë.
Një zgjidhje optimale për këtë problem do të ishte krijimi i një hapësire unike për komunikim, për shembull në Slack. Ftesa për të gjithë pjesëmarrësit në procesin e operimit të sistemeve të jashtme. Po ashtu, një gjurmues unik, për të mos e dubluar kërkesën. Kërkesat duhet të ndjekin në një vend, duke filluar nga njoftimi i monitorimit deri te zgjidhja e gabimeve në prodhim. Mund të thoni se kjo nuk është reale dhe historikisht keni punuar në një gjurmues, dhe ata në një tjetër. Këtu janë shfaqur sisteme të ndryshme, dhe ato kishin ekipet e tyre autonome të IT-së. Pajtohem dhe prandaj problemi duhet të zgjidhet në nivele të larta nga CIO ose pronari i produktit.
Çdo sistem me të cilin ju bashkëpunoni duhet të ofrojë mbështetje si një shërbim me një SLA të qartë për zgjidhjen e problemeve sipas prioriteteve. Dhe jo kur ndonjëherë administratori i supozuar Andrey ka një minutë për ju.
Njeriu - ngushtica
Çdo projekt (ose produkt) ka një person të tillë, i mungesa e të cilit në pushim shkakton trembje te menaxherët? Mund të jetë një inxhinier devops, analisti ose programuesi. Sepse vetëm inxhinieri devops di se në cilat serverë janë instaluar cilat konteinerë, si të rindez një konteiner në rast problemi, dhe në përgjithësi, çdo problem kompleks nuk zgjidhet pa të. Analisti është i vetmi që e di se si funksionon mekanizmi juaj i komplikuar. Cilët flukset e të dhënave shkojnë ku, nën cilat parametra kërkesat në cilat shërbime, cilat do të marrim si përgjigje.
Kush do të kuptojë shpejt pse ka gabime në loge dhe do të rregullojë shpejt një bug kritik në prodhim? Sigurisht, ai programuesi. Ka edhe të tjerë, por për ndonjë arsye, vetëm ai e kupton se si janë të ndërtuara modulet e ndryshme të sistemit.
Rruga kryesore e këtij problemi është mungesa e dokumentacionitSepse nëse të gjitha shërbimet e sistemit tuaj do të ishin të përshkruara, atëherë do të ishte e mundur të zgjidhnit problemin edhe pa një analist. Nëse devops do të kishte ndarë disa ditë nga grafiku i tij të ngarkuar dhe do të kishte përshkruar të gjitha serverat, shërbimet dhe udhëzimet për zgjidhjen e problemeve tipike, problemi në mungesën e tij do të mund të zgjidhej dhe pa të. Nuk ka nevojë të ngacmohet shpejt të pijë birrën e tij në plazh gjatë pushimit dhe të kërkojë wi-fi për të zgjidhur një problem.
Aftësia dhe përgjegjësia e punonjësve të mbështetjes
Në projektet e mëdha, kompanitë nuk kursehen në paga për zhvilluesit. Ato kërkojnë mid-level ose senior me pagesa të larta nga projekte të ngjashme. Situata me mbështetje është pak ndryshe. Këto shpenzime përpiqen të reduktohen në çdo mënyrë. Kompanitë punësojnë njerëz të lirë, të sapodiplomuar dhe me guxim përballen me sfidat. Kjo strategji është 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ë ndalim kushton më shumë se paga mujore e një administratori të sapodiplomuar. Të marrim si pikënisje 1 miliard rubla të ardhura vjetore. Kjo është minimalja për çdo dyqan online nga renditja . Ta ndajmë këtë shumë me numrin e orëve në vit dhe do të marrim më shumë se 100 000 rubla humbje të pastra. Dhe nëse nuk i llogarisim orët e natës, mund të rrisim shumën dyfish.
Por paratë nuk janë gjithçka, apo jo? (jo, natyrisht që janë të rëndësishme) Ka gjithashtu humbje reputacioni. Një orë rënie e një dyqani të njohur online mund të shkaktojë si një valë komentesh në rrjetet sociale, ashtu edhe publikime në mediat tematike. Bisedat e miqve në kuzhinë si "Mos ble asgjë atje, faqja e tyre është gjithmonë e mbyllur" nuk mund të matet fare.
Tani për përgjegjësinë. Në përvojën time, kishte një rast kur admini në turn nuk reagoi në kohë ndaj njoftimit të sistemit të monitorimit për mosaksesin e faqes. Në një mbrëmje të këndshme verore dhe faqja e një dyqani të njohur online në Moskë qetësisht ra. Në mëngjesin e të shtunës, produkti i këtij siti nuk e kuptoi pse faqja nuk hapet, dhe në bisedat e mbështetjes dhe njoftimeve urgjente në Slack ishte qetësi. Një gabim i tillë na kushtoi një shumë me pesë shifra, dhe këtij admini i kushtoi punën.
Përgjegjësia është një aftësi që është e vështirë për t'u zhvilluar. Ai e di t’i shkojë njeriut a nuk është. Prandaj, gjatë intervistave mundohem të zbuloj praninë e saj përmes pyetjeve të ndryshme, të cilat tregojnë në mënyrë indirekte nëse personi është mësuar të marrë përgjegjësi për veten. Nëse personi përgjigjet se e zgjodhi universitetin sepse kështu thanë prindërit, ose ndryshon punë sepse gruaja tha se fiton pak, atëherë është më mirë të mos lidhemi me këta njerëz.
Bashkëpunimi me ekipin e zhvillimit
Kur në prodhim, gjatë përdorimit, përdoruesit hasin probleme të thjeshta, mbështetjeja i zgjidh ato me forcat e saj. Mundohet të riprodhojë problemin, analizon logët dhe kështu me radhë. Por çfarë të bëjmë kur një bug shfaqet në prodhim? Në këtë rast, mbështetjeja hap një detyrë për zhvilluesit dhe këtu fillon e gjithë historia interesante.
Zhvilluesit janë vazhdimisht të ngarkuar. Ata merren me krijimin e veçorive të reja. Korrigjimi i bug-eve që dalin në prodhim është një aktivitet, le të themi, jo shumë interesant. Ka afate të ngushta për përfundimin e sprintit tjetër. Dhe këtu vijnë njerëz të pakëndshëm nga mbështetja dhe thonë: "Shpejt, lëre gjithçka, kemi probleme." Prioriteti i këtyre detyrave është minimal. Sidomos kur problemi nuk është shumë kritik dhe funksionaliteti kryesor i faqes funksionon, dhe kur menaxheri i lëshimeve nuk vrapon me sy të mbushur dhe nuk shkruan: "Shpejt, fut këtë detyrë në lëshimin më të afërt ose hotfix."
Detyrat me prioritet normal ose të ulët kalojnë nga lëshimi në lëshim. Kur pyet: "Kur do të përfundojë detyra?", do të marrësh përgjigje në stilin: "Më fal, tani kemi shumë detyra, pyet liderët e ekipit ose menaxherin e lëshimeve."
Problemët në prodhim kanë një prioritet më të lartë se krijimi i veçorive të reja. Opinione të këqija nuk do të vonojnë, nëse përdoruesit do të hasin vazhdimisht në bug-e. Të rikuperosh një reputacion të prishur është e vështirë.
Çështjet e bashkëpunimit ndërmjet zhvillimit dhe mbështetjes zgjidhen nga DevOps. Kjo akronim përdoret shpesh në formën e një personi konkret, i cili ndihmon në krijimin e ambienteve testuese për zhvillimin, ndërton pipeline CICD dhe nxjerr shpejt kodin e testuar në prodhim. DevOps është një qasje në zhvillimin e softuerit, ku të gjithë pjesëmarrësit e procesit bashkëpunojnë ngushtë me njëri-tjetrin 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ështetje.
Mbështetje dhe zhvillimi në këtë qasje nuk janë departamente të ndryshme me qëllime dhe detyra të veta. Zhvillimi është i përfshirë në operim dhe anasjelltas. Është më pak e zakonshme që fraza e njohur e kolektiveve të shpërndara: "Problemi nuk është në anën time" të shfaqet në biseda, dhe përdoruesit përfundimtarë bëhen pak më të lumtur.
Burimi: habr.com
