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


Как точно определяют мировые классики, организация – сложный организм, где переплетаются и уживаются интересы личности и групп, стимулы и ограничения, жесткая технология и инновации, безусловная дисциплина и свободное творчество, нормативные требования и неформальные инициативы. Чем моложе организация, тем менее устоявшимися будут ее ценности. Это облегчает изменение ее культуры.

Реальный путь изменения инженерной субкультуры оказался сложнее, чем мы ожидали. Нужно было заинтересовать разработчиков новыми технологиями, привить ответственность за весь процесс разработки своего продукта, познакомить их с головной болью администраторов и сопровождения, чтобы разработчики могли без страха залезать на их территорию. А разработчиков в нашей команде более 800, большинство уже вросли корнями в устоявшиеся ценности waterfall, которые не обеспечивали нужный time-to-market для целей и проектов ЕФС.

Профессор MIT Эд Шайне был прав в том, что инженеры и технические специалисты весьма своеобразны. Другие субкультуры кажутся им непонятными и даже несколько суетливыми. Техмены сосредоточены на техническом прогрессе и возможностях технического творчества. Мало того, они скорее хотят выжить людей из своего мира, нежели привлечь их туда. Поэтому простой способ внедрения DevOps через установление KPI и  автоматизацию сквозного производственного процесса нам не подходил.

Изучив тему, решили что попробуем изменить культуру изнутри. Найдем евангелистов «от сохи» в командах разработки и на их примере покажем, что все может быть иначе.  

«Не бойтесь совершать ошибки. Сплоховать порой полезно. Не бойтесь наломать дров» (С. Хансельман)

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

Из базы получателей в 800+ адресатов заявку для участия в пилоте отправило 5 человек. Конверсия менее 1% нас немного огорчила. Вспомнился Лев Гумилев и его пассионарная теория этногенеза: пассионарность — это непреодолимое внутреннее стремление к деятельности, направленной на изменение своей жизни, окружающей обстановки, статуса-кво. Согласно учению Гумилева, Россия была суперотносом с высоким уровнем пассионарности и вопрос – куда все делись? Что руководило нашими субпассионариями? Боязнь изменений? Низкое вовлечение? Или мы просто выбрали неудачный способ коммуникации?

Вспомнилась летняя конференция по DevOps в Мадриде, когда многие иностранцы, узнавая, что мы из России, залезали в Facebook и показывали нам своих русских коллег-разработчиков, работающих в других странах. Неужели большинство активных пассионариев из ИТ-среды мигрировало? А как вы думаете?

«Даже путь в тысячу ли начинается с первого шага» (Лао Цзы)

Немножко пассионарности мы все-таки нацедили. Итак, в нашу немногочисленную, но полную энтузиазма команду вошли опытные разработчики из Москвы и Иннополиса (Татарстан). У всех был разный опыт и цели, так что роли внутри распределили быстро. И работа закипела.

Через месяц команда разработчиков совместно с администраторами и автоматизаторами настроила первую версию pipe-line, начала тиражирование на другие команды и показала результаты. Вместо ручной установки консоли в течение 1,5 часов она осуществлялась через pipe-line за 10 минут, а ночью проверялась стабильность. Появилась автоматическая проверка поднятия контекста приложения. В целом работа по оптимизации не останавливалась, все хотели сделать свой продукт еще лучше. Дополнительно руководство ввело поощрения за проделанную работу.

Пилотной команде было непросто: ребятам приходилось совмещать c разработкой DevOps проектные задачи внутри своих команд. Помогла сильная внутренняя мотивация на результат, преодолевшая процессные разногласия и коммуникационные барьеры.

Позже мы вывели свою градацию участников-смежников и основные подходы к работе с ними:

• «Незнайки» (более 40%)
  

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

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

• Консерваторы (30%)
  

Знают о технологии, но не хотят ничего менять по куче «уважительных» причин: «не моя зона ответственности»,  «я так уже… дцать лет делаю», «мне важнее написать код в срок» и  так далее.

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

