Как стать автором
Обновить

Комментарии 27

Ни в коем случае не осуждаю, но я и без знания ITIL следую таким принципам, есть вещи которые приходят с опытом, а есть в ITIL и определенные глупости, которые в России не применимы на практике. Проще говоря ему не нужно слепо следовать, но знать его «большая честь».
Видите ли, я тоже был уверен, что всё делаю правильно, всё знаю и т.д.
Практика показала обратное. Хотя мне есть чем похвастаться из своего опыта.
У меня ITIL связанно забавное предсказание преподавателя читавшего курсы — «50% слушателей в течение полугода меняют место работы, дабы раскрыть весь свой потенциал с учётом свежеполученных здесь знаний». Я действительно поменял в срок менее полугода)
В итоге компании на 10-500 ПК остаются без ITIL? :)
смена работы — это амбиции. реализовать их получилось в итоге?
Да, ушёл на должность зама.по информационным технологиям, а через год открыл своё ооо.
ооо — услуги саппорта и внедрение?
да
и как?
открыть ооо — это формальность на самом деле.
каков итог?
Отличная статья. Только исправьте «прийдёт»
НЛО прилетело и опубликовало эту надпись здесь
ITIL устарел и зачастую больше вредит. Не все сразу, но большие части. Бизнес слишком быстро развивается и много требует, взгляд на него кардинально поменялся за 20 лет.
DevOps — вот будущее.

Возьмем, например, change management, чтобы не быть голословным.
Нужно изменить конфигурацию сервера, ввести новый сервис, новую фичу — нужен план, его необходимо утвердить, применить, обновить документацию и прочие бюрократические штуки.
Разработчики у нас релизятся несколько раз в день. Чтобы поддержать только документацию в актуальном состоянии — нужна прорва времени. Еще время на утверждение, внедрение, тестирование и прочее.

Времени нет совсем. Если мы будем тратить его на бюрократию, конкуренты нас сомнут и съедят.

Есть система автодеплоя, инструкции которой и служат собственно документацией, а разработка и эксплуатация работает в таких экосистемах, где все автотестится и автодеплоится. Каждый разработчик немного админ и осознает, что он кодит и как это повлияет на экосистему. Каждый админ осознает, как работает этот код и что будет с экосистемой после релиза. Все автоматизировано. Это работает.
backup — ну, он не нужен. Точнее он почти не нужен, весь код децентрализован и хранится распределенно в системе контроля версии. Исходные данные тоже нужно бекапить. И все ))
Упала виртуалка, две, три, сервер, второй, третий. Это неважно. Деплой запускается быстро на других нодах. Нет ноды — он полетит в коммерческое облако. Данные избыточны и легко восстановимы. Вместо 300 единиц всего мы бекапим только две и самое важное там.
Какие ноды? Какой деплой? Какой код? Милости просим на производство, в торговлю, в мир 1с, офиса, принтеров, клиент-банков с глючными апами. Ваше веяние напоминает ранний линукс. Когда все говорили о чуде, которого не случилось. ИМХО
На этом IT кончается, остальное — баловство? А как же стартапы и новые продукты, например, которые надо успеть сделать вчера.
Разные направления, разные задачи, разные инструменты. Строителю строительное, электрику электрическое, врачу врачевное.
Время всё решило.
В ITILv4 есть раздел DevOps
В ИТ кардинальная смена будущего приходит с изменениями и лидеров рынка и изменениями лидеров рынка.
Тоесть, пока НР работает по ITIL и рекомендует его, целесообразно не придумывать велосипед.
Дело ведь не в том, американская вилка и розетка лучше, или европейская. Нужна та, которая применима здесь и сейчас.
Нельзя же подойти и сказать бизнесу — извините, мы не можем развиваться так быстро, как вы хотите, потому что HP рекомендует работать по другому плану.
Это не велосипед, это — эволюция. Не всем это пока надо, но успешным компаниям, которые развиваются и конкурентноспособны — почему нет )
Я вижу в ITIL оптимизацию и снижение хобота. В размерах тех компаний, с которыми у меня есть опыт работы, ИТ развивается быстрее.
Давайте поговорим об инцидентах.
ITIL предлагает в качестве инструмента для объективного указания приоритета параметры, срочность и влияние.

У нас есть первая линия, хелпдеск, которая должна объективно определить срочность. Как? Со слов пользователя?

У пользователя для всех его заявок всегда один и тот же приоритет. Точнее целый набор: «жить не могу», «сверхсрочно» и «сделать вчера!».

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

Среднестатистический helpdesk вообще слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях; если это конечно не услуги вида: «рабочее место», «печать» или «электронная почта». Да и не обязан, кстати.

Влияние? Та же песня. Зачастую невозможно определить влияние инцидента до полного его расследования.

Не работает. Необъективно ) Только для тихой рощицы торговли и чего вы там еще назвали. И то с натяжкой.
Ну да, торговля и производство тихая рощица.
К сожалению, IT на них не заканчивается. И это очень малая часть. И там очень тихо и можно позволить себе ITIL.

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

И там тоже есть среднестатистические админы )
вы хорошо понимаете что разработчики и софт это где-то 2, максимум 3% от всего мира? и это очень оптимистическая оценка.
Улыбнуло.
Основываясь на ваших комментариях, я сперва подумал, что DevOps — методология, не так давно придуманная очень маленькой группой людей. Относится по большей части к разработке и тому, что с ней связано, и не касается очень многих процессов ИТ.
А потом почитал в инете и понял, что так оно и есть.
Предполагаю, что это очень удобная методика и авторы её молодцы.
Но глупо сравнивать кирпич, бревно и пенопласт.
ITIL — это сборник практик. Рекомендаций. На каждый шаг он даёт советы, основываясь на лучшем опыте.
И применять можно и нужно то, что подходит в каждом конкретном случае.
Полагаю, со временем DevOps вполне претендует стать одной из книг ITIL.
Правильно написано) Сам постепенно прихожу к некоторым методикам, которые описаны в ITIL. Даже документация в локальной wiki. Просто в один момент задумался о том, что через n-ое количество времени я тупо забуду как настраивал тот или иной сервис.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории