Разработчиците са от Марс, администраторите са от Венера

Съвпаденията са случайни и наистина беше на друга планета...

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

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

+ Цялата власт е във вашите ръце.
+ Няма нужда да молите никого за достъп до сървъра.
+ Бързо време за реакция във всички посоки.
+ Подобрява добре уменията.
+ Имайте пълно разбиране на продуктовата архитектура.

— Висока отговорност.
— Риск от прекъсване на производството.
— Трудно е да си добър специалист във всички области.

Не се интересувам, да продължим

Втората история.
Голяма компания, голям проект. Има административен отдел с 5-7 служители и няколко групи за развитие. Когато дойдеш да работиш в такава компания, всеки администратор си мисли, че не си дошъл да работиш върху продукт, а да счупиш нещо. Нито подписаното NDA, нито подборът на интервюто показват друго. Не, този човек дойде тук с мръсните си ръчички, за да съсипе целувката ни. Следователно с такъв човек се нуждаете от минимум комуникация, най-малкото можете да хвърлите стикер в отговор. Не отговаряйте на въпроси относно архитектурата на проекта. Препоръчително е да не предоставяте достъп, докато ръководителят на екипа не поиска. И когато поиска, ще го върне с още по-малко привилегии, отколкото са поискали. Почти цялата комуникация с такива администратори се поглъща от черната дупка между отдела за развитие и отдела за администрация. Невъзможно е проблемите да бъдат решени бързо. Но не можете да дойдете лично - администраторите са твърде заети 24/7. (Какво правите през цялото време?) Някои характеристики на ефективността:

• Средното време за внедряване до производство е 4-5 часа
• Максимално време за внедряване в производство 9 часа
• За разработчика едно приложение в производство е черна кутия, точно като самия производствен сървър. Колко са общо?
• Ниско качество на изданията, чести грешки
• Разработчикът не участва в процеса на издаване

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

Акт 1. Админът е невидим.
Ден на пускане, разработчикът и администраторът не комуникират. Админът няма въпроси. Но по-късно ще разберете защо. Админът е принципен човек, няма месинджъри, не дава телефонния си номер на никого и няма профил в социалните мрежи. Никъде дори няма негова снимка, как изглеждаш пич? Седим с отговорния мениджър около 15 минути в недоумение, опитвайки се да установим комуникация с този Voyager 1, след което в корпоративния имейл се появява съобщение, че той е приключил. Ще си кореспондираме ли по пощата? Защо не? Удобно, нали? Е, добре, нека се охладим. Процесът вече е в ход, няма връщане назад. Прочетете съобщението отново. "Свърших". Какво завърши? Където? Къде да те търся? Тук разбирате защо 4 часа за освобождаване е нормално. Получаваме шок от развитието, но завършваме изданието. Вече няма желание за освобождаване.

Акт 2. Не тази версия.
Следващото издание. След като натрупахме опит, започваме да създаваме списъци с необходимия софтуер и библиотеки за сървъра за администратори, като посочваме версиите за някои. Както винаги, получаваме слаб радио сигнал, че администраторът е свършил нещо там. Започва регресионният тест, който отнема около час. Изглежда всичко работи, но има един критичен бъг. Важна функционалност не работи. Следващите няколко часа бяха танци с дайрета, гадаене на утайка от кафе и детайлен преглед на всеки код. Админът казва, че е направил всичко. Приложението, написано от измамни разработчици, не работи, но сървърът работи. Имате ли въпроси към него? В края на един час караме администратора да изпрати версията на библиотеката на производствения сървър в чата и бинго - не е тази, от която се нуждаем. Молим администратора да инсталира необходимата версия, но в отговор получаваме, че не може да направи това поради липсата на тази версия в пакетния мениджър на ОС. Тук, от дъното на паметта си, мениджърът си спомня, че друг администратор вече е решил този проблем, като просто е сглобил необходимата версия на ръка. Но не, нашите няма да направят това. Правилата забраняват. Карл, седим тук от няколко часа, какъв е срокът?! Получаваме нов шок и някак завършваме изданието.

Акт 3, кратък
Спешен билет, ключова функционалност не работи за един от потребителите в производството. Прекарваме няколко часа в ровене и проверка. В среда за разработка всичко работи. Има ясно разбиране, че би било добра идея да се разгледат регистрационните файлове на php-fpm. По това време в проекта нямаше лог системи като ELK или Prometheus. Отваряме билет до административния отдел, така че те дават достъп до php-fpm регистрационните файлове на сървъра. Тук трябва да разберете, че искаме достъп с причина, не помните ли за черната дупка и администраторите, които са заети 24/7? Ако ги помолите да погледнат самите регистрационни файлове, тогава това е задача с приоритет „не в този живот“. Билетът беше създаден, получихме незабавен отговор от ръководителя на административния отдел: „Не трябва да имате нужда от достъп до производствени регистрационни файлове, пишете без грешки.“ Завеса.

Акт 4 и след това
Все още събираме десетки проблеми в производството поради различни версии на библиотеки, неконфигуриран софтуер, неподготвени зареждания на сървъра и други проблеми. Разбира се, има и грешки в кода, няма да обвиняваме администраторите за всички грехове, а само ще споменем още една типична операция за този проект. Имахме доста фонови работници, които бяха стартирани чрез супервайзора, и някои скриптове трябваше да бъдат добавени към cron. Понякога същите тези работници спираха да работят. Натоварването на сървъра за опашки нарастваше със светкавична скорост и тъжните потребители гледаха към въртящия се товарач. За да коригирате бързо такива работници, беше достатъчно просто да ги рестартирате, но отново само администратор можеше да направи това. Докато се извършваше такава елементарна операция, можеше да мине цял ден. Тук, разбира се, си струва да се отбележи, че кривите програмисти трябва да пишат worker, за да не се сринат, но когато паднат, би било хубаво да разберем защо, което понякога е невъзможно поради липсата на достъп до продукцията, на Разбира се, и като следствие липсата на регистрационни файлове от разработчика.

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

