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

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

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

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

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

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

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

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

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

В какъв е капанът?

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

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

Наемането, всъщност, е основният въпрос.

Отваряте обява за "Системен администратор", а там са изброени изисквания като "взаимодействие с разработчици и клиенти", "система за доставка CI/CD", "поддръжка на сървъри и оборудване на компанията", "администриране на вътрешни системи" и така нататък; разбирате, че наемателят говори някаква безсмислица. Проблемът е, че вместо "Системен администратор" в заглавието на обявата трябва да стои "DevOps инженер", и ако промените това заглавие, всичко ще си дойде на мястото.

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

Всъщност, за да не се увеличава нивото на трудовата наркомания, е достатъчно да се наричат обявите с истинските им имена и ясно да се разбира, че DevOps инженер и системен администратор са две различни единици. Само че неумолимото желание на някои работодатели да представят на кандидата възможно най-широк списък с изисквания води до това, че "класическите" системни администратори спират да разбират какво става около тях. Дали професията мутира и те са изостанали от реалността?

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

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

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

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

Може би е било тогава, когато на сцената на някоя конференция се изправи дядо с горящи очи и каза: «А, ние правим така и наричаме това DevOps. Тези момчета ще решат всички ваши проблеми» — и започна да разказва как добре се живее в компанията след внедряването на DevOps практики.

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

Ситуация. От девопса се изисква да разгръща система за откат на версии, без да навлиза в детайли как тя ще работи. Да предположим, че в системата Users — това са отделни полета за име, фамилия и парола. Излиза нова версия на продукта, но за разработчиците «откат» е просто вълшебна пръчица, която всичко поправя, и те дори не са наясно как работи. Например, разработчиците в поредния патч са обединили полетата за име и фамилия, пуснали са го в продукция, а версията забавя по някакви причини. Какво се случва? Ръководството идва при девопса и казва «Дёргай рубильник!», т.е. иска от него да се върне на предишната версия. Какво прави девопса? Той се връща на предишната версия, но тъй като разработчиците не искат да се задълбочават в това как се прави откатът, никой не е казал на девопса, че трябва да се върне и базата. В резултат на това всичко се срива и потребителите вместо забавящия се сайт виждат грешка «500», защото старата версия не работи с полетата на новата база. Девопсът не е наясно с това. Разработчиците мълчат. Ръководството започва да губи нерви и пари и си спомня за бекъпите, предлагаща да се върне на тях, за да «работи поне нещо». В резултат на това потребителите губят всичките си данни за определен период от време.

Разбира се, че девопсът, който "не е направил правилната система за откат", получава много негативи, а това, че лосовете в тази история са разработчиците, никого не интересува.

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

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

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

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