Сегодня нужно искать решения, которые позволяют иметь максимальную гибкость, настраиваемость. И при этом очень чётко понимать — то, что ты строишь сегодня, через 5 лет будет никому не нужно. Надо нормально к этому относиться.
Алексей Марей
Несколько лет назад, в моей прошлой жизни, было у меня несколько ярких случаев, которые слились в одну характерную картинку жизненного опыта. А дело, обобщая, было так. На встречах принимали участие три стороны: заказчик, разработчик и сопровожденец. Что нужно было заказчику – быстрая реакция на частые изменения в виде развёрнутых в продуктиве новых релизов приложения (это по-нашему, по ИТ-шному). А на языке заказчика – оперативная и гибкая реализация новой функциональности, которая подстраивалась бы под изменяющийся бизнес-процесс. Как на это реагировал разработчик – обычно в духе: "Да, мы готовы выпускать релизы часто, но вот релизные окна, они предусмотрены только раз в две недели". Очередь доходила до сопровожденца. А он отвечал так: "У нас сложная гетерогенная среда, нужно тщательнее тестировать релизы перед раскатом в промышленной среде, мы не знаем всех зависимостей наших ИТ-систем, да и вообще любое ваше изменение – это наша головная боль (чем их меньше, тем стабильнее)". И я подумал тогда, насколько тяжело бизнесу с таким подходом, буквально ощутил его недоумение.
Прошли годы, бег времени с тех далёких уже пор, кажется, только ещё больше увеличился. Рынок сейчас требует всё более быстрого вывода новых решений. Нужно быть гибким, подстраиваясь под желания покупателей. А желания меняются часто. Новые решения – новая функциональность, а значит, доработки и доработки. Много доработок. Облачные технологии, web-решения, соцсети, маркетинг там же и т.д. с одной стороны, а подкованность и разборчивость бизнес-руководителей в информационных технологиях – с другой, оказывают сильное давление на ИТ-подразделения. И уже непросто ИТ-руководителям объяснять из года в год, почему у нас "релизные окна раз в две недели", а у соседей по бизнесу – новые продукты с начала года выходят на рынок, не останавливаясь. Время требует. Бизнес требует. Приходится задуматься, а что же делать.
На помощь, на мой взгляд, приходят Agile-подходы во взаимодействии "заказчик-разработчик" и DevOps во взаимодействии "разработчик-сопровожденец". Что же это такое – DevOps? Лексически, это слово производное из двух слов: "development" (среда разработки решений, разработчики) и "operations" (среда эксплуатации, ИТ-инфраструктура, сопровожденцы). Чего хотят первые? Быстрой разработки и скорейшего развёртывания. А чего хотят вторые? Защитить продуктивную среду, обеспечив стабильность систем и отсутствие проблем у пользователей. Вот в этом месте и возникает обычно барьер, функциональный колодец – каждая из сторон замыкается "в себе".
На практике это приводит к тому, что сырые релизы со стороны разработки перебрасываются в среду эксплуатации, а дальше начинается бег с препятствиями: среда тестирования отлична от продуктивной, а значит, в коде не учтено: первое, второе, третье… Откатываемся назад. Время затрачено, заказчик крайне недоволен. DevOps предлагает разрушить эти барьеры. Например, пусть разработчики увидят, каково работать с новым билдом сопровожденцам. А сопровожденцы, в свою очередь – увидят тестовое окружение разработчиков и внесут нужные коррективы. Или пусть разработчики держат в уме, какие метрики нужны сопровожденцам и т.п. Фактически, нужно организовать единую команду людей с разными навыками из разных сред (разработка, тестирование, инфраструктура, мониторинг) для решения одной задачи – помочь бизнесу.
Видел ли я DevOps в жизни? Думаю, да. Мне удалось однажды познакомиться с тимлидом команды внутренних разработчиков. Он мне рассказал, что у них нет проблем с заказчиком: релизы выходят так часто и в то время, когда нужно заказчику. Пожелания заказчика быстро обрабатываются в текущем рабочем режиме и реализуются в коде ПО. Проблем с тестированием и выпуском в продуктив тоже нет – возникающие вопросы по настройке и конфигурации решались сисадминами и DBA оперативно. Как итог – довольный заказчик. И мне кажется, что подобный опыт совсем не единичный…
Если перевести идею DevOps и Agile на язык "родных осин", то получится следующее – соблюдать технологии проектирвоания, а именно : анализировать бизнес процессы, строить и анализировать модель данных, модель процессов; анализировать требования на соответствие имеющейся уже модели и т.д. – это всё долго и нудно, а надо шустро (agile). Поэтому предлагается революционный подход – проектирвоание на коленке. Это быстро, дешево и сердито. А то, что это потом работает через раз, так это не потому, что спроектированно на коленке, а потому, что в эксплуатации работают недоумки, не способные осознать величие сваленного на них кода. Поэтому их(недоумков) надо приглашать на периодические экскурсии к разрабртчикам, чтобы они,так сказать, прониклись.:))) И, к стати, идея не нова. У меня один из сотрудников перебрался в 98-ом в Штаты и устроился программистом к мелкомягому. Потом как-то приехал и рассказал про процесс: – Сережа, тут вот bug есть, нужно срочно, за 15 минут fix слепить. – Ребята, вы понимаете, что этот bug не просто так, и, чтобы сделать это по-человечески, надо сильно модель подправить? – Сережа, ты не понял? 15 минут!
Ну а про тимлида мне анекдот вспомнился(я просто на этом слове споткнулся):
Молодой парнишка, казахстанский намец, перебрался на историческую родину и устроился там на работу. Когда его назначили тимлидом, он собрал тим и сказал – не гоже нам, немцам, чужие слова копировать! Так что зовите меня прсто, по-немецки – группенфюрер!
Ну вот, опять похоже ветку завалил:))))