Comments 27
Ни в коем случае не осуждаю, но я и без знания ITIL следую таким принципам, есть вещи которые приходят с опытом, а есть в ITIL и определенные глупости, которые в России не применимы на практике. Проще говоря ему не нужно слепо следовать, но знать его «большая честь».
У меня ITIL связанно забавное предсказание преподавателя читавшего курсы — «50% слушателей в течение полугода меняют место работы, дабы раскрыть весь свой потенциал с учётом свежеполученных здесь знаний». Я действительно поменял в срок менее полугода)
Отличная статья. Только исправьте «прийдёт»
UFO just landed and posted this here
ITIL устарел и зачастую больше вредит. Не все сразу, но большие части. Бизнес слишком быстро развивается и много требует, взгляд на него кардинально поменялся за 20 лет.
DevOps — вот будущее.
DevOps — вот будущее.
Возьмем, например, change management, чтобы не быть голословным.
Нужно изменить конфигурацию сервера, ввести новый сервис, новую фичу — нужен план, его необходимо утвердить, применить, обновить документацию и прочие бюрократические штуки.
Разработчики у нас релизятся несколько раз в день. Чтобы поддержать только документацию в актуальном состоянии — нужна прорва времени. Еще время на утверждение, внедрение, тестирование и прочее.
Времени нет совсем. Если мы будем тратить его на бюрократию, конкуренты нас сомнут и съедят.
Есть система автодеплоя, инструкции которой и служат собственно документацией, а разработка и эксплуатация работает в таких экосистемах, где все автотестится и автодеплоится. Каждый разработчик немного админ и осознает, что он кодит и как это повлияет на экосистему. Каждый админ осознает, как работает этот код и что будет с экосистемой после релиза. Все автоматизировано. Это работает.
Нужно изменить конфигурацию сервера, ввести новый сервис, новую фичу — нужен план, его необходимо утвердить, применить, обновить документацию и прочие бюрократические штуки.
Разработчики у нас релизятся несколько раз в день. Чтобы поддержать только документацию в актуальном состоянии — нужна прорва времени. Еще время на утверждение, внедрение, тестирование и прочее.
Времени нет совсем. Если мы будем тратить его на бюрократию, конкуренты нас сомнут и съедят.
Есть система автодеплоя, инструкции которой и служат собственно документацией, а разработка и эксплуатация работает в таких экосистемах, где все автотестится и автодеплоится. Каждый разработчик немного админ и осознает, что он кодит и как это повлияет на экосистему. Каждый админ осознает, как работает этот код и что будет с экосистемой после релиза. Все автоматизировано. Это работает.
backup — ну, он не нужен. Точнее он почти не нужен, весь код децентрализован и хранится распределенно в системе контроля версии. Исходные данные тоже нужно бекапить. И все ))
Упала виртуалка, две, три, сервер, второй, третий. Это неважно. Деплой запускается быстро на других нодах. Нет ноды — он полетит в коммерческое облако. Данные избыточны и легко восстановимы. Вместо 300 единиц всего мы бекапим только две и самое важное там.
Упала виртуалка, две, три, сервер, второй, третий. Это неважно. Деплой запускается быстро на других нодах. Нет ноды — он полетит в коммерческое облако. Данные избыточны и легко восстановимы. Вместо 300 единиц всего мы бекапим только две и самое важное там.
В ИТ кардинальная смена будущего приходит с изменениями и лидеров рынка и изменениями лидеров рынка.
Тоесть, пока НР работает по ITIL и рекомендует его, целесообразно не придумывать велосипед.
Дело ведь не в том, американская вилка и розетка лучше, или европейская. Нужна та, которая применима здесь и сейчас.
Тоесть, пока НР работает по ITIL и рекомендует его, целесообразно не придумывать велосипед.
Дело ведь не в том, американская вилка и розетка лучше, или европейская. Нужна та, которая применима здесь и сейчас.
Нельзя же подойти и сказать бизнесу — извините, мы не можем развиваться так быстро, как вы хотите, потому что HP рекомендует работать по другому плану.
Это не велосипед, это — эволюция. Не всем это пока надо, но успешным компаниям, которые развиваются и конкурентноспособны — почему нет )
Это не велосипед, это — эволюция. Не всем это пока надо, но успешным компаниям, которые развиваются и конкурентноспособны — почему нет )
Я вижу в ITIL оптимизацию и снижение хобота. В размерах тех компаний, с которыми у меня есть опыт работы, ИТ развивается быстрее.
Давайте поговорим об инцидентах.
ITIL предлагает в качестве инструмента для объективного указания приоритета параметры, срочность и влияние.
У нас есть первая линия, хелпдеск, которая должна объективно определить срочность. Как? Со слов пользователя?
У пользователя для всех его заявок всегда один и тот же приоритет. Точнее целый набор: «жить не могу», «сверхсрочно» и «сделать вчера!».
Опросные листы? А есть примеры реально работающих оперативных анкет по определению срочности? Приведите, я таких не встречал еще. Определять срочность, пользуясь дистанционным доступом, дотошно проверяя слова пользователя? Долго и дорого. И не всегда помогает. Точнее никогда.
Среднестатистический helpdesk вообще слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях; если это конечно не услуги вида: «рабочее место», «печать» или «электронная почта». Да и не обязан, кстати.
Влияние? Та же песня. Зачастую невозможно определить влияние инцидента до полного его расследования.
Не работает. Необъективно ) Только для тихой рощицы торговли и чего вы там еще назвали. И то с натяжкой.
ITIL предлагает в качестве инструмента для объективного указания приоритета параметры, срочность и влияние.
У нас есть первая линия, хелпдеск, которая должна объективно определить срочность. Как? Со слов пользователя?
У пользователя для всех его заявок всегда один и тот же приоритет. Точнее целый набор: «жить не могу», «сверхсрочно» и «сделать вчера!».
Опросные листы? А есть примеры реально работающих оперативных анкет по определению срочности? Приведите, я таких не встречал еще. Определять срочность, пользуясь дистанционным доступом, дотошно проверяя слова пользователя? Долго и дорого. И не всегда помогает. Точнее никогда.
Среднестатистический helpdesk вообще слабо разбирается в бизнес-специфике большинства услуг, используемых бизнес-приложениях; если это конечно не услуги вида: «рабочее место», «печать» или «электронная почта». Да и не обязан, кстати.
Влияние? Та же песня. Зачастую невозможно определить влияние инцидента до полного его расследования.
Не работает. Необъективно ) Только для тихой рощицы торговли и чего вы там еще назвали. И то с натяжкой.
Ну да, торговля и производство тихая рощица.
К сожалению, IT на них не заканчивается. И это очень малая часть. И там очень тихо и можно позволить себе ITIL.
Есть еще разработчики и их софт на продажу или под монетизацию, например. Социальные сети, сервисы, геолокация, навигация, геймдев. Там счет идет на часы. Конкурентов слишком много.
И там тоже есть среднестатистические админы )
Есть еще разработчики и их софт на продажу или под монетизацию, например. Социальные сети, сервисы, геолокация, навигация, геймдев. Там счет идет на часы. Конкурентов слишком много.
И там тоже есть среднестатистические админы )
Улыбнуло.
Основываясь на ваших комментариях, я сперва подумал, что DevOps — методология, не так давно придуманная очень маленькой группой людей. Относится по большей части к разработке и тому, что с ней связано, и не касается очень многих процессов ИТ.
А потом почитал в инете и понял, что так оно и есть.
Предполагаю, что это очень удобная методика и авторы её молодцы.
Но глупо сравнивать кирпич, бревно и пенопласт.
ITIL — это сборник практик. Рекомендаций. На каждый шаг он даёт советы, основываясь на лучшем опыте.
И применять можно и нужно то, что подходит в каждом конкретном случае.
Полагаю, со временем DevOps вполне претендует стать одной из книг ITIL.
Основываясь на ваших комментариях, я сперва подумал, что DevOps — методология, не так давно придуманная очень маленькой группой людей. Относится по большей части к разработке и тому, что с ней связано, и не касается очень многих процессов ИТ.
А потом почитал в инете и понял, что так оно и есть.
Предполагаю, что это очень удобная методика и авторы её молодцы.
Но глупо сравнивать кирпич, бревно и пенопласт.
ITIL — это сборник практик. Рекомендаций. На каждый шаг он даёт советы, основываясь на лучшем опыте.
И применять можно и нужно то, что подходит в каждом конкретном случае.
Полагаю, со временем DevOps вполне претендует стать одной из книг ITIL.
Правильно написано) Сам постепенно прихожу к некоторым методикам, которые описаны в ITIL. Даже документация в локальной wiki. Просто в один момент задумался о том, что через n-ое количество времени я тупо забуду как настраивал тот или иной сервис.
Sign up to leave a comment.
Зачем ITIL обычному среднестатистическому администратору (10-500 ПК)