Про самый знаменитый процесс управления ИТ-услугами
Ответственность или владение инцидентом является важнейшим аспектом эффективного управления. Назначение владельца обеспечивает быстрое и надлежащее реагирование на инциденты, тем самым сводя к минимуму сбои в работе ИТ-услуг и оптимизируя удовлетворенность пользователей.
Непрерывное совершенствование лежит в основе успешного управления ИТ-услугами, и потому рассмотрим, как оно может быть использовано в ключевых процессах и какие преимущества для них оно дает.
Не новый, но постоянно возникающий вопрос – а есть ли данные о среднем количестве обращений от одного пользователя? Попробовали провести исследование и делимся результатами.
До 80 % крупных инцидентов вызваны изменениями. Сбор данных о показателях успешности изменений и инцидентах, вызванных им, важен для понимания сильных и слабых сторон вашей деятельности. Используйте информацию, чтобы проверить все, что может пойти хорошо, и все, что может пойти плохо с изменениями, и вы будете готовы, если не все пойдет гладко.
Недавно в рамках внутреннего обсуждения услышал про дискуссию, случившуюся на одном из курсов у коллеги. И хотя речь шла о, казалось бы, простейшем понятии – инциденте, спор вышел жарким. Жалею, что мне не довелось поучаствовать. Компенсирую текстом ниже 😊 О чём спор Является ли инцидентом любое отклонение в той части ИТ-экосистемы (что-то не работает или работает медленнее, чем требуется, и т.д. и т.п.), за которую мы отвечаем? Или нет? Что говорится в умных книгах Определение понятия «инцидент» в предыдущей версии ITIL (ITIL v3) звучало так: «Незапланированное прерывание или снижение качества ИТ-услуги. Сбой конфигурационной единицы, который еще не повлиял на услугу,…
Мы заканчиваем серию статей про интересные уроки, которые можно вынести из аварийных ситуаций, рассказом про трудное решение о восстановлении системы в компании Reddit и общими выводами, которые можно учитывать в своей работе.
Непредвиденный инцидент во время тестирования на отказ стал возможностью для улучшения не только конфигурации, но и всего процесса проведения таких тестирований.
Перебои в работе системы никогда не бывают удачными. И всегда дешевле узнать о чужих сбоях, чем учиться на своих собственных. В этой серии статей мы рассмотрим несколько таких обзоров инцидентов с целью извлечь из них уроки. Возможно, некоторые из опубликованных примеров помогут вам сделать свои системы более устойчивыми к сбоям.
Но открывая текст практики «Управление инцидентами», мы обнаруживаем удивительную вещь: в описании процесса обработки и решения инцидента нет ни такого шага, ни хотя бы какого-то упоминания приоритизации. Что же это значит?
В каждой ИТ-организации есть практика управления инцидентами, причем во многих организациях эта практика была разработана много лет назад и никогда не подвергалась переработке, «стиранию пыли» и переосмыслению. Если вам это знакомо, то пришло время модернизировать управление инцидентами, создав систему, использующую автоматизацию и искусственный интеллект в дополнение к человеческим усилиям. В этой статье представлены три идеи для начала.
Давайте поговорим об управлении инцидентами и проблемами. Дело вот в чем. ITIL существует с конца 1980-х годов. Сейчас мы находимся на четвертой версии (ITIL 4), но, несмотря на огромное количество книг, курсов и сообщений в блогах об ITIL, до сих пор существует путаница в вопросе о том, где заканчивается управление инцидентами и начинается управление проблемами. Плюс разница между этими двумя понятиями. Если бы это был просто терминологический вопрос, я бы не стал так беспокоиться об этом, но реальность такова – путаница в управлении инцидентами и проблемами вредит всем нам. Если существует путаница в практике/процессах управления инцидентами и проблемами, то нам…