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

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

Какой лёгкий текст! Для меня лично как нельзя кстати. Спасибо. А где ещё можно почитать про практики ITIL, на доступном для понимания языке. А то как подумаешь про пять томов технической литературы, мозг сразу блокируется.
На ютубе есть очень хорошие видео от Charles Sturt University. Они очень короткие и легки для понимания. Если тема интересна можно смотреть по паре в день. Ссылка: www.youtube.com/playlist?list=PL017C0B75EE2FA714&feature=plcp
Спасибо!
В свободном доступе по большому счету только общая информация, но для понимания её обычно хватает. Можно немного найти по фразе «itil resources free». Если есть конкретные или общие вопросы — задавайте, м.б. следующим постом на них отвечу :)
Простому смертному (не сервис менеджеру, а скорее инженеру) как правило наиболее интересно посмотреть service support и service delivery, aka ITSM (service management). Для общих представлений хватит и введения. В свое время очень неплохо работала книга «введение в ит сервис менеджмент» Потоцкого. Она недешевая, но денег стоила. Не знаю есть ли сейчас что подобное поновее, но и та книга актуальности не потеряла. В 3й версии itil стал на мой взгляд чуть попонятнее и пологичнее, разьве что(книга по 2й)
Также не помешает понимание такого этапа — как Service Operation — то, что мы каждый день используем в жизни. Это service support, только более широко и развернуто
На пункте три хотелось бы остановится. Если описывать максимально подробно, то по факту это будет двойная работа — либо просто отписка.
Работал в компании в которой применялся(пытались применять) практику управления изменениями и вот данный момент, всех очень напрягал, т.к. вместо того, чтобы взять и сделать. Надо было сначала заполнить бумажек, с «масимально подробным» описанием, а потом уже что-то делать. Это удручало, особенно когда задачи были похожи, но всегда чем-то отличались.
Обычно описывается очень подробно. Если задача большая — то разбивается на несколько подзадач и каждая описывается подробно. Цель — по данному документу всегда можно восстановить что и зачем делалось. Если отписывать абы как — то аудит таких изменений будет просто кошмарным.
Также далеко не всегда изменения по данному документу будет производить тот кто его писал, поэтому описывается все вплоть до конректных комманд — чтобы было легко возпроизвести «постороннему» человеку.
Зависит от задачи и требований. В общем случае — чем подробнее, тем лучше, но здравый смысл никто не отменял. Обычное требование — план должен быть достаточно детализированным, чтобы любой специалист с надлежащей квалификацией мог его внедрить. В технические детали можно углубиться, если нужно, но предполагается что специалист знает КАК делать, соответственно нужно описать ЧТО делать.

Важно понимать что аппруверы, т.е люди которые будут подтверждать внедрение либо его блокировать, вполне могут быть не в теме по техническим деталям. План должен быть достаточно читаемым, чтобы они могли понять что ж вы там собираетесь сломать :)
В то же вермя план для инженера вполне имеет смысл детализировать до отдельных комманд, просто потому, что даже если внедряешь сам по своему же собственному плану, в самый ответственны момент запросто забудешь какую нибудь мелочь (бакап проверить, например) которая может зафакпить все по жести.
В серьезных средах всегда будет некоторый прессинг, или просто мандраж, который не лучшим образом воздействует на способность оценивать ситуацию.

Я стараюсь делать планы даже для себя поподробнее, не столько даже планы, сколько чеклисты (у авиации стоит этому поучиться — там ошибаться крайне непродуктивно)
Двойной работы не будет, фактически всю работу вы уже сделаете заранее, при внедрении думать уже будет не надо (да и некогда). Этом может быть неочевидно, но это единственный правильный подход, хороший тон, если изволите, и до этого необходимо дорасти. Потом плюсы становятся более чем очевидными.

Случай с бакапом — реален. При внедрении в плане не было явным образом указано что бакап надо проверить глазами и мозгом, а система мониторинга облажалась, и на деле живого бакапа не было уже сколько дней, хотя статусы были ОК. В результате небольшой человеческой ошибки (был удален не тот файл с очень похожим имем — ошибиться как пить дать) достаточно большая база данных была нагнута в неподъемное состояние. Результат — эпический факап на совершенно ровном месте. Был бы подробный план, прроверили бы бакап, и все бы решилось в рамках окна и проблемы не было бы вообще — просто внедрение бы перенесли.
А все просто было — инженер, который делал внедрение застрял в пробке и торопился. Мелочь просто напросто вылетела из головы, а быстрый взгляд на репорты мониторинга создал иллюзию того, что все хорошо.

