Какво е необходимо за успеха на IT компания през 2019 година? Лекторите на конференциите и срещите казват много шумни и не винаги разбираеми за обикновените хора думи. Борба за времето на деплой, микросервизи, отказ от монолита, DevOps трансформация и още много други. Ако оставим настрана словесната красота и говорим директно, това се свежда до простия тезис: създавайте качествен продукт и го правете с комфорт за екипа.
Последното стана критично важно. Бизнесът най-накрая осъзна, че комфортният процес на разработка увеличава продуктивността, а когато всичко е оптимизирано и работи без проблеми, предоставя и известен простор за маневри в критични ситуации. Някой умен човек веднъж измисли бекъпите заради този маневър, но индустрията се развива и стигнахме до DevOps инженери — хора, които превръщат процеса на взаимодействие между разработката и външната инфраструктура в нещо разумно и не свързано с шаманизъм.
Цялата тази история за „по модул“ е прекрасна, но… Стана така, че част от администраторите рязко бяха наречени DevOps, а от самите DevOps инженери започнаха да искат, поне, умения за телепатия и ясновидство.
Преди да говорим за съвременните проблеми при осигуряване на инфраструктурата, нека определим какво имаме предвид под този термин. В момента ситуацията е такава, че достигнахме до двойственост на понятието: инфраструктурата може условно да бъде външна и условно вътрешна.
Под външна инфраструктура се подразбира всичко, което осигурява работоспособността на услугата или продукта, по разработката на който работи екипът. Това са сървърите на приложението или сайта, хостинг и други услуги, осигуряващи работоспособността на продукта.
Вътрешната инфраструктура включва услуги и оборудване, използвани от самия екип за разработка и други служители, които обикновено не са малко. Това са вътрешни сървъри на системи за съхранение на код, локално разположен таск мениджър и всичко, което съществува в рамките на корпоративния интранет.
С какво точно се занимава системният администратор в компанията? Освен с администрирането на корпоративния интранет, на него често му се налага да се грижи и за работоспособността на офис оборудването. Администраторът е този, който бързо ще донесе нов компютър от склада или готовия за работа резервен лаптоп, ще предложи нова клавиатура и ще се движи на четири крака из офисите, опъвайки Ethernet кабела. Администраторът е местният господар и повелител не само на вътрешните, но и на външните. сървъри, но също така и на стопанските задължения. Да, някои администратори могат да работят само в системната сфера, без да имат работа с хардуера. Те трябва да бъдат разграничени в отделен подклас на "инфраструктурните системни администратори". А има и такива, които се специализират единствено в обслужването на офис оборудването, особено ако компанията има повече от сто служители - работа никога не липсва. Но никой от тях не може да се нарече DevOps.
А кои са DevOps? Девопсите са хора, които се занимават със взаимодействието между разработката на софтуер и външната инфраструктура. По-точно, съвременните девопси са много по-дълбоко ангажирани в процесите на разработка и внедряване, отколкото някога са били администратори, просто качващи обновления на ftp. Една от ключовите задачи на DevOps инженерите сега е осигуряването на комфортен и ефективно организиран процес на взаимодействие между екипите по разработка и инфраструктурата на продукта. Именно тези хора отговарят за разгръщането на системите за възстановяване и внедряване, именно те облекчават част от натоварването на разработчиците и се фокусират максимално върху своята изключително важна задача. При това девопсът никога няма да опъва нов кабел или да издава нов лаптоп от склада (с) КО.
Къде е уловката?
На въпроса "А кой е DevOps?" половината от работниците в сферата започват да отговарят нещо като "Ами, това е, общо взето, администратор, който..." и така нататък. Да, някога, когато професията DevOps-инженер едва-едва започваше да излиза от най-talантливите администратори, които обслужват услуги, разликите между тях не бяха очевидни за всички. Но сега, когато функциите на DevOps и администратора в екипа се различават радикално, объркването им и дори поставянето на равенство между тях е недопустимо.
Но какво се случва с бизнеса?
Наемането, всичко е в него.
Отваряте обява за работа "Системен администратор", а там са изброени изисквания като "взаимодействие с разработчици и клиенти", "система за доставка CI/CD", "обслужване на сървъри и оборудване на компанията", "администриране на вътрешни системи" и така нататък; осъзнавате, че наемателят говори някаква глупост. Проблемът е, че вместо "Системен администратор" в заглавието на обявата трябва да стои "DevOps-инженер", и ако смените това заглавие, всичко заема своето място.
Обаче какво впечатление се създава при четенето на такава обява? Че компанията търси универсален работник, който ще настройва както системата за контрол на версиите, така и мониторинга, и ще сваля теглото с зъби…
А всъщност, за да не се увеличава нивото на абсурдност на трудовия пазар, е достатъчно да наименовате обявите за работа с точните им имена и да разбирате, че DevOps-инженер и системен администратор – това са две различни същности. Просто неуморното желание на някои работодатели да предявяват на кандидата възможно най-широк списък от изисквания довежда до това, че "класическите" системни администратори престават да разбират какво става около тях. Какво, професията се мутингува и те са изостанали?
Не, не и още веднъж не. Има инфраструктурни администратори, които ще управляват вътрешните сървъри на компанията или ще заемат позиции L2/L3 поддръжка и ще помагат на другите служители, и те не са изчезнали и нямат намерение да си тръгват.
Могат ли тези специалисти да станат DevOps инжинери? Разбира се, могат. Всъщност, това е близка среда, която изисква умения в системното администриране, но освен това, добавя работа с мониторинг, системи за доставка и, изобщо, тясно взаимодействие с екипа за разработка и тестване.
Още един проблем на DevOps
Всъщност, всичко не се ограничава само до наемането и постоянната бъркотия между администраторите и девопсите. В определен момент бизнесът се сблъсква с проблема с доставката на актуализации и взаимодействието на екипа за разработка с крайната инфраструктура.
Възможно е това да е станало, когато на сцената на някоя конференция се качи човек с горящи очи и каже ‘А ние го правим по този начин и го наричаме DevOps. Тези момчета ще решат всичките ви проблеми’ — и започна да разказва колко хубаво живеят в компанията след внедряването на DevOps практики.
Но не е достатъчно да наемеш DevOps инженер, за да може всичко да заработи ‘както трябва’. Компанията трябва напълно да премине през DevOps трансформация, т.е. ролята и възможностите на нашия девопс трябва да са ясно разбрани и от екипа за разработка и тестване на продукта. Имаме ‘прекрасна’ история по този въпрос, която ялюстрира напълно цялата мизерия, случваща се на места.
Ситуация. От девопса требуют да се разиска система за откат на версиите, без да се задълбочават в начина, по който тя ще работи. Да предположим, че в системата Users – това са отделни полета за име, фамилия и парола. Излиза нова версия на продукта, но за разработчиците "откатът" е просто вълшебна пръчка, която всичко поправя, и те дори не разбират как работи. Например, разработчиците в поредния патч обединяват полетата за име и фамилия, пускат го в продукция, а версията забавя по някакви причини. Какво се случва? Ръководството идва при девопса и казва "Издърпай ключа!", като молят него да се върне на предишната версия. Какво прави девопсът? Той се връща на предишната версия, но тъй като разработчиците не пожелаха да разберат как става този откат, никой не е казал на девопса, че трябва да се върне и базата. В крайна сметка, всичко пада, и потребителите вместо забавения сайт виждат грешка "500", защото старата версия не работи с полетата на новата база. Девопсът не е наясно с това. Разработчиците мълчат. Ръководството започва да губи нерви и пари и си спомня за резервните копия, предлагайки да се върне към тях, за да "работи поне нещо". В резултат на това потребителите губят всичките си данни за определен период от време.
Разбира се, девопсът получава критики, който "не е направил правилната система за откат", а това, че разработчиците в цялата тази история са виновни, никого не интересува.
Изводът е прост: без нормален подход към DevOps, какъвто и да е, ползата от него не е особено голяма.
Най-важното нещо, което трябва да запомните: DevOps-инженерът не е магьосник, и без качествени комуникации и двустранно взаимодействие с разработката, той няма да се справя със своите задачи. Девопсите не могат да бъдат оставени сами с техните "проблеми" или да получат заповед "не се намесвайте в работата на разработчиците, тяхната работа е да пишат код", а след това да се надяват, че в критичен момент всичко ще работи както трябва. Така не работи.
По същество, DevOps е комбинация от умения на границата между управлението и технологиите. И не е очевидно, че в този коктейл технологиите трябва да са повече от управлението. Ако наистина искате да изградите по-бързи и ефективни процеси на разработка, трябва да се доверите на своя DevOps специалист. Той знае необходимите инструменти, той е реализирал подобни проекти, той знае как да се справи. Помогнете му, слушайте неговите съвети, не се опитвайте да го изолирате в автономно подразделение. Докато администраторите могат да работят сами, DevOps специалистите са безполезни, ако не искате да приемете тяхната помощ.
И накрая: стига да обиждате администраторите на инфраструктурата. Те имат свой важен фронт на работа. Да, администраторът може да стане DevOps инженер, но това трябва да се случи по желание на самия човек, а не по принуда. И няма нищо лошо в това системният администратор да иска да остане системен администратор — това е неговата отделна професия и право. Ако обаче има желание за професионална трансформация, трябва непременно да се помни, че ще трябва да се развиват не само технологични умения, но и управленски. Вероятно ще бъде именно вам като ръководител, който ще трябва да обедините всичките тези хора и да ги научите да комуникират на един и същ език.
Източник: habr.com