• Липса на качествена комуникация между разработчиците и административния отдел
• Администраторите, оказва се (!), изобщо не разбират как е структурирано приложението, какви зависимости има и как работи.
• Разработчиците не разбират как работи производствената среда и в резултат на това не могат да отговорят ефективно на проблемите.
• Процесът на внедряване отнема твърде много време.
• Нестабилни версии.

какво направихме
За всяка версия беше генериран списък с бележки по версията, който включваше списък с работата, която трябва да бъде извършена на сървъра, за да работи следващата версия. Списъкът съдържа няколко раздела, работа, която трябва да се извърши от администратора, лицето, отговорно за изданието, и разработчика. Разработчиците получиха не-root достъп до всички производствени сървъри, което ускори разработката като цяло и решаването на проблеми в частност. Разработчиците също имат разбиране за това как работи производството, на какви услуги е разделено, къде и колко струват репликите. Някои от бойните товари станаха по-ясни, което несъмнено се отразява на качеството на кода. Комуникацията по време на процеса на освобождаване се проведе в чата на един от месинджърите. Първо, имахме дневник на всички действия, и второ, комуникацията се проведе в по-близка среда. Наличието на история на действията неведнъж е позволявало на новите служители да решават проблемите по-бързо. Парадоксално, но това често помагаше на самите администратори. Няма да се ангажирам да кажа със сигурност, но ми се струва, че администраторите са започнали да разбират повече как работи проектът и как е написан. Понякога дори споделяхме някои подробности един с друг. Средното време за освобождаване е намалено до един час. Понякога свършвахме за 30-40 минути. Броят на грешките е намалял значително, ако не и десетократно. Разбира се, други фактори също повлияха на намаляването на времето за освобождаване, като например автотестовете. След всяко издание започнахме да провеждаме ретроспективи. Така че целият екип има представа какво е ново, какво е променено и какво е премахнато. За съжаление, администраторите не винаги идваха при тях, добре, администраторите са заети... Удовлетворението ми от работата като разработчик несъмнено се увеличи. Когато можете бързо да разрешите почти всеки проблем, който е във вашата област на компетентност, вие се чувствате на върха. По-късно ще разбера, че до известна степен въведохме devops култура, разбира се не напълно, но дори това начало на трансформацията беше впечатляващо.

История трета
Започвам. Един администратор, малък отдел за развитие. При пристигането съм пълна нула, защото... Нямам достъп никъде освен от пощата. Пишем на админа и искаме достъп. Освен това има информация, че той е запознат с новия служител и необходимостта от издаване на данни за влизане/пароли. Те дават достъп от хранилището и VPN. Защо да давате достъп до wiki, teamcity, rundesk? Безполезни неща за човек, който е призован да напише цялата бекенд част. Едва след време получаваме достъп до някои инструменти. Пристигането, разбира се, беше посрещнато с недоверие. Опитвам се бавно да усетя как работи инфраструктурата на проекта чрез чатове и водещи въпроси. По принцип нищо не разпознавам. Производството е същата черна кутия, както преди. Но повече от това, дори сценичните сървъри, използвани за тестване, са черна кутия. Не можем да направим нищо друго освен да разположим клон от Git там. Също така не можем да конфигурираме нашето приложение като .env файлове. Достъп за такива операции не се предоставя. Трябва да помолите да промените ред в конфигурацията на вашето приложение на тестовия сървър. (Има теория, че е жизненоважно за администраторите да се чувстват важни за проекта; ако не бъдат помолени да променят редовете в конфигурациите, те просто няма да са необходими). Е, както винаги, не е ли удобно? Това бързо става скучно, след директен разговор с администратора разбираме, че разработчиците са родени да пишат лош код, по природа са некомпетентни личности и е по-добре да ги държим далеч от производството. Но тук също и от тестови сървъри, за всеки случай. Конфликтът бързо ескалира. Няма комуникация с админ. Ситуацията се утежнява от факта, че той е сам. Следва типична картина. Освобождаване. Определена функционалност не работи. Отнема ни много време, за да разберем какво се случва, различни идеи от разработчици се хвърлят в чата, но администраторът в такава ситуация обикновено предполага, че разработчиците са виновни. След това пише в чата, чакай, поправих го. Когато бъдем помолени да оставим история зад себе си с информация за това какъв е проблемът, получаваме токсични извинения. Например, не си пъхай носа, където не му е мястото. Разработчиците трябва да пишат код. Ситуацията, когато много движения на тялото в един проект минават през един човек и само той има достъп да извършва операциите, от които се нуждае всеки, е изключително тъжна. Такъв човек е ужасно тясно място. Ако идеите на Devops се стремят да намалят времето за пускане на пазара, тогава такива хора са най-лошият враг на идеите на Devops. За съжаление тук завесата се затваря.

PS След като поговорих малко за разработчици срещу администратори в чатове с хора, срещнах хора, които споделиха болката ми. Но имаше и такива, които казаха, че никога не са срещали подобно нещо. На една devops конференция попитах Антон Исанин (Алфа Банк) как са се справили с проблема с тясното място под формата на администратори, на което той каза: „Заменихме ги с бутони.“ Между другото подкаст с негово участие. Бих искал да вярвам, че има много повече добри администратори, отколкото врагове. И да, снимката в началото е истинска кореспонденция.

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