Kas ir DevOps un kādus uzdevumus veic DevOps inženieris
Termins DevOps (izstrādes operācijas vai darbības ietvaros
Bagātīgs prakses arsenāls tuvina DevOps citiempopulāra IT jomā, izmantojot Agile metodi. Tā ir iteratīva dizaina pieeja, kas ļauj pielāgoties mainīgajām prasībām. Attiecīgi DevOps speciālists cenšas padarīt produktu labāku, un biznesa procesi ir paredzamāki un pārredzamāki. Tas arī uzlabo uzņēmējdarbības rādītājus, piemēram, saīsina laiku līdz tirgum. Tas ir laika posms no produktu izstrādes sākuma līdz tirgus laišanai tirgū. Zināšanas par faktoriem, kas pagarina laiku programmatūras izveidei, un sistēmas pieeja ļauj DevOps inženierim padarīt ražošanu nepārtrauktu un ātru. Lai padarītu to skaidrāku, automašīnu salikšanai varat uzzīmēt līdzību ar konveijeru. Visas detaļas ir izstrādātas iepriekš, lai montāžas laikā tās lieliski savienotos. Inženieri, kas projektē motoru, domā par tā darbību kopā ar riteņiem, bremzēm utt. DevOps dara to pašu: uzņemas atbildību par vairāk produkta nekā izstrādātājs, pārliecinās, ka visas komandas sadarbojas.
Rozā poniju pasaule: sacensība par modes filozofiju
Tomēr ne visiem uzņēmumiem DevOps ir vajadzīgs.Piemēram, komandās bez iepriekš pastāvošiem IT departamentiem, kas nav iesaistīti digitālā produkta ražošanā, DevOps filozofija vispār nav piemērojama. Šajās jomās ietilpst uzņēmumi, kuru peļņa nav tieši atkarīga no tā, cik apmierināti klienti ir ar IT produktu, ar kuru viņi mijiedarbojas. Turklāt tas bieži vien nav piemērots mazajiem uzņēmumiem. Metodika prasa izmaiņas daudzos izveidotos biznesa procesos un pat korporatīvajā kultūrā. Mazie uzņēmumi var vienkārši nepieļaut šādas izmaiņas no projektu ekonomikas viedokļa.
Modes digitālās transformācijas slimība bieži irattiecas uz šādu uzņēmumu vadītājiem. Tiekoties ar nebeidzamu optimizāciju, viņi aizmirst par citiem faktoriem, kas ietekmē biznesu. Tā rezultātā uzņēmumi zaudē naudu, efektivitāti un sliktākajā gadījumā biznesa procesus, kas tiek veidoti gadiem ilgi. IT giganti, bankas, lieli tirdzniecības un rūpniecības pasākumi ir cits jautājums. Viņiem DevOps var būt ļoti izdevīgs. Tādējādi saskaņā ar Alfa-Bank 2017. gada pārskatu metodikas ieviešana ļāva mums 60 reizes paātrināt izstrādi un ieviešanu.
Stakhanovite-mnogostanochnik darbnīcas vietā
Protams, tik plaša funkcionalitāte ir grūtajāveic vienam darbiniekam, tāpēc ideālā gadījumā visa pārfunkcionāla komanda ir iesaistīta DevOps. Tajā ietilpst profesionāļi, kas pilda procesu un produktu vadītāju, infrastruktūras kodu izstrādātāja, inženiera un daudz citu lomu. Tomēr Krievijas praksē DevOps speciālists bieži var kļūt par modernu veidu, kā ietaupīt naudu produktu radīšanai. Parasti šāda situācija rodas pēc tam, kad uzņēmuma augstākais vadītājs nolemj, ka ir pienācis laiks digitālajai transformācijai. Uzņēmums steidzami pieņem darbā jaunus speciālistus vai paplašina esošo izstrādātāju un sistēmu administratoru pienākumu sarakstu. Rezultātā personāla atlases pakalpojumi nepiedāvā vakances DevOps inženieriem, bet gan vairāku staciju darbiniekiem.
Šādam darbiniekam var uzlikt pienākumus individuālikonfigurēt serverus, izvietot kabeļu sistēmas un pēc tam izsekot kļūdām, konfigurēt datu bāzes un projektu mitināšanu utt. Šis piemērs ir ārkārtējs, bet reāls. Tā rezultātā darbinieki ātri izdeg, un metodikas ieviešana uzņēmuma darbā neizdodas. Attieksme pret DevOps speciālistu kā burvju mākslinieku, kurš vienlaikus var veikt lielu skaitu uzdevumu, apvienojumā ar visas sistēmas darbības uzraudzību, nedos peļņu biznesam.
Vēl viena izplatīta problēma ir saistīta arsadalot komandu divās grupās, kuras nevar saprasties. Iedomājieties, ka IT uzņēmumā parādās DevOps nodaļa, kurai ir atļauts mainīt ierastās darba procedūras. Tomēr šie noteikumi paliek saistoši citiem izstrādātājiem. Protams, šajā gadījumā nav jārunā par sadarbību un darba “bezšuvēm”. Abas komandas sāk sadursmes, un produktivitāte krītas.
Pulvera muca triecienā: DevOps ir ne tikai prasmes
Viens no DevOps nodaļas uzdevumiem ir izveidotkomunikācija starp dažādiem uzņēmuma IT speciālistiem. DevOps inženieriem vajadzētu ne tikai ieviest tehnoloģijas un atkļūdošanas procesus, bet arī iegremdēt attīstības komandu biznesa gaitā - dalīties pienākumos, palīdzēt palielināt kompetences. Neskatoties uz to, šādi speciālisti bieži vien nodarbojas ar tīri tehniskiem uzdevumiem, parasti gan viņu, gan to, kuru kompetences jāpalielina, dēļ banālā laika trūkuma.
Tā rezultātā, sakarā ar to, ka ieviests modernsIkviens izmanto tehnoloģijas, un zināšanas un prasmes ir koncentrētas vienā nodaļā, rodas problemātiskas situācijas, arī katastrofālas. Jauni risinājumi, ko radījuši DevOps inženieri, bez labi koordinēta dažādu departamentu darba, var radīt tik daudz problēmu, cik sākotnēji vajadzēja atrisināt, kas nenozīmē, ka DevOps speciālistiem korporatīvā kultūra būtu jāizveido no nulles, kā šķiet, ka vietējie bieži domā. vadītājiem. Digitālā ražošanas cauruļvada vienotībai un jaunu prasmju un komunikācijas nodošanas veicināšanai jānāk no uzņēmuma vadītājiem. Bez tā pat DevOps komanda attīstīsies vāji un nedalīsies zināšanās ar komandu.
Ne DevOps ārpakalpojumi, nekonsultējoties ar speciālistu no ārpuses. Pirmajā gadījumā ārējo komandu vada nevis klienta uzņēmuma vajadzības, bet gan standarta tehnoloģiju kopums, kas tiek kotēts tirgū. Klientam šī ir loterija: ārpakalpojuma darbinieki tirgū izmanto neskaidru izpratni par DevOps. Tā rezultātā biznesa procesi kļūst arvien sarežģītāki, bet tas nedod nekādu labumu biznesam. Bieži vien uzņēmumi paši veicina šādu pieeju - piemēram, lūdzot nemainīt savus attīstības procesus. Ir skaidrs, ka tas ir pretrunā ar pašu DevOps jēdzienu.
Garš, dārgs, problemātisks: skarbs DevOps krievu valodā
Tā vietā, lai piemērotu DevOps filozofijuvisiem biznesa procesiem vietējie uzņēmumi bieži dod priekšroku darbam ar rīkiem, kas neietekmēs darba ātrumu. Viens no rezultātiem, piemēram, ir "ķieģeļu mūris" - Operations, tas ir, sistēmas administratoru komanda, paliek izolēta, un izstrādātāji viņiem vienkārši met lietojumprogrammas. Protams, tāpēc rīku kopa joprojām uzlabojas. Tomēr fundamentālas izmaiņas nenotiek, pārredzamība nepalielinās un IT komandas sadarbība neuzlabojas.
Vēl viena aizķeršanās, uz kuras viņi pakluptvadītāji, ieviešot DevOps - korporatīvo zināšanu bāzes trūkums. Saskaņā ar 2019. gada DORA ziņojumu komandas, kas izmantoja iekšējos uzņēmuma informācijas avotus, bija 1,73 reizes efektīvākas nekā citas. Šī problēma atkal ir saistīta ar daudzu Krievijas uzņēmumu slēgto kultūru, kurā komanda nedala zināšanas. Šī slēgtā rakstura dēļ uzņēmumi sāk uzkrāt tehniskos parādus. Rīki kļūst novecojuši, artefakti netiek noņemti, dokumentācija netiek atjaunināta.
Objektīvā biznesa nepieciešamība pēc ražošanas stabilitātes un līdz ar to arī peļņas, apvienojumā ar novecojušu tehnoloģiju bāzi un tehniskajiem parādiem noved pie neveiksmīgas DevOps izmantošanas.
Tas viss bieži noved pie tā, ka pēc ilgām mokām vienkārši tiek izmesti DevOps komandas piedāvātie jaunie risinājumi, un procesi tiek "atritināti".
Katram uzņēmumam ir savs digitālās transformācijas ceļš.Vairumā gadījumu tas patiešām maina to, kā jūsu kods tiek izstrādāts un izvietots labāk. Tas nozīmē, ka DevOps joprojām pastāv Krievijā: katru mēnesi tirgū parādās daudz vakanču, kas saistītas ar šo metodiku. Cita lieta, ka aiz tām slēpjas dažādas specialitātes definīcijas un praktiskie uzdevumi. Tomēr uzņēmumiem jāpārtrauc vajāt spokainas ideālas IT sistēmas un kritiski jāizturas pret modernu, bet ne vienmēr ienesīgu filozofiju, prioritizējot savas vajadzības.
Skatiet arī:
Melnajos caurumos var būt visumi. Mēs jums pastāstām par jauno atklājumu
Slimības 3. dienā lielākajai daļai COVID-19 pacientu zūd oža un bieži cieš no iesnas
Pētījumi: okeāna dibenā atrasti 15 miljoni tonnu mikroplastmasas