DevOps в Райффайзенбанке: фаза полета
Про DevOps не рассказывает только ленивый. Некоторые компании внедряют эти практики, а подавляющее большинство присматривается в поисках next big thing или «серебряной пули», ну или просто поддавшись тенденции в ИТ-сообществе. Уникальность каждого случая, поиск собственного пути, опасения сделать хуже (принцип Гиппократа «не навреди») — всё это не способствует ускорению внедрения, лишь добавляя ступеньки на пути к совершенству ИТ. Мы хотим рассказать про свой путь, извилистый и пока не пройденный до конца.
В начале была боль. Была масса проблемных зон, которые беспокоили разные команды, и устранить эти проблемы в существующей парадигме административного деления на кланы «свой-чужой» (разработчик — поддержка) не получалось. Скорость внедрения изменений была никакая — установка важного патча могла занять не один день, что уж говорить про большие релизы… Для проведения тестирования необходимо было поставить изменение на тестовую среду, которой управлял централизованный сервис, но к нему была всегда очередь, и ждать приходилось по несколько дней. Эксперты 44 уровня тратили своё драгоценное время на ручную установку обновлений. Откат обновлений был непредсказуем по времени. Инициатива, не облеченная в форму легального зарегистрированного проекта, могла быть легко похоронена, несмотря на харизму инициатора — в смежных подразделениях тебе могли отказать в любой инициативе, или поставить ее на такую паузу, после которой возвращаться к идее было бессмысленно — рынок «ушёл». С другой стороны, как существовать в большой организации без регламентов, процедур, согласований, всего того, что создавалось для упорядочивания хаоса, а превратилось в бюрократию?
В этой системе координат мы задались целью сократить time to market. На рынке, на тот момент, была остро модной тема DevOps. Как оказалось, история не только про автоматизацию, но про отношения в командах. Мы решили попробовать на себе. Руководители управлений разработки, поддержки и инфраструктуры занялись развитием и продвижением новой идеологии. На ближайшей ИТ-конференции Райфа руководители сказали громкие слова, и обратного пути уже не было — они «подписались» под системообразующими изменениями. Казалось бы, «цели намечены, планы определены, за работу, товарищи» —, но всё пошло не так. После слов возникли Мифы… Как на заре человечества, происходящее вокруг наполнялось смыслами, страх заполнял умы, и события воспринимались через призму чужого опыта. В курилках можно было услышать все 50 причин ничего не делать — и не важно, олдскульная сигарета у тебя в руках или вейп и борода.
В конце концов сложившаяся вокруг DevOps мифология была изучена и оформлена в виде сборника.
| Мифы DevOps Райффайзенбанка | |
 |
Мы уже запустили DevOps |
| DevOps это не для серьезных компаний | |
| Девелоперы будут разбираться в инфраструктуре, а инженеры кодить | |
| Команды ITOps будут не нужны, потому что все переедет в облака | |
| Главное при внедрении DevOps — выбрать правильный инструментарий и больше ничего не надо | |
| DevOps для разработчика: теперь можно всё! |
С каждым менеджером кто боялся спать без света встречались и объясняли, что особых причин для опасений нет, и критерий обеспечения job security как всегда один — отличный рабочий результат. Тем временем, то есть стихийно и чуть раньше:), инициатива возникла и стала развиваться самими сотрудниками — самыми вовлеченными, теми, кому не всё равно. Стабильно работающего продукта при частых поставках релизов, да и саму поставку с высокой частотой в текущих условиях получить было трудно. Нужно было менять подход к задаче, определять правила взаимодействия и роли, расширять границы ответственности — без фанатизма конечно.
В результате было сформировано две модели 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, про достижения (никто ведь не любит рассказывать о неудачах), начались разработки метрик степени «девопснутости» команды. Те из нас, кто поддерживал продукты с релизами раз в полгода, рефлексировали и оправдывались: дескать, хотелось бы внедрить, но смысла особого нет, трудозатраты не окупятся. Масштабность движения и разнообразие путей и практик потребовало некоторого выравнивания — как стандартов, так и знаний.
В нашей большой команде уже несколько лет существует внутренняя программа обучения — «Академия ИТ». Набор курсов, да и сама методика обучения пережила за несколько лет ряд трансформаций, в итоге от Академии, в плане подхода к образованию, осталось лишь пафосное название. Суть последовательных изменений — переход от накачивания теоретическими знаниями к практическим работам. Мы пробовали можно нанять крутых тренеров, прогнать все команды через тренинги, раздать сертификаты и на выходе не получить ничего существенного, никакого работающего решения. Перезапуск Академии был весьма прагматичным: команды получали в свое распоряжение массу проблем интересные, сложные задачи, ресурсы в виде консультаций внутренних и внешних экспертов, виртуальные площадки для проверки гипотез и экспериментов. К концу «семестра» задачи, например, автоматическая поставка до Production, должны быть решены. Возникла очередь из желающих пройти через такую Академию. Обучение на своей проблематике, что называется, «зашло»: жизненная необходимость внедрить решения и знания, встроить их в свою работу, создало нужную мотивацию и отчислений из Академии практически не было. Прогресс заметен и измерим — ведь метрики DevOps мы тоже внедрили, и накопили некоторую статистику.
Откуда столько гордости в рассказе о некоторых успехах, и, в общем-то, неудачах на пути внедрения DevOps? Если коротко — потому что энтерпрайз. В следующих публикациях очень хочется раскрыть эту тему: системные, масштабные изменения в больших (по меркам ИТ) командах. Мы планируем рассказать про культуру, ту самую, которая ест стратегию на завтрак. Хотим рассказать о технических деталях решений по автоматизации: автотест, CI/CD, автоматическое создание и конфигурирование инфраструктуры, ведь без этого DevOps будет лишь вдохновляющей историей. Много времени ушло на выработку подхода к метрикам DevOps — и про это определенно тоже стоит рассказать. Наконец, интересно узнать, как выглядит пройденный путь глазами разработчика, администратора систем, эксперта из техподдержки — наверняка по-разному. В общем, тема развивается, следите за публикациями, оставляйте комментарии, какая тема вам интереснее, и мы расскажем об этом в первую очередь.
