Ja lietojumprogramma nedarbojas, pēdējā lieta, ko vēlaties dzirdēt no saviem kolēģiem, ir frāze “problēma ir jūsu pusē”. Rezultātā lietotāji cieš, un viņiem ir vienalga, kura komandas daļa ir atbildīga par bojājumu. DevOps kultūra radās tieši tāpēc, lai apvienotu attīstību un atbalstu kopā ar kopīgu atbildību par galaproduktu.
Kādas prakses ir iekļautas DevOps koncepcijā un kāpēc tās ir vajadzīgas? Ko dara DevOps inženieri un kas viņiem būtu jāspēj? EPAM eksperti atbild uz šiem un citiem jautājumiem: Kirils Sergejevs, sistēmu inženieris un DevOps evaņģēlists, un Igors Boiko, vadošais sistēmu inženieris un vienas no uzņēmuma DevOps komandām koordinators.
Kāpēc ir nepieciešams DevOps?
Iepriekš pastāvēja barjera starp izstrādātājiem un atbalstu (tā saucamajām operācijām). Tas izklausās paradoksāli, taču viņiem bija atšķirīgi mērķi un KPI, lai gan viņi darīja vienu un to pašu. Izstrādes mērķis bija pēc iespējas ātrāk ieviest biznesa prasības un pievienot tās strādājošam produktam. Atbalsts bija atbildīgs par to, lai lietojumprogramma darbotos stabili, un visas izmaiņas apdraud stabilitāti. Ir interešu konflikts — parādījās DevOps, lai to atrisinātu.
Kas ir DevOps?
Tas ir labs un strīdīgs jautājums: pasaule vēl nav par to galīgi vienojusies. EPAM uzskata, ka DevOps apvieno tehnoloģijas, procesus un mijiedarbības kultūru komandā. Šīs asociācijas mērķis ir nepārtraukti sniegt vērtību galalietotājiem.
Kirils Sergejevs: “Izstrādātāji raksta kodu, testētāji to pārskata, un administratori izvieto galaproduktu ražošanā. Ilgu laiku šīs komandas daļas bija zināmā mērā izkliedētas, un tad radās doma tās apvienot ar kopīgu procesu. Šādi parādījās DevOps prakse.
Pienāca diena, kad izstrādātāji un sistēmu inženieri sāka interesēties viens par otra darbu. Sāka zust barjera starp ražošanu un atbalstu. Tādā veidā radās DevOps, kas ietver praksi, kultūru un komandas mijiedarbību.
Kāda ir DevOps kultūras būtība?
Fakts ir tāds, ka atbildība par gala rezultātu ir katram komandas dalībniekam. Pats interesantākais un grūtākais DevOps filozofijā ir saprast, ka konkrētais cilvēks nav atbildīgs tikai par savu darba posmu, bet ir atbildīgs par to, kā darbosies viss produkts. Problēma neguļ neviena pusē – tā tiek dalīta, un katrs komandas dalībnieks palīdz to atrisināt.
Vissvarīgākais DevOps kultūrā ir atrisināt problēmu, nevis tikai piemērot DevOps praksi. Turklāt šīs prakses tiek īstenotas nevis “kāda pusē”, bet visā produktā. Projektam nav nepieciešams DevOps inženieris pats par sevi — tam ir nepieciešams problēmas risinājums, un DevOps inženiera lomu var sadalīt starp vairākiem komandas locekļiem ar atšķirīgu specializāciju.
Kādi ir DevOps prakšu veidi?
DevOps prakse aptver visus programmatūras dzīves cikla posmus.
Igors Boiko: “Ideāls gadījums ir tad, kad mēs sākam izmantot DevOps praksi tieši projekta uzsākšanas brīdī. Kopā ar arhitektiem plānojam, kāda būs aplikācijas arhitektoniskā ainava, kur tā atradīsies un kā mērogot, un izvēlamies platformu. Mūsdienās modē ir mikropakalpojumu arhitektūra - tai mēs izvēlamies orķestrēšanas sistēmu: jāprot pārvaldīt katru aplikācijas elementu atsevišķi un atjaunināt to neatkarīgi no pārējiem. Vēl viena prakse ir “infrastruktūra kā kods”. Tas ir nosaukums pieejai, kurā projekta infrastruktūra tiek izveidota un pārvaldīta, izmantojot kodu, nevis tiešā mijiedarbībā ar serveriem.
Tālāk mēs pārejam uz izstrādes posmu. Viena no lielākajām praksēm šeit ir CI/CD veidošana: jums jāpalīdz izstrādātājiem ātri, mazās porcijās, biežāk un nesāpīgāk integrēt izmaiņas produktā. CI/CD ietver koda pārskatīšanu, galvenā faila augšupielādi koda bāzē un lietojumprogrammas izvietošanu testēšanas un ražošanas vidēs.
CI/CD posmos kods iziet cauri kvalitātes vārtiem. Ar viņu palīdzību viņi pārbauda, vai kods, kas tiek izvadīts no izstrādātāja darbstacijas, atbilst noteiktajiem kvalitātes kritērijiem. Šeit ir pievienota vienību un lietotāja saskarnes pārbaude. Ātrai, nesāpīgai un mērķtiecīgai produkta izvietošanai varat izvēlēties atbilstošo izvietošanas veidu.
DevOps praktiķiem ir vieta arī gatavā produkta atbalsta posmā. Tos izmanto uzraudzībai, atgriezeniskajai saitei, drošībai un izmaiņu ieviešanai. DevOps aplūko visus šos uzdevumus no nepārtrauktas uzlabošanas perspektīvas. Mēs samazinām atkārtotas darbības un automatizējam tās. Tas ietver arī migrāciju, lietojumprogrammu paplašināšanu un veiktspējas atbalstu.
Kādas ir DevOps prakses priekšrocības?
Ja mēs rakstītu mācību grāmatu par mūsdienu DevOps praksi, pirmajā lapā būtu trīs punkti: automatizācija, izlaidumu paātrināšana un ātra lietotāju atsauksmes.
Kirils Sergejevs: “Pirmā lieta ir automatizācija. Mēs varam automatizēt visas komandas mijiedarbības: uzrakstīja kodu - izlaida to - pārbaudīja - instalēja - apkopoja atsauksmes - atgriezās sākumā. Tas viss notiek automātiski.
Otrais ir izlaišanas paātrināšana un pat izstrādes vienkāršošana. Klientam vienmēr ir svarīgi, lai produkts nonāktu tirgū pēc iespējas ātrāk un sāktu sniegt priekšrocības agrāk nekā konkurentu analogi. Produktu piegādes procesu var uzlabot bezgalīgi: samazināt laiku, pievienot papildu kontroles atzīmes, uzlabot uzraudzību.
Trešais ir lietotāju atsauksmju paātrināšana. Ja viņam ir komentāri, mēs varam nekavējoties veikt korekcijas un nekavējoties atjaunināt lietojumprogrammu.
Kā ir saistīti jēdzieni “sistēmu inženieris”, “konstruktors” un “izstrādātāju inženieris”?
Tie pārklājas, bet pieder nedaudz atšķirīgām jomām.
Sistēmu inženieris uzņēmumā EPAM ir amats. Tie ir dažādos līmeņos: no jaunākā līdz galvenajam speciālistam.
Būvinženieris vairāk ir loma, ko var veikt projektā. Tagad šādi sauc par CI/CD atbildīgos cilvēkus.
DevOps inženieris ir speciālists, kas projektā īsteno DevOps praksi.
Ja to visu summējam, sanāk apmēram šāds: cilvēks sistēmu inženiera amatā spēlē būvinženiera lomu projektā un ir iesaistīts tur DevOps prakšu ieviešanā.
Ko īsti dara DevOps inženieris?
DevOps inženieri saliek kopā visus elementus, kas veido projektu. Viņi pārzina programmētāju, testētāju, 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 attīstības procesā – un veido procesu, ņemot vērā klienta intereses.
Mēs daudz runājām par automatizāciju – ar to pirmām kārtām nodarbojas DevOps inženieri. Tas ir ļoti liels punkts, kas cita starpā ietver vides sagatavošanu.
Kirils Sergejevs: “Pirms atjauninājumu ieviešanas produktā tie ir jāpārbauda trešās puses vidē. To sagatavojuši DevOps inženieri. Viņi ievieš DevOps kultūru visam projektam: viņi ievieš DevOps praksi visos savu projektu slāņos. Šie trīs principi: automatizācija, vienkāršošana, paātrināšana — tie nes visur, kur vien var sasniegt.
Kas būtu jāzina DevOps inženierim?
Kopumā viņam ir jābūt zināšanām dažādās jomās: programmēšana, darbs ar operētājsistēmām, datu bāzēm, montāžas un konfigurācijas sistēmām. Tos papildina spēja strādāt ar mākoņa infrastruktūru, orķestrēšanas un uzraudzības sistēmām.
1. Programmēšanas valodas
DevOps inženieri zina vairākas automatizācijas pamatvalodas un var, piemēram, pateikt programmētājam: “Kā būtu, ja jūs instalētu kodu nevis ar roku, bet izmantojot mūsu skriptu, kas visu automatizē? Mēs tam sagatavosim konfigurācijas failu, tas būs ērti lasāms gan jums, gan mums, un jebkurā laikā varēsim to mainīt. Mēs arī redzēsim, kas, kad un kāpēc tajā veiks izmaiņas.
DevOps inženieris var apgūt vienu vai vairākas no šīm valodām: Python, Groovy, Bash, Powershell, Ruby, Go. Nav nepieciešams tos zināt dziļā līmenī - pietiek ar sintakses pamatiem, OOP principiem un spēju rakstīt vienkāršus skriptus automatizācijai.
2. Operētājsistēmas
DevOps inženierim ir jāsaprot, kurā serverī produkts tiks instalēts, kādā vidē tas darbosies un ar kādiem pakalpojumiem tas mijiedarbosies. Varat izvēlēties specializēties Windows vai Linux saimē.
3. Versiju kontroles sistēmas
Bez zināšanām par versiju kontroles sistēmu DevOps inženieris nekur nav pieejams. Git ir viena no šobrīd populārākajām sistēmām.
4. Mākoņu nodrošinātāji
AWS, Google, Azure - it īpaši, ja mēs runājam par Windows virzienu.
Kirils Sergejevs: “Mākoņpakalpojumu sniedzēji nodrošina mums virtuālos serverus, kas lieliski iekļaujas CI/CD.
Desmit fizisko serveru instalēšanai nepieciešamas aptuveni simts manuālas darbības. Katrs serveris ir manuāli jāpalaiž, jāinstalē un jākonfigurē vajadzīgā operētājsistēma, jāinstalē mūsu lietojumprogramma šajos desmit serveros un pēc tam vēlreiz viss ir jāpārbauda desmit reizes. Mākoņpakalpojumi aizstāj šo procedūru ar desmit koda rindiņām, un labam DevOps inženierim jāspēj ar tiem darboties. Tas ietaupa laiku, pūles un naudu – gan klientam, gan uzņēmumam.
5. Orķestrācijas sistēmas: Docker un Kubernetes
Kirils Sergejevs: “Virtuālie serveri ir sadalīti konteineros, kuros katrā varam instalēt savu aplikāciju. Ja konteineru ir daudz, tie ir jāpārvalda: jāieslēdz viens, jāizslēdz cits, kaut kur jāveido dublējumkopijas. Tas kļūst diezgan sarežģīti un prasa orķestrēšanas sistēmu.
Iepriekš katra aplikācija tika apstrādāta ar atsevišķu serveri – jebkuras izmaiņas tās darbībā varēja ietekmēt aplikācijas apkalpojamību. Pateicoties konteineriem, lietojumprogrammas tiek izolētas un darbojas atsevišķi - katra savā virtuālajā mašīnā. Ja rodas kļūme, nav jātērē laiks, meklējot cēloni. Vienkāršāk ir iznīcināt veco konteineru un pievienot jaunu.
6. Konfigurācijas sistēmas: Chef, Ansible, Puppet
Ja jums ir nepieciešams uzturēt visu serveru parku, jums ir jāveic daudzas tāda paša veida darbības. Tas ir garš un grūts, un arī roku darbs palielina kļūdu iespējamību. Šeit palīgā nāk konfigurācijas sistēmas. Ar viņu palīdzību viņi izveido skriptu, kas ir viegli lasāms programmētājiem, DevOps inženieriem un sistēmu administratoriem. Šis skripts palīdz automātiski veikt tās pašas darbības serveros. Tas samazina manuālās darbības (un līdz ar to arī kļūdas).
Kādu karjeru var izveidot DevOps inženieris?
Jūs varat attīstīties gan horizontāli, gan vertikāli.
Igors Boiko: “No horizontālās attīstības viedokļa DevOps inženieriem tagad ir visplašākās izredzes. Viss nepārtraukti mainās, un jūs varat veidot prasmes dažādās jomās: no versiju kontroles sistēmām līdz uzraudzībai, no konfigurācijas pārvaldības līdz datu bāzēm.
Par sistēmas arhitektu var kļūt, ja darbinieks ir ieinteresēts saprast, kā lietojumprogramma darbojas visos tās dzīves cikla posmos – no izstrādes līdz atbalstam.”
Kā kļūt par DevOps inženieri?
- Izlasiet Phoenix Project un DevOps rokasgrāmatu. Tie ir īstie DevOps filozofijas pīlāri, no kuriem pirmais ir daiļliteratūras darbs.
- Apgūstiet tehnoloģijas no iepriekš minētā saraksta: patstāvīgi vai tiešsaistes kursos.
- Pievienojieties kā DevOps inženieris atvērtā pirmkoda projektam.
- Praktizējiet un piedāvājiet DevOps praksi savos personīgajos un darba projektos.
Avots: www.habr.com