Ce este necesar pentru succesul unei companii IT în 2019? Lectorii de la conferințe și meet-up-uri spun multe cuvinte zgomotoase și nu întotdeauna înțelese de oamenii obișnuiți. Lupta pentru timpul de deplasare, microserviciile, renunțarea la monolit, transformarea DevOps și multe, multe altele. Dacă lăsăm la o parte frumusețea verbală și vorbim direct și simplu, totul se reduce la o teză simplă: faceți un produs de calitate, făcându-l în mod confortabil pentru echipă.
Acesta din urmă a devenit critic. Afacerea a ajuns în cele din urmă la gândul că un proces confortabil de dezvoltare crește productivitatea, iar dacă totul este bine reglat și funcționează ca un ceas, atunci oferă și o oarecare marjă de manevră în situații critice. Cândva, pentru această marjă, un anumit om înțelept a inventat backup-urile, dar industria a evoluat și am ajuns la inginerii DevOps - persoane care transformă procesul de interacțiune între dezvoltare și infrastructura externă într-un ceva adecvat și fără legătură cu şamanismul.
Întreaga această poveste despre „pe module” este minunată, dar… S-a întâmplat ca o parte din administratori să fie brusc etichetați ca DevOps, iar de la proprii ingineri DevOps s-au cerut, ca minim, abilități de telepatie și clarviziune.
Înainte de a vorbi despre problemele moderne ale asigurării infrastructurii, să ne definim ce înțelegem prin acest termen. La momentul actual, situația s-a desfășurat astfel încât am ajuns la dualitatea acestui concept: infrastructura poate fi condiționat externă și condiționat internă.
Prin infrastructura externă se înțelege tot ceea ce asigură funcționarea serviciului sau produsului de care se ocupă echipa. Acestea sunt servere de aplicații sau site-uri, hosting și alte servicii care asigură funcționarea produsului.
Infrastructura internă include servicii și echipamente utilizate de echipa de dezvoltare și alți angajați, care de obicei nu sunt puțini. Acestea sunt servere interne pentru sistemele de stocare a codului, un manager de sarcini desfășurat local și tot ce există în cadrul intranet-ului corporativ.
Ce face administratorul de sistem în companie? În afară de administrarea intranetului corporativ, el se ocupă adesea și de asigurarea funcționării echipamentelor de birou. Administratorul este persoana care aduce rapid un nou desktop sau un laptop de rezervă gata de lucru, oferă o tastatură proaspătă și se târăște pe podea în birouri pentru a întinde un cablu Ethernet. Administratorul este stăpânul local, controlând nu doar resursele interne, ci și externe. servere, dar este și un bun gospodar. Da, unii administratori pot lucra doar în domeniul sistemelor, fără a se ocupa de hardware. Aceștia ar trebui separați într-o subcategorie numită „administratori de sistem infrastructurali”. Alții se specializează exclusiv în întreținerea echipamentelor de birou, mai ales dacă compania are mai mult de o sută de angajați, munca nu se termină niciodată. Dar nici aceștia, nici ceilalți nu sunt devops.
Și cine sunt devops? Devops-ii sunt cei care se ocupă de interacțiunea între dezvoltarea software-ului și infrastructura externă. Mai precis, devops-ii moderni sunt implicați în procesele de dezvoltare și implementare mult mai profund decât au fost vreodată administratorii care doar încărcau actualizările pe ftp. Una dintre sarcinile cheie ale inginerului DevOps în prezent este să asigure un proces confortabil și eficientes între echipele de dezvoltare și infrastructura produsului. Acești oameni sunt responsabili pentru implementarea sistemelor de rollback și de deployment, aceștia reduc o parte din încărcătura dezvoltorilor și se concentrează cât mai mult pe sarcina lor extrem de importantă. Totuși, un devops nu va trasa un cablu nou sau nu va aduce un laptop din depozit (c) KO.
Care este capcana?
La întrebarea „Cine este DevOps?” jumătate dintre angajații din domeniu încep să răspundă ceva de genul „Ei bine, acesta este, pe scurt, un admin care…” și continuă. Da, cu mult timp în urmă, când profesia de inginer DevOps abia începea să se dezvolte din cei mai talentați administratori în materie de servicii, diferențele între ele nu erau evidente pentru toți. Dar acum, când funcțiile de DevOps și admin în echipă au devenit radical diferite, a le confunda sau a le considera egale este inacceptabil.
Însă, care sunt implicațiile pentru afacere?
Angajarea, aici intervine totul.
Deschideți un anunț de angajare pentru „Administrator sistem” și acolo sunt enumerate cerințele „interacțiune cu dezvoltarea și clienții”, „sistem de livrare CI/CD”, „întreținerea serverelor și echipamentelor companiei”, „administrarea sistemelor interne” și așa mai departe; înțelegeți că angajatorul spune ceva absurd. Problema este că, în loc de „Administrator sistem” în titlul anunțului de angajare ar trebui să scrie „Inginer DevOps”, iar dacă schimbați acest titlu, totul își revine la normal.
Însă, ce impresie se formează citind un astfel de anunț de angajare? Că firma caută un „multi-tasker”, care va implementa atât sistemul de control al versiunilor, cât și monitorizarea, și va lucra la diverse lucruri cu dinții…
Și, pentru a nu amplifica haosul pe piața muncii, este suficient să numim anunțurile de angajare pe numele lor și să înțelegem clar că inginerul DevOps și administratorul sistem sunt două entități diferite. Cu toate acestea, dorința insațiabilă a unor angajatori de a solicita un set cât mai larg de cerințe duce la faptul că administratorii de sistem „clasic” nu mai înțeleg ce se întâmplă în jurul lor. Ce, profesia se transformă și ei au rămas în urmă?
Nu, nu și încă o dată nu. Administratorii infrastructurii, care vor gestiona serverele interne ale companiei sau vor ocupa funcții de suport L2/L3 și vor ajuta alți angajați, nu au dispărut și nu au de gând să plece.
Poate deveniți ingineri DevOps? Desigur, pot. De fapt, aceasta este o mediu apropiat, care necesită abilități de administrare a sistemelor, dar pe lângă acestea, se adaugă lucrul cu monitorizarea, sistemele de livrare și, în general, o colaborare strânsă cu echipa de dezvoltare și testare.
O altă problemă a DevOps
De fapt, angajarea și confuzia constantă între administratori și DevOps nu sunt singurele probleme. Într-un anumit moment, afacerea s-a confruntat cu dificultăți în livrarea actualizărilor și în interacțiunea echipei de dezvoltare cu infrastructura finală.
Poate că atunci a urcat pe scena unei conferințe un tip cu ochii sclipind și a spus: „Așa facem noi și numim asta DevOps. Acești oameni vor rezolva toate problemele voastre” — și a început să povestească cât de bine îi merge companiei după implementarea practicilor DevOps.
Cu toate acestea, nu este suficient să angajezi un inginer DevOps pentru ca totul să funcționeze „așa cum trebuie”. Compania trebuie să treacă printr-o transformare DevOps completă, adică rolul și oportunitățile devops-ului nostru trebuie să fie recunoscute și de echipa de dezvoltare și testare a produsului. Avem o „frumoasă” poveste despre acest subiect, care ilustrează pe deplin toate momentele dificile care se petrec uneori.
Situația. De la DevOps se cere să implementeze un sistem de restaurare a versiunilor, fără a se implica prea mult în modul în care va funcționa. Să presupunem că, în sistemul Users, există câmpuri distincte pentru nume, prenume și parolă. Se lansează o nouă versiune a produsului, dar pentru dezvoltatori "restaurarea" este doar o baghetă magică care repară totul, iar ei nici măcar nu își imaginează cum funcționează. Așadar, de exemplu, dezvoltatorii în cadrul unei actualizări au combinat câmpurile de nume și prenume, l-au lansat în producție, iar versiunea se blochează din anumite motive. Ce se întâmplă? Conducerea se duce la DevOps și îi spune „Trage firul!”, adică îi cere să se întoarcă la versiunea anterioară. Ce face DevOps? Se întoarce la versiunea anterioară, dar deoarece dezvoltatorii nu au vrut să se implice în modul în care se face această restaurare, nimeni nu i-a spus lui DevOps că trebuie să restaureze și baza de date. În cele din urmă, totul se prăbușește, iar utilizatorii, în loc de un site lent, văd eroarea „500”, deoarece vechea versiune nu funcționează cu câmpurile noii baze de date. DevOps nu este la curent cu asta. Dezvoltatorii tac. Conducerea începe să își piardă nervii și bani și își amintește de copii de siguranță, propunând să se restaureze din acestea, pentru a avea „ măcar ceva care să funcționeze”. Ca urmare, utilizatorii își pierd toate datele pentru o anumită perioadă de timp.
Desigur, DevOps primește critici, căci "nu a făcut un sistem de restaurare corect", dar faptul că vinovații în această poveste sunt dezvoltatorii, pe nimeni nu pare să-l intereseze.
Concluzia este simplă: fără o abordare corectă a DevOps, efectul nu este foarte mare.
Cel mai important lucru de reținut este că inginerul DevOps nu este magician, iar fără comunicări de calitate și interacțiune bidirecțională cu dezvoltarea, el nu va putea să își îndeplinească sarcinile. DevOps nu poate fi lăsat singur cu "problemele" sale sau să i se spună „nu te băga la dezvoltatori, ei se ocupă de cod”, apoi să ne așteptăm ca în momente critice să funcționeze totul cum trebuie. Așa ceva nu funcționează.
În esență, DevOps reprezintă competențe situate la intersecția dintre management și tehnologie. În mod surprinzător, nu este evident că în această combinație tehnologică ar trebui să existe mai mult management decât tehnologie. Dacă doriți cu adevărat să construiți procese de dezvoltare mai rapide și mai eficiente, trebuie să aveți încredere în DevOps-ul dumneavoastră. El cunoaște instrumentele necesare, a realizat proiecte similare și știe cum să facă. Ajutați-l, ascultați-i sfaturile, nu încercați să-l izolați într-o unitate autonomă. Dacă administratorii pot lucra de unii singuri, în acest caz, DevOps-ii devin inutili; ei nu vă pot ajuta să deveniți mai buni dacă nu doriți să acceptați această ajutor.
Și un ultim lucru: destul cu supărarea administratorilor de infrastructură. Au un front de muncă propriu, extrem de important. Da, un administrator poate deveni inginer DevOps, dar acest lucru ar trebui să se întâmple din dorința propriei persoane, nu sub presiune. Nu este nimic greșit în faptul că un administrator de sistem dorește să rămână administrator de sistem — aceasta este o profesie separată și un drept al său. Dacă există dorința de a trece printr-o transformare profesională, atunci nu trebuie să uităm că va trebui să dezvoltați nu doar abilități tehnologice, ci și abilități de management. Este foarte posibil ca să fie nevoie de dumneavoastră ca lider să aduceți toți acești oameni împreună și să îi învățați să comunice în aceeași limbă.
Sursa: habr.com
