Совпадения случайны, да и вообще это было на другой планете…
Хочу поделиться тремя историями успеха и неуспеха о том как работается бекенд разработчику в команде с админами.
История первая.
Веб студия, количество сотрудников поддается счету одной рукой. Сегодня ты верстальщик, завтра бекендер, послезавтра админ. С одной стороны, можно получить колоссальный опыт. С другой, не хватает компетенции во всех областях. До сих пор помню первый рабочий день, я ещё зеленый, начальник говорит: «Открывай putty», а я не знаю, что это такое. Общение с админами исключено, т.к. ты сам админ. Рассмотрим плюсы и минусы такого положения.
+ Вся власть в твоих руках.
+ Не нужно ни у кого клянчить доступы от сервера.
+ Быстрое время реакции по всем направлениям.
+ Хорошо прокачивает скиллы.
+ Есть полное понимание архитектуры продукта.
— Высокая ответственность.
— Риск поломать продакшен.
— Сложно быть хорошим специалистом во всех областях.
Не интересно, идем дальше
История вторая.
Крупная компания, крупный проект. Имеется отдел администрирования с 5-7 сотрудниками и несколько групп разработки. Когда приходишь работать в такую компанию, каждый админ считает, что ты пришел сюда не работать над продуктом, а что-нибудь сломать. Ни подписанное NDA, ни отбор на собеседовании не говорит об обратном. Нет, этот человек пришел сюда своими грязными ручонками испортить наш целованный продакшен. Поэтому с таким человеком нужно минимум общения, на крайняк можно кинуть стикер в ответ. На вопросы об архитектуре проекта не отвечать. Желательно не выдавать доступы пока тимлид не попросит. А когда попросит, выдать с еще меньшими привилегиями чем просили. Практически вся коммуникация с такими админами поглощается черной дырой между отделом разработки и отделом администрирования. Решить вопросы оперативно невозможно. А подойти лично нельзя — админы слишком заняты 24/7. (Чем вы всё время заняты?) Некоторые ТТХ:
- Среднее время деплоя в продакшен 4-5ч
- Максимальное время деплоя в продакшен 9ч
- Для разработчика приложение в продакшене это черный ящик, как и сам сервер продакшена. А сколько их вообще?
- Низкое качество релизов, частые ошибки
- Разработчик не принимает участия в процессе релиза
Ну а что я ждал, конечно на продакшен новеньких не пускают. Ну да ладно, набравшись терпения начинаем получать доверие у окружающих. Но почему-то с админами не всё так просто.
Акт 1. Админ невидимка.
День релиза, разработчик и админ не общаются. У админа нет никаких вопросов. Но почему понимаешь позже. Админ принципиальная личность, не имеет мессенджеров, номер телефона никому не дает, профиля в соцсетях не имеет. Да даже фото его нигде нет, как ты выглядишь чувак? Сидим с ответственным менеджером минут 15 в недоумении, пытаемся наладить связь с этим «Вояджер-1», тут на корпоративную почту падает сообщение, что он закончил. Мы что по почте будем переписываться? А почему бы нет? Удобно, не правда ли? Ну да ладно, остынем. Процесс уже идет, назад дороги нет. Читаем ещё раз сообщение. «Я закончил». А что ты закончил? Где? Куда смотреть чтоб тебя? Тут вы понимаете, почему 4ч на релиз это нормально. Получаем разработческий шок, но релиз заканчиваем. Желания релизиться больше нет.
Акт 2. Не та версия.
Очередной релиз. Понабравшись опыта, мы начинаем формировать списки необходимого софта и библиотек на сервер для админов, с указанием версий для некоторых. Как всегда, получаем слабый радиосигнал, что админ что-то там закончил. Начинается регрессионный тест, который сам по себе занимает около часа. Вроде бы всё работает, но есть один критичный баг. Важная функциональность не работает. Следующие несколько часов танцы с бубнами, гадание на кофейной гуще, детальный пересмотр каждого куска кода. Админ говорит, что всё сделал. Не работает же приложение написанное криворукими разработчиками, а сервер работает. Какие к нему вопросы. На исходе какого-то часа таки добиваемся от админа, чтобы тот скинул в чат версию библиотеки на продакшен сервере и бинго — она не та, что нужна. Просим админа поставить нужную версию, в ответ получаем, что он этого сделать не может по причине отсутствия этой версии в пакетном менеджере ОС. Тут из закромов памяти менеджер вспоминает, что другой админ уже решал эту проблему, просто собрав нужную версию руками. Но нет, наш этого делать не станет. Регламент запрещает. Карл мы уже несколько часов сидим, какой регламент?! Получаем очередной шок, релиз кое-как заканчиваем.
Акт 3, короткий
Срочный тикет, на продакшене не работает ключевой функционал у одного из пользователей. Пару часов тыкаем, проверяем. В девелоп среде всё работает. Есть четкое понимание, что неплохо бы заглянуть в логи php-fpm. Системы для логов вроде ELK или Prometheus в ту пору на проекте не было. Заводим тикет на отдел администрирования, чтобы те дали доступ к логам php-fpm на сервер. Тут надо понимать, что доступ просим не с проста, вы же помните про черную дыру и занятость админов 24/7? Если попросить их посмотреть логи самим, то это задача с приоритетом «не в этой жизни». Тикет создан, получаем моментальный ответ от главы отдела администрирования: «Вам не должен быть нужен доступ к логам на продакшене, пишите без багов». Занавес.
Акт 4 и последующие
Собираем ещё ни один десяток проблем на продакшене, из-за разных версий библиотек, не настроенного по, неподготовленного к нагрузкам сервера и прочих проблем. Кодовые баги конечно тоже бывают, не будем во всех грехах винить админов, упомянем только ещё одну типичную операцию для того проекта. Было у нас достаточно много фоновых воркеров, которые запускались через супервизор, а некоторые скрипты надо было добавлять в cron. Иногда эти самые воркеры переставали работать. На сервере очередей молниеносно росла нагрузка, а грусные пользователи смотрели на крутящийся лодер. Для быстрой починки такие воркеры достаточно было просто перезапустить, но опять же сделать это мог только админ. Пока такая элементарная операция выполнялась мог пройти целый день. Тут конечно стоит отметить, что криворукие программисты должны писать воркеры так чтобы они не падали, но, когда они упали, неплохо бы понимать почему, что иногда невозможно по причине отсутствия доступов на продакшен конечно же и как следствие отсутствие логов у разработчика.
Преображения.
Потерпев это всё довольно длительное время, совместно с командой мы начали рулить в более успешное для нас русло. Если резюмировать, какие перед нами стояли проблемы?
- Отсутствие качественной коммуникации между разработчиками и отделом администрирования
- Админы, оказывается(!), совершенно не понимают, как устроено приложение, какие у него зависимости и как оно работает.
- Разработчики не понимают, как устроена продакшен среда и как следствие не могут эффективно реагировать на проблемы.
- Слишком длительное время занимает процесс деплоя.
- Нестабильные релизы.
Что мы сделали?
К каждому релизу формировали список Release Notes, который включал перечень работ, которые необходимо произвести на сервере, для работы очередного релиза. Список содержал несколько секций, работы, которые должен провести администратор, ответственный за релиз и разработчик. Разработчики получили доступ (не root) на все продакшен сервера, что ускорило разработку в целом и решение проблем в частности. Так же у разработчиков появилось понимание как устроен продакшен, на какие сервисы поделен, где и сколько стоит реплик. От части стали более понятны боевые нагрузки, что несомненно влияет на качество кода. Общение в процессе релиза происходило в чате одного из мессенджеров. Во-первых, у нас появлялся лог всех действий, во-вторых, общение происходило в более тесной среде. Наличие истории действий ни раз позволяло новым сотрудникам быстрее решить проблемы. Парадокс, но это чаще помогало самим админам. Я не возьмусь утверждать точно, но мне кажется, что админы стали больше понимать, как устроен проект, как он написан. Иногда мы даже делились некоторыми деталями друг с другом. Среднее время релиза сократилось до часа. Иногда мы укладывались за 30-40 минут. Количество багов сократилось в разы, если не в десятки раз. Конечно на сокращение времени релиза влияли и другие факторы, например, такие как автотесты. После каждого релиза мы стали проводить ретроспективы. Чтобы вся команда имела представление, что нового появилось, что изменилось, а что было убрано. К сожалению, админы далеко не всегда на них приходили, ну админы же занятые… Удовлетворенность работой у меня как у разработчика несомненно повысилась. Когда ты можешь решить быстро практически любую проблему, которая в твоей зоне компетенции, ты чувствуешь себя на коне. Позже, я пойму, что мы в какой-то степени внедрили девопс культуру, не полностью конечно, но даже то начало трансформации было впечатляющим.
История третья
Стартап. Один админ, небольшой отдел разработчиков. По приходу я полный ноль, т.к. кроме как от почты доступов у меня никуда нет. Пишем админу, просим дать доступы. К тому же есть информация, что он в курсе, нового сотрудника и необходимости в выдаче логинов/паролей. Дают доступ от репозитория и впн. Зачем давать доступы к wiki, teamcity, rundesk? Бесполезные вещи для человека, которого позвали полностью писать бекенд часть. Лишь со временем получаем доступ к некоторым инструментам. Приход конечно же встречен недоверием. Пробую потихоньку прощупать как устроена инфраструктура проекта через чаты и наводящие вопросы. В основном ничего не узнаю. Продакшен такой же черный ящик, как и прежде. Но более того, тут черный ящик даже stage сервера, используемые для тестирования. Кроме деплоя туда ветки из гита мы ничего не можем. Так же мы не можем конфигурировать своё приложение наподобие .env файлов. Доступ для таких операций не положен. Надо заниматься попрашайничеством чтобы тебе поменяли строчку в конфиге твоего приложения на тестовом сервере. (Есть теория, что админам жизненно необходимо чувствовать себя самими важными на проекте, если их не будут просить менять строчки в конфигах, они просто будут не нужны). Ну как всегда, не правда ли удобно? Такое быстро надоедает, после прямого разговора с админом выясняем, что разработчики родились для того чтобы писать плохой код, по природе своей некомпитентные личности и лучше их держать подальше от продакшена. Но тут ещё и от тестовых серверов на всякий случай. Конфликт быстро набирает обороты. Коммуникации с админом нет. Ситуация усугубляется тем, что он один. Дальше типичная картина. Релиз. Не работает определенный функционал. Долго разбираемся в чем дело, в чат накидываются разные идеи от разработчиков, но админ в такой ситуации как правило исходит, что виноваты разработчики. Потом пишет в чате, стойте я поправил. На просьбы оставить историю после себя с информацией в чем была проблема получаем токсичные отговорки. Мол не суй свой нос куда не надо. Разработчики должны писать код. Ситуация, когда многие телодвижения в проекте проходят через одного единственного человека и только у него есть доступы для совершения нужных всем операций крайне печальна. Такой человек ужасное бутылочное горлышко. Если идеи Devops стремятся сократить time-to-market, то такие люди это злейший враг идей devops’a. К сожалению здесь закрывается занавес.
P.S. Немного пообщавшись на тему разработчики vs админы в чатах с людьми, я встретил людей, которые разделили мою боль. Но также были и те, кто сказал, что с таким не сталкивался. На одной devops конференции я поинтересовался у Антона Исанина (Альфа-банк) как они боролись с проблемой бутылочного горлышка в виде админов, на что он сказал: «Мы их заменили на кнопки». Вот кстати с его участием. Хочется верить, что хороших админов гораздо больше чем врагов. И да, картинка в начале это реальная переписка.
Источник: habr.com