Чи сумісний DevOps з ITIL?

У своїй кар’єрі я був як розробником програмного забезпечення, так і практиком ITIL в операційній ролі. Таким чином, DevOps був для мене природним прогресом.
Однак я завжди боровся з вузькоспеціалізованою мовою, яку впроваджує ITIL, і робить це "Доступним для розробників" достатньо, щоб не було повним відключенням для розробників.

ITIL - це міжнародно визнана структура управління послугами ІТ, розроблена протягом 30 років як сукупність практик, які мають доведену користь для стабільності роботи та зрілості організації.

Чи справді DevOps сумісний з ITIL, чи, по суті, нам потрібно перейняти дух ITIL і "перекласти" його на мову, що краще розуміється командами розробників:

• Управління випадками та проблемами → Дефекти виробництва, помилки або проблеми
• Управління змінами та випуском → Постійна доставка
• Управління подіями → Ведення журналів, телеметрія, приладобудування та оповіщення

На мій погляд, культура DevOps поєднується із зміною методології до управління процесами Agile .
ITIL сильно спрямований на чіткий формалізм процесу та результатів і, таким чином, більше адаптується до моделі Водоспаду .

Це не означає, що ITIL несумісний з Devops, але зазвичай це два окремі процеси з різними термінами. Я маю на увазі, що включення нового продукту в референс ITIL зазвичай затримується до тих пір, поки продукт / додаток не буде випущений у виробництво на деякий час, коли ранні підводні камені та деяка документація, необхідна для інтеграції ITIL, були зроблені та адаптовані після того, як продукт " жити ».

Одне з речей ITIL - це Сервісний дизайн, який, як передбачається, визначається перед будь-якою задачею розробки, спритний процес буде / може переглянути дизайн у кожній ітерації, порушуючи формалізм, необхідний у процесі ITIL.

Головною метою ITIL є, як ви вже сказали, створення рамки для того, щоб нічого не було пропущено між етапом проектування / задуму та обслуговування (Build / Run). У культурі девепса весь колектив відповідає за всі етапи довгостроково, тому формалізм зменшується.

Це не означає, що ми повинні забувати ITIL, основні принципи абсолютно хороші, і, на мою думку, слід використовувати як контрольний список для створення початкового відставання продукту. Це просто те, що слідування принципу ITIL з усім його формалізмом йде проти часу досягнення мети скорочення ринку швидкої ітеративної розробки програмного забезпечення, а іноді навіть не застосовується, оскільки менше передачі інформації, необхідної між командами, оскільки завдання виконує одна і та ж команда .

Я сертифікований ITIL (хоча минув час.) Я погоджуюся з Tensibai: ITIL і DevOps не несумісні , але це не обов'язково робить їх чудовими друзями.

Можна стверджувати, що процеси в ITIL повинні відбуватися якимось чином, особливо для великих організацій. Для успішної інтеграції практик DevOps, де ITIL вже практикується, потрібні ретельне планування, спілкування та виконання. Знову ж таки, це стосується будь-якої трансформації DevOps.

Для трансформації "greenfield", де немає ITIL або DevOps, я б створив комбінацію обох, використовуючи "відображену" термінологію, як ви описали. Поки всі в організації знаходяться на одній сторінці, використовуючи одну і ту ж мову, ITIL та DevOps можуть додавати цінність у поєднанні.

Мені сподобалися відповіді , що надаються ІТ - скептика на епізоді з DevOpsCafe.org Якщо я пам'ятаю правильно, його образ мислення в тому , що якщо ви на самому справі дійсно зрозуміти ITIL, є дуже мало конфліктів. Що більшість керівних принципів ITIL є дуже загальними і що конфлікти знаходяться в значній мірі між деякими впровадженнями ITIL, а не за фактичними специфікаціями.