Realitatea unui inginer de rețea (cu tăiței și... sare?)
Recent, în timp ce discutam despre diverse incidente cu inginerii, am observat un model interesant.
În aceste discuții, problema „cauzei fundamentale” apare invariabil. Cititorii fideli probabil știu că am pe . În multe organizații, analiza incidentelor se bazează în întregime pe acest concept. Ei folosesc diferite tehnici pentru identificarea relațiilor cauză-efect, cum ar fi . Aceste metode presupun așa-numita „liniaritate a evenimentelor” ca o dogmă incontestabilă.
Când contestați această idee și subliniați că liniaritatea este înșelătoare în mod liniștitor în sistemele complexe, se naște o discuție fascinantă. Disputații insistă cu pasiune că doar cunoașterea „cauzei fundamentale” ne permite să înțelegem ce se întâmplă.
Am observat un model interesant: dezvoltatorii și devopții reacționează diferit la această idee. Din experiența mea, dezvoltatorii sunt mai susceptibili să susțină că cauza principală contează și că relațiile cauză-efect pot fi întotdeauna stabilite în evenimente. Pe de altă parte, DevOps sunt mai des de acord că o lume complexă nu se supune întotdeauna liniarității.
Mereu m-am întrebat de ce este asta? Ce mărci programatorii să critice ideea „cauza principală este un mit” așa? Ca un sistem imunitar care recunoaște un agent străin. De ce reacționează astfel, în timp ce devops-ul mai degrabă înclinat luați în considerare această idee?
Nu sunt complet sigur, dar am niște păreri despre asta. Se referă la diferitele contexte în care acești profesioniști își desfășoară activitatea zilnică.
Dezvoltatorii lucrează adesea cu instrumente deterministe. Desigur, compilatoare, linkere, sisteme de operare - toate acestea sunt sisteme complexe, dar suntem obișnuiți cu faptul că dau un rezultat determinist și ne imaginăm ca fiind determinist: dacă oferim aceleași date de intrare, atunci ne așteptăm de obicei la aceeași ieșire din aceste sisteme. Și dacă există o problemă cu rezultatul („bug”), atunci dezvoltatorii o rezolvă analizând datele de intrare (fie de la utilizator, fie de la un set de instrumente în timpul procesului de dezvoltare). Ei caută o „eroare” și apoi schimbă datele de intrare. Aceasta remediază „bug”.
Ipoteza de bază a dezvoltării software: aceleași date de intrare în mod fiabil și determinist produc aceeași ieșire.
De fapt, un rezultat nedeterminist este el însuși considerat un bug: dacă rezultatul neașteptat sau eronat nu este reprodus, atunci dezvoltatorii tind să extindă investigația și la alte părți ale stivei (sistem de operare, rețea etc.), care se comportă și ele. mai mult sau mai puțin determinist, producând același rezultat cu aceleași date de intrare... și dacă nu este, atunci aceasta este încă considerată o eroare. Este doar acum o eroare a sistemului de operare sau a rețelei.
În orice caz, determinismul este o presupunere de bază, aproape considerată de la sine înțeleasă pentru majoritatea muncii pe care o fac programatorii.
Dar pentru orice tip devop care și-a petrecut ziua găzduind hardware sau găsind un API cloud, ideea unei lumi complet deterministe (atâta timp cât este chiar posibil să mapați toate intrările!) este un concept trecător în cel mai bun caz. Chiar dacă o lași deoparte , inginerii experimentați au văzut cele mai ciudate lucruri din această lume. Ei știu asta , ca să nu mai vorbim de milioanele de alți factori din mediu.
Prin urmare, este mai ușor pentru inginerii experimentați să se îndoiască de faptul că toate incidentele au o singură cauză principală, iar tehnici precum „Cinci motive” vor duce corect (și repetat!) la acea cauză principală. De fapt, acest lucru contrazice propria lor experiență, în care piesele puzzle-ului nu se potrivesc atât de bine în practică. Prin urmare, ei acceptă mai ușor această idee.
Desigur, nu spun că dezvoltatorii sunt naivi, proști sau incapabili să înțeleagă cum liniaritatea poate fi înșelătoare.
Dar mi se pare că o reacție comună a dezvoltatorilor în aceste dezbateri are adesea de-a face cu faptul că conceptul de determinism le servește bine în general în munca de zi cu zi. Ei nu se confruntă cu nondeterminism atât de des pe cât trebuie inginerii să prindă pisicile lui Schrödinger în infrastructura lor.
Este posibil ca acest lucru să nu explice pe deplin reacțiile dezvoltatorului observate, dar este un memento puternic că reacțiile noastre sunt un amestec complex de mulți factori.
Este important să ne amintim această complexitate, indiferent dacă avem de-a face cu un singur incident, colaborăm la o conductă de livrare de software sau încercăm să înțelegem lumea mai largă.
Sursa: www.habr.com