Bună, Habr! Sustin sistemele IT Highload de zece ani. Nu voi scrie în acest articol despre problemele de configurare a nginx pentru a funcționa în modul 1000+ RPS sau alte lucruri tehnice. Voi împărtăși observațiile mele despre problemele din procesele care apar în susținerea și funcționarea unor astfel de sisteme.
monitorizarea
Asistența tehnică nu așteaptă până când sosește o solicitare cu conținutul „De ce... site-ul nu funcționează din nou?” În termen de un minut după ce site-ul se blochează, asistența ar trebui să vadă deja problema și să înceapă să o rezolve. Dar site-ul este vârful aisbergului. Disponibilitatea sa este una dintre primele care sunt monitorizate.
Ce să faci cu situația în care mărfurile rămase dintr-un magazin online nu mai ajung din sistemul ERP? Sau sistemul CRM care calculează reducerile pentru clienți a încetat să mai răspundă? Site-ul pare să funcționeze. Condițional Zabbix primește răspunsul său 200. Duty Shift nu a primit nicio notificare de la monitorizare și urmărește cu bucurie primul episod din noul sezon din Game of Thrones.
Monitorizarea este adesea limitată doar la măsurarea stării memoriei, a memoriei RAM și a încărcării procesorului serverului. Dar pentru afaceri este mult mai important să obțineți disponibilitatea produsului pe site. Eșecul condiționat a unei mașini virtuale din cluster va duce la faptul că traficul nu va mai merge la ea și încărcarea pe alte servere va crește. Compania nu va pierde bani.
Prin urmare, pe lângă monitorizarea parametrilor tehnici ai sistemelor de operare de pe servere, trebuie să configurați metrica de afaceri. Valori care afectează direct banii. Interacțiuni diverse cu sisteme externe (CRM, ERP și altele). Numărul de comenzi pentru o anumită perioadă de timp. Autorizări de succes sau nereușite ale clienților și alte valori.
Interacțiunea cu sistemele externe
Orice site web sau aplicație mobilă cu o cifră de afaceri anuală de peste un miliard de ruble interacționează cu sisteme externe. Începând de la CRM și ERP menționat mai sus și terminând cu transferul datelor de vânzări către un sistem extern Big Data pentru analiza achizițiilor și oferirea clientului un produs pe care cu siguranță îl va cumpăra (de fapt, nu). Fiecare astfel de sistem are propriul său suport. Și adesea comunicarea cu aceste sisteme provoacă durere. Mai ales când problema este globală și trebuie să o analizezi în sisteme diferite.
Unele sisteme oferă un număr de telefon sau o telegramă pentru administratorii lor. Undeva trebuie să scrieți scrisori către manageri sau să mergeți la dispozitivele de urmărire a erorilor acestor sisteme externe. Chiar și în contextul unei companii mari, sisteme diferite operează adesea în sisteme contabile de aplicații diferite. Uneori devine imposibil să urmăriți starea unei aplicații. Primiți o cerere într-o Jira condiționată. Apoi, în comentariul acestei prime Jiră ai pus un link către problemă într-o altă Jiră. În a doua Jira din aplicație, cineva scrie deja un comentariu care trebuie să sunați administratorul condiționat Andrey pentru a rezolva problema. Și așa mai departe.
Cea mai bună soluție la această problemă ar fi crearea unui singur spațiu pentru comunicare, de exemplu în Slack. Invitarea tuturor participanților în procesul de operare a sistemelor externe să se alăture. Și, de asemenea, un singur tracker pentru a nu duplica aplicațiile. Aplicațiile ar trebui să fie urmărite într-un singur loc, de la notificările de monitorizare până la ieșirea soluțiilor de erori în viitor. Veți spune că acest lucru este nerealist și s-a întâmplat istoric că lucrăm într-un tracker, iar ei funcționează în altul. Au apărut sisteme diferite, aveau propriile echipe IT autonome. Sunt de acord și, prin urmare, problema trebuie rezolvată de sus la nivel de CIO sau de proprietar de produs.
Fiecare sistem cu care interacționați ar trebui să ofere asistență ca serviciu cu un SLA clar pentru a rezolva problemele în funcție de prioritate. Și nu atunci când administratorul condiționat Andrey are un minut pentru tine.
Omul cu gâtul de sticlă
Toată lumea dintr-un proiect (sau produs) are o persoană a cărei plecare în vacanță provoacă convulsii în rândul superiorilor? Acesta ar putea fi un inginer devops, un analist sau un dezvoltator. La urma urmei, doar un inginer devops știe ce servere au ce containere instalate, cum să repornească containerul în cazul unei probleme și, în general, orice problemă complexă nu poate fi rezolvată fără el. Analistul este singurul care știe cum funcționează mecanismul tău complex. Ce fluxuri de date merg unde. În ce parametri de solicitări la ce servicii, la care vom primi răspunsuri.
Cine va înțelege rapid de ce există erori în jurnale și va remedia prompt o eroare critică în produs? Desigur, același dezvoltator. Există și altele, dar din anumite motive doar el înțelege cum funcționează diferitele module ale sistemului.
Rădăcina acestei probleme este lipsa documentației. La urma urmei, dacă toate serviciile sistemului dvs. ar fi descrise, atunci ar fi posibil să rezolvați problema fără un analist. Dacă devopii au luat câteva zile din programul său încărcat și au descris toate serverele, serviciile și instrucțiunile pentru rezolvarea problemelor tipice, atunci problema în absența lui ar putea fi rezolvată fără el. Nu trebuie să vă terminați rapid berea pe plajă în timpul vacanței și să căutați wi-fi pentru a rezolva problema.
Competența și responsabilitatea personalului suport
La proiectele mari, companiile nu se zgârcesc cu salariile dezvoltatorilor. Ei caută medii sau seniori scumpi din proiecte similare. Cu sprijin, situația este puțin diferită. Ei încearcă să reducă aceste costuri în toate modurile posibile. Companiile angajează lucrători Enikey de ieri ieftini și intră cu îndrăzneală în luptă. Această strategie este posibilă dacă vorbim despre un site web pentru cărți de vizită a unei fabrici din Zelenograd.
Dacă vorbim de un mare magazin online, atunci fiecare oră de nefuncționare costă mai mult decât salariul lunar al unui administrator Enikey. Să luăm ca punct de plecare 1 miliard de ruble de cifră de afaceri anuală. Aceasta este cifra de afaceri minimă a oricărui magazin online din rating . Împărțiți această sumă la numărul de ore pe an și obțineți mai mult de 100 de ruble de pierderi nete. Și dacă nu numărați orele de noapte, puteți dubla în siguranță suma.
Dar banii nu sunt principalul lucru, nu? (nu, desigur principalul) Există și pierderi de reputație. Căderea unui cunoscut magazin online poate provoca atât un val de recenzii pe rețelele de socializare, cât și publicații în media tematică. Iar conversațiile prietenilor din bucătărie în stilul „Nu cumpăra nimic acolo, site-ul lor este întotdeauna în jos” nu pot fi măsurate deloc.
Acum la responsabilitate. In practica mea a existat un caz in care administratorul de serviciu nu a raspuns la timp la o notificare din partea sistemului de monitorizare despre indisponibilitatea site-ului. Într-o seară plăcută de vineri de vară, site-ul unui cunoscut magazin online din Moscova zăcea liniștit. Sâmbătă dimineața, managerul de produs al acestui site nu a înțeles de ce site-ul nu s-a deschis și a fost tăcere în chat-urile de asistență și notificare urgentă din Slack. O astfel de greșeală ne-a costat o sumă de șase cifre, iar acest ofițer de serviciu slujba lui.
Responsabilitatea este o abilitate dificil de dezvoltat. Ori o persoană o are sau nu. Prin urmare, în timpul interviurilor, încerc să identific prezența acestuia cu diverse întrebări care arată indirect dacă o persoană este obișnuită să-și asume responsabilitatea. Dacă o persoană răspunde că a ales o universitate pentru că așa au spus părinții sau își schimbă locul de muncă pentru că soția a spus că nu câștigă suficient, atunci este mai bine să nu te implici cu astfel de oameni.
Interacțiunea cu echipa de dezvoltare
Atunci când utilizatorii întâmpină probleme simple cu un produs în timpul funcționării, suportul le rezolvă singur. Încearcă să reproducă problema, analizează jurnalele și așa mai departe. Dar ce să faci când apare o eroare în produs? În acest caz, suportul atribuie sarcina dezvoltatorilor și de aici începe distracția.
Dezvoltatorii sunt în mod constant supraîncărcați. Ei creează noi funcții. Remedierea erorilor legate de vânzări nu este cea mai interesantă activitate. Se apropie termenul limită pentru finalizarea următorului sprint. Și apoi vin oameni neplăcuți de la asistență și spun: „Lasă totul imediat, avem probleme”. Prioritatea unor astfel de sarcini este minimă. Mai ales atunci când problema nu este cea mai critică și funcționalitatea principală a site-ului funcționează și când managerul de versiuni nu alergă cu ochii bombați și scrie: „Adăugați urgent această sarcină la următoarea versiune sau remediere rapidă”.
Problemele cu prioritate normală sau scăzută sunt mutate de la lansare la lansare. La întrebarea „Când va fi finalizată sarcina?” veți primi răspunsuri în stilul: „Ne pare rău, există o mulțime de sarcini în acest moment, întrebați liderii echipei sau managerul de eliberare.”
Problemele de productivitate au o prioritate mai mare decât crearea de noi funcții. Recenziile proaste nu vor întârzia să apară dacă utilizatorii dau în mod constant peste erori. O reputație deteriorată este greu de restabilit.
Problemele de interacțiune dintre dezvoltare și suport sunt rezolvate de DevOps. Această abreviere este adesea folosită sub forma unei anumite persoane care ajută la crearea de medii de testare pentru dezvoltare, construiește conducte CICD și aduce rapid codul testat în producție. DevOps este o abordare a dezvoltării software atunci când toți participanții la proces interacționează strâns între ei și ajută la crearea și actualizarea rapidă a produselor și serviciilor software. Mă refer la analiști, dezvoltatori, testeri și suport.
În această abordare, sprijinul și dezvoltarea nu sunt departamente diferite cu propriile lor scopuri și obiective. Dezvoltarea este implicată în operare și invers. Celebra frază a echipelor distribuite: „Problema nu este de partea mea” nu mai apare atât de des în chat-uri, iar utilizatorii finali devin puțin mai fericiți.
Sursa: www.habr.com