Comments
Одно простое действие очень быстро переводит ИТ подразделение в разряд использующих все эти многочисленные методики.
Стать вместо рядового ИТ подразделения организации внутренним аутсорсером.
Совершенно меняется экономика работы. Теперь вы не поглотители денег внутри организации, а их генератор. Поскольку другим отделам теперь нужно закладывать затраты на свою деятельность в том числе и на ИТ. Бухгалтерия теперь планирует затраты на поддержание работоспособности своей базы, закладывает деньги на ресурсы на что бы обеспечить нужную производительность. Экономисты обосновывают затраты на свои визио и дополнительные сервера для генерации отчетности и олап-кубов. Девелоперы получают лимиты на развертывание виртуалок для тестов.

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

ну так вот… что бы все это обеспечить и нужно понимание ITIL и иже с ними
Все зависит от готовности бизнеса. Все зависит от опыта и влияния ИТ-директора.
Но это реальные изменения, которые переводят ИТ из пассивно-оправдывающейся позиции пожирателей бюджета в глазах собственников в нормальное функционирующее сервисно и клиенто-ориентированное подразделение с реально обоснованной экономикой. Как собственно и должно быть.
Как хорошо что мне не надо больше связываться с ITIL…
DevOps рулит.
Если немного пойти вглубь, devops — это во многом способ переложить всю бюрократию ITIL на роботов.
Управление конфигурациями — в git.
Документация (RTFS) — в git.
Управление изменениями — в git, тестах и мониторинге (если devops дозревший, а не зачаточный).
Опционально заменяем везде выше git на service discovery и контейнеры.

А кое-какие вещи никуда не исчезают типа управления инцидентами и проблемами, и подход ITIL в этом вполне неплох. Главное — его упростить так, чтобы пользоваться можно было без тормозов и не задумываясь, (например, не плодить сущности больше, чем минимально необходимо).
Может у нас разные определения ДевОпс…
Но у нас от проекта зависит гит или шмидт… Ну технологии и методы…

К примеру я джавист много лет, но нынче вот к примеру конфигурировал Firewalls в продакшене длйнашего продукта… и мне нравится вся эта аджайл тема…
Уже не хочется вспоминать как я работл по всяким там ITIL. Я не хочу это все как-то в плохом свете предствлять…
В тех орг. структурах в которых я был раньше это наверно было лучшее… (Опыт не Российский)
Only those users with full accounts are able to leave comments. Log in, please.