Kas yra „DevOps“ ir kokias užduotis atlieka „DevOps“ inžinierius
Terminas „DevOps“ (kūrimo operacijos arba operacijos viduje
Turtingas praktikos arsenalas suartina „DevOps“ su kitaispopuliarus IT srityje naudojant „Agile“ metodą. Tai iteracinis projektavimo metodas, leidžiantis prisitaikyti prie besikeičiančių reikalavimų. Atitinkamai „DevOps“ specialistas stengiasi padaryti produktą geresnį, o verslo procesai labiau nuspėjami ir skaidresni. Tai taip pat pagerina verslo metriką, pavyzdžiui, sutrumpina „Time-to-Market“. Tai yra laiko tarpas nuo produkto kūrimo pradžios iki rinkos paleidimo. Žinios apie veiksnius, kurie prailgina laiką kuriant programinę įrangą, ir sisteminis požiūris leidžia „DevOps“ inžinieriui gaminti nepertraukiamai ir greitai. Kad būtų aiškiau, galite surinkti analogiją su konvejeriu automobiliams surinkti. Visos dalys yra suprojektuotos iš anksto, kad montuojant jos puikiai derėtų. Inžinieriai, kurie kuria variklį, galvoja apie jo veikimą kartu su ratais, stabdžių sistema ir pan. „DevOps“ daro tą patį: prisiima atsakomybę už daugiau produkto nei kūrėjas, užtikrina, kad visos komandos bendradarbiautų.
„Pink Pony World“: mados filosofijos lenktynės
Tačiau ne visoms įmonėms reikia „DevOps“. Pavyzdžiui, komandose, neturinčiose IT padalinių, kurios nedalyvauja skaitmeninio produkto gamyboje, „DevOps“ filosofija visiškai netaikoma. Šiose srityse yra įmonės, kurių pelnas tiesiogiai nepriklauso nuo to, ar klientai patenkinti IT produktu, su kuriuo jie bendrauja. Be to, jis dažnai netinka mažoms įmonėms. Metodika reikalauja daugelio nusistovėjusių verslo procesų ir net įmonių kultūros pokyčių. Mažos įmonės gali tiesiog netoleruoti tokių pokyčių projektų ekonomikoje.
Madinga skaitmeninės transformacijos liga dažnai būnarūpinasi tokių bendrovių vadovais. Siekdami begalinio optimizavimo, jie pamiršta apie kitus verslą veikiančius veiksnius. Dėl to įmonės praranda pinigus, efektyvumą, o blogiausiu atveju - verslo procesus, kurie buvo kuriami per daugelį metų. IT milžinai, bankai, didelės prekybos ir pramonės renginiai yra kitas dalykas. Jiems „DevOps“ gali būti labai naudinga. Taigi, remiantis „Alfa-Bank“ 2017 m. Metine ataskaita, metodikos įvedimas leido 60 kartų paspartinti kūrimą ir įgyvendinimą.
„Stakhanovite-multi-machine operator“ vietoj darbuotojų dirbtuvių
Žinoma, toks didelis funkcionalumas yra sunkusvienam darbuotojui, todėl idealiu atveju „DevOps“ dalyvauja visa funkcionali komanda. Jame yra specialistai, kurie atlieka procesų ir produktų vadybininkų, infrastruktūros kodų kūrėjų, inžinierių ir daug kitų vaidmenų. Tačiau Rusijos praktikoje „DevOps“ specialistas dažnai gali tapti madingu būdu taupyti pinigus kuriant produktus. Paprastai tokia situacija įvyksta po to, kai aukščiausias įmonės vadovas nusprendžia, kad atėjo laikas skaitmeninei transformacijai. Bendrovė skubiai įdarbina naujus specialistus arba praplečia esamų kūrėjų ir sistemų administratorių atsakomybės sąrašą. Todėl įdarbinimo tarnybos siūlo ne „DevOps“ inžinierių, bet kelių stočių darbuotojų laisvas darbo vietas.
Toks darbuotojas gali būti įpareigotas individualiainustatykite serverius, nustatykite laidus, tada sekite klaidas, nustatykite duomenų bazes ir projektų prieglobą ir pan. Šis pavyzdys yra kraštutinis, bet tikras. Todėl darbuotojai greitai perdega, o metodikos diegimas įmonės darbe žlunga. Elgesys su „DevOps“ specialistu kaip magas, kuris vienu metu gali atlikti daugybę užduočių kartu su visos sistemos veikimo stebėjimu, verslui pelno neduos.
Kita paplitusi problema yra susijusi sususkirstyti komandą į dvi grupes, kurios negali sutarti tarpusavyje. Įsivaizduokite, kad IT įmonė turi „DevOps“ skyrių, kuriam leidžiama keisti įprastas darbo procedūras. Tačiau šios taisyklės lieka privalomos kitiems kūrėjams. Žinoma, šiuo atveju nereikia kalbėti apie bendradarbiavimą ir darbo „vientisumą“. Abi komandos pradeda susidurti, o produktyvumas krenta.
Barelio milteliai triume: „DevOps“ yra ne tik įgūdžiai
Viena iš „DevOps“ skyriaus užduočių yra įsteigtibendravimas tarp skirtingų įmonės IT specialistų. „DevOps“ inžinieriai turėtų ne tik diegti technologijas ir derinti procesus, bet ir panardinti kūrėjų komandą į verslo eigą - dalytis atsakomybe, padėti didinti kompetencijas. Nepaisant to, tokie specialistai dažnai užsiima grynai techninėmis užduotimis, dažniausiai dėl banalaus laiko trūkumo tiek jiems, tiek tiems, kurių kompetencijas reikia didinti.
Kaip rezultatas, dėl to, kad įvestas madingasVisi naudojasi technologijomis, o žinios ir įgūdžiai sutelkti viename skyriuje, atsiranda probleminių situacijų, įskaitant katastrofiškas. Nauji „DevOps“ inžinierių sukurti sprendimai be koordinuoto skirtingų padalinių darbo gali sukelti tiek problemų, kiek iš pradžių turėjo išspręsti, o tai nereiškia, kad „DevOps“ specialistai turėtų kurti įmonės kultūrą nuo nulio, kaip atrodo, kad dažnai tiki vietiniai. lyderiai. Skaitmeninės gamybos vamzdyno vieningumą ir naujų įgūdžių bei komunikacijos perdavimo skatinimą turi priimti įmonės vadovai. Be to net „DevOps“ komanda vystysis prastai ir nesidalins žiniomis su komanda.
Nei „DevOps“ užsakomųjų paslaugų, neikonsultuojantis su specialistu iš išorės. Pirmuoju atveju išorinė komanda vadovaujasi ne kliento įmonės poreikiais, o standartiniu technologijų rinkiniu, kuris yra kotiruojamas rinkoje. Klientui tai yra loterija: užsakomieji darbuotojai naudoja miglotą „DevOps“ supratimą rinkoje. Todėl verslo procesai tampa vis sudėtingesni, tačiau tai neduoda jokios naudos verslui. Dažnai pačios įmonės skatina tokį požiūrį - pavyzdžiui, prašydamos nekeisti savo plėtros procesų. Akivaizdu, kad tai prieštarauja pačiai „DevOps“ koncepcijai.
Ilgas, brangus, problemiškas: griežtas „DevOps“ rusų kalba
Užuot pritaikius „DevOps“ filosofijąvietoj visų verslo procesų vidaus įmonės dažnai renkasi darbą su įrankiais, kurie neturės įtakos darbo greičiui. Vienas iš rezultatų, pavyzdžiui, yra „plytų siena“ - „Operations“, tai yra sistemos administratorių komanda, lieka izoliuota, o kūrėjai jiems tiesiog meta programas. Žinoma, dėl to vis dar tobulėja įrankių rinkinys. Tačiau esminiai pokyčiai nevyksta, skaidrumas nedidėja ir IT komandos bendradarbiavimas negerėja.
Dar vienas kliuvinys, į kurį jie užkliūvavadovų diegiant DevOps – korporatyvinių žinių bazių trūkumas. Remiantis 2019 m. DORA ataskaita, komandos, kurios naudojo vidinius įmonės informacijos šaltinius, buvo 1,73 karto efektyvesnės nei kitos. Ši problema vėlgi susijusi su uždara daugelio Rusijos įmonių kultūra, kurioje komanda nesidalija žiniomis. Dėl tokio uždarumo įmonės pradeda kaupti technines skolas. Priemonės pasensta, artefaktai nepašalinami, dokumentacija neatnaujinama.
Objektyvus verslo poreikis gamybos stabilumui, taigi ir pelnui, kartu su pasenusia technologijų baze ir techninėmis skolomis lemia nesėkmingą DevOps naudojimą.
Visa tai dažnai lemia tai, kad po ilgų kankinimų nauji „DevOps“ komandos siūlomi sprendimai yra tiesiog išmesti, o procesai „atsukami atgal“.
Kiekviena įmonė turi savo skaitmeninės transformacijos kelią. Daugeliu atvejų tai iš tikrųjų keičia jūsų kodo kūrimą ir diegimą į gerąją pusę. Tai reiškia, kad „DevOps“ vis dar egzistuoja Rusijoje: kiekvieną mėnesį rinkoje atsiranda daug laisvų vietų, susijusių su šia metodika. Kitas dalykas yra tai, kad už jų slypi skirtingi specialybės apibrėžimai ir praktinės užduotys. Tačiau įmonės turėtų nustoti vaikytis vaiduokliškas idealias IT sistemas ir kritiškai vertinti madingą, bet nebūtinai pelningą filosofiją, prioritetą teikiant savo poreikiams.
Taip pat žiūrėkite:
Juodosiose skylėse gali būti visatų. Mes jums pasakojame apie naują atradimą
3 ligos dieną dauguma COVID-19 pacientų praranda kvapo pojūtį ir dažnai kenčia nuo slogos
Tyrimai: vandenyno dugne rasta 15 milijonų tonų mikroplastikų