Про DevOps не рассказывает только ленивый. Некоторые компании внедряют эти практики, а подавляющее большинство присматривается в поисках next big thing или «серебряной пули», ну или просто поддавшись тенденции в ИТ-сообществе. Уникальность каждого случая, поиск собственного пути, опасения сделать хуже (принцип Гиппократа «не навреди») — всё это не способствует ускорению внедрения, лишь добавляя ступеньки на пути к совершенству ИТ. Мы хотим рассказать про свой путь, извилистый и пока не пройденный до конца.
В начале была боль. Была масса проблемных зон, которые беспокоили разные команды, и устранить эти проблемы в существующей парадигме административного деления на кланы «свой-чужой» (разработчик — поддержка) не получалось. Скорость внедрения изменений была никакая — установка важного патча могла занять не один день, что уж говорить про большие релизы… Для проведения тестирования необходимо было поставить изменение на тестовую среду, которой управлял централизованный сервис, но к нему была всегда очередь, и ждать приходилось по несколько дней. Эксперты 44 уровня тратили своё драгоценное время на ручную установку обновлений. Откат обновлений был непредсказуем по времени. Инициатива, не облеченная в форму легального зарегистрированного проекта, могла быть легко похоронена, несмотря на харизму инициатора — в смежных подразделениях тебе могли отказать в любой инициативе, или поставить ее на такую паузу, после которой возвращаться к идее было бессмысленно — рынок «ушёл». С другой стороны, как существовать в большой организации без регламентов, процедур, согласований, всего того, что создавалось для упорядочивания хаоса, а превратилось в бюрократию?
В этой системе координат мы задались целью сократить time to market. На рынке, на тот момент, была остро модной тема DevOps. Как оказалось, история не только про автоматизацию, но про отношения в командах. Мы решили попробовать на себе. Руководители управлений разработки, поддержки и инфраструктуры занялись развитием и продвижением новой идеологии. На ближайшей ИТ-конференции Райфа руководители сказали громкие слова, и обратного пути уже не было — они «подписались» под системообразующими изменениями. Казалось бы, «цели намечены, планы определены, за работу, товарищи» — но всё пошло не так. После слов возникли Мифы… Как на заре человечества, происходящее вокруг наполнялось смыслами, страх заполнял умы, и события воспринимались через призму чужого опыта. В курилках можно было услышать все 50 причин ничего не делать — и не важно, олдскульная сигарета у тебя в руках или вейп иборода.
В конце концов сложившаяся вокруг DevOps мифология была изучена и оформлена в виде сборника.
С каждым менеджеромкто боялся спать без света встречались и объясняли, что особых причин для опасений нет, и критерий обеспечения job security как всегда один — отличный рабочий результат. Тем временем, то есть стихийно и чуть раньше :), инициатива возникла и стала развиваться самими сотрудниками — самыми вовлеченными, теми, кому не всё равно. Стабильно работающего продукта при частых поставках релизов, да и саму поставку с высокой частотой в текущих условиях получить было трудно. Нужно было менять подход к задаче, определять правила взаимодействия и роли, расширять границы ответственности — без фанатизма конечно.
В результате было сформировано две модели DevOps, которых сегодня придерживаются команды. В них появились новые роли Support Expert и DevSupport expert, которые развивают и эксплуатируют набор сформированных в командах практик, направленных на более детальное погружение коллег в процессы друг друга. Выстраиваются новые договоренности, решаются основные проблемы взаимодействия, высказываются ожидания с обоих сторон.
Рассказы о достигнутых результатах на внутренних митапах, сарафанное радио и профессинальная гордыня сделали своё дело — очень быстро все команды начали пробовать автоматизировать тестирование, поставку, сборку.
Сначала были относительно «простые» истории с «правильными» технологиями — с ними справились сами, но на некоторых коробочных монстров пришлось «натравливать» внешних вендоров. Во всех эпизодах огромную роль сыграл внутренний центр компетенций и энтузиазм некоторых коллег: благодаря им удалось раскатать CI/CD даже на динозаврах, по своей сути не приспособленных для автоматизации.
Появились негласные стандарты: то, что зарекомендовало себя как эффективное решение и было согласовано в нашей инфраструктуре. Такие решения можно было раскатать в своей команде очень быстро, не связываясь с согласованиями, бюджетами, закупками, а самое главное — уже имея внутреннюю экспертизу. Что тут началось… На каждой внутренней встрече в ИТ, в каждом выступлении звучали слова про DevOps, про достижения (никто ведь не любит рассказывать о неудачах), начались разработки метрик степени «девопснутости» команды. Те из нас, кто поддерживал продукты с релизами раз в полгода, рефлексировали и оправдывались: дескать, хотелось бы внедрить, но смысла особого нет, трудозатраты не окупятся. Масштабность движения и разнообразие путей и практик потребовало некоторого выравнивания — как стандартов, так и знаний.
В нашей большой команде уже несколько лет существует внутренняя программа обучения — «Академия ИТ». Набор курсов, да и сама методика обучения пережила за несколько лет ряд трансформаций, в итоге от Академии, в плане подхода к образованию, осталось лишь пафосное название. Суть последовательных изменений — переход от накачивания теоретическими знаниями к практическим работам.Мы пробовали можно нанять крутых тренеров, прогнать все команды через тренинги, раздать сертификаты и на выходе не получить ничего существенного, никакого работающего решения. Перезапуск Академии был весьма прагматичным: команды получали в свое распоряжение массу проблем интересные, сложные задачи, ресурсы в виде консультаций внутренних и внешних экспертов, виртуальные площадки для проверки гипотез и экспериментов. К концу «семестра» задачи, например, автоматическая поставка до Production, должны быть решены. Возникла очередь из желающих пройти через такую Академию. Обучение на своей проблематике, что называется, «зашло»: жизненная необходимость внедрить решения и знания, встроить их в свою работу, создало нужную мотивацию и отчислений из Академии практически не было. Прогресс заметен и измерим — ведь метрики DevOps мы тоже внедрили, и накопили некоторую статистику.
Откуда столько гордости в рассказе о некоторых успехах, и, в общем-то, неудачах на пути внедрения DevOps? Если коротко — потому что энтерпрайз. В следующих публикациях очень хочется раскрыть эту тему: системные, масштабные изменения в больших (по меркам ИТ) командах. Мы планируем рассказать про культуру, ту самую, которая ест стратегию на завтрак. Хотим рассказать о технических деталях решений по автоматизации: автотест, CI/CD, автоматическое создание и конфигурирование инфраструктуры, ведь без этого DevOps будет лишь вдохновляющей историей. Много времени ушло на выработку подхода к метрикам DevOps — и про это определенно тоже стоит рассказать. Наконец, интересно узнать, как выглядит пройденный путь глазами разработчика, администратора систем, эксперта из техподдержки — наверняка по-разному. В общем, тема развивается, следите за публикациями, оставляйте комментарии, какая тема вам интереснее, и мы расскажем об этом в первую очередь.
В начале была боль. Была масса проблемных зон, которые беспокоили разные команды, и устранить эти проблемы в существующей парадигме административного деления на кланы «свой-чужой» (разработчик — поддержка) не получалось. Скорость внедрения изменений была никакая — установка важного патча могла занять не один день, что уж говорить про большие релизы… Для проведения тестирования необходимо было поставить изменение на тестовую среду, которой управлял централизованный сервис, но к нему была всегда очередь, и ждать приходилось по несколько дней. Эксперты 44 уровня тратили своё драгоценное время на ручную установку обновлений. Откат обновлений был непредсказуем по времени. Инициатива, не облеченная в форму легального зарегистрированного проекта, могла быть легко похоронена, несмотря на харизму инициатора — в смежных подразделениях тебе могли отказать в любой инициативе, или поставить ее на такую паузу, после которой возвращаться к идее было бессмысленно — рынок «ушёл». С другой стороны, как существовать в большой организации без регламентов, процедур, согласований, всего того, что создавалось для упорядочивания хаоса, а превратилось в бюрократию?
В этой системе координат мы задались целью сократить time to market. На рынке, на тот момент, была остро модной тема DevOps. Как оказалось, история не только про автоматизацию, но про отношения в командах. Мы решили попробовать на себе. Руководители управлений разработки, поддержки и инфраструктуры занялись развитием и продвижением новой идеологии. На ближайшей ИТ-конференции Райфа руководители сказали громкие слова, и обратного пути уже не было — они «подписались» под системообразующими изменениями. Казалось бы, «цели намечены, планы определены, за работу, товарищи» — но всё пошло не так. После слов возникли Мифы… Как на заре человечества, происходящее вокруг наполнялось смыслами, страх заполнял умы, и события воспринимались через призму чужого опыта. В курилках можно было услышать все 50 причин ничего не делать — и не важно, олдскульная сигарета у тебя в руках или вейп и
В конце концов сложившаяся вокруг DevOps мифология была изучена и оформлена в виде сборника.
| Мифы DevOps Райффайзенбанка | |
 |
