Концепция DevOps всё больше проникает в умы руководителей и сотрудников ИТ-подразделений, а также в наши заметки на портале REALITSM. Это не удивительно, ведь с трудностями при организации взаимодействия подразделений "Dev" и "Ops" так или иначе сталкиваются почти все, у кого есть программное обеспечение заказной разработки. Мы регулярно помогаем нашим заказчикам решать задачи интеграции деятельности департаментов разработки и поддержки в рамках процессов управления инцидентами/запросами и управления изменениями (о нём и пойдёт речь дальше), поэтому знаем о возникающих проблемах не понаслышке. Поэтому никак не можем остаться в стороне от концепции, призванной данные проблемы решать.
На всякий случай сразу уточню – при этом мы ни в коем случае не сторонники что-либо скоропалительно выбрасывать. А уж тем более методологию, которая себя оправдала в большом количестве компаний в разных странах. Речь про ITIL, конечно. На просторах Сети доводилось видеть комментарии вроде: "ITIL – устаревшая методология, которая скоро уступит место DevOps". Одновременно где-то на близлежащих страницах я находил примерно такие: "Почитал тут ITIL, так представляете, хоть и старьё по сравнению с нашим DevOps, а мысли умные есть". Получается, как и с любой актуальной для своего времени идеей, важно не поддаться тяге всё разрушить до основания и заново построить. К счастью все (или почти все) уже всё правильно поняли. Поняли, что двигаться надо в сторону бимодальных, а ещё вернее – "многоскоростных" ИТ, в работе которых разные услуги, скажем так, "предоставляются с разной скоростью". И для каких-то услуг и систем приоритетным требованием останется стабильность, то есть изменения будут внедряться по классической схеме ITIL.
Здесь, видимо, следует уточнить, как я себе понимаю ключевые отличия двух подходов.
Как говорят про ITIL, "он принёс порядок туда, где ранее был хаос, но в некоторых случаях его формальность и негибкость зашли слишком далеко". Как мы все знаем, упомянутая "классическая" схема, по сути, является отражением "водопадной" концепции. По большому счёту, основная задача такого процесса – защита продуктивной среды, обеспечение стабильности. Схема достаточно инертна и бюрократична, следует принципу "семь раз отмерь – один отрежь" или "тише едешь – дальше будешь".
Подход DevOps, в свою очередь, – это динамичная схема, в которой на первом месте те самые быстро меняющиеся приоритеты бизнеса, а защита должна обеспечиваться с помощью максимальной автоматизации тестирования и развёртывания. Ну а также за счёт объединения людей в кросс-функциональные команды и плотного вовлечения заказчика, что на выходе (вроде как) даёт общее повышение скорости поставки результата. То есть возникшую проблему просто быстро устраняем, а за счёт частых релизов – сразу выкладываем код в продуктив.
В силу объективных и не очень причин не все услуги и системы целесообразно сопровождать с использованием подхода DevOps. Как раз об этом упомянутая "бимодальность". Значит надо так организовать процесс управления изменениями, чтобы он обеспечивал возможность реализации изменений по разным сценариям – нацеленным на гибкость или стабильность. Говорят, что чудес не бывает. Видимо, и в этом случае не стоит сильно на них рассчитывать. Совсем уж единым процесс, скорее всего, не получится. Выходов, по большому счёту, всего два:
- отдельные процессы управления изменениями, разделённые по какому-либо критерию; скорее всего в роли критерия будет ИТ-услуга или ИТ-система;
- единый высокоуровневый процесс и набор моделей изменений.
Второй вариант видится предпочтительным, так как позволяет обеспечить гибкость в контролируемых пределах. В "гибкую" ветку процесса придётся интегрировать те же этапы, что содержит высокоуровневый процесс. Но поскольку два подхода существенно отличаются, напрашиваются две мета-модели – "гибкая" и "стабильная". Производными от них будут модели изменений по отдельным услугам. Возможен также вариант двух отдельных процессов ("гибкий"/"стабильный"), каждый со своим набором моделей.
Что думаете по этому поводу, коллеги? Какой у вас на эту тему есть опыт?
