Портал №1 по управлению цифровыми
и информационными технологиями

Кто отвечает за конвейер развёртывания?

Нужно очень сильно отстать от жизни (примерно лет на 5-7, что по нынешним временам приравнивается к вечности), либо иметь крайне веские аргументы, чтобы не использовать для доставки готового кода до среды эксплуатации конвейер развёртывания (в народе часто именуемый конвейером CI/CD, что в данном случае непринципиально).

Простейший конвейер согласно Дж.Хамблу и Д.Фарли

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

Организационная же сторона вопроса не так проста, как кажется. Кто должен/может его создать? Кто обеспечит функционирование? Кто починит, когда сломается? Кто будет его постоянно улучшать, когда требуется? Кто очередной раз придумает, как сделать, чтобы он работал ещё быстрее? Кажется, что вопросов много, но, похоже, он один — кто отвечает за конвейер развёртывания?

Жизнь (иногда ещё говорят — опыт) подсказывает следующие возможные варианты ответов для средних и крупных предприятий:

  1. Никто
  2. Специальный отдел создания и обеспечения работоспособности конвейеров
  3. Отдел администрирования ИТ-систем
  4. Один из центров компетенции по технологиям (пригодно для матричной структуры)
  5. Специальный человек внутри продуктовой команды
  6. Вся продуктовая команда

Рассмотрим эти варианты.

Первый отметаем сразу: при том, что встречается он с завидной регулярностью (то есть — может показывать текущий уровень зрелости разработки ПО), вряд ли можно его считать целевым состоянием.

Второй вариант (спец.отдел) вполне возможен для случаев, когда, к примеру, над изменением ИТ-ландшафта трудятся несколько десятков очень схожих между собой команд, как по применяемым технологиям, так и по структуре собственно команд. Преимущество варианта — экономия ресурсов и стремительный рост компетенции именно в деле построения конвейеров. Недостаток — организационное разграничение ответственности в вопросе, который сильно влияет на качество и скорость работы команд; такое разграничение создаёт очередной административный барьер, а значит — замедляет и снижает качество.

Третий вариант (отдел администрирования), казалось бы, не отличается от предыдущего — речь всё ещё про отдельное структурное подразделение. Ан нет, существенное отличие есть. В предыдущем варианте мы имеем отдельное разделяемое между командами подразделение, в этом варианте таким подразделением является блок эксплуатации. Недостаток, связанный с построением административного барьера, становится слишком негативным, ведь мы таким образом разрушаем всю идею DevOps: Ops не должен быть отдельно от Dev.

Четвёртый вариант (один из центров компетенций) может быть вполне рабочим для случаев, когда применяемых технологий не очень много. В матричной структуре центр компетенций обеспечивает количество и качество ресурса (простите за цинизм), а также технологическую поддержку. Построение конвейера — один из технологических вопросов, который может находиться в зоне ответственности центра компетенций. Например, для web-технологий конвейеры строятся одним образом, а для, простите, 1С — другим.

Пятый вариант (один из участников продуктовой команды) похож на первый в том смысле, что он вполне может быть текущим состоянием, но вряд ли — целевым. Нам не интересно, чтобы один мегаэксперт в команде знал, как устроен наш конвейер. Нам нужно, чтобы это знание было общим, и ответственность за работу в целом, и за скорость работы в частности, была общей.

Наконец, за последний вариант (вся команда) будут агитировать все международные эксперты вместе со всемирным разумом: команда, скажут они, должна сама отвечать за свои инструменты. И быть самоорганизующейся. И все внутри — взаимозаменяемыми, T-shaped, вот это вот всё. Спору нет, красивая картинка, плюсов в ней много.

Мне же представляется, что всё чуть-чуть интереснее. Помните, в самом начале при постановке вопроса, я сделал оговорку — для средних и крупных предприятий? Это важный момент. Представим, что у нас трудится под сотню продуктовых команд. Предположим, что текущее состояние, как у многих, плачевно — где-то что-то есть, но на скоростные конвейеры похоже не очень, словосочетание Continouos Integration всеми произносится, но мало кем понимается, а за слова Trunk based development разработчики готовы вступать в драку. В таком случае тратить время на отдельное построение конвейеров в каждой команде нерационально. Хуже того, эта дорога никогда не будет пройдена. Можно год заниматься агитацией и пропагандой здорового образа жизни, но вот вести этот самый здоровый образ через год будет лишь десяток команд, но не все, и даже не большинство (что любопытно — заявлять «у нас всё уже давно есть» будут, наверное, почти все; см. эффект Даннинга-Крюгера).

