🥇DevOps или как губим заплатата и бъдещето на ИТ индустрията

Най-тъжното в съвременната ситуация е, че IT постепенно се превръща в индустрия, в която изобщо няма дума 'спри' по отношение на задълженията на един човек.

Четейки обяви за работа, понякога виждаш не 2-3 души, а цяла компания в едно лице - всички бързат, техническият дълг расте, старият legacy на фона на новите продукти изглежда съвършенство, защото поне в него има документация и коментар в кода. Новите продукти се пишат със скоростта на светлината, но в крайна сметка не могат да се използват още година след завършването им, а често и тази година не носи печалба. По-скоро разходите за 'облака' са по-високи от продажбите на услугата. Парите на инвеститорите отиват за поддържане на услугата, която все още не работи, но вече е пусната в мрежата като работеща.
Пример: известна компания, чийто ремастър на стара игра получи най-ниски оценки в историята на индустрията. Аз бях един от тези, които купиха този продукт, но дори сега той работи ужасно и по идея не е трябвало да излиза в такъв вид за продажба. Връщания на пари, спад в рейтингите, огромно количество блокировки на потребители на форумите за оплаквания относно работата на услугите. Броят на пачовете не вдъхновява, а плаши, но въпреки това - продуктът не е използваем. Ако този подход довежда до такива резултати при компания, която се занимава с разработка от 91 година, то при компаниите, които едва сега започват дейността си, ситуацията е още по-лоша.

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

Често срещам твърдението, че DevOps екипи не трябва да съществуват, че това е методология и т.н., но ето какво – компаниите по някаква причина спряха да търсят системни администратори, DBA, специалисти по инфраструктура и инженери по изграждане – в момента всичко това е DevOps инженер в едно лице. Разбира се, в отделни компании все още има такива ваканции, но те стават все по-малко. Много хора наричат това развитие, а аз лично виждам деградация, тъй като е невъзможно да се поддържа високо ниво на знания във всички области и в същото време да се работи не повече от 8 часа. Естествено – това са фантазии. В действителност много IT специалисти са принудени да работят по 12 и 14 часа, от които се заплаща 8. А често и без почивки, защото „имам задача, документацията е лоша или липсва, а услугата струва пари“, а за една грешка в облака реално може да не получиш заплата за два месеца, особено ако работиш като самоосигуряващо се лице. Всъщност губим думата в бизнеса, заедно с разделението на задълженията, все по-често се сблъсквам с факта, че мениджърите нахлуват в процесите на разработка, без да разбират нищо, бъркат бизнес данни с работата на приложението и в резултат на това започва хаос.

Когато започне хаос, бизнесът иска да намери виновния, и тук е необходим универсален виновен, трудно е да се наклони вината на 10+ души, затова мениджърите обединяват позиции, защото колкото повече задължения има един специалист, толкова по-лесно е да се докаже безотговорността му. А в условията на Agile, намирането на „виновния“ и наказанието – това е основата на тази методология на управление. Agile отдавна излезе от IT, а основната му концепция стана – изискване за ежедневни резултати. Проблемът е, че за специализиран специалист не винаги има ежедневен резултат, а това означава, че отчетността ще бъде по-трудна, и това е още една причина, поради която бизнесът иска „специалисти по всичко“. Но основната причина е разбира се, заплатата – тя е основната причина за всички промени, заради надбавки хората бяха готови да работят за себе си и за другите. Но в крайна сметка, както и в други сфери, това просто стана задължение, за по-ниско заплащане за по-голямо количество предоставени услуги.

Сега често виждаме дори статии, че разработчиците трябва да умеят да деплоират и да се занимават с инфраструктурата заедно с DevOps инженера. Но какво води това? Правилно – до спад на качеството на услугите и разработчиците. Буквално преди 2 дни обяснявах на един разработчик, че можем да пишем и четем от различни хостове, а той ми доказваше с ярост, че никога не е виждал такова нещо; в settings имаме orm host, port, db, user, password и всичко…. Но разработчикът знае как да стартира деплои, да пише YAML файлове…. Но вече е забравил за юнит тестовете и коментарите в кода.

В крайна сметка виждаме следното – постоянни преумора, търсене на решения на проблеми извън работно време, постоянно обучение през уикенда, не за увеличаване на доходите, а за да останат на повърхността. Разработчиците са принудени да помагат на DevOps инженера с CI/CD, а ако разработчикът няма време, той започва да се затъва, а мениджърите започват да му объркват ума. Ако това не помага да се увеличи желанието за работа извънредно, започват да налагат наказания и глоби. Човек търси ново работно място, оставяйки след себе си технически дълг с размерите на Еверест. В резултат дългът нараства и при разработчиците, тъй като те са принудени да пишат код с по-малко рефакторинг, за да успеят да помогнат на стария или новия DevOps инженер, а мениджърите са напълно удовлетворени, тъй като виновният е открит и е видим веднага, което значи, че основното правило в Agile мениджмънта е спазено – виновният е намерен, резултатите от наказанието са видими.

В миналото пред ITGM направих презентация ‘Кога ще се научим да казваме “не”’ – резултатите бяха много показателни. Огромен брой хора смятат, че тази дума е табу и докато не спрем да я смятаме за такава, проблемите ще нарастват.

Частично тази статия ме вдъхнови тази статия, но по-късно може би ще я опиша с по-малко заобиколни термини.

Само регистрирани потребители могат да участват в анкетата. Влезте, моля.