Анонсированный на конец года выход переведенного силами itSMF-Россия русскоязычного экзамена ITIL v3 Foundation состоялся. Экзамен доступен для заказа в аккредитованных экзаменационных центрах на тех же условиях, что и версии на других языках. Слушатели аккредитованных курсов "Основы ITILv3" получили доступ к двум вариантам пробного экзамена на русском языке. Всего этот экзамен доступен на 18 языках, включая английский без учета разных вариантов испанского. Ваш e-mail не будет опубликован. Подписаться на еженедельный дайджест. Новый учебный курс Cleverics: Основы DevOps и новая деловая игра GamingWorks: Проект Феникс — DevOps на практике. Определение потребности в ресурсах и расчет стоимости услуг Экономически обоснованное управление ИТ. Подписка на дайджест Реестр ISO Задать вопрос! Проверено временем Книги О портале. ITSM , Всё это - ЛЮДИ , Источники знаний , Новости компаний , Сертификация. Спасибо всем, кто организовал и выполнил перевод! Успехов всем, кто им воспользуется! Экзамен ITILv3 Foundation с декабря станет доступен на русском языке ITIL Practitioner — новый учебный курс Правильный следующий шаг после ITIL Foundation. Добавить комментарий Отменить ответ Ваш e-mail не будет опубликован. Ближайшие мероприятия Зарегистрируйтесь, чтобы получить больше полезных знаний: Экономика и финансы ИТ. Управление разработкой ПО по методологии Scrum Agile. Service Desk и поддержка пользователей. Operational Support and Analysis ITIL OSA. Эксплуатация и предоставление ИТ-услуг. Управление архитектурой предприятия на основе TOGAF и IT4IT. Единственный верный способ всегда оставаться в курсе событий и регулярно получать новые идеи: We recommend moving this block and the preceding CSS link to the HEAD of your HTML file. Авторы и редакторы портала — консультанты и тренеры компании Cleverics. Использование материалов данного сайта допускается исключительно с разрешения правообладателя. Использование данного сайта означает согласие с обязательством соблюдать нашу Политику конфиденциальности и Согласие на обработку персональных данных.
Только полноправные пользователи могут оставлять комментарии. TM Feed Хабрахабр Geektimes Тостер Мой круг Фрилансим. Хабрахабр Публикации Пользователи Хабы Компании Песочница. Сегодня много кто слышал про ITIL: ИТ процессы, инциденты, тикеты и прочие составляющие ИТ менеджмента. Сегодня поговорим об одном из самых важных ИТ процессов в плане поддержания стабильности инфраструктуры организации — Управлении Изменениями, он же Change Management. Change Management наиболее тесно связан со следующими процессами: Incident Management, Problem Management, Configuration Management. Нужно изменить конфигурацию сервера — составь план, утверди, примени, обнови документацию. Нужно ввести в эксплуатацию новый роутер — составь план, утверди, примени, обнови документацию. Нужно перенести базу данных с одного хоста на другой — … ну вы поняли. Может показаться, что все это излишняя бюрократия, занимающая ваше драгоценное время. Однако, никто и не предлагает с места в карьер углубляться в бюрократию с самого начала. Бюрократию можно оставить крупным корпорациям, которые могут себе позволить любые издержки ради поддержания стабильности. Что бы ни говорили эстеты ИТ менеджмента, я искренне верю, что в компаниях любого размера можно использовать методики Change Management — по-тихоньку, без фанатизма внедряя всё лучшее, что в нём есть постепенно, а не одним махом. А начать можно с одного маленького, но очень полезного документа — т. Change Plan — документа, в котором описывается как будет проходить чендж. В свое время сам разрабатывал его шаблон для компании, в которой работал — документ получился очень практичным. Ниже приведу его разделы. Описание Что будет делаться в двух словах. Для чего это будет делаться если пораскинуть мозгами, то может оказаться, что и делать ничего не надо ; Кто будет участвовать. Желательно на официальную, но можно и на другие проверенные источники. Документация обуславливает корректность ваших действий. И вообще ее полезно читать. Подготовка Pre-installation Все что нужно сделать до момента X — времени, на которое запланирован чендж. Важными пунктами этого раздела являются: Для чего нужен бэкап я не буду распространяться, а вот насчет согласования уточню, что этот пункт крайне важен. Все, кого может затронуть чендж должны быть предупреждены, а ответственные лица должны дать свое согласие. Например, с 16 до 17 вы соберетесь заменить принтер, а именно в это время в бухгалтерии отправят на печать зарплатные листы… Согласитесь, будет неприятно. Внедрение install plan Все действия, которые будут выполняться в момент X. По шагам — максимально подробно: При желании можно указать сколько времени займет та или иная операция. Заключительные действия Post-installation Проверить, что система и все остальные системы, с ней взаимодействующие, работают корректно; Вернуть обратно все настройки, которые делались в рамках подготовки к ченджу; Внести изменения в документацию; План отката Backout Plan Действия, которые будут выполняться в случае проблем и невозможности их устранения в приемлемые сроки. Приложения Если в плане много справочной информации, то здесь можно всю ее собрать. IP адреса, имена серверов, пути в файловой системе, и прочее. С содержимым плана закончили. Помимо очевидных плюсов у составления таких планов есть один приятный бонус: При этом выполнять их сможет не только один сотрудник, но и любой человек, который более-менее в теме. Всем надо когда-то выходить в отпуск. Это далеко не ITIL, но это уже кусочек от него, который сделает инфраструктуру организации более стабильной. ИТ специалист же, который применяет такие, пусть и урезанные, подходы, сможет прокачать свои скилы, которые несомненно пригодятся в карьере. ITIL , change management. Тестирование IT-систем авторов , 1,1k публикаций. Программирование 2,9k авторов , 6,5k публикаций. JavaScript 1,9k авторов , 4k публикаций. CSS авторов , 1,2k публикаций. IT-стандарты авторов , публикаций. Системное программирование авторов , публикации. HTML автора , публикаций. Разработка веб-сайтов 4,1k авторов , 9,6k публикаций. Совершенный код авторов , публикации. Разработка мобильных приложений 1k авторов , 2,8k публикаций. Добавить в закладки Илья Митруков ilyamitrukov карма. Для меня лично как нельзя кстати. А где ещё можно почитать про практики ITIL, на доступном для понимания языке. А то как подумаешь про пять томов технической литературы, мозг сразу блокируется. На ютубе есть очень хорошие видео от Charles Sturt University. Они очень короткие и легки для понимания. Если тема интересна можно смотреть по паре в день. В свободном доступе по большому счету только общая информация, но для понимания её обычно хватает. Если есть конкретные или общие вопросы — задавайте, м. Простому смертному не сервис менеджеру, а скорее инженеру как правило наиболее интересно посмотреть 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 во взаимном согласовании всех процессов и грамотной их организации. К примеру, не имея внятного каталога сервисов в том числе и поддерживающих , с описанными процессами, методиками, метриками и т. А то v3 видел только урывками. Интересно было бы почитать. А я пока подпишусь…. Ну, собственно вот архивчик перегнал все в PDF для удобства. Очень интересная и важная тема. Только знающий человек тут подсказал, то что вы описываете ближе скорее к управлению релизами, а не изменениями. Управление изменениями это процесс внесения изменений в продукт. От поступления запроса на изменение, до непосредственно самих изменений. А управление релизами, это уже применение этих изменений в продуктивной среде. Строго говоря, Change — это любое изменение в любом CI Configuration Item. CI — элемент Configuration Management — процесса в рамках которого ведется учет всех элементов инфраструктуры — серверов, АТС, лицензий на софт, процессов, контрактов… и связей всего этого хозяйства друг с другом. CI характеризует каждую единицу инфраструктуры в разумных деталях. В общем это отдельная тема. Если говорить о Release Management. Слышал о нем, как части ITIL… не готов прокомментировать. Данный момент позволит нам избежать всевозможных недоразумений и негодований со стороны начальства по результатам проведенного изменения, так как оно заранее будет знать, чем данный чейндж для него чреват. Именно на таких простых, жизненных ситуациях становится понятной цель применения ITSM подхода. Тем более, что внедрив однажды что-то простое, со временем понимаешь, что это можно улучшить, процесс по сути своей, бесконечный. На самом деле скептики не так уж и не правы. ITIL в исходном виде действительно не работает у нас Россия и тому множество причин в том числе и законодательно запрещены некоторые подходы , но это не означает, что нельзя адаптировать методику. Если есть понимание цели, есть знание путей достижения, то ничего не мешает использовать те или иные подходы, облегчая тем самым достижение цели, и повышая качество результата. ITIL это сбор рекомендаций и методик, а как внедрять зависит уже от поставленных процессов в компании. Itil не может работать или не работать, потому что это не методология. А использовать чужой опыт или наступать на грабли самому — каждый решает сам, за свои деньги: Большое спасибо за материал. Вроде бы мало, но весомо. Жду новых материалов от Вас в том же духе. Некоторое время назад на ИНТУИТе опубликовали курс про ITIL v3. Вы проходили этот курс? Я его сейчас прохожу. Пока только на первых лекциях. Впечатления пока хорошие, материал доступный для понимания. А я уже прошёл, за неделю наверное до этого поста. Слишком уж сухо и без примеров подан материал хотя в ITIL наверное по-другому и не получится. Ну и заметил вроде несколько косячков в вопросах. А уже потом читать полный вариант. Вот-вот, я сейчас на 4й главе курса и понимаю, что без наглядных примеров это все очень тяжело воспринимается. Но и гугление тоже, надо сказать, не помогает с примерами, то ли жмут все, то ли действительно по ITIL мало кто смог организовать работу ;. Метки лучше разделять запятой. Сейчас Вчера Неделя Почему нет русского Amazon, или где зарыта? Мифы, которые надо закрыть 5,2k Первая российская материнская плата массового сегмента 21,9k Интересные публикации Хабрахабр Geektimes. Как я боролся с комарами. Личный опыт и тесты на себе GT. Neuralink — Будущее, которое сложно себе представить. Вы будете его частью GT. Как запутать аналитика — 5. Linux все еще не торт. Почему нет русского Amazon, или где зарыта? Мифы, которые надо закрыть. Китай заблокирует VPN для частных лиц GT. Как пенсионный фонд сливает персональные данные GT. Разделы Публикации Хабы Компании Пользователи Песочница. Информация О сайте Правила Помощь Соглашение Конфиденциальность. Услуги Реклама Тарифы Контент Семинары.
https://gist.github.com/4e3f95a097ff4d6e273921a7125648a5
https://gist.github.com/33d9f5f394ccfacc75f303e83387ae4e
https://gist.github.com/35d653ae8bb5b3ada5225776e8ef84a6