В моей карьере я был и разработчиком программного обеспечения, и практикующим ITIL в оперативной должности. Таким образом, DevOps был естественным прогрессом для меня.
Тем не менее, я всегда боролся с узкоспециализированным языком, который вводит ITIL, и сделал его «дружественным к разработчикам» достаточно, чтобы не быть полным отвержением для разработчиков.
ITIL - это международно-признанная структура управления ИТ-услугами, которая была разработана более 30 лет назад как набор практических методов, которые доказали свою эффективность для операционной стабильности и зрелости организации.
Действительно ли DevOps совместимо с ITIL или, по сути, нам нужно взять дух ITIL и «перевести» его на язык, который лучше понимают команды разработчиков:
- Управление инцидентами и проблемами → Производственные дефекты, ошибки или проблемы
- Управление изменениями и выпусками → Непрерывная доставка
- Управление событиями → Ведение журнала, телеметрия, приборостроение и оповещение
terminology
itil
operations
Ричард Слейтер
источник
источник
Ответы:
На мой взгляд, культура DevOps сопровождается изменением методологии в сторону гибкого управления процессами.
ITIL в значительной степени нацелен на четкий формализм процесса и результатов и, таким образом, более адаптирован к модели водопада .
Это не означает, что ITIL несовместим с Devops, но обычно это два отдельных процесса с разными временными рамками. Я имею в виду, что включение нового продукта в ссылочный ITIL обычно откладывается до тех пор, пока продукт / приложение не будет выпущено в производство на некоторое время, когда были сделаны ранние ошибки и некоторая документация, необходимая для интеграции ITIL, после того, как продукт будет " прямой эфир".
Одной из вещей в ITIL является Service Design, который, как предполагается, определяется перед любой задачей разработки, гибкий процесс будет / может проверять дизайн в каждой итерации, нарушая формализм, необходимый в процессе ITIL.
Как вы сказали, главной целью ITIL является создание структуры, гарантирующей, что между фазой проектирования / разработки и обслуживания (Build / Run) ничего не пропущено. В культуре devops вся команда отвечает за все этапы в долгосрочной перспективе, поэтому формализм сокращен.
Это не значит, что мы должны забыть ITIL, основные принципы абсолютно хороши и, на мой взгляд, должны использоваться в качестве контрольного списка для создания первоначального отставания продукта. Просто следование принципу ITIL со всем его формализмом идет вразрез с целью сокращения времени на рынке быстрой итеративной разработки программного обеспечения, а иногда даже не применимо, поскольку между командами требуется меньше передачи информации, поскольку задачи выполняются одной командой ,
источник
Я сертифицирован ITIL (хотя это было давно.) Я согласен с Tensibai: ITIL и DevOps не являются несовместимыми , но это не обязательно делает их хорошими друзьями.
Можно привести аргумент, что процессы в ITIL должны происходить каким-то образом, особенно для крупных организаций. Успешная интеграция практик DevOps, где ITIL уже практикуется, требует тщательного планирования, коммуникации и выполнения. Опять же, это верно для любой трансформации DevOps.
Для преобразования «с нуля», где нет ни ITIL, ни DevOps, я бы разработал комбинацию обоих, используя терминологию «сопоставленных», как вы описали. Пока все в организации находятся на одной и той же странице, используя один и тот же язык, ITIL и DevOps могут повысить ценность при объединении.
источник
Мне понравились ответы , предоставляемые ИТ - скептика на эпизоде из DevOpsCafe.org Если я помню правильно, его образ мышления в том , что если вы на самом деле действительно понять ITIL, есть очень мало конфликтов. То, что большинство рекомендаций ITIL являются очень общими, и что конфликты в значительной степени возникают между некоторыми реализациями ITIL, а не за фактической спецификацией.
источник