De ce este nevoie pentru ca o companie IT să aibă succes în 2019? Lectorii de la conferințe și întâlniri spun o mulțime de cuvinte tare care nu sunt întotdeauna de înțeles pentru oamenii normali. Lupta pentru timpul de implementare, microservicii, abandonarea monolitului, transformarea DevOps și multe, multe altele. Dacă renunțăm la frumusețea verbală și vorbim direct și în rusă, atunci totul se reduce la o teză simplă: faceți un produs de înaltă calitate și faceți-l cu confort pentru echipă.
Acesta din urmă a devenit extrem de important. Afacerile au ajuns în sfârșit la concluzia că un proces confortabil de dezvoltare crește productivitatea, iar dacă totul este depanat și funcționează ca un ceas, oferă și un spațiu de manevră în situații critice. Cândva, de dragul acestei manevre, o anumită persoană inteligentă a venit cu backup-uri, dar industria se dezvoltă și am ajuns la inginerii DevOps - oameni care transformă procesul de interacțiune dintre dezvoltare și infrastructura externă în ceva adecvat și nu are legătură cu şamanismul.
Toată această poveste „modulară” este minunată, dar... S-a întâmplat că unii dintre admini au fost denumiți brusc DevOps, iar inginerilor DevOps înșiși au început să li se ceară să aibă cel puțin abilitățile de telepatie și clarviziune.
Înainte de a vorbi despre problemele moderne de furnizare a infrastructurii, să definim ce înțelegem prin acest termen. În momentul de față, situația s-a dezvoltat în așa fel încât am ajuns la dualitatea acestui concept: infrastructura poate fi condiționat extern și condiționat intern.
Prin infrastructură externă înțelegem tot ceea ce asigură funcționalitatea serviciului sau produsului pe care echipa îl dezvoltă. Acestea sunt servere de aplicații sau site-uri web, găzduire și alte servicii care asigură funcționalitatea produsului.
Infrastructura internă include servicii și echipamente care sunt utilizate de echipa de dezvoltare însăși și de alți angajați, dintre care de obicei sunt mulți. Acestea sunt servere interne ale sistemelor de stocare a codului, un manager de activități implementat local și tot, tot, tot ce există în intranetul corporativ.
Ce face un administrator de sistem într-o companie? Pe lângă munca de administrare a acestui intranet foarte corporativ, acesta poartă adesea povara preocupărilor economice pentru a asigura operabilitatea echipamentelor de birou. Administratorul este același tip care va trage rapid o unitate de sistem nouă sau un laptop de rezervă gata de utilizare din camera din spate, va oferi o tastatură nouă și se va târa în patru picioare prin birouri, întinzând cablul Ethernet. Un administrator este proprietarul local și conducătorul nu numai al serverelor interne și externe, ci și al unui director de afaceri. Da, unii administratori pot lucra doar în planul de sistem, fără hardware. Acestea ar trebui să fie separate într-o subclasă separată de „administratori de sistem de infrastructură”. Iar unii sunt specializați în deservirea exclusiv a echipamentelor de birou; din fericire, dacă firma are peste o sută de oameni, munca nu se termină niciodată. Dar niciunul dintre ei nu este devop.
Cine sunt DevOps? Devopii sunt tipi care vorbesc despre interacțiunea dezvoltării software cu infrastructura externă. Mai precis, dezvoltatorii moderni sunt implicați în procesele de dezvoltare și implementare mult mai profund decât au fost implicați vreodată administratorii care pur și simplu au încărcat actualizări pe ftp. Una dintre sarcinile cheie ale unui inginer DevOps acum este să asigure un proces confortabil și structurat eficient de interacțiune între echipele de dezvoltare și infrastructura produsului. Acești oameni sunt responsabili pentru implementarea sistemelor de rollback și implementare; acești oameni sunt cei care preiau o parte din sarcina dezvoltatorilor și se concentrează cât mai mult posibil pe sarcina lor extrem de importantă. În același timp, devopții nu vor rula niciodată un cablu nou și nu vor emite un laptop nou din camera din spate (c) KO
Care e siretlicul?
La întrebarea „Cine este DevOps?” jumătate dintre muncitorii din domeniu încep să răspundă ceva de genul „Ei bine, pe scurt, acesta este adminul care...” și mai departe în text. Da, pe vremuri, când profesia de inginer DevOps tocmai ieșea de la cei mai talentați administratori în ceea ce privește întreținerea serviciilor, diferențele dintre ei nu erau evidente pentru toată lumea. Dar acum, când funcțiile devopilor și ale adminului din echipă au devenit radical diferite, este inacceptabil să le confundăm între ele sau chiar să le echivalăm.
Dar ce înseamnă asta pentru afaceri?
Angajarea, totul este despre asta.
Deschideți un post vacant pentru „Administrator de sistem”, iar cerințele enumerate acolo sunt „interacțiunea cu dezvoltarea și clienții”, „sistem de livrare CI/CD”, „întreținerea serverelor și a echipamentelor companiei”, „administrarea sistemelor interne” etc. pe; înțelegi că angajatorul vorbește prostii. Problema este că, în loc de „Administrator de sistem”, titlul postului vacant ar trebui să fie „Inginer DevOps”, iar dacă acest titlu este schimbat, atunci totul este la locul lor.
Totuși, ce impresie ai când citești un astfel de post vacant? Că compania caută un operator cu mai multe mașini care să implementeze atât un sistem de control al versiunii, cât și un sistem de monitorizare și să strângă sucitorul cu dinții...
Dar pentru a nu crește gradul de dependență de droguri pe piața muncii, este suficient să numiți posturile vacante pe numele lor propriu și să înțelegeți clar că un inginer DevOps și un administrator de sistem sunt două entități diferite. Dar dorința ireprimabilă a unor angajatori de a prezenta candidatului cea mai largă listă de cerințe posibilă duce la faptul că administratorii de sistem „clasici” nu mai înțeleagă ce se întâmplă în jurul lor. Ce, profesia este în schimbare și sunt în urmă cu vremurile?
Nu nu și încă o dată nu. Administratorii de infrastructură care vor gestiona serverele interne ale companiei sau vor ocupa posturi de suport L2/L3 și vor ajuta alți angajați, nu au plecat și nu vor pleca.
Acești specialiști pot deveni ingineri DevOps? Desigur că pot. De fapt, acesta este un mediu înrudit care necesită abilități de administrare a sistemului, dar pe lângă aceasta, se adaugă lucrul cu sistemele de monitorizare, livrare și, în general, interacțiunea strânsă cu echipa de dezvoltare și testare.
O altă problemă DevOps
De fapt, totul nu se limitează doar la angajare și confuzie constantă între administratori și devopți. La un moment dat, afacerea s-a confruntat cu problema livrării de actualizări și a interacțiunii echipei de dezvoltare cu infrastructura finală.
Poate că a fost când un unchi cu ochi strălucitori s-a ridicat pe scena unei conferințe și a spus: „Facem asta și îi spunem DevOps. Acești tipi îți vor rezolva toate problemele” - și au început să spună cât de bună este viața în companie după implementarea practicilor DevOps.
Cu toate acestea, nu este suficient să angajezi un inginer DevOps pentru ca totul să funcționeze așa cum ar trebui. Compania trebuie să treacă printr-o transformare DevOps completă, adică rolul și capacitățile DevOps-ului nostru trebuie să fie înțelese clar și de partea echipei de dezvoltare și testare a produselor. Avem o poveste „minunată” pe această temă care ilustrează pe deplin toată brutalitatea care se întâmplă în unele locuri.
Situatie. DevOps este necesar pentru a implementa un sistem de retragere a versiunii fără să se aprofundeze cu adevărat în modul în care va funcționa. Să presupunem că în sistemul Users există câmpuri separate pentru prenume, nume și parolă. Apare o nouă versiune a produsului, dar pentru dezvoltatori, un „rollback” este doar o baghetă magică care va repara totul și nici măcar nu știu cum funcționează. Deci, de exemplu, în următorul patch, dezvoltatorii au combinat câmpurile nume și prenume, l-au lansat în producție, dar versiunea este lentă din anumite motive. Ce se întâmplă? Managementul vine la devops și spune „Trageți comutatorul!”, adică îi cere să revină la versiunea anterioară. Ce face devops? Se revine la versiunea anterioară, dar, din moment ce dezvoltatorii nu au vrut să-și dea seama cum s-a făcut această derulare, nimeni nu a spus echipei devops că și baza de date trebuie să fie derulată înapoi. Ca urmare, totul se blochează pentru noi și, în loc de un site web lent, utilizatorii văd o eroare „500”, deoarece versiunea veche nu funcționează cu câmpurile noii baze de date. Devops nu știe despre asta. Dezvoltatorii tac. Conducerea începe să-și piardă nervii și banii și își amintește de copiile de rezervă, oferindu-se să retragă de la ele, astfel încât „măcar ceva să funcționeze”. Drept urmare, utilizatorii își pierd toate datele într-o perioadă de timp.
Nucile, desigur, merg la devop-uri, care „nu au făcut un sistem de rollback adecvat”, și nimănui nu-i pasă că elanii din această poveste sunt dezvoltatori.
Concluzia este simplă: fără o abordare normală a DevOps ca atare, este de puțin folos.
Principalul lucru de reținut: un inginer DevOps nu este un magician și, fără comunicații de calitate și interacțiune bidirecțională cu dezvoltarea, nu va face față sarcinilor sale. Dezvoltatorii nu pot fi lăsați singuri cu „problemele” lor sau să li se primească comanda „nu vă amestecați cu dezvoltatorii, sarcina lor este să codifice” și apoi să spere că într-un moment critic totul va funcționa așa cum ar trebui. Nu așa funcționează.
În esență, DevOps este o competență la granița dintre management și tehnologie. Mai mult, este departe de a fi evident că ar trebui să existe mai multă tehnologie decât management în acest cocktail. Dacă doriți cu adevărat să construiți procese de dezvoltare mai rapide și mai eficiente, trebuie să aveți încredere în echipa dvs. de devops. Cunoaște instrumentele potrivite, a implementat proiecte similare, știe să o facă. Ajută-l, ascultă-i sfatul, nu încerca să-l izolezi într-un fel de unitate autonomă. Dacă administratorii pot lucra pe cont propriu, atunci devop-urile sunt inutile în acest caz; ei nu vă vor putea ajuta să deveniți mai buni dacă nu doriți să acceptați acest ajutor.
Și un ultim lucru: nu mai jignești administratorii de infrastructură. Ei au propriul lor front de lucru, extrem de important. Da, un administrator poate deveni inginer DevOps, dar acest lucru ar trebui să se întâmple la cererea persoanei însuși și nu sub presiune. Și nu este nimic în neregulă cu faptul că un administrator de sistem vrea să rămână administrator de sistem - aceasta este profesia lui separată și dreptul său. Dacă vrei să treci printr-o transformare profesională, atunci nu trebuie să uiți niciodată că va trebui să-ți dezvolți nu doar abilitățile tehnologice, ci și cele de management. Cel mai probabil, va depinde de tine, ca lider, să aduci toți acești oameni împreună și să-i înveți să comunice în aceeași limbă.
Sursa: www.habr.com