Kāpēc nepieciešams DevOps un kas ir DevOps speciālisti

Kad programma nefunkcionē, vismaz ko nevēlies dzirdēt no kolēģiem, ir frāze "problēma ir jūsu pusē". Rezultātā cieš lietotāji – un viņiem ir vienalga, kura komandas daļa ir atbildīga par traucējumiem. DevOps kultūra radās tieši tāpēc, lai saliedētu izstrādi un atbalstu un apvienotu tos kopīgā atbildībā par gala produktu.

Kādas prakses iekļaujas DevOps jēdzienā un kāpēc tās ir nepieciešamas? Ar ko nodarbojas DevOps inženieri un ko viņi jāprot? Uz šiem un citiem jautājumiem atbild eksperti no EPAM: Kirils Sergejevs, sistēmu inženieris un DevOps evaņģēlists, un Igors Boiko, vadošais sistēmu inženieris un vienas no DevOps komandām koordinators uzņēmumā.

Kāpēc nepieciešams DevOps?

Agrāk starp izstrādātājiem un atbalsta (t. i., operations) darbiniekiem pastāvēja barjera. Izklausās paradoksāli, bet viņiem bija dažādi mērķi un KPI, lai gan viņi veica kopīgu uzdevumu. Izstrādes mērķis bija pēc iespējas ātrāk īstenot biznesa prasības un pievienot tās strādājošam produktam. Atbalsts atbildēja par to, lai programma stabilā darbotos – un jebkuras izmaiņas apdraud stabilitāti. Redzama interešu konflikta rezultātā – DevOps radās, lai to atrisinātu.

Kas ir DevOps?

Jautājums ir labs – un strīdīgs: pasaulē par to vēl nav panākta vienošanās. EPAM uzskata, ka DevOps apvieno tehnoloģijas, procesus un komandas sadarbības kultūru. Šī apvienošana ir vērsta uz vērtību nepārtrauktu piegādi gala lietotājiem.

Kirils Sergejevs: "Izstrādātāji raksta kodu, testētāji to pārbauda, bet administratori instalē gala produktu ražošanas vidē. Ilgu laiku šīs komandas daļas bija diezgan atdalītas, bet pēc tam radās ideja tās apvienot kopīgā procesā. Tādējādi radās DevOps prakses."

Ir pienācis tas brīdis, kad izstrādātāji un sistēmu inženieri sāka interesēties par citu darbu. Barjera starp ražošanu un atbalstu sāka dzist. Tādējādi radās DevOps, kas ietver prakses, kultūru un sadarbības kārtību komandā.

Kāds ir DevOps kultūras pamats?

At the core, the responsibility for the final outcome rests with each member of the team. The most interesting and complex aspect of DevOps philosophy is realizing that an individual is not just responsible for their particular phase of work, but for how the entire product will function. The issue does not lie on anyone’s side – it is a shared challenge, and every team member contributes to its resolution.

A fundamental aspect of DevOps culture is addressing problems, not just applying DevOps practices. Moreover, these practices are not implemented 'on someone’s side' but throughout the entire product. A project does not merely need a DevOps engineer; it requires a solution to a problem, and the role of a DevOps engineer can be distributed among several team members with different specializations.

What DevOps practices exist?

DevOps practices encompass all stages of the software lifecycle.

Igors Boiko: 'The ideal scenario is to start using DevOps practices right at the project initiation. Along with the architects, we plan what the architectural landscape of the application will be, where it will be located, and how it will scale, choosing the platform. Currently, microservices architecture is in vogue – we select an orchestration system for it: it is necessary to manage each component of the application independently and update it without affecting others. Another practice is “infrastructure as code”. This refers to an approach where the project’s infrastructure is created and managed through code rather than direct interaction with servers.

Next, we move on to the development stage. Here, one of the largest practices is building CI/CD: we need to help developers integrate changes into the product quickly, in small increments, more frequently and with less pain. CI/CD encompasses code checking, merging to the master branch, and deploying the application in testing and production environments.

At the CI/CD stages, the code goes through quality gates. These are used to ensure that the code released from the developer's workstation meets the specified quality criteria. Unit testing and UI testing are introduced here. For rapid, painless, and focused product deployment, an appropriate type of deployment can be selected.

