Защо DevOps не се интегрира добре в руския бизнес и кой е виновен

Какво е DevOps и какви задачи прави инженер на DevOps

Терминът DevOps (Операции за разработка или операции в рамките на

развитие - "High-tech") е използвано за първи път през2009 ИТ консултант Патрик Дебоа. По същество това означава не просто свободна позиция, а цяла методология, която ви позволява да създавате цифрови продукти по-ефективно и бързо. Свързан набор от инструменти от разработка, управление на продукти, софтуерно инженерство и други специалности осигурява непрекъснат процес на създаване на софтуер.

Богат арсенал от практики приближава DevOps до другитепопулярен в IT сферата, използвайки метода Agile. Това е итеративен подход към дизайна, който ви позволява да се адаптирате към променящите се изисквания. Съответно специалистът DevOps се опитва да направи продукта по-добър, а бизнес процесите по-предсказуеми и по-прозрачни. Той също така подобрява бизнес показателите, като например съкращаване на Time to Market. Това е продължителността на времето от началото на разработването на продукта до пускането му на пазара. Познаването на факторите, които удължават времето за създаване на софтуер, и системният подход позволяват на инженера DevOps да направи производството непрекъснато и бързо. За да стане по-ясно, можете да направите аналогия с конвейер за сглобяване на автомобили. Всички части са проектирани предварително, така че да паснат перфектно заедно по време на сглобяването. Инженерите, които проектират двигател, мислят за това как работи във връзка с колела, спирачки и т.н. DevOps прави същото: поема отговорност за повече от продукта, отколкото разработчика, гарантира, че всички екипи си сътрудничат.

Свят на розово пони: Състезание за модна философия

Не всички компании обаче се нуждаят от DevOps. Например в екипи без предварително съществуващи ИТ отдели, които не участват в производството на цифров продукт, философията на DevOps изобщо не се прилага. Тези области включват компании, чиято печалба не зависи пряко от това колко доволни са клиентите от ИТ продукта, с който си взаимодействат. Освен това често не е подходящ за малък бизнес. Методологията изисква промени в много установени бизнес процеси и дори корпоративна култура. Малките компании може просто да не толерират подобни промени по отношение на икономиката на проектите.

Модната болест на дигиталната трансформация често е такавакасае ръководителите на такива компании. В преследване на безкрайна оптимизация те забравят за други фактори, които влияят на бизнеса. В резултат на това компаниите губят пари, ефективност и в най-лошия случай бизнес процеси, които са изграждани през годините. ИТ гиганти, банки, големи търговски и индустриални събития са друг въпрос. За тях DevOps може да бъде много полезен. По този начин, според годишния отчет на Алфа-Банк за 2017 г., въвеждането на методологията ни позволи да ускорим разработването и внедряването с 60 пъти.

Stakhanovite-mnogostanochnik вместо работилница

Разбира се, такава широка функционалност е труднана служител, така че в идеалния случай в DevOps участва цял многофункционален екип. Включва професионалисти в роли и мениджъри на процеси и продукти, разработчик на инфраструктурен код, инженер и много други роли. В руската практика обаче специалистът по DevOps често може да се превърне в модерен начин да спестите пари за създаване на продукти. Обикновено тази ситуация се случва, след като топ мениджърът на компанията реши, че е дошъл моментът за дигитална трансформация. Компанията спешно набира нови специалисти или разширява списъка с отговорности на съществуващите разработчици и системни администратори. В резултат на това услугите за набиране на персонал не създават свободни работни места за инженери на DevOps, а за служители на много станции.

Такъв служител може да бъде задължен индивидуалнонастройване на сървъри, полагане на кабели и след това проследяване на грешки, настройване на бази данни и хостинг на проекти и т.н. Този пример е екстремен, но реален. В резултат на това служителите бързо изгарят и внедряването на методологията в работата на компанията се проваля. Третирането на специалист от DevOps като магьосник, който може едновременно да се справи с голям брой задачи, заедно с наблюдението на работата на цялата система, няма да донесе печалба на бизнеса.

