Përshëndetje, Habr! Unë kam mbështetur sistemet Highload IT për dhjetë vjet. Unë nuk do të shkruaj në këtë artikull për problemet e konfigurimit të nginx për të punuar në modalitetin 1000+ RPS ose gjëra të tjera teknike. Unë do të ndaj vëzhgimet e mia për problemet në proceset që lindin në mbështetjen dhe funksionimin e sistemeve të tilla.
Monitorimi
Mbështetja teknike nuk pret derisa të arrijë një kërkesë me përmbajtjen "Çfarë Pse... faqja nuk po funksionon përsëri?" Brenda një minutë pas rrëzimit të faqes, mbështetja duhet ta shohë tashmë problemin dhe të fillojë ta zgjidhë atë. Por vendi është maja e ajsbergut. Disponueshmëria e tij është një nga të parat që monitorohet.
Çfarë duhet bërë me situatën kur mallrat e mbetura të një dyqani online nuk vijnë më nga sistemi ERP? Apo sistemi CRM që llogarit zbritjet për klientët ka ndaluar të përgjigjet? Faqja duket se po funksionon. Zabbix i kushtëzuar merr përgjigjen e tij 200. Ndërrimi i detyrës nuk ka marrë asnjë njoftim nga monitorimi dhe po shikon me kënaqësi episodin e parë të sezonit të ri të Game of Thrones.
Monitorimi shpesh kufizohet vetëm në matjen e gjendjes së kujtesës, RAM-it dhe ngarkesës së procesorit të serverit. Por për biznesin është shumë më e rëndësishme të marrësh disponueshmërinë e produktit në faqen e internetit. Dështimi i kushtëzuar i një makine virtuale në grup do të çojë në faktin se trafiku do të ndalojë të shkojë në të dhe ngarkesa në serverët e tjerë do të rritet. Kompania nuk do të humbasë para.
Prandaj, përveç monitorimit të parametrave teknikë të sistemeve operative në serverë, duhet të konfiguroni matjet e biznesit. Metrikë që ndikojnë drejtpërdrejt në para. Ndërveprime të ndryshme me sisteme të jashtme (CRM, ERP dhe të tjera). Numri i porosive për një periudhë të caktuar kohore. Autorizimet e klientëve të suksesshëm ose të pasuksesshëm dhe metrika të tjera.
Ndërveprimi me sistemet e jashtme
Çdo faqe interneti ose aplikacion celular me një qarkullim vjetor prej më shumë se një miliardë rubla ndërvepron me sistemet e jashtme. Duke filluar nga CRM dhe ERP e sipërpërmendur dhe duke përfunduar me transferimin e të dhënave të shitjeve në një sistem të jashtëm Big Data për të analizuar blerjet dhe për t'i ofruar klientit një produkt që ai patjetër do ta blejë (në fakt, jo). Secili sistem i tillë ka mbështetjen e vet. Dhe shpesh komunikimi me këto sisteme shkakton dhimbje. Sidomos kur problemi është global dhe ju duhet ta analizoni atë në sisteme të ndryshme.
Disa sisteme ofrojnë një numër telefoni ose telegram për administratorët e tyre. Diku duhet t'u shkruani letra menaxherëve ose të shkoni te gjurmuesit e gabimeve të këtyre sistemeve të jashtme. Edhe brenda kontekstit të një kompanie të madhe, sisteme të ndryshme shpesh operojnë në sisteme të ndryshme të kontabilitetit të aplikacioneve. Ndonjëherë bëhet e pamundur të gjurmosh statusin e një aplikacioni. Ju merrni një kërkesë në një Jira të kushtëzuar. Pastaj në komentin e kësaj Jira të parë ju vendosni një lidhje me çështjen në një tjetër Jira. Në Jira-n e dytë në aplikacion, dikush tashmë po shkruan një koment që ju duhet të telefononi administratorin e kushtëzuar Andrey për të zgjidhur çështjen. Dhe kështu me radhë.
Zgjidhja më e mirë për këtë problem do të ishte krijimi i një hapësire të vetme për komunikim, për shembull në Slack. Duke ftuar të gjithë pjesëmarrësit në procesin e funksionimit të sistemeve të jashtme për t'u bashkuar. Dhe gjithashtu një gjurmues i vetëm në mënyrë që të mos dublikohen aplikacionet. Aplikacionet duhet të gjurmohen në një vend, nga monitorimi i njoftimeve deri te dalja e zgjidhjeve të gabimeve në të ardhmen. Ju do të thoni se kjo është joreale dhe historikisht ka ndodhur që ne të punojmë në një gjurmues, dhe ata të punojnë në një tjetër. U shfaqën sisteme të ndryshme, ata kishin ekipet e tyre autonome të IT. Jam dakord, dhe për këtë arsye problemi duhet të zgjidhet nga lart në nivel CIO ose pronari 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 të zgjidhur çështjet sipas përparësisë. Dhe jo kur administratori i kushtëzuar Andrey ka një minutë për ju.
Njeri i ngushticës
A kanë të gjithë në një projekt (ose produkt) një person, shkuarja në pushime e të cilit shkakton konvulsione mes eprorëve të tyre? Ky mund të jetë një inxhinier devops, analist ose zhvillues. Në fund të fundit, vetëm një inxhinier devops e di se cilët serverë kanë cilat kontejnerë të instaluar, si të rindizni kontejnerin në rast të një problemi dhe në përgjithësi, çdo problem kompleks nuk mund të zgjidhet pa të. Analisti është i vetmi që e di se si funksionon mekanizmi juaj kompleks. Cilat rryma të dhënash shkojnë. Në cilat parametra kërkesash për cilat shërbime, cilat do të marrim përgjigje.
Kush do ta kuptojë shpejt pse ka gabime në regjistra dhe do të rregullojë menjëherë një defekt kritik në produkt? Sigurisht i njëjti zhvillues. Ka të tjerë, por për disa arsye vetëm ai e kupton se si funksionojnë modulet e ndryshme të sistemit.
Rrënja e këtij problemi është mungesa e dokumentacionit. Në fund të fundit, nëse do të përshkruheshin të gjitha shërbimet e sistemit tuaj, atëherë do të ishte e mundur të merresh me problemin pa një analist. Nëse devops do të merrte disa ditë nga orari i tij i ngjeshur dhe do të përshkruante të gjithë serverët, shërbimet dhe udhëzimet për zgjidhjen e problemeve tipike, atëherë problemi në mungesë të tij mund të zgjidhej pa të. Ju nuk keni nevojë të përfundoni shpejt birrën tuaj në plazh gjatë pushimeve dhe të kërkoni wi-fi për të zgjidhur problemin.
Kompetenca dhe përgjegjësia e personelit mbështetës
Në projektet e mëdha, kompanitë nuk kursejnë në pagat e zhvilluesve. Ata janë në kërkim të të mesmeve apo të moshuarve të shtrenjtë nga projekte të ngjashme. Me mbështetje situata është pak më ndryshe. Ata po përpiqen t'i ulin këto kosto në çdo mënyrë. Kompanitë punësojnë punëtorë të lirë të djeshëm Enikey dhe me guxim shkojnë në betejë. Kjo strategji është e mundur nëse po flasim për një faqe interneti të kartës së biznesit të një uzine në Zelenograd.
Nëse po flasim për një dyqan të madh online, atëherë çdo orë pushimi kushton më shumë se paga mujore e një administratori të Enikey. Le të marrim si pikënisje 1 miliardë rubla qarkullim vjetor. Ky është xhiroja minimale e çdo dyqani në internet nga vlerësimi . Ndani këtë shumë me numrin e orëve në vit dhe merrni më shumë se 100 rubla humbje neto. Dhe nëse nuk i numëroni orët e natës, mund ta dyfishoni me siguri shumën.
Por paraja nuk është gjëja kryesore, apo jo? (jo, sigurisht gjëja kryesore) Ka edhe humbje reputacioni. Rënia e një dyqani të mirënjohur në internet mund të shkaktojë si një valë komentesh në rrjetet sociale ashtu edhe botime në media tematike. Dhe bisedat e miqve në kuzhinë në stilin "Mos ble asgjë atje, uebsajti i tyre është gjithmonë i prishur" nuk mund të maten fare.
Tani tek përgjegjësia. Në praktikën time ka pasur një rast kur administratori në detyrë nuk i është përgjigjur në kohë një njoftimi nga sistemi i monitorimit për mosdisponueshmërinë e faqes. Në një mbrëmje të këndshme vere të së premtes, faqja e internetit e një dyqani të njohur online në Moskë ishte e qetë. Të shtunën në mëngjes, menaxheri i produkteve të kësaj faqeje nuk e kuptoi pse faqja nuk u hap dhe pati heshtje në bisedat e mbështetjes dhe njoftimeve urgjente në Slack. Një gabim i tillë na kushtoi një shumë gjashtëshifrore dhe ky detyrues punën e tij.
Përgjegjësia është një aftësi e vështirë për t'u zhvilluar. Ose një person e ka atë ose jo. Prandaj, gjatë intervistave, mundohem ta identifikoj praninë e saj me pyetje të ndryshme që tregojnë indirekt nëse një person është mësuar të marrë përgjegjësi. Nëse një person përgjigjet se zgjodhi një universitet sepse prindërit e tij thanë kështu ose ndryshon punë sepse gruaja e tij tha se ai nuk fiton mjaftueshëm, atëherë është më mirë të mos përfshiheni me njerëz të tillë.
Ndërveprimi me ekipin e zhvillimit
Kur përdoruesit hasin probleme të thjeshta me një produkt gjatë funksionimit, mbështetja i zgjidh ato vetë. Përpiqet të riprodhojë problemin, analizon regjistrat, etj. Por çfarë të bëni kur shfaqet një gabim në produkt? Në këtë rast, mbështetja ua cakton detyrën zhvilluesve dhe këtu fillon argëtimi.
Zhvilluesit janë vazhdimisht të mbingarkuar. Ata po krijojnë veçori të reja. Rregullimi i defekteve me shitjet nuk është aktiviteti më interesant. Afatet po afrojnë për të përfunduar sprintin e radhës. Dhe më pas vijnë njerëz të pakëndshëm nga mbështetja dhe thonë: "Lëreni gjithçka menjëherë, kemi probleme". Prioriteti i detyrave të tilla është minimal. Sidomos kur problemi nuk është më i rëndësishmi dhe funksionaliteti kryesor i faqes funksionon, dhe kur menaxheri i lëshimit nuk vrapon me sy të fryrë dhe shkruan: "Shtojeni urgjentisht këtë detyrë në versionin ose rregullimin tjetër të nxehtë".
Çështjet me prioritet normal ose të ulët zhvendosen nga publikimi në publik. Në pyetjen "Kur do të përfundojë detyra?" ju do të merrni përgjigje në stilin e: "Më falni, ka shumë detyra tani, pyesni drejtuesit e ekipit tuaj ose lironi menaxherin."
Problemet e produktivitetit kanë përparësi më të madhe sesa krijimi i veçorive të reja. Shqyrtimet e këqija nuk do të vonojnë nëse përdoruesit vazhdimisht hasin në defekte. Një reputacion i dëmtuar është i vështirë për t'u rikthyer.
Çështjet e ndërveprimit midis zhvillimit dhe mbështetjes zgjidhen nga DevOps. Kjo shkurtesë përdoret shpesh në formën e një personi specifik që ndihmon në krijimin e mjediseve testuese për zhvillim, ndërton tubacionet CICD dhe sjell shpejt kodin e testuar në prodhim. DevOps është një qasje për zhvillimin e softuerit kur të gjithë pjesëmarrësit në proces ndërveprojnë ngushtë me njëri-tjetrin dhe ndihmojnë në krijimin dhe përditësimin e shpejtë të produkteve dhe shërbimeve softuerike. E kam fjalën për analistë, zhvillues, testues dhe mbështetje.
Në këtë qasje, mbështetja dhe zhvillimi nuk janë departamente të ndryshme me qëllimet dhe objektivat e tyre. Zhvillimi është i përfshirë në funksionim dhe anasjelltas. Fraza e famshme e ekipeve të shpërndara: "Problemi nuk është në anën time" nuk shfaqet më në biseda kaq shpesh dhe përdoruesit fundorë bëhen pak më të lumtur.
Burimi: www.habr.com