DevOps praksēm ir vieta arī atbalsta posmā, kad produkts ir gatavs. Tās tiek izmantotas uzraudzībai, atgriezeniskajai saitei, drošībai un izmaiņu ieviešanai. DevOps uz šiem uzdevumiem skatās kā būtiskām uzlabošanas iespējām. Mēs cenšamies samazināt atkārtotas darbības un automatizēt tās. Šeit ietilpst arī migrācijas, lietotnes paplašināšana, kā arī darba spējas uzturēšana.

Kādas priekšrocības sniedz DevOps prakses?

Ja mēs rakstītu mācību grāmatu par mūsdienu DevOps praksēm, tās pirmajā lapā tiktu iekļauti trīs punkti: automatizācija, izlaišanas paātrināšana un ātra atgriezeniskā saite no lietotājiem.

Kirils Sergejevs: "Pirmais punkts – automatizācija. Mēs varam automatizēt visu sadarbību komandā: uzrakstījām kodu – izlaides – pārbaudījām – instalējām – apkopojuši atsauksmes – atgriezāmies sākumā. Viss šis process tiek veikts automātiski.

Otrais punkts – izlaišanas paātrināšana un pat izstrādes vienkāršošana. Pasūtītājam vienmēr ir svarīgi, lai produkts nonāktu tirgū pēc iespējas ātrāk un sāktu gūt ieguvumus agrāk nekā konkurentu analogi. Produkta piegādes procesu var bezgalīgi uzlabot: saīsināt laiku, pievienot papildu kontroles punktus, pilnveidot uzraudzību.

Trešais punkts – ātrāka atgriezeniskā saite no lietotājiem. Ja lietotājam ir piezīmes, mēs varam nekavējoties veikt labojumus un tūlīt atjaunināt lietotni.

Kā saplūst jēdzieni "sistēmu inženieris", "build inženieris" un "DevOps inženieris"?

Tie pārklājas, bet attiecas uz nedaudz atšķirīgām jomām.

Sistēmu inženieris uzņēmumā EPAM ir amats. Tie ir dažādos līmeņos: no junior līdz Chief Specialist.

Build inženieris ir drīzāk loma, kuru var veikt projektā. Pašlaik tā sauc cilvēkus, kas ir atbildīgi par CI/CD.

DevOps inženieris ir speciālists, kurš projektā ievieš DevOps prakses.

Ja visu to apkopojam, sanāk sekojošais: cilvēks, kas ieņem sistēmu inženiera amatu, projektā veic build inženiera lomu un nodarbojas ar DevOps prakšu ieviešanu.

Ar ko tieši nodarbojas DevOps inženieris?

DevOps inženieri apvieno visas projekta sastāvdaļas. Viņi pārzina programmētāju, testētāju un sistēmu administratoru darba specifiku un palīdz vienkāršot viņu darbu. Viņi izprot biznesa vajadzības un prasības, tā lomu izstrādes procesā, un veido procesu, ņemot vērā pasūtītāja intereses.

Mēs daudz runājām par automatizāciju – ar to DevOps inženieri nodarbojas vispirms. Tas ir ļoti būtisks punkts, kurā, starp citu, ietilpst apkārtnes sagatavošana.

Kirils Sergejevs: "Pirms atjauninājumu ieviešanas produktā, tos nepieciešams pārbaudīt trešās puses vidē. To sagatavo DevOps inženieri. Viņi arī ievieš DevOps kultūru projektā kopumā: ievieš DevOps prakses visos savus projektu slāņos. Šie trīs principi: automatizācija, vienkāršošana, paātrināšana – tie tiek ieviesti visur, kur viņi var sasniegt."

Ko būtu jāzina DevOps inženierim?

Pamatā viņam jābūt zināšanām no dažādām jomām: programmēšana, darbs ar operētājsistēmām, datu bāzēm, kompilācijas un konfigurācijas sistēmām. Tam pievienojas prasmes strādāt ar mākoņa infrastruktūru, orķestrācijas un uzraudzības sistēmām.

1. Programmēšanas valodas

DevOps inženieri pārvalda vairākas pamata valodas automatizācijai un var, piemēram, teikt programmētājam: "Varbūt tu darīsi koda uzstādīšanu nevis manuāli, bet gan ar mūsu skriptu, kas visu automatizē? Mēs sagatavosim tam config failu, kurš būs ērti lasāms gan tev, gan mums – un mēs jebkurā brīdī varēsim to mainīt. Un vēl mēs redzēsim, kurš, kad un kādēļ veic izmaiņas tajā."

