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