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

Модели изменений в контексте DevOps

Опубликовано 3 июня 2016
Рубрики: Управление изменениями
Комментарии

Teams_1Концепция DevOps всё больше проникает в умы руководителей и сотрудников ИТ-подразделений, а также в наши заметки на портале REALITSM. Это не удивительно, ведь с трудностями при организации взаимодействия подразделений "Dev" и "Ops" так или иначе сталкиваются почти все, у кого есть программное обеспечение заказной разработки. Мы регулярно помогаем нашим заказчикам решать задачи интеграции деятельности департаментов разработки и поддержки в рамках процессов управления инцидентами/запросами и управления изменениями (о нём и пойдёт речь дальше), поэтому знаем о возникающих проблемах не понаслышке. Поэтому никак не можем остаться в стороне от концепции, призванной данные проблемы решать.

На всякий случай сразу уточню – при этом мы ни в коем случае не сторонники что-либо скоропалительно выбрасывать. А уж тем более методологию, которая себя оправдала в большом количестве компаний в разных странах. Речь про ITIL, конечно. На просторах Сети доводилось видеть комментарии вроде: "ITIL – устаревшая методология, которая скоро уступит место DevOps". Одновременно где-то на близлежащих страницах я находил примерно такие: "Почитал тут ITIL, так представляете, хоть и старьё по сравнению с нашим DevOps, а мысли умные есть". Получается, как и с любой актуальной для своего времени идеей, важно не поддаться тяге всё разрушить до основания и заново построить. К счастью все (или почти все) уже всё правильно поняли. Поняли, что двигаться надо в сторону бимодальных, а ещё вернее – "многоскоростных" ИТ, в работе которых разные услуги, скажем так, "предоставляются с разной скоростью". И для каких-то услуг и систем приоритетным требованием останется стабильность, то есть изменения будут внедряться по классической схеме ITIL.

Здесь, видимо, следует уточнить, как я себе понимаю ключевые отличия двух подходов.

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

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

В силу объективных и не очень причин не все услуги и системы целесообразно сопровождать с использованием подхода DevOps. Как раз об этом упомянутая "бимодальность". Значит надо так организовать процесс управления изменениями, чтобы он обеспечивал возможность реализации изменений по разным сценариям – нацеленным на гибкость или стабильность. Говорят, что чудес не бывает. Видимо, и в этом случае не стоит сильно на них рассчитывать. Совсем уж единым процесс, скорее всего, не получится. Выходов, по большому счёту, всего два:

  1. отдельные процессы управления изменениями, разделённые по какому-либо критерию; скорее всего в роли критерия будет ИТ-услуга или ИТ-система;
  2. единый высокоуровневый процесс и набор моделей изменений.

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

Что думаете по этому поводу, коллеги? Какой у вас на эту тему есть опыт?

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM