Bună, Habr! De zece ani mă ocup de sisteme IT de înaltă performanță. Nu voi scrie în acest articol despre problemele configurării nginx pentru a funcționa în modul de peste 1000 RPS sau alte lucruri tehnice. Voi împărtăși observații despre problemele din procesele care apar în suportul și exploatarea acestor sisteme.
Monitorizare
Asistența tehnică nu așteaptă să vină o solicitare cu conținutul «De ce... site-ul nu funcționează din nou?». Suportul ar trebui să observe problema într-un minut după căderea site-ului și să înceapă să o rezolve. Dar site-ul este vârful unei iceberg.. Accesibilitatea sa este monitorizată printre primele criterii.
Ce trebuie să facem în situația în care stocurile de produse din magazinul online nu mai vin din sistemul ERP? Sau sistemul CRM, care calculează reducerile pentru clienți, a încetat să răspundă? De fapt, site-ul arată că funcționează. Zabbix primește un răspuns 200. Schimbul de rezervă nu a primit niciun notificare de la sistemul de monitorizare și se bucură de prima serie din noul sezon al «Game of Thrones».
Adesea, monitorizarea se limitează doar la măsurarea stării memoriei, a RAM-ului și a încărcăturii procesorului. servere. Dar pentru afaceri este mult mai important să obțină accesibilitatea produselor de pe site. O cădere condiționată a unei mașini virtuale din cluster va duce la faptul că traficul nu va mai merge către ea și va crește încărcătura pe celelalte servere. Compania nu va pierde bani.
Prin urmare, pe lângă monitorizarea parametrilor tehnici ai sistemelor de operare de pe servere, trebuie să configurăm metricile de afaceri. Metrici care influențează direct banii. Diferite interacțiuni cu sisteme externe (CRM, ERP și altele). Numărul de comenzi într-un anumit interval de timp. Autorizările clienților, fie că sunt reușite sau nu, și alte metrici.
Interacțiunea cu sisteme externe
Orice site 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ționate anterior și terminând cu transmiterea de date despre vânzări către un sistem extern de Big Data pentru analiza achizițiilor și propunerea unui produs clientului pe care cu siguranță îl va cumpăra (de fapt, nu). Fiecare astfel de sistem are suportul său. Și, adesea, comunicarea cu aceste sisteme cauzează durere. În special atunci când problema este globală și trebuie să o analizăm în diferite sisteme.
Unele sisteme oferă telefonul sau Telegramul administratorilor lor. În alte părți, trebuie să scrii mesaje managerilor sau să accesezi sistemele externe de urmărire a problemelor. Chiar și în cadrul unei mari companii, diferitele sisteme funcționează adesea în sisteme diferite de gestionare a cererilor. Uneori, devine imposibil să urmărești starea unei cereri. Primești o cerere într-o anumită Jira. Apoi, în comentariul acelei prime Jira, pui un link către o sarcină dintr-o altă Jira. În cea de-a doua Jira, cineva deja scrie un comentariu că trebuie să sunăm pe administratorul nostru, Andrei, pentru a rezolva problema. Și așa mai departe.
O soluție optimă pentru această problemă ar fi crearea unui spațiu unic pentru comunicare, de exemplu, în Slack. Invitarea tuturor participanților la procesul de exploatare a sistemelor externe. De asemenea, un tracker unic, pentru a nu dubla cererile. Cererile trebuie să fie urmărite într-un singur loc, începând de la notificarea monitorizării și până la rezolvarea bug-urilor în producție. Vei spune că asta este nerealizabil și că așa s-a întâmplat istoric, că lucrăm într-un tracker, iar ei în altul. Au apărut diferite sisteme, fiecare având echipe IT autonome. Sunt de acord și, prin urmare, problema trebuie rezolvată de sus, la nivel de CIO sau product owner.
Fiecare sistem cu care interacționezi trebuie să ofere suport ca un serviciu, cu un SLA clar pentru rezolvarea problemelor în funcție de priorități. Nu atunci când administratorul tău, Andrei, are un moment liber pentru tine.
O persoană-ținută într-o sticlă
Există pe fiecare proiect (sau produs) o astfel de persoană, plecarea în concediu a cărei provoacă crampe la șef? Poate fi un inginer devops, un analist sau un dezvoltator. Numai inginerul devops știe pe ce servere sunt instalate ce containere, cum să repornească un container în cazul unei probleme, și, în general, orice problemă complexă nu se rezolvă fără el. Analistul este singurul care știe cum funcționează mecanismul vostru complex. Ce fluxuri de date merg unde. La ce parametrii de cerere către ce servicii, ce răspunsuri vom primi.
Cine va înțelege rapid de ce în jurnale sunt erori și va fixa rapid un bug critic în producție? Desigur, acel dezvoltator. Există și alții, dar de ce doar el înțelege cum sunt structurate diferitele module ale sistemului.
Rădăcina acestei probleme este absența documentației.. Dacă toate serviciile sistemului tău ar fi fost documentate, s-ar fi putut rezolva problema fără un analist. Dacă devops ar fi dedicat câteva zile din agenda sa aglomerată pentru a documenta toate serverele, serviciile și instrucțiunile pentru soluționarea problemelor standard, atunci lipsa lui ar fi putut fi compensată. Nu este nevoie să bei rapid berea pe plajă în vacanță și să cauți wi-fi pentru a rezolva o problemă.
Competența și responsabilitatea angajaților de suport
În proiectele mari, companiile nu economisesc la salariile dezvoltatorilor. Îi recrutează pe cei costisitori, intermediari sau seniori din proiecte similare. Situația cu suportul este un pic diferită. Aceste cheltuieli sunt reduse pe cât posibil. Companiile angajează foste persoane fără experiență și se îndreaptă încrezătoare spre provocare. Această strategie este viabilă atunci când vine vorba de un site de prezentare pentru o fabrică din Zelenograd.
Dacă este vorba despre un mare magazin online, fiecare oră de nefuncționare costă mai mult decât salariul lunar al unui administrator fără experiență. Să luăm ca punct de plecare un volum de afaceri anual de 1 miliard de ruble. Acesta este volumul minim de afaceri pentru orice magazin online din clasamentul . Împărțim această sumă la numărul de ore dintr-un an și obținem pierderi nete de peste 100 000 de ruble. Iar dacă nu luăm în considerare orele de noapte, putem dubla suma.
Dar banii nu sunt totul, nu-i așa? (nu, desigur, banii sunt esențiali) Există și pierderi reputaționale. O oră în care un magazin online cunoscut nu funcționează poate provoca o avalanșă de recenzii pe rețelele sociale, precum și articole în mass-media de specialitate. Discuțiile dintre prieteni în stilul „Nu cumpăra nimic de acolo, site-ul lor nu funcționează constant” nu pot fi cuantificate.
Acum să discutăm despre responsabilitate. În experiența mea, a fost un caz în care administratorul de serviciu nu a reacționat la timp la notificarea sistemului de monitorizare despre indisponibilitatea site-ului. Într-o seară plăcută de vineri de vară, site-ul unui cunoscut magazin online din Moscova nu funcționa. Sâmbătă dimineața, product manager-ul acestui site nu a înțeles de ce site-ul nu se deschide, iar în chat-urile de suport și alerte urgente din Slack era liniște. Această eroare ne-a costat o sumă cu șase cifre și a însemnat multă muncă pentru acest administrator de serviciu.
Responsabilitatea este o abilitate care este greu de dezvoltat. Fie este la o persoană, fie nu. De aceea, în timpul interviurilor, încerc să identific prezența sa prin diverse întrebări care arată indirect dacă omul este obișnuit să își asume responsabilitatea. Dacă o persoană răspunde că a ales instituția de învățământ superior pentru că așa au spus părinții sau schimbă locul de muncă pentru că soția a spus că câștigă prea puțin, atunci cu astfel de oameni este mai bine să nu te asociezi.
Interacțiune cu echipa de dezvoltare
Când, în producție, utilizatorii întâmpină probleme simple, suportul le rezolvă singur. Încercând să reproducă problema, analizează logurile și așa mai departe. Dar ce se întâmplă când apare un bug în producție? În acest caz, suportul creează o sarcină pentru dezvoltatori și aici începe partea cea mai interesantă.
Dezvoltatorii sunt mereu supraîncărcați. Ei se ocupă cu crearea de noi funcționalități. Fixarea bug-urilor din producție nu este, să spunem, cea mai interesantă activitate. Termenele limită pentru finalizarea unei noi sprint sunt presante. Și apoi vin oamenii neplăcuți din suport și spun: „Urgent, lasă totul, avem probleme”. Prioritatea acestor sarcini este minimă. Mai ales când problema nu este critică și funcționalitatea principală a site-ului funcționează, iar managerul de lansare nu aleargă panicat și nu scrie: „Include urgent această sarcină în următoarea lansare sau hotfix”.
Sarcinile cu prioritate normală sau scăzută trec dintr-o lansare în alta. La întrebarea „Când va fi finalizată sarcina?” vei primi răspunsuri de genul: „Îmi pare rău, acum sunt multe sarcini, întreabă-i pe liderii de echipă sau pe managerul de lansare”.
Problemele din producție au o prioritate mai mare decât crearea de noi funcționalități. Recenziile negative nu vor întârzia să apară dacă utilizatorii se confruntă constant cu bug-uri. Este greu să îți recuperezi reputația deteriorată.
Întrebările legate de interacțiunea dintre dezvoltare și suport sunt rezolvate de DevOps. Această abreviere este adesea folosită pentru a desemna o persoană care ajută la crearea de medii de testare pentru dezvoltare, construieste CICD pipelines și trimite rapid codul testat în producție. DevOps este o abordare a dezvoltării software-ului în care toți participanții la proces colaborează strâns și contribuie la crearea și actualizarea mai rapidă a produselor și serviciilor software. Mă refer la analiști, dezvoltatori, testeri și suport.
Asistența și dezvoltarea în această abordare nu sunt departamente diferite cu scopuri și sarcini proprii. Dezvoltarea este implicată în operare și invers. Faima frazei din echipele distribuite: „Problema nu este de partea mea” nu mai apare atât de des în conversații, iar utilizatorii finali devin puțin mai fericiți.
Sursa: habr.com
