Comments 32
Какой лёгкий текст! Для меня лично как нельзя кстати. Спасибо. А где ещё можно почитать про практики ITIL, на доступном для понимания языке. А то как подумаешь про пять томов технической литературы, мозг сразу блокируется.
На ютубе есть очень хорошие видео от Charles Sturt University. Они очень короткие и легки для понимания. Если тема интересна можно смотреть по паре в день. Ссылка: www.youtube.com/playlist?list=PL017C0B75EE2FA714&feature=plcp
В свободном доступе по большому счету только общая информация, но для понимания её обычно хватает. Можно немного найти по фразе «itil resources free». Если есть конкретные или общие вопросы — задавайте, м.б. следующим постом на них отвечу :)
На пункте три хотелось бы остановится. Если описывать максимально подробно, то по факту это будет двойная работа — либо просто отписка.
Работал в компании в которой применялся(пытались применять) практику управления изменениями и вот данный момент, всех очень напрягал, т.к. вместо того, чтобы взять и сделать. Надо было сначала заполнить бумажек, с «масимально подробным» описанием, а потом уже что-то делать. Это удручало, особенно когда задачи были похожи, но всегда чем-то отличались.
Работал в компании в которой применялся(пытались применять) практику управления изменениями и вот данный момент, всех очень напрягал, т.к. вместо того, чтобы взять и сделать. Надо было сначала заполнить бумажек, с «масимально подробным» описанием, а потом уже что-то делать. Это удручало, особенно когда задачи были похожи, но всегда чем-то отличались.
Обычно описывается очень подробно. Если задача большая — то разбивается на несколько подзадач и каждая описывается подробно. Цель — по данному документу всегда можно восстановить что и зачем делалось. Если отписывать абы как — то аудит таких изменений будет просто кошмарным.
Также далеко не всегда изменения по данному документу будет производить тот кто его писал, поэтому описывается все вплоть до конректных комманд — чтобы было легко возпроизвести «постороннему» человеку.
Также далеко не всегда изменения по данному документу будет производить тот кто его писал, поэтому описывается все вплоть до конректных комманд — чтобы было легко возпроизвести «постороннему» человеку.
UFO just landed and posted this here
[ремарка по поводу случая с бекапом]
Ситуации разные конечно бывают. Но файлик вместо удаления лучше было бы сначала переименовать(а ещё лучше скопировать и удалить старый, чтобы удостоверится что нет открытых дескрипторов). :)
Была аналогичная ситуация с удалением диска внутри виртуальной машины. Правда вместо физического удаления, его прдварительно отцепили, что к серьезным проблемам не привело.
[в целом по комментарию]
Идея понятна. Видимо я пока не был в той ситуации, когда можно было бы это на практике применять. Видимо у нас пока ну совсем маленькая для ITIL компания.
Вот, например, установка патчей на Оракл. Вроде бы с каждым из них идет инструкция, как его ставить, но через раз идя по этой инструкции что-нибудь всё равно можно сломать. И получается ситуация, что план есть, всё по нему сделано, а результат отличается от ожидаемого.
Ситуации разные конечно бывают. Но файлик вместо удаления лучше было бы сначала переименовать(а ещё лучше скопировать и удалить старый, чтобы удостоверится что нет открытых дескрипторов). :)
Была аналогичная ситуация с удалением диска внутри виртуальной машины. Правда вместо физического удаления, его прдварительно отцепили, что к серьезным проблемам не привело.
[в целом по комментарию]
Идея понятна. Видимо я пока не был в той ситуации, когда можно было бы это на практике применять. Видимо у нас пока ну совсем маленькая для ITIL компания.
Вот, например, установка патчей на Оракл. Вроде бы с каждым из них идет инструкция, как его ставить, но через раз идя по этой инструкции что-нибудь всё равно можно сломать. И получается ситуация, что план есть, всё по нему сделано, а результат отличается от ожидаемого.
UFO just landed and posted this here
Спасибо за коммент. Подписываюсь под каждым пунктом.
Да, в маломальски средней компании уже можно использовать и Change Windows и апруверов и Disaster Recovery.
Что мне нравится в ITIL — это логичность. До любого процесса можно дойти самостоятельно и внедрить без боли. Поэтому, когда знакомишься с методиками, в голове возникает только одна мысль: «Хм, Ну да. А что можно иначе?»… тем и обоснована её популярность.
Да, в маломальски средней компании уже можно использовать и Change Windows и апруверов и Disaster Recovery.
Что мне нравится в ITIL — это логичность. До любого процесса можно дойти самостоятельно и внедрить без боли. Поэтому, когда знакомишься с методиками, в голове возникает только одна мысль: «Хм, Ну да. А что можно иначе?»… тем и обоснована её популярность.
О, это — один из самых важных пунктов. Если все на самом деле просто, то все шаги заполняются за пять-десять минут. Если же всё сложнее, то это знак к тому, что стоит записать шаги по пунктам, чтобы ничего не забыть. К слову сказать, если шаги продуманы качественно, то время применения изменений сокращается в разы, потому, что можно мозг практически отключить и сконцентрироваться на мониторинге ситуации, а не думать о том, что делать дальше.
Естественно, Change Management ради Change Management — это бред, и очень хорошо, когда это понимают и руководство и технари. Главное — чтобы работа шла хорошо.
Естественно, Change Management ради Change Management — это бред, и очень хорошо, когда это понимают и руководство и технари. Главное — чтобы работа шла хорошо.
Хорошее описание «в двух словах», что более чем похвально, учитывая Ваше «не читал» и «не учился». Знание того, что люди, со временем, сами приходят к таим вещам — меня очень радует, что вселяет уверенность в ИТ-будущем, но истинная ценность ITIL во взаимном согласовании всех процессов и грамотной их организации.
К примеру, не имея внятного каталога сервисов (в том числе и поддерживающих), с описанными процессами, методиками, метриками и т.д. — невозможно даже представить вменяемый SLA или OLA. Библиотека, главным образом, отвечает на вопрос «как делать», а не «что делать». Понимание «что-делать» придет, после (или во время изучения), само.
PS.В ближайшее время выложу все книги ITIL v3 в PDF (на буржуйском) + учебный курс в PowerPoint(на русском) + видеозапись пройденых курсов.
К примеру, не имея внятного каталога сервисов (в том числе и поддерживающих), с описанными процессами, методиками, метриками и т.д. — невозможно даже представить вменяемый SLA или OLA. Библиотека, главным образом, отвечает на вопрос «как делать», а не «что делать». Понимание «что-делать» придет, после (или во время изучения), само.
PS.В ближайшее время выложу все книги ITIL v3 в PDF (на буржуйском) + учебный курс в PowerPoint(на русском) + видеозапись пройденых курсов.
Сообщите, когда выложите. А то v3 видел только урывками. Интересно было бы почитать. А я пока подпишусь…
Ну, собственно вот архивчик (перегнал все в PDF для удобства). Все книги на буржуйском + учебный план на русском, с иллюстрациями.
Спасибо за статью. Очень интересная и важная тема. Только знающий человек тут подсказал, то что вы описываете ближе скорее к управлению релизами, а не изменениями. Управление изменениями это процесс внесения изменений в продукт. От поступления запроса на изменение, до непосредственно самих изменений. А управление релизами, это уже применение этих изменений в продуктивной среде.
Строго говоря, Change — это любое изменение в любом CI (Configuration Item).
CI — элемент Configuration Management — процесса в рамках которого ведется учет всех элементов инфраструктуры — серверов, АТС, лицензий на софт, процессов, контрактов… и связей всего этого хозяйства друг с другом.
CI характеризует каждую единицу инфраструктуры в разумных деталях.
Если это сервер, то в документации записано, что он «такой-то модели», «имеет такой-то IP», имеет связь с такой-то СХД, привязан к такому-то контракту и так далее. В общем это отдельная тема.
Если говорить о Release Management. Слышал о нем, как части ITIL… не готов прокомментировать. Ретируюсь :)
CI — элемент Configuration Management — процесса в рамках которого ведется учет всех элементов инфраструктуры — серверов, АТС, лицензий на софт, процессов, контрактов… и связей всего этого хозяйства друг с другом.
CI характеризует каждую единицу инфраструктуры в разумных деталях.
Если это сервер, то в документации записано, что он «такой-то модели», «имеет такой-то IP», имеет связь с такой-то СХД, привязан к такому-то контракту и так далее. В общем это отдельная тема.
Если говорить о Release Management. Слышал о нем, как части ITIL… не готов прокомментировать. Ретируюсь :)
В первый пункт плана также не помешает добавить оценку такого понятия как «Impact» — какое влияние на жизнеспособность бизнес функций имеет данное изменение. Исходя из «влияния» можно описать приоритет (срочность) данного изменения.
Данный момент позволит нам избежать всевозможных недоразумений и негодований со стороны начальства по результатам проведенного изменения, т.к. оно заранее будет знать, чем данный чейндж для него чреват
Данный момент позволит нам избежать всевозможных недоразумений и негодований со стороны начальства по результатам проведенного изменения, т.к. оно заранее будет знать, чем данный чейндж для него чреват
Спасибо за статью. Хороший ответ тем скептикам, кто уверен что «у нас такое не работает», что это бесполезный «тренд» и т.д. Именно на таких простых, жизненных ситуациях становится понятной цель применения ITSM подхода. Тем более, что внедрив однажды что-то простое, со временем понимаешь, что это можно улучшить, процесс по сути своей, бесконечный
На самом деле скептики не так уж и не правы. ITIL в исходном виде действительно не работает у нас (Россия) и тому множество причин (в том числе и законодательно запрещены некоторые подходы), но это не означает, что нельзя адаптировать методику. Если есть понимание цели, есть знание путей достижения, то ничего не мешает использовать те или иные подходы, облегчая тем самым достижение цели, и повышая качество результата.
Большое спасибо за материал. Вроде бы мало, но весомо. Жду новых материалов от Вас в том же духе.
Некоторое время назад на ИНТУИТе опубликовали курс про ITIL v3.1 — www.intuit.ru/department/itmngt/itil_dpo/
спасибо, записался.
Вы проходили этот курс? Как впечатления?
Вы проходили этот курс? Как впечатления?
Я его сейчас прохожу. Пока только на первых лекциях.
Впечатления пока хорошие, материал доступный для понимания.
Впечатления пока хорошие, материал доступный для понимания.
А я уже прошёл, за неделю наверное до этого поста. Впечатления на 4+. Слишком уж сухо и без примеров подан материал (хотя в ITIL наверное по-другому и не получится). Ну и заметил вроде несколько косячков в вопросах. Имея под рукой «святое пятикнижие» на английском могу сказать, что в курсе есть все основные темы, но в оригинале информации конечно больше — но для «первого прохода» по теме очень даже рекомендовал бы. А уже потом читать полный вариант.
Sign up to leave a comment.
Практика ITIL для небольшой компании. Change Management