За администраторите, devops, безкрайното объркване и DevOps трансформацията в компанията

Какво е необходимо на една ИТ компания, за да бъде успешна през 2019 г.? Лекторите на конференции и срещи казват много гръмки думи, които не винаги са разбираеми за нормалните хора. Борбата за време за внедряване, микроуслуги, изоставяне на монолита, DevOps трансформация и много, много повече. Ако загърбим словесната красота и говорим директно и на руски, тогава всичко се свежда до една проста теза: направете висококачествен продукт и го направете с комфорт за екипа.

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

Цялата тази „модулна“ история е прекрасна, но... Случи се така, че някои от администраторите внезапно бяха наречени DevOps, а от самите инженери на DevOps започнаха да се изискват поне умения за телепатия и ясновидство.

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

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

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

Какво прави системният администратор в една компания? В допълнение към работата по администрирането на този корпоративен интранет, той често носи тежестта на икономическите грижи за осигуряване на работоспособността на офис оборудването. Администраторът е същият човек, който бързо ще измъкне нов системен модул или резервен лаптоп, готов за употреба, от задната стая, ще даде нова клавиатура и ще пълзи на четири крака през офисите, опъвайки Ethernet кабела. Администраторът е локален собственик и владетел не само на вътрешни и външни сървъри, но и на бизнес ръководител. Да, някои администратори могат да работят само в системната равнина, без хардуер. Те трябва да бъдат отделени в отделен подклас „администратори на инфраструктурни системи“. А някои се специализират в обслужването изключително на офис оборудване; за щастие, ако компанията има повече от сто души, работата никога не свършва. Но нито един от тях не е devops.

Кои са DevOps? Devops са хора, които говорят за взаимодействието на разработката на софтуер с външна инфраструктура. По-точно, съвременните devops участват в процесите на разработка и внедряване много по-дълбоко, отколкото някога са участвали администраторите, които просто са качвали актуализации на ftp. Една от ключовите задачи на инженера на DevOps сега е да осигури удобен и ефективно структуриран процес на взаимодействие между екипите за разработка и продуктовата инфраструктура. Именно тези хора са отговорни за внедряването на системи за връщане назад и внедряване; именно тези хора поемат част от товара от разработчиците и се концентрират максимално върху своята изключително важна задача. В същото време devops никога няма да пусне нов кабел или да издаде нов лаптоп от задната стая (c) KO

Каква е уловката?

На въпроса „Кой е DevOps?“ половината от работещите в полето започват да отговарят нещо като „Е, накратко, това е администраторът, който ...“ и по-нататък в текста. Да, някога, когато професията на DevOps инженера току-що се появи от най-талантливите администратори по отношение на поддръжката на услуги, разликите между тях не бяха очевидни за всички. Но сега, когато функциите на devops и admin в екипа са станали коренно различни, е недопустимо да ги бъркаме една с друга или дори да ги приравняваме.

Но какво означава това за бизнеса?

Наемането, всичко е въпрос на работа.

Отваряте свободна позиция за “Системен администратор”, а там посочените изисквания са “взаимодействие с разработки и клиенти”, “CI/CD система за доставка”, “поддръжка на сървъри и оборудване на компанията”, “администриране на вътрешни системи” и т.н. На; разбирате, че работодателят говори глупости. Уловката е, че вместо „Системен администратор“ заглавието на свободната длъжност трябва да бъде „Инженер на DevOps“ и ако това заглавие се промени, всичко си идва на мястото.

Но какво впечатление остава човек, когато прочете подобна ваканция? Че компанията търси многомашинен оператор, който ще внедри както система за контрол на версиите, така и система за мониторинг и ще стиска туистъра със зъби...

Но за да не се увеличи степента на наркомания на пазара на труда, достатъчно е да наречете свободните работни места с истинските им имена и ясно да разберете, че DevOps инженер и системен администратор са две различни единици. Но неудържимото желание на някои работодатели да представят възможно най-широк списък от изисквания към кандидата води до факта, че „класическите“ системни администратори престават да разбират какво се случва около тях. Какво, професията мутира и те са изостанали?

Не не и още веднъж не. Инфраструктурните администратори, които ще управляват вътрешните сървъри на компанията или ще заемат L2/L3 позиции за поддръжка и ще помагат на други служители, не са си отишли ​​и няма да си отидат.

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

Още един проблем с DevOps

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

Може би това беше, когато чичо с искрящи очи се изправи на сцената на някаква конференция и каза: „Ние правим това и го наричаме DevOps. Тези момчета ще решат всичките ви проблеми” - и започна да разказва колко добър е животът в компанията след прилагането на DevOps практиките.

Не е достатъчно обаче да наемете DevOps инженер, за да накарате всичко да работи както трябва. Компанията трябва да претърпи цялостна трансформация на DevOps, тоест ролята и възможностите на нашите DevOps също трябва да бъдат ясно разбрани от страна на екипа за разработване и тестване на продукти. Имаме „прекрасна“ история по тази тема, която напълно илюстрира цялата бруталност, която се случва на някои места.

Ситуация. DevOps е необходим за внедряване на система за връщане на версията, без наистина да се задълбочава в това как ще работи. Да приемем, че в рамките на системата Users има отделни полета за име, фамилия и парола. Излиза нова версия на продукта, но за разработчиците „връщането назад“ е просто магическа пръчка, която ще поправи всичко и те дори не знаят как работи. Така например в следващия пач разработчиците комбинираха полетата за име и фамилия, пуснаха го в производство, но версията е бавна по някаква причина. Какво се случва? Ръководството идва при devops и казва „Издърпайте превключвателя!“, тоест го моли да се върне към предишната версия. Какво прави devops? Връща се към предишната версия, но тъй като разработчиците не искаха да разберат как е направено това връщане, никой не каза на екипа на devops, че базата данни също трябва да бъде върната. В резултат на това всичко ни се срива и вместо бавен уебсайт потребителите виждат грешка „500“, тъй като старата версия не работи с полетата на новата база данни. Devops не знае за това. Разработчиците мълчат. Ръководството започва да губи нервите и парите си и си спомня резервните копия, като предлага да се върне от тях, така че „поне нещо да работи“. В резултат на това потребителите губят всичките си данни за определен период от време.

Ядките, разбира се, отиват при devops, които „не са направили подходяща система за връщане назад“ и никой не се интересува, че лосовете в тази история са разработчици.

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

По същество DevOps е компетенция на границата между управление и технология. Освен това далеч не е очевидно, че в този коктейл трябва да има повече технология, отколкото управление. Ако наистина искате да изградите по-бързи и по-ефективни процеси за разработка, трябва да се доверите на вашия екип за devops. Той знае правилните инструменти, изпълнявал е подобни проекти, знае как да го направи. Помагайте му, слушайте съветите му, не се опитвайте да го изолирате в някаква автономна единица. Ако администраторите могат да работят сами, тогава devops са безполезни в този случай; те няма да могат да ви помогнат да станете по-добри, ако вие сами не искате да приемете тази помощ.

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

Източник: www.habr.com