DevOps разгружает разработчиков, они снова пишут код. Сага | АйТи-Капитан Объясняет

Привет, я Михаил, канал IT капитан. В этом эпизоде 

я хочу поговорить о том, как команды приходят к тому, чтобы привлечь к работе Девопса. В начале, 

когда проект только начинает разрабатываться либо уже запущен, него мало пользователь, сам проект 

маленький, серверная инфраструктура маленькая, пользователей мало, и всё это не требует 

какой-то длительной настройки. Но по мере роста проекта увеличивается число его программных 

компонентов. количество приложений. Возможно, даже проект приходит к микросервисной архитектуре. 

И, а, времени бэкэндразработчиков на поддержку этой инфраструктуры тратится всё больше и 

больше. Тогда к нам на помощь приходит Devops. Давайте посмотрим, как это обычно происходит на 

практике. Погнали. На схеме небольшой кусочек нашего конвейера по производству программного 

обеспечения. Backend разработчики, frontend, тестовый сервер, команда тестировщиков, про 

Production сервер и пользователи, которые пользуются нашим продуктом. В команду разработки 

прилетает пять задач. Все они хорошо расписаны в документе, который называется техническое 

задание. Давайте выполним все эти задачи. Итак, у нас уже есть приложение вот на бэкэнде, 

которое представляет из себя опишечку REST API. И реестр контрагентов - это всего лишь четыре 

новых эндпоинта. Просчитать список контрагентов, получить одного контрагента, создать нового 

контрагента и отредактировать контрагента. Эта задача не требует никаких изменений на сервере. 

меняется только вот приложение на бэкэнде, приложение на фронтэнде и добавляется табличка 

в базе данных. У нас всё это уже было. Задача по поиску контрагентов было принято решение 

использовать SECH. Для этого нужно строить его в докере, чтобы остальные разработчики могли этим 

пользоваться. Нужно развернуть его на тестовом сервере, на продакшене и поменять конфигурации 

приложения UP backend на обоих серверах. Фильтр контрагентов решили сделать на основе того, что 

есть, либо просто используя SQL базу Postgress, либо тоже на основе Elastic Sech. Никаких 

изменений на серверах не потребовалось. Для задачи SMS-уведомления контрагентам понадобилось 

разработчикам сделать ещё одно приложение А SMMS на бэкэнде и добавить брокер сообщений Кавка. 

Для этого по предыдущей схеме настраиваем его для коллег в докере, чтобы они у себя локально могли 

работать. Настраиваем кавку на тестовом сервере, настраиваем её на продакш сервере. Меняем 

конфигурацию у приложений Backend. Задача по email уведомлениям делается на основе тех же самых 

технологий, но нам нужно создать новое приложение Appmail. Для этого его тоже нужно развернуть на 

тестовом сервере и на продакш сервере. Все пять задач сделаны, запущены на проде. пользователи 

активно юзают, но через какое-то время стали приходить сообщения от пользователей, 

например, через служб поддержки о том, что не работает функциональность на проекте. И 

служба поддержки, соответственно, переправляет эти запросы в отдел. Инд-разработчикам нужно решать 

эти цеденты в продакшене. И это может случаться в любое время суток. Задачи сделаны. Тестовый сервер 

настроен, prodдакшн сервер настроен, всё работает, но периодически ломается. Что мы ожидали и за 

что мы заплатили деньги-разработчикам? По сути, за то, чтобы они доработали app Backend и сделали 

два новых приложения App SMS и App email. Все остальные задачи являлись для них непрофильными, 

но тем не менее им всё равно приходилось этим заниматься. Более того, они получили обязанность 

быть на связи по вечерам и в выходные, чтобы решать какие-то инциденты на продакшн 

сервере, когда пользователи сталкиваются с проблемами. Мы оцениваем работу разработчиков, потому как быстро и качественно 

они разработали вот эти пять задач. А то, как хорошо они настроили, например, тестовый 

сервер, нет. Поэтому чаще всего это та такая факультативная работа и делается всё быстрее и 

быстрее, соответствующим качеством. Пометим часть стрелочек красным. Это лишние коммуникация для 

бэкэндразработчиков, не профильные для них задачи. А вот такие жалобы от пользователя о том, 

что, например, упала база данных в продакшене, вообще не должны приходить и тем более не должны 

приходить бэкэнд разработчикам. Мы должны узнавать о каких-то проблемах на сервере до того, как с 

ними столкнутся пользователи. Для этого хорошо бы обзавестись системой мониторинга, который 

постоянно будет проверять работоспособность всего на продакшн сервере и сигнализировать нам 

проблеме ещё до того, как они узнают пользователи. И как только начинается вот эта история о 

том, что нужно сделать систему мониторинга, какое-то централизованное хранилище логов и так 

далее и тому подобное, графики какие-то вывести, всё разработчиков мы можем потерять. Они полностью 

могут уйти в это. На помощь приходит DevOPS. Всё, мы нанимаем специального человека, который 

занимается всеми этими вопросами. Все красные стрелочки достались ему. Единственное, что 

осталось разработчиком - это позаботиться самим о себе, настроить своё рабочее окружение, развернуть 

все эти хранилища у себя на компьютерах с помощью докера и сигнализировать девопсом о том, какое 

программное обеспечение должно быть на серверах. Отдельно хочется поговорить по поводу того, 

как разработчики разворачивают свой код на серверах. Может быть такое, что они делают 

это вручную. То есть, если менеджмент совсем совсем совсем не даёт времени на доработку 

инфраструктуры, то бкэнд разработчику часто бывает проще руками зайти на сервер и собрать там 

приложение. И чаще всего это входит в привычку, в том числе у менеджмента. Зачем тратить время на 

автоматизацию, если до этого справлялись вручную? Но когда приложение становится вот столько много, 

это всё занимает огромное количество времени. И поэтому здесь будет уместно 

нарисовать CICD платформу для того, чтобы вот эти приложения автоматически 

собирались, когда выходят новая версия, добавляется какая-то функциональность. Ну, отметим 

стрелочки чёрненьким всё наше общение с серверами. И получается так, что наняв человека, для которого 

все эти задачи являются профильными, мы разгрузили отдел бэкэнд разработки, и люди начинают получать 

деньги ровно за то, зачем мы их наняли. Пишут код. Современные программные продукты чаще всего это не 

одно какое-то приложение, а целый кластер, много набор каких-то сервисов или микросервисов. плюс 

хранилища различные, балансировщики, нагрузки, веб-сервера. Всё это требует обслуживания, 

настройки, расширения, какой-то работы с инцидентами. нужна автоматизация в развёртывании 

приложения для того, чтобы не только разработчик мог это сделать, а ещё, например, тестировщик мог 

нажать кнопочку на веточке в Гитлабе, раскатить, чтобы всё это появлялось на тестовом сервере без 

участия разработчика. Ну и на продакшн сервере, само собой. Подписывайтесь на мой канал 

IT Каapтан. Я буду продолжать выпускать эпизоды про оптимизацию процессов в командах по 

разработки программного обеспечения. Пока. M.