7 tehnici de depanare pentru a accelera depanarea în producție

Furnizarea de suport de producție unei aplicații este unul dintre cele mai provocatoare aspecte ale dezvoltării software. Dezvoltatorii sunt repartizați echipei de întreținere și lucrează la corectarea erorilor aplicației. Ele sunt, totuși, disponibile și la gardă în cazul în care are loc o întrerupere a producției, caz în care lucrează pentru a readuce aplicația pe drumul cel mai rapid posibil.

Acest articol își propune să ofere un set de recomandări organizate, astfel încât să puteți preveni erorile în producție și să găsiți probleme mult mai rapid. Gestionarea acestor aplicații în producție este o sarcină complicată: deseori, nu există documentație disponibilă, aplicația a fost scrisă într-o stivă de tehnologie moștenită sau ambele. Există foarte puține sesiuni de instruire și este obișnuit să fii chemat pentru a oferi suport pentru o aplicație despre care știi puțin.

Mulți dezvoltatori nu au experiență în manipularea unei aplicații în producție. Există o serie de probleme care apar în mediile de producție care provoacă erori și întreruperi, în general, provocând pierderi de venituri de mii și uneori milioane de dolari companiei. Mai mult decât atât, deoarece majoritatea dezvoltatorilor nu au nicio expunere la mediu, continuă să facă unele greșeli care, la rândul lor, vor cauza acele probleme. Această listă de sfaturi ar trebui să vă facă munca mai puțin dureroasă prin predarea din experiența de producție.

Sfat #1: Eliminați sau automatizați toată configurația necesară pentru ca aplicația să ruleze.

Câtă configurație este necesară pentru a instala software-ul pe un nou server? În trecut, finalizarea acestui lucru putea dura uneori trei zile de fiecare dată când exista un nou dezvoltator în echipă. Instalarea aplicației ar necesita mulți pași care trebuie efectuati manual. În timp, software-ul evoluează către versiuni noi care devin incompatibile cu acele instrucțiuni și, desigur, instrucțiunile nu sunt de obicei actualizate. Dintr-o dată, petreci mult mai mult timp decât este necesar pur și simplu pentru a pune în funcțiune aplicația.

Odată cu apariția containerizării, a devenit mult mai ușor să oferiți o modalitate de a pune în funcțiune o aplicație în cel mai scurt timp, cu configurație zero și cu avantajul suplimentar că, deoarece imaginea Docker este autonomă, rulați o aplicație mult mai mică. riscul de a întâmpina probleme cu diferite versiuni ale sistemului de operare, limbi și cadre utilizate.

De asemenea, simplificați configurarea dezvoltatorului, astfel încât să nu aveți nevoie de mult timp pentru a fi în funcțiune, inclusiv configurarea IDE. Un dezvoltator ar trebui să poată trece de la zero la erou în mai puțin de 30 de minute.

Când apare o problemă de producție, uneori cei mai buni experți ai tăi s-ar putea să nu fie disponibili (de exemplu, vacanță sau boală) și vrei ca oricine ai aruncat la problemă să o poată rezolva și rapid.

Sfatul nr. 2: Nu cădea în capcana supei stiva tehnologică.

Cu cât sunt mai puține tehnologii utilizate, cu atât mai bine. Desigur, uneori, trebuie să utilizați instrumentul potrivit pentru muncă. Cu toate acestea, aveți grijă să nu supraîncărcați cu „uneltele potrivite”. Chiar și apa potabilă poate duce la probleme grave de sănătate dacă o faci prea mult. Fiecare limbaj și cadru nou adăugat la stiva tehnologică trebuie să treacă peste un proces de luare a deciziilor clar definit, cu o analiză atentă a impactului.

• Nu adăugați o nouă dependență de cadru doar pentru că aveți nevoie de o clasă StringUtils .
• Nu adăugați o limbă complet nouă doar pentru că trebuie să scrieți un script rapid pentru a muta fișierele.

O grămadă mare de dependențe îți poate face viața mizerabilă atunci când bibliotecile devin incompatibile sau când se găsesc amenințări de securitate fie cadrele în sine, fie dependențele lor tranzitive.

Mai mult, amintiți-vă, complexitățile adăugate ale stivei fac dificilă găsirea și formarea de noi dezvoltatori pentru echipă. Oamenii trec la noi roluri în alte companii, iar tu trebuie să găsești altele noi. Cifra de afaceri este foarte mare în echipele de ingineri, chiar și în companiile recunoscute pentru beneficii grozave și pentru echilibrul dintre viața profesională și viața privată. Doriți să găsiți noul membru al echipei cât mai repede posibil. Fiecare tehnologie nouă adăugată în partea superioară a stivei de tehnologie mărește timpul necesar pentru a găsi un nou candidat și are potențialul de a face noi angajați din ce în ce mai scump.

Sfatul #3: Înregistrarea trebuie să vă ghideze pentru a găsi problema, nu să vă înece cu detalii inutile.

