Coincidențele sunt întâmplătoare și într-adevăr a fost pe o altă planetă...
Aș dori să vă împărtășesc trei povești de succes și eșec despre modul în care un dezvoltator backend lucrează într-o echipă cu administratori.
Istoria în primul rând.
Studio web, numărul de angajați poate fi numărat cu o singură mână. Astăzi ești designer de layout, mâine ești backender, poimâine ești administrator. Pe de o parte, poți câștiga o experiență extraordinară. Pe de altă parte, există o lipsă de competență în toate domeniile. Îmi amintesc încă prima zi de muncă, sunt încă verde, șeful spune: „Deschide chit”, dar nu știu ce este. Comunicarea cu administratorii este exclusă, deoarece tu esti administrator. Să luăm în considerare avantajele și dezavantajele acestei situații.
+ Toată puterea este în mâinile tale.
+ Nu este nevoie să implori pe nimeni pentru acces la server.
+ Timp de reacție rapid în toate direcțiile.
+ Îmbunătățește bine abilitățile.
+ Aveți o înțelegere completă a arhitecturii produsului.
— Înaltă responsabilitate.
— Risc de întrerupere a producției.
— Este dificil să fii un bun specialist în toate domeniile.
Nu mă interesează, să mergem mai departe
A doua poveste.
Companie mare, proiect mare. Există un departament administrativ cu 5-7 angajați și mai multe grupuri de dezvoltare. Când vii să lucrezi într-o astfel de companie, fiecare administrator crede că nu ai venit aici pentru a lucra la un produs, ci pentru a sparge ceva. Nici NDA semnat, nici selecția la interviu nu indică altfel. Nu, omul ăsta a venit aici cu mâinile lui murdare ca să ne strice producția de săruturi. Prin urmare, cu o astfel de persoană aveți nevoie de un minim de comunicare; cel puțin, puteți arunca un autocolant ca răspuns. Nu răspundeți la întrebări despre arhitectura proiectului. Este recomandabil să nu acordați acces până când liderul echipei nu cere. Și când va cere, o va da înapoi cu și mai puține privilegii decât au cerut. Aproape toată comunicarea cu astfel de admini este absorbită de gaura neagră dintre departamentul de dezvoltare și departamentul de administrare. Este imposibil să rezolvi problemele cu promptitudine. Dar nu poți veni personal - administratorii sunt prea ocupați 24/7. (Ce faci tot timpul?) Câteva caracteristici de performanță:
- Timpul mediu de implementare în producție este de 4-5 ore
- Timp maxim de implementare în producție 9 ore
- Pentru un dezvoltator, o aplicație în producție este o cutie neagră, la fel ca serverul de producție însuși. Câte sunt în total?
- Calitate scăzută a lansărilor, erori frecvente
- Dezvoltatorul nu participă la procesul de lansare
Ei bine, la ce mă așteptam, desigur, oamenii noi nu au voie să intre în producție. Ei bine, după ce am câștigat răbdare, începem să câștigăm încrederea altora. Dar din anumite motive, lucrurile nu sunt atât de simple cu adminii.
Actul 1. Administratorul este invizibil.
Ziua lansării, dezvoltatorul și administratorul nu comunică. Administratorul nu are întrebări. Dar înțelegi de ce mai târziu. Administratorul este o persoană cu principii, nu are mesageri, nu dă nimănui numărul său de telefon și nu are profil pe rețelele de socializare. Nu există nici măcar o fotografie cu el nicăieri, cu ce arăți omule? Stăm cu managerul responsabil aproximativ 15 minute nedumeriți, încercând să stabilim o comunicare cu acest Voyager 1, apoi apare un mesaj în e-mailul corporativ că a terminat. O să corespondem prin poștă? De ce nu? Convenabil, nu-i așa? Ei bine, hai să ne răcorim. Procesul este deja în derulare, nu există întoarcere. Citiți din nou mesajul. "Am terminat". Ce ai terminat? Unde? Unde sa te caut? Aici înțelegeți de ce 4 ore pentru eliberare sunt normale. Primim un șoc de dezvoltare, dar terminăm lansarea. Nu mai există nicio dorință de eliberare.
Actul 2. Nu acea versiune.
Următoarea ediție. După ce am acumulat experiență, începem să creăm liste cu software-ul și bibliotecile necesare pentru server pentru administratori, indicând versiunile pentru unii. Ca întotdeauna, primim un semnal radio slab că administratorul a terminat ceva acolo. Începe testul de regresie, care în sine durează aproximativ o oră. Totul pare să funcționeze, dar există o eroare critică. Funcționalitatea importantă nu funcționează. Următoarele ore au fost dans cu tamburine, ghicire pe zaț de cafea și o trecere în revistă detaliată a fiecărei bucăți de cod. Administratorul spune că a făcut totul. Aplicația scrisă de dezvoltatori strâmbi nu funcționează, dar serverul funcționează. Aveți întrebări pentru el? La sfârșitul unei ore, îl convingem pe administrator să trimită versiunea bibliotecii de pe serverul de producție în chat și bingo - nu este cea de care avem nevoie. Solicităm administratorului să instaleze versiunea necesară, dar ca răspuns primim că nu poate face acest lucru din cauza absenței acestei versiuni în managerul de pachete OS. Aici, din adâncurile memoriei sale, managerul își amintește că un alt admin rezolvase deja această problemă prin simpla asamblare manuală a versiunii necesare. Dar nu, ai noștri nu vor face asta. Regulamentele interzic. Karl, stăm aici de câteva ore, care este timpul limită?! Primim un alt șoc și terminăm cumva eliberarea.
Actul 3, scurt
Tichet urgent, funcționalitatea cheie nu funcționează pentru unul dintre utilizatorii din producție. Petrecem câteva ore înghițind și verificând. Într-un mediu de dezvoltare, totul funcționează. Există o înțelegere clară că ar fi o idee bună să te uiți în jurnalele php-fpm. La acel moment nu existau sisteme de jurnal precum ELK sau Prometheus pe proiect. Deschidem un bilet către departamentul de administrare, astfel încât să dea acces la jurnalele php-fpm de pe server. Aici trebuie să înțelegeți că solicităm accesul dintr-un motiv, nu vă amintiți că gaura neagră și administratorii sunt ocupați 24/7? Dacă le ceri să se uite la jurnalele ei înșiși, atunci aceasta este o sarcină cu prioritate „nu în această viață”. Biletul a fost creat, am primit un răspuns instantaneu de la șeful departamentului de administrare: „Nu ar trebui să aveți acces la jurnalele de producție, scrieți fără bug-uri.” O perdea.
Actul 4 și mai departe
Încă colectăm zeci de probleme în producție, din cauza diferitelor versiuni de biblioteci, software neconfigurat, încărcări nepregătite de server și alte probleme. Desigur, există și erori de cod, nu vom învinovăți administratorii pentru toate păcatele, vom menționa doar încă o operațiune tipică pentru acel proiect. Aveam destul de mulți lucrători de fundal care au fost lansati prin supervizor și unele scripturi au trebuit să fie adăugate la cron. Uneori, aceiași muncitori au încetat să lucreze. Sarcina de pe serverul de coadă a crescut cu viteza fulgerului, iar utilizatorii triști s-au uitat la încărcătorul care se învârte. Pentru a remedia rapid astfel de lucrători, a fost suficient să-i reporniți pur și simplu, dar din nou, doar un administrator putea face acest lucru. În timp ce se făcea o astfel de operație de bază, putea trece o zi întreagă. Aici, bineînțeles, este de remarcat faptul că programatorii strâmbi ar trebui să scrie lucrători astfel încât să nu se prăbușească, dar atunci când cad, ar fi bine să înțelegem de ce, ceea ce uneori este imposibil din cauza lipsei de acces la producție, de desigur, și, în consecință, lipsa jurnalelor de la dezvoltator.
Transfigurarea.
După ce am îndurat toate acestea destul de mult timp, împreună cu echipa am început să ne îndreptăm într-o direcție care a avut mai mult succes pentru noi. Pe scurt, cu ce probleme ne-am confruntat?
- Lipsa unei comunicări de calitate între dezvoltatori și departamentul administrativ
- Administratorii, se pare (!), nu înțeleg deloc cum este structurată aplicația, ce dependențe are și cum funcționează.
- Dezvoltatorii nu înțeleg cum funcționează mediul de producție și, ca urmare, nu pot răspunde eficient la probleme.
- Procesul de implementare durează prea mult.
- Lansări instabile.
Ce am făcut?
Pentru fiecare lansare, a fost generată o listă de Note de lansare, care includea o listă de lucrări care trebuie făcute pe server pentru ca următoarea ediție să funcționeze. Lista conținea mai multe secțiuni, lucrări care ar trebui efectuate de administrator, persoana responsabilă pentru lansare și dezvoltator. Dezvoltatorii au primit acces non-root la toate serverele de producție, ceea ce a accelerat dezvoltarea în general și rezolvarea problemelor în special. Dezvoltatorii au, de asemenea, o înțelegere a modului în care funcționează producția, în ce servicii este împărțită, unde și cât costă replicile. Unele dintre încărcăturile de luptă au devenit mai clare, ceea ce afectează fără îndoială calitatea codului. Comunicarea în timpul procesului de lansare a avut loc în chat-ul unuia dintre mesagerii instant. În primul rând, am avut un jurnal al tuturor acțiunilor, iar în al doilea rând, comunicarea a avut loc într-un mediu mai apropiat. A avea un istoric de acțiuni a permis de mai multe ori noilor angajați să rezolve problemele mai rapid. Este un paradox, dar acest lucru a ajutat adesea administratorii înșiși. Nu mă voi angaja să spun cu siguranță, dar mi se pare că administratorii au început să înțeleagă mai mult cum funcționează proiectul și cum este scris. Uneori chiar am împărtășit unele detalii unul cu celălalt. Timpul mediu de lansare a fost redus la o oră. Uneori terminam în 30-40 de minute. Numărul de bug-uri a scăzut semnificativ, dacă nu de zece ori. Desigur, și alți factori au influențat reducerea timpului de lansare, cum ar fi autotestele. După fiecare lansare, am început să facem retrospective. Pentru ca întreaga echipă să aibă o idee despre ce este nou, ce s-a schimbat și ce a fost eliminat. Din păcate, administratorii nu au venit întotdeauna la ei, ei bine, administratorii sunt ocupați... Satisfacția mea la locul de muncă ca dezvoltator a crescut fără îndoială. Când poți rezolva rapid aproape orice problemă care se află în aria ta de competență, te simți în frunte. Mai târziu, voi înțelege că într-o oarecare măsură am introdus o cultură devops, nu complet, desigur, dar chiar și acel început de transformare a fost impresionant.
Povestea trei
Lansare. Un administrator, un mic departament de dezvoltare. La sosire sunt un zero complet, pentru că... Nu am acces nicăieri în afară de e-mail. Scriem administratorului și cerem acces. În plus, există informații că acesta este la curent cu noul angajat și despre necesitatea emiterii autentificărilor/parolelor. Ele oferă acces din depozit și VPN. De ce să acordați acces la wiki, teamcity, rundesk? Lucruri inutile pentru o persoană care a fost chemată să scrie toată partea backend. Doar în timp obținem acces la unele instrumente. Sosirea, desigur, a fost întâmpinată cu neîncredere. Încerc să îmi fac treptat o idee despre cum funcționează infrastructura proiectului prin chat-uri și întrebări principale. Practic nu recunosc nimic. Producția este aceeași cutie neagră ca înainte. Dar mai mult decât atât, chiar și serverele de scenă folosite pentru testare sunt o cutie neagră. Nu putem face altceva decât să implementăm o ramură din Git acolo. De asemenea, nu putem configura aplicația noastră ca fișiere .env. Accesul pentru astfel de operațiuni nu este permis. Trebuie să te rogi să schimbi o linie în configurația aplicației tale pe serverul de testare. (Există o teorie conform căreia este vital ca administratorii să se simtă importanți în proiect; dacă nu li se cere să schimbe liniile din configurații, pur și simplu nu vor fi necesari). Ei bine, ca întotdeauna, nu este convenabil? Acest lucru devine rapid plictisitor, după o conversație directă cu adminul aflăm că dezvoltatorii s-au născut pentru a scrie cod prost, sunt din fire persoane incompetenți și este mai bine să-i ținem departe de producție. Dar aici și de pe serverele de test, pentru orice eventualitate. Conflictul se intensifică rapid. Nu există nicio comunicare cu administratorul. Situația este agravată de faptul că este singur. Următoarea este o imagine tipică. Eliberare. Anumite funcționalități nu funcționează. Ne ia mult timp să ne dăm seama ce se întâmplă, diverse idei de la dezvoltatori sunt aruncate în chat, dar administratorul într-o astfel de situație presupune de obicei că dezvoltatorii sunt de vină. Apoi scrie în chat, stai, l-am corectat. Când sunt rugați să lăsăm în urmă o poveste cu informații despre care a fost problema, primim scuze toxice. De exemplu, nu-ți băga nasul acolo unde nu-i este locul. Dezvoltatorii trebuie să scrie cod. Situația în care multe mișcări ale corpului într-un proiect trec printr-o singură persoană și doar el are acces pentru a efectua operațiile de care toată lumea are nevoie este extrem de tristă. O astfel de persoană este un blocaj groaznic. Dacă ideile Devops se străduiesc să reducă timpul de lansare pe piață, atunci astfel de oameni sunt cel mai mare dușman al ideilor Devops. Din păcate, cortina se închide aici.
PS După ce am vorbit puțin despre dezvoltatori vs administratori în chat-urile cu oameni, am întâlnit oameni care mi-au împărtășit durerea. Dar au fost și cei care au spus că nu au mai întâlnit așa ceva. La o conferință devops, l-am întrebat pe Anton Isanin (Alfa Bank) cum au tratat problema blocajului sub forma administratorilor, cărora le-a spus: „Le-am înlocuit cu butoane”. Apropo cu participarea sa. Aș vrea să cred că există mult mai mulți admini buni decât dușmani. Și da, poza de la început este o adevărată corespondență.
Sursa: www.habr.com