Про DevOps

 

Сегодня нужно искать решения, которые позволяют иметь максимальную гибкость, настраиваемость. И при этом очень чётко понимать — то, что ты строишь сегодня, через 5 лет будет никому не нужно. Надо нормально к этому относиться.
Алексей Марей

devops_00Несколько лет назад, в моей прошлой жизни, было у меня несколько ярких случаев, которые слились в одну характерную картинку жизненного опыта. А дело, обобщая, было так. На встречах принимали участие три стороны: заказчик, разработчик и сопровожденец. Что нужно было заказчику — быстрая реакция на частые изменения в виде развёрнутых в продуктиве новых релизов приложения (это по-нашему, по ИТ-шному). А на языке заказчика — оперативная и гибкая реализация новой функциональности, которая подстраивалась бы под изменяющийся бизнес-процесс. Как на это реагировал разработчик — обычно в духе: "Да, мы готовы выпускать релизы часто, но вот релизные окна, они предусмотрены только раз в две недели". Очередь доходила до сопровожденца. А он отвечал так: "У нас сложная гетерогенная среда, нужно тщательнее тестировать релизы перед раскатом в промышленной среде, мы не знаем всех зависимостей наших ИТ-систем, да и вообще любое ваше изменение — это наша головная боль (чем их меньше, тем стабильнее)". И я подумал тогда, насколько тяжело бизнесу с таким подходом, буквально ощутил его недоумение.

Прошли годы, бег времени с тех далёких уже пор, кажется, только ещё больше увеличился. Рынок сейчас требует всё более быстрого вывода новых решений. Нужно быть гибким, подстраиваясь под желания покупателей. А желания меняются часто. Новые решения — новая функциональность, а значит, доработки и доработки. Много доработок. Облачные технологии, web-решения, соцсети, маркетинг там же и т.д. с одной стороны, а подкованность и разборчивость бизнес-руководителей в информационных технологиях — с другой, оказывают сильное давление на ИТ-подразделения. И уже непросто ИТ-руководителям объяснять из года в год, почему у нас "релизные окна раз в две недели", а у соседей по бизнесу — новые продукты с начала года выходят на рынок, не останавливаясь. Время требует. Бизнес требует. Приходится задуматься, а что же делать. 

На помощь, на мой взгляд, приходят Agile-подходы во взаимодействии "заказчик-разработчик" и DevOps во взаимодействии "разработчик-сопровожденец". Что же это такое — DevOps? Лексически, это слово производное из двух слов: "development" (среда разработки решений, разработчики) и "operations" (среда эксплуатации, ИТ-инфраструктура, сопровожденцы). Чего хотят первые? Быстрой разработки и скорейшего развёртывания. А чего хотят вторые? Защитить продуктивную среду, обеспечив стабильность систем и отсутствие проблем у пользователей. Вот в этом месте и возникает обычно барьер, функциональный колодец — каждая из сторон замыкается "в себе". 

devops_1

На практике это приводит к тому, что сырые релизы со стороны разработки перебрасываются в среду эксплуатации, а дальше начинается бег с препятствиями: среда тестирования отлична от продуктивной, а значит, в коде не учтено: первое, второе, третье... Откатываемся назад. Время затрачено, заказчик крайне недоволен. DevOps предлагает разрушить эти барьеры. Например, пусть разработчики увидят, каково работать с новым билдом сопровожденцам. А сопровожденцы, в свою очередь — увидят тестовое окружение разработчиков и внесут нужные коррективы. Или пусть разработчики держат в уме, какие метрики нужны сопровожденцам и т.п. Фактически, нужно организовать единую команду людей с разными навыками из разных сред (разработка, тестирование, инфраструктура, мониторинг) для решения одной задачи — помочь бизнесу.

Видел ли я DevOps в жизни? Думаю, да. Мне удалось однажды познакомиться с тимлидом команды внутренних разработчиков. Он мне рассказал, что у них нет проблем с заказчиком: релизы выходят так часто и в то время, когда нужно заказчику. Пожелания заказчика быстро обрабатываются в текущем рабочем режиме и реализуются в коде ПО. Проблем с тестированием и выпуском в продуктив тоже нет — возникающие вопросы по настройке и конфигурации решались сисадминами и DBA оперативно. Как итог — довольный заказчик. И мне кажется, что подобный опыт совсем не единичный...
devops

Kanban Kanban-метод

Практика построения быстрого потока. Новый мастер-класс!
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

    Если перевести идею DevOps и Agile на язык "родных осин", то получится следующее — соблюдать технологии проектирвоания, а именно : анализировать бизнес процессы, строить и анализировать модель данных, модель процессов; анализировать требования на соответствие имеющейся уже модели и т.д. — это всё долго и нудно, а надо шустро (agile). Поэтому предлагается революционный подход — проектирвоание на коленке. Это быстро, дешево и сердито. А то, что это потом работает через раз, так это не потому, что спроектированно на коленке, а потому, что в эксплуатации работают недоумки, не способные осознать величие сваленного на них кода. Поэтому их(недоумков) надо приглашать на периодические экскурсии к разрабртчикам, чтобы они,так сказать, прониклись.:))) И, к стати, идея не нова. У меня один из сотрудников перебрался в 98-ом в Штаты и устроился программистом к мелкомягому. Потом как-то приехал и рассказал про процесс: — Сережа, тут вот bug есть, нужно срочно, за 15 минут fix слепить. — Ребята, вы понимаете, что этот bug не просто так, и, чтобы сделать это по-человечески, надо сильно модель подправить? — Сережа, ты не понял? 15 минут!

    Ну а про тимлида мне анекдот вспомнился(я просто на этом слове споткнулся):

    Молодой парнишка, казахстанский намец, перебрался на историческую родину и устроился там на работу. Когда его назначили тимлидом, он собрал тим и сказал — не гоже нам, немцам, чужие слова копировать! Так что зовите меня прсто, по-немецки — группенфюрер!

    Ну вот, опять похоже ветку завалил:))))

    1. Денис Денисов Автор

      Добрый день, Роман!

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

НОЯ
18
Учебный курс:
Release, Control and Validation (ITIL RCV)