Еще один важный момент — change window. Окно нужно не для того, чтобы формально ограничить вас во времени, а чтобы ограничить время в течение которого fuckups are possible. Если в это время что то происходит плохое — это нормальная ситуация. Если вне этого окна — это уже самодеятельность\безответственность\плохое планирование со всеми вытекающими последствиями для профессионального имижда.

Еще нельзя недооцивать важность disaster recovery, но это уже другая история.
[ремарка по поводу случая с бекапом]
Ситуации разные конечно бывают. Но файлик вместо удаления лучше было бы сначала переименовать(а ещё лучше скопировать и удалить старый, чтобы удостоверится что нет открытых дескрипторов). :)

Была аналогичная ситуация с удалением диска внутри виртуальной машины. Правда вместо физического удаления, его прдварительно отцепили, что к серьезным проблемам не привело.

[в целом по комментарию]
Идея понятна. Видимо я пока не был в той ситуации, когда можно было бы это на практике применять. Видимо у нас пока ну совсем маленькая для ITIL компания.
Вот, например, установка патчей на Оракл. Вроде бы с каждым из них идет инструкция, как его ставить, но через раз идя по этой инструкции что-нибудь всё равно можно сломать. И получается ситуация, что план есть, всё по нему сделано, а результат отличается от ожидаемого.
Еще важный момент забыл. Наличие change management снимает с внедряющей стороны львиную долю ответственности, в случае если что то будет упущено и чендж повлияет на что то, что выпало из поля зрения. В сложных системах это запросто. Когда все одобрения получены, это значит что все кто их давал исели возможность подумать о том, на что из их области ответственности, в которой они ориентируются гораздо лучше внедряющей пати, этот чендж может повлиять (не только в случае успеха, но и в случае неудачи или осложнений), и должны быть к этому готовы во время окна (читай хотя бы один инженер их соседней команды должен быть по крайней мере в городе).

Внедряющему остается продумать свою часть — все остально не на его совести.
Спасибо за коммент. Подписываюсь под каждым пунктом.
Да, в маломальски средней компании уже можно использовать и Change Windows и апруверов и Disaster Recovery.
Что мне нравится в ITIL — это логичность. До любого процесса можно дойти самостоятельно и внедрить без боли. Поэтому, когда знакомишься с методиками, в голове возникает только одна мысль: «Хм, Ну да. А что можно иначе?»… тем и обоснована её популярность.
Хорошую тему подняли, полезную, и редко обсуждаемую. В западных мирах это само собой разумеющиеся вещи, в русскоговорящем мире пока не так проникло.
ITIL тем и хорош, что он library. Это же не навязчивая методология, не «панацея» от всех болезней, а по сути просто сборник практик. Иными словами — сборник граблей и их возможных решений. Не вникать в него — по свти подписывать себя на многократное наступление на те самые грабли. Не продуктивно, как минимум.
О, это — один из самых важных пунктов. Если все на самом деле просто, то все шаги заполняются за пять-десять минут. Если же всё сложнее, то это знак к тому, что стоит записать шаги по пунктам, чтобы ничего не забыть. К слову сказать, если шаги продуманы качественно, то время применения изменений сокращается в разы, потому, что можно мозг практически отключить и сконцентрироваться на мониторинге ситуации, а не думать о том, что делать дальше.
Естественно, Change Management ради Change Management — это бред, и очень хорошо, когда это понимают и руководство и технари. Главное — чтобы работа шла хорошо.
Хорошее описание «в двух словах», что более чем похвально, учитывая Ваше «не читал» и «не учился». Знание того, что люди, со временем, сами приходят к таим вещам — меня очень радует, что вселяет уверенность в ИТ-будущем, но истинная ценность ITIL во взаимном согласовании всех процессов и грамотной их организации.
К примеру, не имея внятного каталога сервисов (в том числе и поддерживающих), с описанными процессами, методиками, метриками и т.д. — невозможно даже представить вменяемый SLA или OLA. Библиотека, главным образом, отвечает на вопрос «как делать», а не «что делать». Понимание «что-делать» придет, после (или во время изучения), само.