Мы уже запустили DevOps |
| DevOps это не для серьезных компаний | |
| Девелоперы будут разбираться в инфраструктуре, а инженеры кодить | |
| Команды ITOps будут не нужны, потому что все переедет в облака | |
| Главное при внедрении DevOps — выбрать правильный инструментарий и больше ничего не надо | |
| DevOps для разработчика: теперь можно всё! | |
С каждым менеджером
В результате было сформировано две модели DevOps, которых сегодня придерживаются команды. В них появились новые роли Support Expert и DevSupport expert, которые развивают и эксплуатируют набор сформированных в командах практик, направленных на более детальное погружение коллег в процессы друг друга. Выстраиваются новые договоренности, решаются основные проблемы взаимодействия, высказываются ожидания с обоих сторон.
| Shared DevOps «Общая цель – и скорость, и надежность» |
Embedded DevOps «Все члены команды сфокусированы на продукт» |
| Эта модель является первоочередной и необходимой во всех командах. С каждой стороны Dev + Ops выделяется по одному сотруднику (Support Expert + DevSupport Expert). Модель предполагает общекомандную сосредоточенность на своих целях. Члены команды максимально вовлечены в процессы (Run + Change). Каждый понимает, что он работает над общим продуктом и несет единую ответственность за его стабильность и развитие. |
Эта модель подразумевает наличие DevOps-команды, которая в целом отвечает за развитие и поддержку продукта E2E, каждый член который может выполнять разные роли. Support Expert является членом SCRUM-команды и выделен полностью на все активности данной команды. Такая модель возможна, когда команда разрабатывает достаточно стабильный продукт и объем операционных работ низок, а также если есть такая необходимость со стороны владельца продукта. |
Рассказы о достигнутых результатах на внутренних митапах, сарафанное радио и профессинальная гордыня сделали своё дело — очень быстро все команды начали пробовать автоматизировать тестирование, поставку, сборку.
Сначала были относительно «простые» истории с «правильными» технологиями — с ними справились сами, но на некоторых коробочных монстров пришлось «натравливать» внешних вендоров. Во всех эпизодах огромную роль сыграл внутренний центр компетенций и энтузиазм некоторых коллег: благодаря им удалось раскатать CI/CD даже на динозаврах, по своей сути не приспособленных для автоматизации.
Появились негласные стандарты: то, что зарекомендовало себя как эффективное решение и было согласовано в нашей инфраструктуре. Такие решения можно было раскатать в своей команде очень быстро, не связываясь с согласованиями, бюджетами, закупками, а самое главное — уже имея внутреннюю экспертизу. Что тут началось… На каждой внутренней встрече в ИТ, в каждом выступлении звучали слова про DevOps, про достижения (никто ведь не любит рассказывать о неудачах), начались разработки метрик степени «девопснутости» команды. Те из нас, кто поддерживал продукты с релизами раз в полгода, рефлексировали и оправдывались: дескать, хотелось бы внедрить, но смысла особого нет, трудозатраты не окупятся. Масштабность движения и разнообразие путей и практик потребовало некоторого выравнивания — как стандартов, так и знаний.
В нашей большой команде уже несколько лет существует внутренняя программа обучения — «Академия ИТ». Набор курсов, да и сама методика обучения пережила за несколько лет ряд трансформаций, в итоге от Академии, в плане подхода к образованию, осталось лишь пафосное название. Суть последовательных изменений — переход от накачивания теоретическими знаниями к практическим работам.
Откуда столько гордости в рассказе о некоторых успехах, и, в общем-то, неудачах на пути внедрения DevOps? Если коротко — потому что энтерпрайз. В следующих публикациях очень хочется раскрыть эту тему: системные, масштабные изменения в больших (по меркам ИТ) командах. Мы планируем рассказать про культуру, ту самую, которая ест стратегию на завтрак. Хотим рассказать о технических деталях решений по автоматизации: автотест, CI/CD, автоматическое создание и конфигурирование инфраструктуры, ведь без этого DevOps будет лишь вдохновляющей историей. Много времени ушло на выработку подхода к метрикам DevOps — и про это определенно тоже стоит рассказать. Наконец, интересно узнать, как выглядит пройденный путь глазами разработчика, администратора систем, эксперта из техподдержки — наверняка по-разному. В общем, тема развивается, следите за публикациями, оставляйте комментарии, какая тема вам интереснее, и мы расскажем об этом в первую очередь.