• Религиозные фанатики (20%)
  

Какой DevOps лучше: кошерный или православный? Когда мы начинали изменения, разработка сервисов шла полным ходом, некоторые уже выходили в прод. Команда разработки ядра ЕФС успела сделать свой DevOps – как смогла и на чем сумела. Действительно, это был лучший пример автоматизации на тот момент, но практика была только на dev-стендах. Требовались серьезные изменения и переделки для масштабирования, что огорчало многих.

С этой группой было очень интересно внедрять изменения, потому что в ее основе оказались очень умные и опытные разработчики. У нас были яркие эмоциональные дискуссии, которые стали гораздо продуктивнее после того, как мы провели первое демо: когда мы показали, как у нас устроен и работает pipe-line, коллеги сами захотели переделать свой.

• Сказочники (менее 10%)
  

К сожалению, есть такая категория разработчиков, которые не принимают ответственности за качество программного обеспечения. Например, для чего им писать автотесты? «Потому что KPI». Поэтому они пишут тесты–пустышки чтобы быстрее отвязаться от этой задачи. Последствия накрывают всех, включая сказочников: в авральном режиме приходится исправлять дефекты в своем и соседнем проекте, потому что поставленная автодеплоем установка развалила стенд, и другие команды вынуждены отдыхать в ожидании восстановления стенда.

Эта категория оказалась для нас самой сложной. Хорошо, что таких было немного. С ними можно работать только через их собственные ошибки: развалили стенд из-за тестов, заблокировали работу на день для всех модулей – разбор полетов.

В работе с возражениями мы часто начинали диалог с вопроса: «Хочешь больше не тратить силы на написание инструкций?» Это была зацепка, которая реально работала, никто не любит писать инструкции.

Конечно, не обошлось без пожеланий сверху, когда в бэклоги команд были включены работы по DevOps, и от каждой инициативы был выделен ответственный за настройку pipe-line. Участников подключали к ежедневному «стендапу» через корпоративный Skype — команда разработки ЕФС распределена между Москвой, Санкт-Петербургом, Ростовом, Воронежем, Иннополисом и другими городами.

«Возможности пробуждают реальность, и нет ничего нелепее, чем отрицать это» (Р. Музиль)

Единой коммуникации и инструментам, которые мы используем, будет посвящен отдельный пост. Для работы мы использовали Confluence, SharePoint, где создали базу знаний с последовательностью действий по настройке скриптов Ansible, выложили  матрицу коммуникаций и еще много полезной информации.

Помимо стендапов, раз в неделю мы проводили демо по работе pipe-line. Со временем мы организовали эстафету: демо проводит разработчик от следующей команды, которая настроила pipe-line. Процесс включения команд в DevOps не прекращается до сих пор, подход эстафеты позволяет всегда что-то дополнить к опыту, накопленному предшественниками.


К сожалению, до финиша пилота дошли не все. Выход из зоны комфорта, необходимость постоянно доказывать ценность того, что ты делаешь, двойная нагрузка и административные проволочки (куда без них) не прошли без потерь в команде. Сегодня развитие DevOps продолжают только 3 из 5 экспериментаторов ЕФС, остальные вышли из пилота и продолжили работу над текущими задачами в командах. Но к этим трем сейчас подключились новые евангилисты.

Могли ли мы избежать потерь? Наверное, нет. Но если бы мы были чуть бережнее, то увидели бы точку перелома раньше. Бонусную программу мотивации непроизводственной активности мы внедрили позднее.

В итоге мы получили доказательство того, что автоматизация процесса не является определяющей. Успех будет достигнут, когда все 800+ участников будут нести ответственность за свой продукт до конца, а это станет возможным только в условиях особенной инженерной культуры. Оценить уровень предпринятых изменений сложно, выбор конкретных индикаторов еще впереди. А как вы считаете, какие индикаторы DevOps будут показательны?