PS.В ближайшее время выложу все книги ITIL v3 в PDF (на буржуйском) + учебный курс в PowerPoint(на русском) + видеозапись пройденых курсов.
Сообщите, когда выложите. А то v3 видел только урывками. Интересно было бы почитать. А я пока подпишусь…
Ну, собственно вот архивчик (перегнал все в PDF для удобства). Все книги на буржуйском + учебный план на русском, с иллюстрациями.
Прекрасно, огромное Вам спасибо. Скачал.
Пожалуйста.
Видео на обработке пока.
Спасибо за статью. Очень интересная и важная тема. Только знающий человек тут подсказал, то что вы описываете ближе скорее к управлению релизами, а не изменениями. Управление изменениями это процесс внесения изменений в продукт. От поступления запроса на изменение, до непосредственно самих изменений. А управление релизами, это уже применение этих изменений в продуктивной среде.
Строго говоря, Change — это любое изменение в любом CI (Configuration Item).
CI — элемент Configuration Management — процесса в рамках которого ведется учет всех элементов инфраструктуры — серверов, АТС, лицензий на софт, процессов, контрактов… и связей всего этого хозяйства друг с другом.
CI характеризует каждую единицу инфраструктуры в разумных деталях.
Если это сервер, то в документации записано, что он «такой-то модели», «имеет такой-то IP», имеет связь с такой-то СХД, привязан к такому-то контракту и так далее. В общем это отдельная тема.
Если говорить о Release Management. Слышал о нем, как части ITIL… не готов прокомментировать. Ретируюсь :)
В первый пункт плана также не помешает добавить оценку такого понятия как «Impact» — какое влияние на жизнеспособность бизнес функций имеет данное изменение. Исходя из «влияния» можно описать приоритет (срочность) данного изменения.

Данный момент позволит нам избежать всевозможных недоразумений и негодований со стороны начальства по результатам проведенного изменения, т.к. оно заранее будет знать, чем данный чейндж для него чреват
Спасибо за статью. Хороший ответ тем скептикам, кто уверен что «у нас такое не работает», что это бесполезный «тренд» и т.д. Именно на таких простых, жизненных ситуациях становится понятной цель применения ITSM подхода. Тем более, что внедрив однажды что-то простое, со временем понимаешь, что это можно улучшить, процесс по сути своей, бесконечный
На самом деле скептики не так уж и не правы. ITIL в исходном виде действительно не работает у нас (Россия) и тому множество причин (в том числе и законодательно запрещены некоторые подходы), но это не означает, что нельзя адаптировать методику. Если есть понимание цели, есть знание путей достижения, то ничего не мешает использовать те или иные подходы, облегчая тем самым достижение цели, и повышая качество результата.
думаю что в исходном виде он нигде не работает :) ITIL это сбор рекомендаций и методик, а как внедрять зависит уже от поставленных процессов в компании
Itil не может работать или не работать, потому что это не методология. А использовать чужой опыт или наступать на грабли самому — каждый решает сам, за свои деньги :)
Большое спасибо за материал. Вроде бы мало, но весомо. Жду новых материалов от Вас в том же духе.
спасибо, записался.

Вы проходили этот курс? Как впечатления?
Я его сейчас прохожу. Пока только на первых лекциях.
Впечатления пока хорошие, материал доступный для понимания.
А я уже прошёл, за неделю наверное до этого поста. Впечатления на 4+. Слишком уж сухо и без примеров подан материал (хотя в ITIL наверное по-другому и не получится). Ну и заметил вроде несколько косячков в вопросах. Имея под рукой «святое пятикнижие» на английском могу сказать, что в курсе есть все основные темы, но в оригинале информации конечно больше — но для «первого прохода» по теме очень даже рекомендовал бы. А уже потом читать полный вариант.
Вот-вот, я сейчас на 4й главе курса и понимаю, что без наглядных примеров это все очень тяжело воспринимается. Но и гугление тоже, надо сказать, не помогает с примерами, то ли жмут все, то ли действительно по ITIL мало кто смог организовать работу ;)
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.