DevOps для бизнеса. Наш опыт и выводы

Обратили внимание, что запросов на DevOps-инженеров с одной стороны стало больше, а с другой стороны, не все кто их ищет, правильно понимают, что такое DevOps и как это работает. Мы собрали и структурировали свой опыт, чтобы разъяснить, в каких случаях нужен DevOps, а когда можно обойтись и без него.

DevOps — это методология разработки ПО, задача которой наладить взаимодействие между командой разработчиков, тестировщиков и сисадминов. Чтобы IT-специалисты не дробились на автономные отделы, в разных кабинетах, а наоборот, вместе обслуживали общий продукт.

Такой подход позволяет избежать типичных затруднений большой, распределенной команды разработчиков, когда «проблема не на нашей стороне». Так как при DevOps подходе вся «сторона» наша. Эффективное сотрудничество находится в интересах разработчиков, qa и сисадминов.

DevOps-инженер — специалист на стыке компетенций. Он налаживает взаимодействие между разработчиками, тестировщиками, сисадминами, соответственно, разбираться должен во всем. DevOps-инженер автоматизирует процесс создания продукта на всех этапах: от разработки и тестирования, до развертывания и доставки продукта пользователю.

DevOps — ускоряет процесс разработки и обновления ПО, а также повышает конкурентоспособность бизнеса при помощи:

DevOps нужен компаниям, которые либо разрабатывают IT-продукты, либо поддерживают их. В небольших стартапах DevOps хорош тем, что настраивает процессы с самого начала и позволяет быстро добиться оптимального сочетания специалистов, процессов и используемых технологий.

Для больших компаний все сложнее. DevOps там нужен не меньше чем в стартапах, но интегрировать его сложнее, за счет устоявшегося уклада работы. Не каждый бизнес готов объединять отделы и глобально пересматривать методологию работы.

DevOps не нужен компаниям, которые потребляют IT-услуги, разработанные и поддерживаемые другими организациями. Но если разработанный для вас продукт вы обслуживаете и поддерживаете сами — то DevOps имеет место быть.

Даже в IT-среде, которая считается самой передовой, до сих пор применяются принципы «разделяй и властвуй». Каждый специалист беспокоится за свою локальную зону ответственности, не акцентируясь на том, какими трудностями сталкиваются его коллеги и насколько успешно проект идет к релизу.

Как итог: отдел разработки и системные администраторы — не понимают друг друга находясь по разные «стороны». Сисадмины предъявляют разработчикам требования, которые те находят нефункциональными, а сисадминов не волнуют баги в функционале сайта — это не их зона ответственности, им важнее, чтобы сервер не упал. Здесь не найти правого или виноватого, каждый беспокоится только о своих локальных задачах, потому, что так построена система.

Разработчики вынуждены взаимодействовать с сисадминами через систему заявок — направляя свои запросы через менеджеров или системы постановки задач. Эта схема более менее стабильно работает, когда разработчик на 100% понимает что ему нужно от сисадмина. Если сотрудники не понимают специфики работы друг друга и ставят ТЗ в стиле «ну сделайте красиво», то внедрение нового функционала превращается в ад.

Пример из личного опыта. Во время разработки hr-системы для крупного производства, разработчики сделали запрос отделу системного администрирования на комплект из четырех серверов на базе debian linux. Далее, отдел подготовил стенд к развертыванию, а разработчики назначили дату релиза. В дату запуска оказалось что четыре сервера всё-таки должны быть организованы на базе win serv. Итог — перенос сроков релиза на неделю, лишение премий двух отделов в полном составе.

Почему так получилось?

Из-за проблем коммуникации между отделами. Процессы работы подразделений были непрозрачными друг для друга. У специалистов не было возможности узнать об ошибках коллег и своевременно устранить их, пока они не стали критичными. А возможно, коллеги и не интересовались проблемами смежных отделов, пока косяки релиза не ударили по всем.

Как решить такую проблему?

Внедрить DevOps-инженера, уйти от больших релизов, перейдя к практике CI/CD, а именно непрерывного развертывания и интеграции ПО, в процессе разработки. CI/CD объединяет разработку, тестирование и развертывание приложений в постоянный непрерывный процесс

Что дает такой подход в итоге?

После объединения всех нужных специалистов в одну команду, DevOps подталкивает их к истине — если большие релизы приносят страдания, то их нужно дробить на более мелкие. Проводить тестирование после каждого деплоя, а не за день до продакшена. Благодаря такой систематической работе, код и его инфраструктура становятся более управляемыми, так как в них выделяются небольшие фиксированные кусочки — микросервисы.

Чего позволяют добиться микросервисы?

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

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

Попытка перейти на DevOps лишняя трата времени, когда компания не готова трансформироваться полностью — DevOps это не просто инженер, который пришел настроить процессы в компании, а методология работы, чтобы она принесла пользу бизнесу, нужно чтобы ей руководствовались все сотрудники, включая руководство.

Еще один наглядный пример из опыта. В сеть частных медучреждений, пришел новый начальник отдела безопасности, стал налаживать работу, погружаться в процессы...и обнаружил что инцидентов по нарушению безопасности мобильного приложения самообслуживания с каждым месяцем все больше. Безопасник совместно с техническим директором пришли к решению пересмотреть работу IT-отдела и найти DevOps-инженера – нашли в формате аутсорса в нашем лице. В течение года наш специалист налаживал им работу конвейера разработки-тестирования-развертывания, внедрял проверку безопасности после каждого деплоя. Сначала работники IT-отдела клиники были не в восторге, было неудобно, слишком много повторяющейся, как казалось, лишней работы и страданий. Но, увеличив количество развертываний, клиника снизила частоту инцидентов безопасности почти до нуля. Эффект налицо.

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

Основываясь на своем опыте и клиентов, которые пришли к DevOps вместе с нами, уверенно говорим — DevOps-инженер закроет боли, связанные с наладкой процессов в отделе разработки и системного администрирования как в digital-студии, так и в компании, для которой цифровой продукт не является ключевым. Участие DevOps-инженера позволит команде сфокусироваться на обновлениях системы, внедрении новых функций, не беспокоясь о том, как соединить все части процесса разработки, тестирования и развертывания ПО воедино.

Сомневаетесь, нужен ли вам DevOps? Или знаете, что нужен, но пока не нашли? Обращайтесь к нам, мы точно поможем.