Înregistrarea este foarte asemănătoare cu comentariile. Este necesar să documentați toate deciziile critice luate plus toate informațiile de utilizat în tehnicile de depanare. Nu este simplu, dar cu puțină experiență, este posibil să trasăm câteva scenarii posibile de întrerupere a producției și apoi să introduceți jurnalul necesar pentru a rezolva cel puțin asta. Desigur, înregistrarea în jurnal evoluează împreună cu baza de cod, în funcție de ce fel de probleme apar. În general, ar trebui să aveți 80% din înregistrarea dvs. pe cele mai importante 20% din codul dvs. - partea care va fi folosită cel mai mult. Informațiile importante, de exemplu, sunt valorile din argumentele transmise într-o metodă, tipurile de rulare din clasele pentru copii și deciziile importante luate de software - adică momentul în care acesta se afla la o răscruce de drumuri și alegea fie la stânga, fie la dreapta.

Sfatul #4: Gestionați situațiile neașteptate.

Hartați foarte clar care sunt ipotezele codului. Dacă o anumită variabilă ar trebui să conțină întotdeauna valorile 2, 5 sau 7, asigurați-vă că este de tip enum, nu int. Sursa numărul unu de întreruperi mari de producție este atunci când o anumită presupunere eșuează. Toată lumea caută problema în locul nepotrivit pentru că consideră câteva lucruri de la sine înțeles.

Ipotezele ar trebui să fie documentate în mod explicit, iar orice eșec la aceste ipoteze ar trebui să treacă suficiente alarme pentru ca echipa de asistență de producție să poată remedia rapid situația. De asemenea, ar trebui să existe un cod pentru a împiedica datele să intre într-o stare nevalidă sau cel puțin să creeze un fel de alertă în acest caz. Dacă anumite informații ar trebui să fie stocate într-o singură înregistrare și dintr-o dată apar două înregistrări, ar trebui să fie lansat un avertisment.

Sfatul #5: Ar trebui să fie simplu să reproduci o problemă care se întâmplă unui client.

Unul dintre cei mai grei pași este întotdeauna replicarea problemei cu care se confruntă clientul. De multe ori, veți petrece 95% din timp încercând să reproduceți problema, iar apoi, în momentul în care o puteți replica, este o chestiune de minute pentru a corela, a testa și a implementa. Ca atare, arhitectul aplicației ar trebui să se asigure că este extrem de simplu și rapid de a reproduce problemele. Multe dintre acestea se întâmplă deoarece, pentru a ajunge la aceeași situație în care se află clientul, dezvoltatorul trebuie să facă o cantitate semnificativă de configurare a aplicației. Există multe înregistrări stocate care, împreună, agravează situația în care se află clientul - problema fiind că tu, în calitate de dezvoltator, trebuie să ghicesți exact ce a făcut clientul. Și uneori, au efectuat o secvență de pași, dintre care își amintesc doar de ultimul.

De asemenea, clientul va explica problema în termeni de afaceri, pe care dezvoltatorul trebuie să o traducă apoi în termeni tehnici. Și dacă dezvoltatorul are mai puțină experiență cu aplicația, nu va ști să ceară detaliile lipsă, deoarece nici măcar nu le cunoaște încă. Copierea întregii baze de date de producție pe mașina dvs. este imposibilă. Deci ar trebui să existe un instrument care să importe rapid din baza de date de producție doar câteva înregistrări necesare pentru a simula situația.

Să presupunem că clientul are o problemă cu ecranul Comenzi. S-ar putea să trebuiască să importați câteva dintre comenzile lor, înregistrarea clienților lor, unele înregistrări cu detaliile comenzii, înregistrările de configurare a comenzii etc. Apoi le puteți exporta într-o bază de date într-o instanță Docker, lansați acea instanță și, exact așa, sunteți văzând același lucru pe care îl vede clientul. Toate acestea, desigur, ar trebui făcute cu atenția corespunzătoare pentru a se asigura că niciun dezvoltator nu are acces la date sensibile.

Sfat #6: Ar trebui să fie evident unde să plasați punctele de întrerupere în aplicație.

Dacă aveți un ecran Client, ar trebui să existe un obiect Client unde puteți plasa punctele de întrerupere pentru a depana o problemă pe acel ecran. Uneori, dezvoltatorii cad în febra abstracției și vin cu câteva concepte incredibil de inteligente despre cum să gestioneze evenimentele interfeței cu utilizatorul. În schimb, ar trebui să ne bazăm întotdeauna pe principiul KISS (Keep it Simple, St— er, Silly) și să avem o metodă ușor de localizat pentru fiecare eveniment UI. De asemenea, pentru joburile de procesare în lot și sarcinile programate — ar trebui să existe o modalitate ușoară de a identifica locul unde se află punctul de întrerupere pentru a evalua dacă acel cod funcționează sau nu.

Sfat #7: Asigurați-vă că toate dependențele externe sunt documentate în mod explicit.

În mod ideal, faceți acest lucru în fișierul README din sistemul de control al sursei, astfel încât documentația să nu se piardă. Documentați orice sisteme externe, baze de date sau resurse care trebuie să fie disponibile pentru ca aplicația să ruleze corect. De asemenea, rețineți care dintre acestea sunt opționale și adăugați instrucțiuni despre cum să le gestionați atunci când sunt opționale și nu sunt disponibile.

Dincolo de tehnicile de depanare

Odată ce aceste recomandări sunt urmate în timp ce se creează noi caracteristici sau se asigură întreținerea unui sistem, asistența pentru producție va deveni mult mai ușoară, iar compania dumneavoastră va cheltui mult mai puțin timp (și bani). După cum știți deja, timpul este esențial în depanarea erorilor de producție și a blocărilor - orice minut care poate fi salvat face o mare diferență în concluzie. Codare fericită!