company_banner

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 — и про это определенно тоже стоит рассказать. Наконец, интересно узнать, как выглядит пройденный путь глазами разработчика, администратора систем, эксперта из техподдержки — наверняка по-разному. В общем, тема развивается, следите за публикациями, оставляйте комментарии, какая тема вам интереснее, и мы расскажем об этом в первую очередь.
    Райффайзенбанк 222,58
    Компания
    Поделиться публикацией
    Комментарии 14
    • +1

      Дико извиняюсь за оффтоп, из какого фильма кпдв?

    • +9
      Введение в тему — это, конечно же, хорошо, но на техническом ресурсы хочется не воды, а конкретики :)

      Было бы интересно услышать про выбранные решения для доставки продукта, управления кластерами и контейнерами, CI/CD и вот это всё.
      • +6
        Согласен. Очередная публикация про DevOps ни о чём.
        • 0

          Обязательно раскроем эту тему в следующих наших постах!

        • 0

          Спасибо за подробный рассказ.


          Как вы девопсите на pci-dss периметре? Секьюрити правила для зон где хранится и обрабатывается платежная информация как будто специально сделаны чтобы усложнить коммуникацию опсов и девелоперов.

          • 0
            По-крайней мере у себя, не замечал ситуации, где pci-dss влияет на коммуникацию.
            • 0

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


              Очень странно что у вас не влияет. Расскажите про девопс в pcidss по подробнее если затрагивали этот кусок.

          • –1
            Заинтригован, продолжайте, будет интересно почитать как вы реализовывали мониторинг успешности релизов (авто-тесты, health-checking приложений после вывода и т.п.), для больших legacy монолитов это всегда больная тема.
            Метрики DevOps тоже крайне интересуют, что вы вкладываете в понятие успешного внедрения DevOps.
            • 0

              Спасибо за вопрос. Обязательно эту тему тоже раскроем в одной из следующих статьях.

            • +3
              Что нового вносит статья для понимания DevOps? И как можно сравнить ваше внедрение, с внедрением оного, например, в СБТ?
              • 0

                Целью данной статьи не было "открыть Америку" в мир DevOps. Мы лишь хотим поделиться своим опытом, опытом внедрения DevOps в масштабах энтерпрайз. Что касается вопроса сравнения с СБТ, то это другая история, к примеру, у нас другой подход с культурно-организационной точки зрения. В следующих статьях мы про это расскажем.

                • 0
                  Это в рамках одной статьи и надо было писать, зачем плодить статьи
              • 0

                Интересно почитать про DevOps "динозавров" непригодных для автоматизации.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое