DevOps a devenit un subiect foarte popular în ultimii ani. Mulți visează să se alăture acestuia, dar, așa cum arată practica, de multe ori doar din cauza nivelului salariilor.
Unii oameni listează DevOps pe CV-ul lor, deși nu știu sau înțeleg întotdeauna esența termenului. Unii oameni cred că după ce ai studiat Ansible, GitLab, Jenkins, Terraform și altele asemenea (lista poate fi continuată după gustul tău), vei deveni imediat un „devopsist”. Acest lucru, desigur, nu este adevărat.
În ultimii ani, m-am implicat în principal în implementarea DevOps în diverse companii. Înainte de asta, a lucrat mai bine de 20 de ani în posturi, de la administrator de sistem până la director IT. În prezent, inginer principal DevOps la Playgendary.
Cine este DevOps
Ideea de a scrie un articol a apărut după o altă întrebare: „cine este DevOps?” Nu există încă un termen stabilit pentru ce sau cine este. Unele dintre răspunsuri sunt deja în aceasta . În primul rând, voi evidenția punctele principale din acesta, apoi îmi voi împărtăși observațiile și gândurile.
DevOps nu este un specialist care poate fi angajat, nu un set de utilități și nu un departament de dezvoltatori cu ingineri.
DevOps este o filozofie și o metodologie.
Cu alte cuvinte, este un set de practici care ajută dezvoltatorii să interacționeze activ cu administratorii de sistem. Adică să se conecteze și să integreze procesele de lucru unul în celălalt.
Odată cu apariția DevOps, structura și rolurile specialiștilor au rămas aceleași (sunt dezvoltatori, sunt 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 actualizat regulat.
- Software-ul trebuie făcut rapid.
- Software-ul ar trebui să fie implementat convenabil și într-un timp scurt.
Nu există un singur instrument pentru DevOps. Configurarea, livrarea și studierea mai multor produse nu înseamnă că DevOps a apărut în companie. Există o mulțime de instrumente și toate sunt utilizate în etape diferite, dar servesc unui scop comun.
Și aceasta este doar o parte a instrumentelor DevOps
Intervievez oameni pentru postul de inginer DevOps de mai bine de 2 ani și am ajuns să realizez cât de important este să înțelegem clar esența termenului. Am acumulat experiențe specifice, observații și gânduri pe care vreau să le împărtășesc.
Din experiența interviului, văd următoarea imagine: specialiștii care consideră DevOps un titlu de post au de obicei neînțelegeri cu colegii.
A fost un exemplu izbitor. Un tânăr a venit la un interviu cu multe cuvinte inteligente pe CV-ul său. La ultimele sale trei locuri de muncă, avea 5-6 luni de experiență. Am părăsit două startup-uri pentru că „nu au decolat”. Dar despre a treia companie, el a spus că nimeni nu-l înțelege acolo: dezvoltatorii scriu cod pe Windows, iar directorul forțează ca acest cod să fie „împachetat” în Docker obișnuit și încorporat în conducta CI/CD. Tipul a spus o mulțime de lucruri negative despre locul său actual de muncă și despre colegii săi - am vrut doar să răspund: „Deci nu vei vinde un elefant”.
Apoi i-am pus o întrebare care se află în fruntea listei mele pentru fiecare candidat.
— Ce înseamnă DevOps pentru tine personal?
- În general sau cum îl percep?
M-a interesat opinia lui personală. El cunoștea teoria și originea termenului, dar nu era puternic de acord cu ele. El credea că DevOps era un titlu de post. Aici se află rădăcina problemelor sale. La fel și alți specialiști cu aceeași părere.
Angajatorii, care au auzit multe despre „magia DevOps”, vor să găsească o persoană care să vină să creeze această „magie”. Iar solicitanții din categoria „DevOps este un job” nu înțeleg că prin această abordare nu vor putea îndeplini așteptările. Și, în general, au scris DevOps pe CV-ul lor pentru că este o tendință și plătesc foarte mult pentru asta.
Metodologia și filozofia DevOps
Metodologia poate fi teoretică și practică. În cazul nostru, este al doilea. După 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 diferi semnificativ. Ceea ce nu o face mai bine sau mai rău.
Metodologia DevOps este doar un mijloc de a atinge obiectivele.
Acum despre ce este filozofia DevOps. Și aceasta este probabil cea mai dificilă întrebare.
Este destul de greu de formulat un răspuns scurt și succint, deoarece nu a fost încă formalizat. Și din moment ce adepții filozofiei DevOps sunt mai implicați în practică, pur și simplu nu există timp pentru filosofare. Cu toate acestea, acesta este un proces foarte important. Mai mult, este direct legată de activitățile de inginerie. Există chiar și o zonă specializată de cunoaștere - .
La universitatea mea nu exista o astfel de materie, trebuia să studiez totul pe cont propriu folosind materialele pe care le puteam găsi în anii 90. Subiectul este opțional pentru învățământul ingineresc, de unde și lipsa formalizării răspunsului. Dar acei oameni care sunt serios cufundați în DevOps încep să simtă un anumit „spirit” sau „comprehensiune inconștientă” a tuturor proceselor companiei.
Folosind propria mea experiență, am încercat să oficializez unele dintre „postulatele” acestei filosofii. Rezultatul este următorul:
- DevOps nu este ceva independent care poate fi separat într-o zonă separată de cunoaștere sau activitate.
- Toți angajații companiei ar trebui să fie ghidați de metodologia DevOps atunci când își planifică activitățile.
- DevOps afectează toate procesele din cadrul unei companii.
- DevOps există pentru a reduce costurile de timp pentru orice proces din cadrul unei companii pentru a asigura dezvoltarea serviciilor sale și confortul maxim al clienților.
- DevOps, în limbaj modern, este poziția proactivă a fiecărui angajat al companiei, având ca scop reducerea costurilor de timp și îmbunătățirea calității produselor IT din jurul nostru.
Cred că „postulatele” mele sunt un subiect separat de discuție. Dar acum există ceva pe care să construim.
Ce face DevOps
Cuvântul cheie aici este comunicare. Există o mulțime de comunicări, al căror inițiator ar trebui să fie exact același inginer DevOps. De ce este asta? Pentru că aceasta este filozofie și metodologie, și numai atunci cunoștințe de inginerie.
Nu pot vorbi cu încredere 100% despre piața muncii din Vest. 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 sute de prevânzări tehnice pentru serviciul „Implementarea DevOps” pentru mari companii și bănci rusești.
În Rusia, DevOps este încă un subiect foarte tânăr, dar deja trending. Din câte știu, doar la Moscova deficitul de astfel de specialiști în 2019 a fost de peste 1000 de oameni. Și cuvântul Kubernetes pentru angajatori este aproape ca o cârpă roșie pentru un taur. Adepții acestui instrument sunt gata să-l folosească chiar și acolo unde nu este necesar și profitabil din punct de vedere economic. Angajatorul nu înțelege întotdeauna în ce cazuri ce este mai potrivit de utilizat și, cu o implementare adecvată, întreținerea unui cluster Kubernetes costă de 2-3 ori mai mult decât implementarea unei aplicații folosind o schemă convențională de cluster. Folosește-l acolo unde chiar ai nevoie.
Implementarea DevOps este costisitoare din punct de vedere financiar. Și se justifică doar acolo unde aduce beneficii economice în alte domenii, și nu de la sine.
Inginerii DevOps sunt, de fapt, pionieri – ei sunt cei care ar trebui să fie primii care implementează această metodologie în companie și construiesc procese. Pentru ca acest lucru să aibă succes, specialistul trebuie să interacționeze constant cu angajații și colegii de la toate nivelurile. După cum spun de obicei, toți angajații companiei ar trebui să fie implicați în procesul de implementare a DevOps: de la femeia de curățenie până la CEO. Și aceasta este o condiție prealabilă. Dacă cel mai junior membru al echipei nu știe și nu înțelege ce este DevOps și de ce sunt efectuate anumite acțiuni organizaționale, atunci implementarea cu succes nu va funcționa.
De asemenea, un inginer DevOps trebuie să folosească o resursă administrativă din când în când. De exemplu, pentru a depăși „rezistența mediului” - atunci când echipa nu este pregătită să accepte instrumentele și metodologia DevOps.
Dezvoltatorul ar trebui să scrie doar cod și teste. Pentru a face acest lucru, nu are nevoie de un laptop super-puternic pe care va implementa și va sprijini local întreaga infrastructură a proiectului. De exemplu, un frontender găzduiește toate elementele aplicației pe laptopul său, inclusiv baza de date, emulator S3 (minio) etc. Adică petrece mult timp întreținând această infrastructură locală și se luptă de unul singur cu toate problemele unei astfel de soluții. În loc să dezvolte cod pentru față. Astfel de oameni pot fi foarte rezistenti la orice schimbare.
Dar există echipe care, dimpotrivă, sunt bucuroși să introducă noi instrumente și metode și participă activ la acest proces. Deși nici în acest caz, comunicarea dintre inginerul DevOps și echipă nu a fost anulată.
Când DevOps nu este necesar
Există situații în care DevOps nu este necesar. Acesta este un fapt - trebuie înțeles și acceptat.
În primul rând, acest lucru se aplică oricăror companii (în special întreprinderile mici), când profitul acestora nu depinde direct de prezența sau absența produselor IT care oferă servicii de informare clienților. Și aici nu vorbim despre site-ul companiei, fie că este o „carte de vizită” statică sau cu blocuri dinamice de știri etc.
DevOps este necesar atunci când satisfacția clientului dvs. și dorința acestuia de a reveni din nou la dvs. depind de disponibilitatea acestor servicii de informații pentru interacțiunea cu clientul, calitatea și direcționarea acestora.
Un exemplu izbitor este o bancă binecunoscută. Compania nu are birouri tradiționale pentru clienți, fluxul de documente se realizează prin poștă sau curier, iar mulți angajați lucrează de acasă. Compania a încetat să mai 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 întâlnirilor și conferințelor tematice. Pe unele dintre ele le-am vizitat personal - aceasta este o experiență foarte utilă pentru cei care doresc să se dezvolte în această direcție. Iată link-uri către canale YouTube cu prelegeri și materiale bune despre DevOps:
Acum uită-te la afacerea ta și gândește-te la asta: cât de mult depind compania ta și profiturile sale de produsele IT pentru a permite interacțiunea cu clienții?
Dacă compania dvs. vinde pește într-un magazin mic și singurul produs IT este două configurații 1C: Enterprise (Contabilitate și UNF), atunci nu are sens să vorbim despre DevOps.
Dacă lucrați la o mare întreprindere comercială și de producție (de exemplu, produceți puști de vânătoare), atunci ar trebui să vă gândiți la asta. Puteți lua inițiativa și transmite conducerii dvs. perspectivele de implementare a DevOps. Ei bine, și, în același timp, conduce acest proces. O poziție proactivă este una dintre principiile importante ale filozofiei DevOps.
Dimensiunea și volumul cifrei de afaceri financiare anuale nu reprezintă principalul criteriu pentru a determina dacă compania dumneavoastră are nevoie de DevOps.
Să ne imaginăm o mare întreprindere industrială care nu interacționează direct cu clienții. De exemplu, unii producători de automobile și companii producătoare de automobile. Nu sunt sigur acum, dar din experiența mea trecută, timp de mulți ani, toată interacțiunea cu clienții s-a făcut prin e-mail și telefon.
Clienții lor sunt o listă limitată de dealeri de mașini. Și fiecăruia i se atribuie un specialist de la producător. Tot fluxul de documente intern are loc prin SAP ERP. Angajații interni sunt în esență clienți ai sistemului informațional. Dar acest IS este controlat prin mijloace clasice de gestionare a sistemelor cluster. Ceea ce exclude posibilitatea utilizării practicilor DevOps.
De aici concluzia: pentru astfel de întreprinderi, implementarea DevOps nu este ceva extrem de important, dacă ne amintim de obiectivele metodologiei de la începutul articolului. Dar nu exclud ca ei să folosească unele instrumente DevOps astăzi.
Pe de altă parte, există multe companii mici care dezvoltă software folosind metodologia, filozofia, practicile și instrumentele DevOps. Și ei cred că costul implementării DevOps este costul care le permite să concureze eficient pe piața software. Pot fi văzute exemple de astfel de companii .
Principalul criteriu pentru a înțelege dacă DevOps este necesar: ce valoare au produsele tale IT pentru companie și clienți.
Dacă produsul principal al companiei care generează profit este software-ul, aveți nevoie de DevOps. Și nu este atât de important dacă câștigi bani reali folosind alte produse. Aici sunt incluse și magazinele online sau aplicațiile mobile cu jocuri.
Orice joc există datorită finanțării: directe sau indirecte de la jucători. La Playgendary, dezvoltăm jocuri mobile gratuite cu peste 200 de persoane direct implicate în crearea lor. Cum folosim DevOps?
Da, exact la fel ca cel descris mai sus. Comunic în mod constant cu dezvoltatorii și testerii și efectuez instruiri interne pentru angajați cu privire la metodologia și instrumentele DevOps.
Acum folosim în mod activ Jenkins ca instrument de conducte CI/CD pentru executarea tuturor conductelor de asamblare cu Unity și implementarea ulterioară în App Store și Play Market. Mai multe din setul de instrumente clasic:
- Asana - pentru managementul proiectelor. Integrarea cu Jenkins a fost configurată.
- Google Meet - pentru întâlniri video.
- Slack - pentru comunicații și diverse alerte, inclusiv notificări de la Jenkins.
- Atlassian Confluence - pentru documentare și lucru în grup.
Planurile noastre imediate includ introducerea analizei codului static folosind SonarQube și efectuarea de testare automată a UI folosind Selenium în etapa de integrare continuă.
În loc de concluzie
Aș dori să închei cu următorul gând: pentru a deveni un inginer DevOps înalt calificat, este vital să înveți cum să comunici în direct cu oamenii.
Un inginer DevOps este un jucător de echipă. Si nimic altceva. Inițiativa în comunicarea cu colegii ar trebui să vină de la el, și nu sub influența unor împrejurări. Un specialist DevOps trebuie să vadă și să propună cea mai bună soluție pentru echipă.
Și da, implementarea oricărei soluții va necesita multe discuții, iar până la sfârșit se poate schimba cu totul. Dezvoltându-se independent, propunându-și și implementând ideile sale, o astfel de persoană are o valoare din ce în ce mai mare atât pentru echipă, cât și pentru angajator. Ceea ce, în cele din urmă, se reflectă în cuantumul remunerației sale lunare sau sub formă de bonusuri suplimentare.
Sursa: www.habr.com