Друг често срещан проблем е свързан сразделяне на отбора на две групи, които не могат да се разбират помежду си. Представете си, че ИТ компания има отдел DevOps, който има право да променя обичайните работни процедури. Тези правила обаче остават задължителни за други разработчици. Разбира се, в този случай не е необходимо да се говори за сътрудничество и „безпроблемност“ на работата. Двата отбора започват да се сблъскват и производителността спада.

Барел прах в трюма: DevOps не са само умения

Една от задачите на отдела DevOps е да установикомуникация между различни ИТ специалисти на компанията. Инженерите на DevOps трябва не само да внедрят технологии и процеси за отстраняване на грешки, но също така да потопят екипа за разработка в хода на бизнеса - да споделят отговорности, да спомогнат за увеличаване на компетентностите. Независимо от това, често такива специалисти се занимават с чисто технически задачи, обикновено поради баналната липса на време, както за тях, така и за тези, чиито компетенции трябва да бъдат увеличени.

В резултат на това, поради факта, че въведените модерниВсеки използва технологии, а знанията и уменията са съсредоточени в рамките на един отдел, възникват проблемни ситуации, включително катастрофални. Новите решения, създадени от инженерите на DevOps, без добре координирана работа на различни отдели, могат да донесат толкова проблеми, колкото би трябвало да решат първоначално, което не означава, че специалистите на DevOps трябва да създадат корпоративна култура от нулата, както изглежда вътрешната лидери. Единството на дигиталния производствен тръбопровод и насърчаването на трансфера на нови умения и комуникация трябва да идват от лидерите на компанията. Без това дори екипът на DevOps ще се развива слабо и няма да споделя знания с екипа.

Нито аутсорсингът на DevOps, нитоконсултация със специалист отвън. В първия случай външният екип се ръководи не от нуждите на компанията клиент, а от стандартния набор от технологии, които се котират на пазара. За клиента това е лотария: изнесените служители използват неясно разбиране за DevOps на пазара. В резултат на това бизнес процесите стават все по-сложни, но това не носи никакви ползи за бизнеса. Често самите компании насърчават този подход - например, като ги молят да не променят процесите си на развитие. Ясно е, че това противоречи на самата концепция за DevOps.

Дълго, скъпо, проблематично: сурови DevOps на руски

Вместо да се прилага философията на DevOpsпред всички бизнес процеси местните компании често предпочитат да работят върху инструменти, които няма да повлияят на скоростта на работа. Един от резултатите, например, е „тухлената стена“ - Operations, тоест екипът от системни администратори, остава в изолация и разработчиците просто им хвърлят приложения. Разбира се, в резултат на това кутията с инструменти все още се подобрява. Основни промени обаче не настъпват, прозрачността не се увеличава и сътрудничеството на ИТ екипа не се подобрява.

Още една пречка, на която се натъкватмениджъри при внедряване на DevOps - липса на корпоративни бази знания. Според доклада на DORA за 2019 г. екипите, които са използвали вътрешни източници на информация на компанията, са били 1,73 пъти по-ефективни от останалите. Този проблем отново се свежда до затворената култура на много руски компании, в които екипът не споделя знания. Поради този затворен характер компаниите започват да натрупват технически дългове. Инструментите остаряват, артефактите не се премахват, документацията не се актуализира.

Обективната бизнес нужда от стабилност на производството и следователно печалба, съчетана с остаряла технологична база и технически дълг, водят до неуспешното използване на DevOps.

Всичко това често води до факта, че след дълги мъки новите решения, предлагани от екипа на DevOps, просто се изхвърлят и процесите се „връщат назад“.

Всяка компания има свой собствен път на дигитална трансформация. В повечето случаи това наистина променя начина на разработване и внедряване на вашия код към по-добро. Това означава, че DevOps все още съществува в Русия: всеки месец на пазара се появяват много свободни работни места, свързани с тази методология. Друго нещо е, че зад тях има различни дефиниции на специалността и практически задачи. Компаниите обаче трябва да спрат да преследват призрачни идеални ИТ системи и да бъдат критични към възприемането на модерна, но не непременно печеливша философия, като дават приоритет на собствените си нужди.

Вижте също:

Възможно е да има вселени в черни дупки. Разказваме ви за новото откритие

На 3-ти ден от заболяването повечето пациенти с COVID-19 губят обонянието си и често страдат от хрема

Изследвания: 15 милиона тона микропластмаса, открити на дъното на океана