DevOps inženieris var apgūt vienu vai vairākas no šīm valodām: Python, Groovy, Bash, Powershell, Ruby, Go. Nav nepieciešams tās zināt dziļā līmenī – pietiek ar pamatiem sintaksē, OOP principiem, spējām uzrakstīt vienkāršus skriptus automatizācijai.

2. Operētājsistēmas

DevOps inženierim jāizprot, uz kā servera tiks uzstādīts produkts, kādā vidē tas darbosies, ar kādām pakalpojumiem tas mijiedarbosies. Var izvēlēties specializāciju uz Windows vai Linux ģimenē.

3. Versiju kontroles sistēmas

Bez zināšanām par versiju kontroles sistēmām DevOps inženierim nav kur doties. Git – šobrīd viena no populārākajām sistēmām.

4. Mākoņu pakalpojumu sniedzēji

AWS, Google, Azure – īpaši, ja mēs runājam par Windows virzienu.

Kirils Sergejevs: «Mākoņu pakalpojumu sniedzēji piedāvā mums virtuālos serverus, kas lieliski iekļaujas CI/CD sistēmās.

Desmit instalēšana fizisko serveru prasa apmēram simts manuālas darbības. Katru serveri ir jāpalaiž, jāinstalē un jāiestata nepieciešamā operētājsistēma, jāinstalē mūsu lietotne uz šiem desmit serveriem un pēc tam desmit reizes jāveic visi pārbaudes. Mākoņu pakalpojumi aizvieto šo procedūru ar desmit koda rindām, un labam DevOps inženierim jāspēj šīs iespējas izmantot. Tādējādi viņš ietaupa laiku, pūles un naudu – gan pasūtītājam, gan uzņēmumam».

5. Orkestrācijas sistēmas: Docker un Kubernetes

Kirils Sergejevs: «Virtuālie serveri tiek sadalīti konteineros, kuru katrā mēs varam instalēt mūsu lietotni. Kad konteineru ir daudz, ir nepieciešama to pārvaldīšana: vienu ieslēgt, otru izslēgt, kaut kur veikt dublējumus. Tas kļūst diezgan sarežģīti, tāpēc ir nepieciešama orkestrācijas sistēma.

Agrāk katru lietotni apkalpoja atsevišķs serveris – jebkuras izmaiņas tās darbībā varēja ietekmēt lietotnes darbību. Pateicoties konteineriem, lietotnes kļūst izolētas un tiek palaistas atsevišķi – katra savā virtuālajā mašīnā. Ja notiek kļūme, nav nepieciešams tērēt laiku, lai meklētu cēloņus. Vienkāršāk ir iznīcināt veco konteineru un pievienot jauno».

6. Konfigurācijas sistēmas: Chef, Ansible, Puppet

Kad ir nepieciešams apkalpot visu serveru parku, jāveic daudz līdzīgu darbību. Tas ir ilgs un sarežģīts process, turklāt manuālais darbs palielina kļūdu iespēju. Šeit nāk palīgā konfigurācijas sistēmas. Ar to palīdzību izveido skriptu, kuru ir ērti lasīt gan programmētājiem, gan DevOps inženieriem, gan sistēmu administratoriem. Šis skripts palīdz automātiski veikt vienādas darbības serveros. Tādējādi manuālo darbību (un, līdz ar to, kļūdu) kļūst mazāk.

Kādu karjeru var veidot DevOps inženieris?

Attīstība var notikt gan horizontāli, gan vertikāli.

Igors Boiko: «No horizontālā attīstības viedokļa DevOps inženieriem tagad ir visplašākās iespējas. Viss pastāvīgi mainās, un prasmes var attīstīt visdažādākajos virzienos: no versiju kontroles līdz monitorēšanai, no konfigurāciju pārvaldības līdz datubāzēm.

Vai kļūt par sistēmu arhitektu, ja darbiniekam interesē izprast, kā lietotne darbojas visos tās dzīves cikla posmos – no izstrādes līdz atbalstam.

Kā kļūt par DevOps inženieri?

1. Izlasiet grāmatas «Projektu “Fēnikss”» un DevOps rokasgrāmatu. Tie ir patiesi DevOps filozofijas pīlāri, pirmā ir mākslas romāns.
2. Studējiet tehnoloģijas no iepriekš minētā saraksta: patstāvīgi vai tiešsaistes kursos.
3. Pievienojieties kā DevOps inženieris atvērtā pirmkoda projektam.
4. Praktizējiet un piedāvājiet DevOps prakses savos personiskajos un darba projektos.

Avots: habr.com