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

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

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

Что такое DevOps?

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

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

Кто такой DevOps-инженер?

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

В чем цель DevOps?

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

  • Ускорения выпуска приложений
  • Улучшения качества релизов приложений
  • Сокращения ручных процедур
  • Быстрого исправления ошибок
  • Сокращения времени между исправлениями

Каким организациям нужен DevOps?

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

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

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

Какие проблемы бизнеса решает подход DevOps?

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

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

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

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

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

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

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

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

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

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

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

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

Когда DevOps не поможет?

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

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

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

DevOps — это не только внутренняя история IT-компаний

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

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

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

99
10 комментариев

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

11
Ответить

Разница между серверами на win и на Linux настолько огромная что я даже не представляю как так можно было наладить. Разработчики на полпути сменили язык разработки? Или они вдруг забыли что пишут на шарпе и им нужен все таки win сервер? DevOps тут вообще не при чем.

9
Ответить

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

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

Ответить

Комментарий недоступен

6
Ответить

Специалисты по DevOps могут быть разные. Кому-то в штат, действительно требуются сисадмины, но в вакансиях их почему-то назвали модным словом DevOps.
Конечно, как любой человек, DevOps-специалист может факапить или что-то не знать. Однако, хороший DevOps — разбирается не только в том, что делает Ops, но и в том что делает (И, САМОЕ ГЛАВНОЕ) не делает Dev.

Ответить

Если ты знаешь уже пару языков программирования - выучить ещё один вообще не проблема. И настраивать тестовое окружение это опять таки не nunit/xUnit тесты писать, язык можно и не знать, а вот скажем требуемую структуру папок, нужные конфиги положить на машину, настроить демоны и прочую тестовую обвязку - это как раз работа для DevOps.

Ответить

Здравствуйте. Два вопроса.
1. Для кого hr - систему делали?
2. У вас на сайте все кейсы по дизайну, где можно ваши девопс проекты посмотреть ?

1
Ответить