Книги По Itil V3 На Русском
Книги ITIL Материальная составляющая ITIL - это книги. Существует несколько версий ITIL. В 2007 вторая версия (здесь и далее - ITIL2) была подвергнута «обновлению» до новой, третьей, версии (здесь и далее - ITIL3). ITIL1 до сих пор издается, и есть люди (постепенно исчезающая каста консерваторов старой школы), что до сих пор присягают на этих книгах. Материальная составляющая ITIL - это книги. Существует несколько версий ITIL. В 2007 вторая версия (здесь и далее - ITIL2) была подвергнута «обновлению» до новой, третьей, версии (здесь и далее - ITIL3). ITIL1 до сих пор издается, и есть люди (постепенно исчезающая каста консерваторов старой школы), что до сих пор присягают на этих книгах. Язык: Русский. (голосов: 0).. Обновленная библиотека лучших практик в области управления ИТ сервисами - ITIL V3. Включает в себя пять новых книг: Service Strategy, Service Design, Service Transition, Service Operation, Continual Service Improvement, а также дополнительно книгу The Official Introduction to the ITIL Service Lifecycle (на английском языке)If you are implementing ITIL within your organisation and want to purchase the complete set of the five NEW core publications plus The Official Introduction to the ITIL Service Lifecycle, this.
Работа для Вас: Завершился проект перевода Глоссария ITIL v3 на русский язык Untitled Document В itSMF Россия завершился проект перевода официального Глоссария ITIL v3 на русский язык. Основную часть работы взяли на себя представители itSMF. В качестве экспертов участвовали более 25 человек.
Ими было произведено рецензирование базовой версии перевода. 18 экспертов участвовали в очном обсуждении ключевых спорных терминов. В текущий момент на сайте выложена предварительная версия Глоссария. Запущен проект сопровождения версии перевода – Глоссарий будет постоянно обновляться. Коллеги, каждый из вас может поучаствовать в улучшении Глоссария. Для этого достаточно прислать письмо на адрес Председателя Комитета по публикациям и переводам с описанием неточности или ошибки, на ваш взгляд. Убедительно просим вас не присылать новые или возможные, на ваш взгляд толкования терминов: 'прошу перевести CI как ЭК, КЭ, КМЭ, и т. д.'
Термин CI уже переведен как КЕ группой экспертов. А вот за сообщения о логических ошибках, опечатках или неточностях будем вам очень благодарны. Официальный глоссарий будет использован при переводе книг ITIL v3. Скачать Глоссарий ITIL v3 на русском языке Помогите своим коллегам быть в курсе интересных новостей!
Сегодня много кто слышал про ITIL: ИТ процессы, инциденты, тикеты и прочие составляющие ИТ менеджмента. — ничего страшного, еще обсудим. Сразу оговорюсь: не прочитал ни одной книги из библиотеки ITIL, не проходил курсы и, пока, не являюсь сертифицированным специалистом — поэтому просьба помидорами в меня не кидаться, а корректно и вежливо поправить, если буду в чем-то не прав. В то же время по этим самым IT процессами (в том самом виде, в котором они задумывались авторами ITIL) мне посчастливилось проработать аж три с половиной года — поэтому всю «кухню» знаю с практической стороны и знаю, что всё это реально, черт возьми, работает не только на бумаге, но и в жизни. Сегодня поговорим об одном из самых важных ИТ процессов в плане поддержания стабильности инфраструктуры организации — Управлении Изменениями, он же Change Management. Change Management наиболее тесно связан со следующими процессами: Incident Management, Problem Management, Configuration Management.
Суть его заключается в контроле действий, связанных с любого рода изменениями (они же в обиходе «ченджи» от «change») в ИТ инфраструктуре. Нужно изменить конфигурацию сервера — составь план, утверди, примени, обнови документацию. Нужно ввести в эксплуатацию новый роутер — составь план, утверди, примени, обнови документацию. Нужно перенести базу данных с одного хоста на другой — ну вы поняли. Может показаться, что все это излишняя бюрократия, занимающая ваше драгоценное время. Отчасти — да.
Однако, никто и не предлагает с места в карьер углубляться в бюрократию с самого начала. Бюрократию можно оставить крупным корпорациям, которые могут себе позволить любые издержки ради поддержания стабильности. Что бы ни говорили эстеты ИТ менеджмента, я искренне верю, что в компаниях любого размера можно использовать методики Change Management — по-тихоньку, без фанатизма внедряя всё лучшее, что в нём есть постепенно, а не одним махом. А начать можно с одного маленького, но очень полезного документа — т.н.
Change Plan — документа, в котором описывается как будет проходить чендж. В свое время сам разрабатывал его шаблон для компании, в которой работал — документ получился очень практичным. Ниже приведу его разделы. Надеюсь пригодится:. Описание Что будет делаться в двух словах. Для чего это будет делаться (если пораскинуть мозгами, то может оказаться, что и делать ничего не надо); Кто будет участвовать. Cсылки на документацию.
Желательно на официальную, но можно и на другие проверенные источники. Документация обуславливает корректность ваших действий. И вообще ее полезно читать. Подготовка (Pre-installation) Все что нужно сделать до момента X — времени, на которое запланирован чендж.
Важными пунктами этого раздела являются: Согласование и Бэкап. Для чего нужен бэкап я не буду распространяться, а вот насчет согласования уточню, что этот пункт крайне важен. Все, кого может затронуть чендж должны быть предупреждены, а ответственные лица должны дать свое согласие. Например, с 16 до 17 вы соберетесь заменить принтер, а именно в это время в бухгалтерии отправят на печать зарплатные листы Согласитесь, будет неприятно. Внедрение (install plan) Все действия, которые будут выполняться в момент X.
По шагам — максимально подробно: зайти на сервер такой то по SSH, выполнить команды: 1, 2, 3 И так далее. При желании можно указать сколько времени займет та или иная операция.
Заключительные действия (Post-installation) Проверить, что система и все остальные системы, с ней взаимодействующие, работают корректно; Вернуть обратно все настройки, которые делались в рамках подготовки к ченджу; Внести изменения в документацию;. План отката (Backout Plan) Действия, которые будут выполняться в случае проблем и невозможности их устранения в приемлемые сроки. Приложения Если в плане много справочной информации, то здесь можно всю ее собрать.
IP адреса, имена серверов, пути в файловой системе, и прочее. С содержимым плана закончили. Помимо очевидных плюсов у составления таких планов есть один приятный бонус: со временем их накопится столько, что добрую половину изменений можно будет выполнять по отработанной ранее схеме. При этом выполнять их сможет не только один сотрудник, но и любой человек, который более-менее в теме. Всем надо когда-то выходить в отпуск. Несмотря на всю простоту, в 95% организаций такого рода подходы не используется даже близко. Это далеко не ITIL, но это уже кусочек от него, который сделает инфраструктуру организации более стабильной.
ИТ специалист же, который применяет такие, пусть и урезанные, подходы, сможет прокачать свои скилы, которые несомненно пригодятся в карьере. Изучайте, внедряйте. Спасибо за внимание. Метки:.
Добавить метки Пометьте публикацию своими метками Метки необходимо разделять запятой. Например: php, javascript, адронный коллайдер, задача трех тел. Простому смертному (не сервис менеджеру, а скорее инженеру) как правило наиболее интересно посмотреть service support и service delivery, aka ITSM (service management). Для общих представлений хватит и введения. В свое время очень неплохо работала книга «введение в ит сервис менеджмент» Потоцкого. Она недешевая, но денег стоила. Не знаю есть ли сейчас что подобное поновее, но и та книга актуальности не потеряла.
В 3й версии itil стал на мой взгляд чуть попонятнее и пологичнее, разьве что(книга по 2й). Зависит от задачи и требований.
Книги По Itil V3 На Русском
В общем случае — чем подробнее, тем лучше, но здравый смысл никто не отменял. Обычное требование — план должен быть достаточно детализированным, чтобы любой специалист с надлежащей квалификацией мог его внедрить. В технические детали можно углубиться, если нужно, но предполагается что специалист знает КАК делать, соответственно нужно описать ЧТО делать. Важно понимать что аппруверы, т.е люди которые будут подтверждать внедрение либо его блокировать, вполне могут быть не в теме по техническим деталям. План должен быть достаточно читаемым, чтобы они могли понять что ж вы там собираетесь сломать:) В то же вермя план для инженера вполне имеет смысл детализировать до отдельных комманд, просто потому, что даже если внедряешь сам по своему же собственному плану, в самый ответственны момент запросто забудешь какую нибудь мелочь (бакап проверить, например) которая может зафакпить все по жести. В серьезных средах всегда будет некоторый прессинг, или просто мандраж, который не лучшим образом воздействует на способность оценивать ситуацию. Я стараюсь делать планы даже для себя поподробнее, не столько даже планы, сколько чеклисты (у авиации стоит этому поучиться — там ошибаться крайне непродуктивно) Двойной работы не будет, фактически всю работу вы уже сделаете заранее, при внедрении думать уже будет не надо (да и некогда).
Этом может быть неочевидно, но это единственный правильный подход, хороший тон, если изволите, и до этого необходимо дорасти. Потом плюсы становятся более чем очевидными.
Случай с бакапом — реален. При внедрении в плане не было явным образом указано что бакап надо проверить глазами и мозгом, а система мониторинга облажалась, и на деле живого бакапа не было уже сколько дней, хотя статусы были ОК. В результате небольшой человеческой ошибки (был удален не тот файл с очень похожим имем — ошибиться как пить дать) достаточно большая база данных была нагнута в неподъемное состояние. Результат — эпический факап на совершенно ровном месте. Был бы подробный план, прроверили бы бакап, и все бы решилось в рамках окна и проблемы не было бы вообще — просто внедрение бы перенесли. А все просто было — инженер, который делал внедрение застрял в пробке и торопился.
Мелочь просто напросто вылетела из головы, а быстрый взгляд на репорты мониторинга создал иллюзию того, что все хорошо. Еще один важный момент — change window. Окно нужно не для того, чтобы формально ограничить вас во времени, а чтобы ограничить время в течение которого fuckups are possible. Если в это время что то происходит плохое — это нормальная ситуация. Если вне этого окна — это уже самодеятельность безответственность плохое планирование со всеми вытекающими последствиями для профессионального имижда. Еще нельзя недооцивать важность disaster recovery, но это уже другая история.
ремарка по поводу случая с бекапом Ситуации разные конечно бывают. Но файлик вместо удаления лучше было бы сначала переименовать(а ещё лучше скопировать и удалить старый, чтобы удостоверится что нет открытых дескрипторов).:) Была аналогичная ситуация с удалением диска внутри виртуальной машины. Правда вместо физического удаления, его прдварительно отцепили, что к серьезным проблемам не привело. в целом по комментарию Идея понятна. Видимо я пока не был в той ситуации, когда можно было бы это на практике применять.
Процессы Itil
Видимо у нас пока ну совсем маленькая для ITIL компания. Вот, например, установка патчей на Оракл. Вроде бы с каждым из них идет инструкция, как его ставить, но через раз идя по этой инструкции что-нибудь всё равно можно сломать. И получается ситуация, что план есть, всё по нему сделано, а результат отличается от ожидаемого. Еще важный момент забыл. Наличие change management снимает с внедряющей стороны львиную долю ответственности, в случае если что то будет упущено и чендж повлияет на что то, что выпало из поля зрения.
В сложных системах это запросто. Когда все одобрения получены, это значит что все кто их давал исели возможность подумать о том, на что из их области ответственности, в которой они ориентируются гораздо лучше внедряющей пати, этот чендж может повлиять (не только в случае успеха, но и в случае неудачи или осложнений), и должны быть к этому готовы во время окна (читай хотя бы один инженер их соседней команды должен быть по крайней мере в городе). Внедряющему остается продумать свою часть — все остально не на его совести. О, это — один из самых важных пунктов. Если все на самом деле просто, то все шаги заполняются за пять-десять минут. Если же всё сложнее, то это знак к тому, что стоит записать шаги по пунктам, чтобы ничего не забыть.
К слову сказать, если шаги продуманы качественно, то время применения изменений сокращается в разы, потому, что можно мозг практически отключить и сконцентрироваться на мониторинге ситуации, а не думать о том, что делать дальше. Естественно, Change Management ради Change Management — это бред, и очень хорошо, когда это понимают и руководство и технари. Главное — чтобы работа шла хорошо. Хорошее описание «в двух словах», что более чем похвально, учитывая Ваше «не читал» и «не учился». Знание того, что люди, со временем, сами приходят к таим вещам — меня очень радует, что вселяет уверенность в ИТ-будущем, но истинная ценность ITIL во взаимном согласовании всех процессов и грамотной их организации. К примеру, не имея внятного каталога сервисов (в том числе и поддерживающих), с описанными процессами, методиками, метриками и т.д. — невозможно даже представить вменяемый SLA или OLA.
Библиотека, главным образом, отвечает на вопрос «как делать», а не «что делать». Понимание «что-делать» придет, после (или во время изучения), само. PS.В ближайшее время выложу все книги ITIL v3 в PDF (на буржуйском) + учебный курс в PowerPoint(на русском) + видеозапись пройденых курсов.
Строго говоря, Change — это любое изменение в любом CI (Configuration Item). CI — элемент Configuration Management — процесса в рамках которого ведется учет всех элементов инфраструктуры — серверов, АТС, лицензий на софт, процессов, контрактов и связей всего этого хозяйства друг с другом. CI характеризует каждую единицу инфраструктуры в разумных деталях. Если это сервер, то в документации записано, что он «такой-то модели», «имеет такой-то IP», имеет связь с такой-то СХД, привязан к такому-то контракту и так далее.
В общем это отдельная тема. Если говорить о Release Management. Слышал о нем, как части ITIL не готов прокомментировать.