Tema DevOps a devenit foarte populară în ultimii ani. Mulți își doresc să se integreze în acest domeniu, dar, așa cum arată practica, de multe ori o fac doar din cauza nivelului salariilor.
Unii menționează în CV-urile lor DevOps, deși nu întotdeauna știu și înțeleg esența termenului. Cineva consideră că, studiind Ansible, GitLab, Jenkins, Terraform și altele de acest fel (lista poate continua după bunul plac), devin imediat «devops». Asta, desigur, nu este adevărat.
În ultimii câțiva ani, m-am ocupat în principal cu implementarea DevOps în diverse companii. Până atunci am lucrat mai bine de 20 de ani în funcții de la administrator de sistem la director IT. Acum - DevOps Lead Engineer la Playgendary.
Cine este DevOps
Ideea de a scrie un articol a apărut după o întrebare frecventă: «cine este DevOps?». Până acum nu există un termen stabilit a ceea ce sau cine este acesta. Unele răspunsuri se găsesc deja în acest . În primul rând, voi evidenția principalele aspecte din el, apoi voi împărtăși observațiile și gândurile mele.
DevOps nu este un specialist pe care îl poți angaja, nu este un set de utilitare și nu este un departament de dezvoltare cu ingineri.
DevOps este o filosofie și o metodologie.
Cu alte cuvinte, este un set de practici care ajută la interacțiunea activă a dezvoltatorilor cu administratorii de sistem. Adică, leagă și integrează fluxurile de lucru între ele.
Odată cu apariția DevOps, structura și rolurile specialiștilor au rămas aceleași (există dezvoltatori, există ingineri), dar regulile de interacțiune s-au schimbat. Granițele dintre departamente s-au estompat.
Obiectivele DevOps pot fi descrise în trei puncte:
- Software-ul trebuie să fie actualizat regulat.
- Software-ul trebuie să fie dezvoltat rapid.
- Software-ul trebuie să fie implementat convenabil și într-un timp scurt.
DevOps nu are un instrument unic. A configura, a instala și a studia mai multe produse nu înseamnă că în companie a apărut DevOps. Există foarte multe instrumente și toate sunt folosite în diferite etape, dar servesc unui singur scop comun.
Și aceasta este doar o parte din instrumentele DevOps
De mai bine de 2 ani, intervievez oameni pentru poziția de inginer DevOps și am realizat cât de important este să înțelegem clar esența termenului. S-a acumulat o experiență specifică, observații și gânduri pe care vreau să le împărtășesc.
Din experiența interviurilor, observ următoarea situație: specialiștii care consideră DevOps o funcție au, de obicei, neînțelegeri cu colegii.
A fost un exemplu strălucit. La interviu a venit un tânăr cu multe cuvinte sofisticate în CV. La ultimele trei locuri de muncă a avut o experiență de 5-6 luni. A plecat de la două startupuri pentru că „nu au avut succes”. Iar despre a treia companie a spus că acolo nimeni nu-l înțelege: dezvoltatorii scriu cod pe Windows, iar directorul îl obligă să „învelească” acest cod în Docker obișnuit și să-l integreze în pipeline-ul CI/CD. Tânărul a povestit multe lucruri negative despre actualul său loc de muncă și colegi — îți venea să-i răspunzi: „Dar tu nu poți vinde un elefant.”
Apoi i-am pus o întrebare, care este una dintre primele din lista mea pentru fiecare candidat.
— Ce înseamnă pentru tine personal DevOps?
— În general sau cum îl percep eu?
M-a interesat opinia lui personală. El cunoștea teoria și originea termenului, dar era categoric în dezacord cu ele. Considera că DevOps este o funcție. Aici se află rădăcina problemelor sale, la fel ca și pentru alți specialiști cu aceeași părere.
Angajatorii, după ce au auzit despre „magia DevOps”, vor să găsească pe cineva care să vină și să creeze această „magie”. Iar candidații care consideră că „DevOps este o funcție” nu înțeleg că, printr-o astfel de abordare, nu vor putea justifica așteptările. În general, au menționat în CV-ul lor DevOps pentru că este o tendință și pentru că se plătește bine pentru asta.
Metodologia și filosofia DevOps
Metodologia poate fi teoretică și practică. În cazul nostru — a doua. Așa cum am menționat mai sus, DevOps este un set de practici și strategii utilizate pentru a atinge obiectivele declarate. Și, în fiecare caz, în funcție de procesele de afaceri ale companiei, acesta poate varia semnificativ. Acest lucru nu îl face mai bun sau mai rău.
Metodologia DevOps este doar un mijloc de a atinge obiectivele stabilite.
Acum să discutăm despre ce înseamnă filosofia DevOps. Și aceasta, probabil, este cea mai dificilă întrebare.
Să formulezi un răspuns concis și clar este destul de complicat, deoarece nu a fost încă formalizat. Și având în vedere că adepții filozofiei DevOps se concentrează mai mult pe practică — nu au timp pentru filozofare. Totuși, este un proces extrem de important. Și este direct legat de activitatea inginerilor. Există chiar un domeniu specializat de cunoaștere — .
La universitate la care am studiat nu avea o astfel de disciplină, așa că a trebuit să învăț totul singur din materialele pe care am reușit să le găsesc în anii '90. Subiectul nu este obligatoriu pentru educația în inginerie, de aici și lipsa unei formalizări a răspunsului. Însă persoanele care s-au cufundat serios în DevOps încep să simtă un fel de „duh” sau „o universalitate inconștientă” a tuturor proceselor companiei.
Din experiența mea, am încercat să formalizez câteva „postulate” ale acestei filozofii. Iată ce a rezultat:
- DevOps nu este ceva independent, care să poată fi desprins ca o direcție separată de cunoștințe sau activitate.
- Toți angajații companiei trebuie să se ghideze după metodologia DevOps atunci când își planifică activitatea.
- DevOps afectează toate procesele din cadrul companiei.
- DevOps există pentru a reduce timpul alocat oricăror procese interne ale companiei, pentru a asigura dezvoltarea serviciilor sale și confortul maxim al clientului.
- DevOps, pe scurt, reprezintă o poziție proactivă a fiecărui angajat al companiei, vizând reducerea costurilor de timp și îmbunătățirea calității produselor IT care ne înconjoară.
Cred că postulatele mele constituie un subiect separat de discuție. Dar acum avem un punct de plecare.
Ce face DevOps
Cuvântul cheie aici este — comunicarea. Există foarte multe comunicări, inițiatorul cărora ar trebui să fie tocmai acel inginer DevOps. De ce? Pentru că este o filozofie și o metodologie, iar cunoștințele tehnice vin abia după.
Nu pot vorbi cu 100% siguranță despre piața muncii din Occident. Dar știu destul de multe despre piața DevOps din Rusia. Pe lângă sute de interviuri, în ultimul an și jumătate am participat la o sută de preselecții tehnice pentru serviciul „Implementarea DevOps” pentru mari companii și bănci rusești.
În Rusia, DevOps este încă un domeniu foarte tânăr, dar deja la modă. Cât de bine știu, doar în Moscova, deficitul acestor specialiști a fost de peste 1000 de persoane în 2019. Iar cuvântul Kubernetes este pentru angajatori aproape ca o cârpă roșie pentru un taur. Adeptii acestui instrument sunt gata să-l folosească chiar și acolo unde nu este necesar și economic avantajos. Angajatorul nu înțelege întotdeauna în ce cazuri este mai bine să folosească, iar în cazul unui desfășurării corespunzătoare, întreținerea unui cluster Kubernetes costă de 2-3 ori mai mult decât desfășurarea aplicației printr-un sistem de cluster obișnuit. Folosiți-l acolo unde este cu adevărat necesar.
Implementarea DevOps, din punct de vedere financiar, este costisitoare. Și este justificată doar acolo unde aduce beneficii economice în alte domenii, nu de la sine.
Inginerii DevOps sunt, de fapt, pionieri — tocmai ei trebuie să implementeze această metodologie în companie și să stabilească procesele. Pentru a avea succes, specialistul trebuie să interacționeze constant cu angajații și colegii la toate nivelurile. Așa cum îmi place să spun, în procesul de implementare a DevOps trebuie să fie implicați toți angajații companiei: de la curățenie până la CEO. Și aceasta este o condiție esențială. Dacă cel mai tânăr membru al echipei nu va ști și nu va înțelege ce este DevOps și de ce se fac anumite acțiuni organizaționale, nu va fi o implementare de succes.
De asemenea, inginerul DevOps trebuie să folosească din când în când resurse administrative. De exemplu, pentru a depăși «rezistența mediului» — atunci când echipa nu este pregătită să accepte instrumentele și metodologia DevOps.
Dezvoltatorul trebuie să scrie doar cod și teste. Pentru asta, nu are nevoie de un laptop super puternic pe care să desfășoare și să mențină local întreaga infrastructură a proiectului. De exemplu, un frontender păstrează pe laptopul său toate elementele aplicației, inclusiv baza de date, emulatorul S3 (minio) și altele. Adică, își consumă mult timp întreținând această infrastructură locală și se luptă singur cu toate problemele unei astfel de soluții. În loc să dezvolte cod pentru front. Astfel de oameni pot rezista puternic la orice modificare.
Dar există echipe care, dimpotrivă, sunt încântate de introducerea de noi instrumente și metode și participă activ în acest proces. Chiar și în acest caz, comunicarea dintre inginerul DevOps și echipă nu a fost anulată.
Când nu este necesar DevOps
Există situații în care DevOps nu este necesar. Acesta este un fapt – trebuie să-l înțelegem și să-l acceptăm.
În primul rând, acest lucru se referă la orice companie (în special micile afaceri) când profitul lor nu depinde direct de existența sau absența produselor IT care oferă servicii de informație clienților. Și aici nu este vorba despre site-ul companiei, fie el o simplă «carte de vizită» statică sau cu blocuri de știri dinamice etc.
DevOps este necesar atunci când existența acestor servicii informaționale de interacțiune cu clientul, calitatea și targetarea lor influențează satisfacția clientului și dorința acestuia de a reveni la voi.
Un exemplu izbitor este o bancă cunoscută. Compania nu are birouri obișnuite pentru clienți, circulația documentelor se face prin poștă sau curieri, iar mulți angajați lucrează de acasă. Compania a încetat să fie doar o bancă și, în opinia mea, s-a transformat într-o companie IT cu tehnologii DevOps dezvoltate.
Multe alte exemple și prelegeri pot fi găsite în înregistrările mitingurilor și conferințelor tematice. O parte dintre acestea le-am vizionat personal – este o experiență foarte utilă pentru cei care doresc să se dezvolte în această direcție. Iată linkuri către canale YouTube cu prelegeri bune și materiale despre DevOps:
Acum, priviți-vă afacerea și gândiți-vă la următorul lucru: cât de mult depind compania dumneavoastră și profitul său de produsele IT care asigură interacțiunea cu clientul?
Dacă compania dumneavoastră vinde pește într-un mic magazin și singurele produse IT sunt două configurații 1C: Întreprindere (Contabilitate și UNF), atunci este puțin probabil să existe sens în a vorbi despre DevOps.
Dacă însă lucrați într-o mare întreprindere comercială și de producție (de exemplu, produceți puști de vânătoare), atunci merită să reflectați. Puteți să luați inițiativa și să informați conducerea despre perspectivele implementării DevOps. Și, în plus, să conduceți acest proces. O poziție proactivă este unul dintre principiile importante ale filozofiei DevOps.
Dimensiunea și volumul cifrei de afaceri financiare anuale nu reprezintă principalul criteriu pentru stabilirea necesității DevOps în compania dumneavoastră.
Să ne imaginăm o mare companie industrială care nu interacționează direct cu clienții. De exemplu, unele companii auto și producători de automobile. Acum nu sunt sigur, dar din experiența mea anterioară, mulți ani întregi toată interacțiunea cu clienții s-a desfășurat prin e-mail și telefon.
Clienții lor reprezintă o listă restrânsă de dealeri auto. Și fiecărui dealer îi este alocat un specialist de la producător. Toată documentația internă se desfășoară prin ERP SAP. Angajații interni, de fapt, sunt clienți ai sistemului informațional. Dar gestionarea acestui sistem informațional se face prin metode clasice de gestionare a sistemelor cluster. Acest lucru exclude posibilitatea adoptării practicilor DevOps.
Concluzia este că pentru astfel de companii, implementarea DevOps nu este critică, dacă ne amintim de scopurile metodologiei menționate la începutul articolului. Dar nu exclud că unele instrumente DevOps sunt folosite de ei astăzi.
Pe de altă parte, există multe companii mici care dezvoltă software folosind metodologia, filosofia, practicile și instrumentele DevOps. Și consideră că cheltuielile pentru implementarea DevOps sunt costuri care le permit să concureze eficient pe piața software-ului. Exemple de astfel de companii pot fi observate .
Criteriul principal pentru a înțelege dacă ai nevoie de DevOps este: ce importanță au produsele tale IT pentru companie și clienți.
Dacă produsul principal al companiei care generează profit este software-ul — ai nevoie de DevOps. Și nu contează atât de mult dacă câștigi bani reali prin alte bunuri. Aici se includ și magazinele online sau aplicațiile mobile cu jocuri.
Orice jocuri pot exista datorită finanțării: directe sau indirecte din partea jucătorilor. La Playgendary dezvoltăm jocuri mobile gratuite, în crearea cărora participă direct peste 200 de persoane. Cum folosim DevOps?
Exact la fel cum este descris mai sus. Comunică constant cu dezvoltatorii și testerii, organizez instruiri interne pentru angajați privind metodologia și instrumentele DevOps.
Acum folosim activ Jenkins ca instrument pentru CI/CD pipelines pentru a executa toate conductorii de construcție cu Unity și pentru implementarea ulterioară în App Store și Play Market. De asemenea, din setul clasic de instrumente:
- Asana — pentru gestionarea proiectelor. Integrarea cu Jenkins este configurată.
- Google Meet — pentru organizarea întâlnirilor video.
- Slack — pentru comunicare și diverse notificări, inclusiv cele din Jenkins.
- Atlassian Confluence — pentru documentare și colaborare în grup.
În planurile viitoare se află implementarea analizei statice a codului folosind SonarQube și realizarea testării automate a interfeței utilizatorului cu ajutorul Selenium în etapa de Integrare Continuă.
În concluzie
Vreau să închei cu următoarea idee: pentru a deveni un inginer DevOps de înaltă calitate, este esențial să înveți să comunici eficient cu oamenii.
Inginerul DevOps este un jucător de echipă. Și altfel nu poate fi. Inițiativa în comunicarea cu colegii trebuie să vină de la el însuși, nu sub influența unor circumstanțe externe. Specialiștii DevOps trebuie să observe și să propună cele mai bune soluții pentru echipă.
Și da, implementarea oricărei soluții va necesita multe discuții, iar la final se poate modifica complet. Dezvoltându-se autonom, propunând și realizând propriile idei, o astfel de persoană reprezintă o valoare din ce în ce mai mare atât pentru echipă, cât și pentru angajator. Ce, în cele din urmă, se reflectă și în mărimea remunerației sale lunare sau sub formă de bonusuri suplimentare.
Sursa: habr.com