Более перспективным вариантом является комбинация 4 и 6: центр компетенций отвечает за идеологию, обучение, устранение технических ограничений и создание шаблонов конвейеров, а продуктовые команды отвечают за «экземпляры» конвейеров, которые они применяют. Центры компетенций смогут и объяснить что такое хорошо, и помочь это хорошо получить (и даже — проконтролировать), а команды берут на себя полную ответственность с помощью привнесённой компетенции теперь делать дело, и делать его правильным образом.

При таком раскладе счастье в вопросе конвейеров развёртывания может быть достигнуто в разумной временной перспективе.


Но это, разумеется, не конец истории. Всё становится ещё интереснее, когда и если структура изменится от component based teams в сторону feature based teams. Почему интереснее и как с этим быть мы рассмотрим как-нибудь в следующий раз. А пока приглашаю всех, дочитавших до этого места, на наш учебный курс «Основы DevOps», на котором мы обсуждаем ровно такие управленческие вопросы.

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • FinOps с помощью Governance-as-Code
      Масштабы и сложность решений, основанных на облачных технологиях, продолжают расти. Слишком часто это расширение также означает, что затраты продолжают выходить из-под контроля. В
    • Применима ли концепция «сдвиг влево» (shift left) для инженеров по надёжности систем (SRE)?
      Концепция «сдвига влево» помогает упростить некоторые аспекты разработки программного обеспечения. Но предназначена эта концепция не только для разработчиков. Она
    • Метрики потока создания ценности
      Свой первый отчёт с данными о работе процесса в ИТ я сделал где-то в самом конце 90-х годов. Я тогда работал в поддержке, мне было важно понять как быстро мы выполняем заявки,
    • Я понял только то, что ничего не понял
      На тему услуг написано довольно много самых разных статей, т.к. оказание услуг – самый распространенный вид человеческой деятельности. Банковские услуги, гостиничные услуги, юридические услуги, логистические услуги; парикмахер, курьер, айтишник – все это деятельность в сфере услуг. Моя работа тоже относится к этой же сфере, поэтому не могу не поделиться своими наблюдениями, или, как говорится, поговорить о наболевшем.
    • DevOps-путешествие American Airlines
      Несколько лет назад компания American Airlines начала путешествие, которое первоначально было направлено на преобразование DevOps в ИТ, но в дальнейшем набирало обороты и переросло в преобразование доставки продуктов, охватывающее весь бизнес.
    • Чтение признаков: Паттерны диаграммы рассеяния (Lead Time Scatterplot)
      Научившись определять общие закономерности в диаграмме рассеяния времени цикла, вы сможете заметить проблемные области до того, как они разрастутся. Сегодня мы покажем вам, как распознать наиболее распространенные модели диаграммы рассеяния и объясним, что они означают для вашего проекта.
    • Проблемные зоны цифровой трансформации
      Управление на основе гибких методологий подразумевает наличие гибкой команды, занимающейся развитием цифрового продукта. Однако, такие команды не возникают сами собой, их
    • Чтение знаков: Паттерны Канбан CFD
      Чтобы улучшить рабочие процессы, сначала нужно понять, как определить проблемные области. Метод Канбан использует визуальные методы для оценки ваших процессов. Диаграмма совокупных потоков Канбан является особенно мощным инструментом. На них фиксируется количество задач в каждом состоянии процесса через регулярные промежутки времени, как правило, ежедневно или еженедельно.
    • Краткое руководство по DevOps для не ИТ-руководителя бизнеса
      Тщательно продумайте, как выглядит успех. В цифровом мире это скорость, гибкость, контроль и оперативность, а не составление планов и следование им. Именно эти новые ИТ-практики принесут вам эти преимущества. Они уже принесли их многим другим предприятиям, которые встали на этот путь и, в некоторых случаях, разрушили отрасли.
    • 8 тенденций развития IT Service Desk в 2022 году
      Корпоративная служба поддержки ИТ в настоящее время находится в «идеальном шторме» для изменений или, точнее, в «идеальном шторме» для необходимости изменений. Случилось так
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT