Što je DevOps i koje zadatke radi inženjer DevOpsa
Pojam DevOps (Razvojne operacije ili operacije unutar
Bogat arsenal praksi približava DevOps drugimapopularan u IT sferi koristeći Agile metodu. To je iterativni pristup dizajnu koji vam omogućuje prilagodbu promjenjivim zahtjevima. U skladu s tim, stručnjak za DevOps pokušava proizvod učiniti boljim, a poslovne procese predvidljivijim i transparentnijim. Također poboljšava poslovne metrike, poput skraćivanja vremena izlaska na tržište. To je vremensko razdoblje od početka razvoja proizvoda do njegovog izlaska na tržište. Poznavanje čimbenika koji produžuju vrijeme za stvaranje softvera i sistemski pristup omogućuju inženjeru DevOps da proizvodnju učini kontinuiranom i brzom. Da biste to učinili jasnijim, možete povući analogiju s pokretnom trakom za sastavljanje automobila. Svi su dijelovi unaprijed dizajnirani tako da se savršeno slažu tijekom montaže. Inženjeri koji razvijaju motor razmišljaju o tome kako on radi zajedno s kotačima, sustavom kočenja itd. DevOps čini isto: preuzima odgovornost za veći dio proizvoda nego što to radi programer, osigurava suradnju svih timova.
Svijet ružičastog ponija: utrka za modnu filozofiju
Međutim, nisu sve tvrtke potrebne za DevOps. Primjerice, u timovima bez već postojećih IT odjela koji nisu uključeni u proizvodnju digitalnog proizvoda, filozofija DevOps uopće ne vrijedi. Ova područja uključuju tvrtke čiji profit ne ovisi izravno o tome koliko su kupci zadovoljni IT proizvodom s kojim komuniciraju. Osim toga, često nije prikladan za mala poduzeća. Metodologija zahtijeva promjene u mnogim uspostavljenim poslovnim procesima, pa čak i korporativnoj kulturi. Male tvrtke mogu jednostavno ne tolerirati takve promjene sa stajališta projektne ekonomije.
Modna bolest digitalne transformacije je čestotiče se šefova takvih tvrtki. U potrazi za beskrajnom optimizacijom, zaboravljaju na druge čimbenike koji utječu na poslovanje. Kao rezultat toga, tvrtke gube novac, efikasnost, a u najgorem slučaju i poslovne procese koji su se izgrađivali tijekom godina. IT divovi, banke, veliki trgovinski i industrijski događaji su druga stvar. Za njih DevOps može biti vrlo koristan. Dakle, prema godišnjem izvješću Alfa-banke za 2017. godinu, uvođenje metodologije omogućilo nam je ubrzanje razvoja i primjene za 60 puta.
Stakhanovite-mnogostanochnik umjesto radionice zaposlenika
Naravno, takva opsežna funkcionalnost je teškakoju će izvoditi jedan zaposlenik, pa je idealno da čitav višefunkcionalni tim bude uključen u DevOps. Uključuje profesionalce koji ispunjavaju uloge upravitelja procesa i proizvoda, programera infrastrukturnog koda, inženjera i mnoge druge uloge. Međutim, u ruskoj praksi stručnjak za DevOps često može postati moderan način uštede novca na stvaranju proizvoda. Obično se ova situacija dogodi nakon što top menadžer tvrtke odluči da je došlo vrijeme za digitalnu transformaciju. Tvrtka hitno zapošljava nove stručnjake ili proširuje popis odgovornosti postojećih programera i administratora sustava. Kao rezultat toga, službe za zapošljavanje ne nude radna mjesta za inženjere DevOps-a, već za zaposlenike s više stanica.
Takav se zaposlenik može pojedinačno obvezatipostaviti poslužitelje, postaviti kablove, a zatim pratiti pogreške, postaviti baze podataka i hosting projekata i tako dalje. Ovaj je primjer ekstreman, ali stvaran. Kao rezultat toga, zaposlenici brzo izgaraju, a primjena metodologije u radu tvrtke propada. Tretiranje stručnjaka za DevOps kao mađioničara koji može istodobno rješavati velik broj zadataka, zajedno sa praćenjem rada cijelog sustava, neće donijeti dobit poslu.
S tim je povezan još jedan uobičajeni problempodijelivši tim u dvije skupine koje se međusobno ne mogu slagati. Zamislite da IT tvrtka ima odjel DevOps, koji smije mijenjati uobičajene radne postupke. Međutim, ta pravila ostaju obvezujuća za druge programere. Naravno, u ovom slučaju ne treba govoriti o suradnji i "neometanosti" rada. Dvije momčadi počinju se sukobljavati i produktivnost opada.
Bačva praha u spremištu: DevOps nisu samo vještine
Jedan od zadataka odjela DevOps je uspostavljanjekomunikacija između različitih IT stručnjaka tvrtke. Inženjeri DevOps ne bi trebali implementirati samo tehnologije i procese otklanjanja pogrešaka, već također uroniti razvojni tim u posao - podijeliti odgovornosti i pomoći u povećanju kompetencija. Ipak, takvi se stručnjaci često bave isključivo tehničkim zadacima, obično zbog banalnog nedostatka vremena, kako za njih tako i za one čije kompetencije treba povećati.
Kao rezultat toga, zbog činjenice da je uveo moderanSvi koriste tehnologije, a znanje i vještine koncentrirani su unutar jednog odjela, pojavljuju se problematične situacije, uključujući i katastrofalne. Nova rješenja koja su stvorili inženjeri DevOpsa, bez dobro koordiniranog rada različitih odjela, mogu donijeti onoliko problema koliko su ih trebali riješiti u početku, što ne znači da bi stručnjaci DevOps-a trebali stvoriti korporativnu kulturu od nule, kako se čini da domaći često misle. vođe. Jedinstvo digitalnog proizvodnog cjevovoda i poticanje prijenosa novih vještina i komunikacije moraju dolaziti od čelnika tvrtke. Bez toga će se čak i DevOps tim slabo razvijati i neće dijeliti znanje s timom.
Niti DevOps outsourcing nitisavjetovanje sa stručnjakom izvana. U prvom se slučaju vanjski tim ne rukovodi potrebama tvrtke klijenta, već standardnim skupom tehnologija koje kotiraju na tržištu. Za klijenta je ovo lutrija: zaposlenici koji posluju izvan tvrtke koriste nejasno razumijevanje DevOps-a na tržištu. Kao rezultat toga, poslovni procesi postaju sve složeniji, ali to ne donosi nikakve koristi za posao. Često i same tvrtke potiču takav pristup - na primjer, tražeći od njih da ne mijenjaju svoje razvojne procese. Jasno je da je to suprotno samom konceptu DevOpsa.
Dugo, skupo, problematično: grubi DevOps na ruskom
Umjesto primjene filozofije DevOps nau svim poslovnim procesima domaće tvrtke često radije rade na alatima koji neće utjecati na brzinu rada. Na primjer, jedan od rezultata je "ciglani zid" - Operacije, odnosno tim administratora sustava, ostaje izoliran, a programeri im jednostavno dobacuju aplikacije. Kao rezultat, kutija alata se i dalje poboljšava. Međutim, temeljne promjene se ne događaju, transparentnost se ne povećava i suradnja IT tima ne poboljšava.
Još jedna prepreka na koju menadžeri nailaze prilikom implementacije DevOps-a je nedostatak baza znanja poduzeća.Prema izvješću DORA-e za 2019. godinu, timovi koji su koristili interne izvore informacija o tvrtki bili su 1,73 puta učinkovitiji od drugih.Ovaj se problem ponovno svodi na zatvorenu kulturu mnogih ruskih tvrtki, u kojoj tim ne razmjenjuje znanje.Zbog te tajnosti tvrtke počinju akumulirati tehnički dug, alati zastarijevaju, artefakti se ne brišu, a dokumentacija se ne ažurira.
Objektivna potreba poslovanja za stabilnošću proizvodnje, a time i dobit, zajedno sa zastarjelom tehnološkom bazom i tehničkim dugom, dovodi doDevOps neuspjeh.
Sve to često dovodi do činjenice da se, nakon dugih muka, nova rješenja koja nudi tim DevOps jednostavno bacaju i procesi se "vraćaju natrag".
Svaka tvrtka ima svoj put digitalne transformacije. U većini slučajeva to stvarno mijenja način na koji se vaš kôd razvija i primjenjuje na bolje. To znači da DevOps i dalje postoji u Rusiji: svakog se mjeseca na tržištu pojavi puno slobodnih mjesta povezanih s ovom metodologijom. Druga je stvar što iza njih stoje različite definicije specijalnosti i praktični zadaci. Međutim, tvrtke bi trebale prestati ganjati sablasno idealne informatičke sustave i biti kritične prema usvajanju trendovske, ali ne nužno profitabilne filozofije, dajući prioritet vlastitim potrebama.
Pogledajte i:
U crnim rupama mogu postojati svemiri. Govorimo vam o novom otkriću
Na 3. dan bolesti, većina bolesnika s COVID-19 gubi smrad i često pate od curenja iz nosa
Istraživanje: 15 milijuna tona mikroplastike pronađeno na dnu oceana