Шта је ДевОпс и које задатке ради инжињер ДевОпс-а
Термин ДевОпс (Развојне операције или операције унутар
Богат арсенал пракси приближава ДевОпс другимапопуларан у ИТ сфери користећи Агиле методу. То је итеративни приступ дизајну који вам омогућава да се прилагодите променљивим захтевима. Сходно томе, специјалиста за ДевОпс покушава да учини производ бољим, а пословни процеси предвидљивијим и транспарентнијим. Такође побољшава пословне метрике, попут скраћивања времена до изласка на тржиште. Ово је временско раздобље од почетка развоја производа до његовог лансирања на тржиште. Познавање фактора који продужавају време за стварање софтвера и системски приступ омогућавају инжењеру ДевОпс да производњу учини континуираном и брзом. Да бисте то учинили јаснијим, можете повући аналогију са покретном траком за склапање аутомобила. Сви делови су унапред дизајнирани тако да се савршено уклапају током монтаже. Инжењери који дизајнирају мотор размишљају о томе како он ради заједно са точковима, системом кочења итд. ДевОпс ради исто: преузима одговорност за већи део производа од програмера, водећи рачуна да сви тимови сарађују.
Свет ружичастих понија: трка за модну филозофију
Међутим, нису све компаније потребне за ДевОпс.На пример, у тимовима без већ постојећих ИТ одељења који нису укључени у производњу дигиталног производа, филозофија ДевОпс уопште не важи. Ова подручја укључују компаније чији профит не зависи директно од тога колико су купци задовољни ИТ производом са којим комуницирају. Поред тога, често није погодан за мала предузећа. Методологија захтева промене у многим успостављеним пословним процесима, па чак и корпоративној култури. Мале компаније једноставно не могу толерисати такве промене са становишта пројектне економије.
Модерна болест дигиталне трансформације је честотиче се шефова таквих компанија. У потрази за бескрајном оптимизацијом, заборављају на друге факторе који утичу на пословање. Као резултат, компаније губе новац, ефикасност, а у најгорем случају и пословне процесе који су се изграђивали током година. ИТ гиганти, банке, велики трговински и индустријски догађаји су друга ствар. За њих ДевОпс може бити врло користан. Тако је, према годишњем извештају Алфа-банке за 2017. годину, увођење методологије омогућило да убрзамо развој и примену за 60 пута.
Стакхановите-многостаноцхник уместо радионице запослених
Наравно, таква опсежна функционалност је тешкапо запосленом, тако да је идеално да читав вишефункционални тим буде укључен у ДевОпс. Укључује професионалце у улогама и менаџерима процеса и производа, програмеру инфраструктуре, инжењеру и многим другим улогама. Међутим, у руској пракси, специјалиста за ДевОпс често може постати модеран начин уштеде новца на стварању производа. Типично се ова ситуација дешава након што топ менаџер компаније одлучи да је дошло време за дигиталну трансформацију. Компанија хитно запошљава нове стручњаке или проширује списак одговорности постојећих програмера и системских администратора. Као резултат тога, службе за запошљавање не нуде упражњена места за инжењере ДевОпс-а, већ за запослене у више станица.
Такав запослени може бити појединачно обавезанподесите сервере, поставите каблове, а затим пратите грешке, подесите базе података и хостовање пројеката итд. Овај пример је екстреман, али стваран. Као резултат, запослени брзо изгоре, а примена методологије у раду компаније пропада. Третирање стручњака за ДевОпс као мађионичара који може истовремено да се бави великим бројем задатака, заједно са праћењем рада целокупног система, неће донети профит послу.
Још један уобичајени проблем је повезан саподеливши тим у две групе које се међусобно не могу слагати. Замислите да ИТ компанија има одељење ДевОпс, коме је дозвољено да мења уобичајене радне процедуре. Међутим, ова правила остају обавезујућа за друге програмере. Наравно, у овом случају не треба говорити о сарадњи и „неприметности“ рада. Два тима почињу да се сукобљавају и продуктивност опада.
Бачва праха у складишту: ДевОпс нису само вештине
Један од задатака одељења ДевОпс је успостављањекомуникација између различитих ИТ стручњака компаније. Инжењери ДевОпс-а не би требало само да примењују технологије и процесе отклањања грешака, већ и да уроне развојни тим у посао - деле одговорности, помажу у повећању компетенција. Ипак, такви стручњаци се често баве чисто техничким задацима, обично због баналног недостатка времена, како за њих тако и за оне чије компетенције треба повећати.
Као резултат, због чињенице да је увео модеранСви користе технологије, а знање и вештине концентрисани су у једном одељењу, настају проблематичне ситуације, укључујући и катастрофалне. Нова решења која су креирали инжењери ДевОпс-а, без координираног рада различитих одељења, могу донети онолико проблема колико је требало да их реше у почетку, што не значи да би стручњаци ДевОпс-а требали створити корпоративну културу од нуле, као што изгледа да домаћи често мисле. Вође. Јединство дигиталне производне линије и подстицање преноса нових вештина и комуникације морају долазити од вођа компаније. Без тога, чак и ДевОпс тим ће се лоше развијати и неће делити знање са тимом.
Нити ДевОпс оутсоурцинг нитиконсултације са специјалистом споља. У првом случају, спољни тим се не руководи потребама компаније клијента, већ стандардним скупом технологија које се котирају на тржишту. За клијента је ово лутрија: запослени који се баве спољним пословима користе нејасно разумевање ДевОпс-а на тржишту. Као резултат, пословни процеси постају све сложенији, али то не доноси никакве користи за посао. Често и саме компаније подстичу овај приступ - на пример, тражећи од њих да не мењају своје развојне процесе. Јасно је да је то супротно самом концепту ДевОпс-а.
Дуго, скупо, проблематично: груби ДевОпс на руском
Уместо да применимо филозофију ДевОпс наод свих пословних процеса, домаће компаније често преферирају рад на алатима који неће утицати на брзину рада. На пример, један од резултата је „циглани зид“ - Операције, односно тим системских администратора, остаје изолован, а програмери им једноставно добацују апликације. Као резултат, кутија алата се и даље побољшава. Међутим, темељне промене се не дешавају, транспарентност се не повећава и сарадња ИТ тима се не побољшава.
Још једна замка на коју наиђуменаџери приликом имплементације ДевОпс-а – недостатак корпоративних база знања. Према извештају ДОРА за 2019, тимови који су користили интерне изворе информација компаније били су 1,73 пута ефикаснији од осталих. Овај проблем се опет своди на затворену културу многих руских компанија, у којима тим не дели знање. Због ове затворености, компаније почињу да акумулирају техничке дугове. Алати постају застарели, артефакти се не уклањају, документација се не ажурира.
Објективна пословна потреба за стабилношћу производње, а самим тим и профитом, заједно са застарелом технолошком базом и техничким дугом доводе до неуспешне употребе ДевОпс-а.
Све ово често доводи до чињенице да се, после дуге агоније, нова решења која нуди тим ДевОпс једноставно бацају, а процеси „враћају уназад“.
Свака компанија има свој пут дигиталне трансформације.У већини случајева то заиста мења начин на који се ваш код развија и примењује на боље. То значи да ДевОпс и даље постоји у Русији: сваког месеца се на тржишту појави пуно слободних радних места повезаних са овом методологијом. Друга ствар је што иза њих стоје различите дефиниције специјалности и практични задаци. Међутим, компаније би требале престати јурити сабласно идеалне ИТ системе и бити критичне према усвајању трендовске, али не нужно профитабилне филозофије, дајући приоритет сопственим потребама.
Погледајте и:
У црним рупама могу бити универзуми. Говоримо вам о новом открићу
Трећег дана болести, већина пацијената са ЦОВИД-19 губи смрад и често пате од цурења из носа
Истраживање: 15 милиона тона микропластике пронађено на дну океана