Управление проблемами Archives – Страница 4 из 8

Сохранение контроля

Можно наглядно наблюдать, как компании сталкиваются со проблемой управления сложностью современных приложений. Создание ПО собственной разработки для внутренних нужд, для реализации ключевых бизнес-процессов компании, чаще всего основывается на принципе микросервисной архитектуры. Эта метаструктура приложения очень далека от представления последнего в виде некоторого монолитного объекта, обладающего определенными характеристиками. При использовании микросервисной архитектуры приложение конструируется в виде облака (хотел написать – массива, но слово “облако” гораздо лучше описывает картину) маленьких приложений, хорошо выполняющих только одну функцию. Отдельные экземпляры запущенных микросервисов абсолютно изолированы друг от друга, для их создания и/или удаления используются автоматические средства доставки, контейнеры. Каждый из таких сервисов имеет свои требования…

Problem Management: эскалация инцидента на вторую линию

В редакцию портала поступил вопрос: Коллеги, добрый день! Прочитал много материалов, касающихся Problem Management. Совсем не прочувствовал идею, что Управлению проблемами сложно внедрять и до него нужно "дорасти". Возьмем на примере. Звонит пользователь, и говорит, что не может на компьютер зайти — заблокирована учетная запись. Причем утверждает, что это происходит каждый день. Проверяю по тикетам — так и есть. Каждый день мой сотрудник первой линии успешно решает данный инцидент. То есть налицо наличие проблемы. Но Problem Management не выстроен. Я хочу, чтобы ITSM система мне позволила на основе данного инцидента создать проблему, которую перевести на вторую линию, к которой можно приклеить прошлые такие…

Вопрос из зала, 18 июля 2017, последний комментарий 2 августа 2017

Правильная последовательность внедрения ITSM-процессов

В редакцию портала поступил вопрос: Добрый день, коллеги! Наша компания находится на этапе внедрения процессов ITSM. В качестве первоочередных к внедрению процессов остановились на 6: управление обращениями, управление инцидентами, управление запросами на обслуживание, управление изменениями, управление конфигурациями, управление проблемами. Возник спор: в какой последовательности внедрять процессы. Я считаю, что правильнее было бы сперва смоделировать и описать регламенты всех шести процессов, а уже после этого формировать требования для разработчиков системы автоматизации, автоматизировать и обучать персонал новым правилам работы, т.к. часть изменений в системе автоматизации по одному процессу затронет и другие. Коллеги придерживаются мнения, что внедрять каждый из процессов нужно последовательно. Подскажите, есть…

Вопрос из зала, 4 июля 2017, последний комментарий 8 июля 2019

Правильные вопросы

Недавно, в очередной раз обсуждая техники анализа проблем, используемые в рамках процесса управления проблемами (Problem Management), спорили по поводу количества вопросов, которые нужно/можно задавать, реализуя методику «Пять «Почему?» («5-why»). Суть метода, напомню, заключается в том, что мы берём какое-то явление (проблему) и задаём себе вопрос: «Почему это происходит?». Найдя ответ на этот вопрос («Это происходит, потому что, происходит то»), мы задаём тот же самый вопрос «почему?» про «то» («А почему происходит то?»). И т.д. и т.п. Утверждается [ITIL SO, 4.4.4.3], что, следуя по этой цепочке, мы «обычно на пятой итерации добираемся до корневой причины». На самом деле то, как быстро…

Игорь Гутник, 25 декабря 2016, последний комментарий 27 декабря 2016

Всегда ли Known Error – ошибка?

Согласно ITIL® процесс «Управление проблемами» (Problem Management) направлен на минимизацию негативного влияния на бизнес инцидентов, вызванных ошибками в ИТ-инфраструктуре и предотвращение повторного возникновения таких инцидентов [SO, 4.4.1.1]. Часть работы процесса заключается в поиске корневой причины, вызывающей инцидент(ы) или, если не забывать и про проактивную составляющую процесса, корневой причины, которая может вызвать инцидент(ы) и устранению данной причины, либо, если это по какой-либо причине невозможно и/или не рационально, предложению обходного решения (workaround). При этом нужно понимать, что в общем случае ошибка – это не всегда ошибка в прямом смысле слова. Это может быть сложное сочетание конфигурационных единиц и условий их эксплуатации, которое…

Координатор проблем в слабой матрице

В процессе управления проблемами есть такая роль: координатор проблем. Как правило, эта роль предполагает ответственность за диагностику и решение проблем в какой-то предметной области, в том числе, с привлечением специалистов из смежных областей. И иногда я слышу от заказчиков вопрос: «А кто, собственно, должен быть координатором той или иной проблемы»? Например, время от времени начинает тормозить приложение. Вполне логично координатором данной проблемы становится один из ведущих специалистов app-саппорта. Далее, предположим, в результате диагностики он выясняет, что тормоза возникают на СХД. Почему? Причин может быть множество, способов решения еще больше. А наш координатор проблемы в СХД не специалист. Как быть? Кто…

Дмитрий Исайченко, 22 августа 2016, последний комментарий 29 августа 2016

Major incident – когда становится горячо…

На курсе ITIL Foundation слушатели часто задают вопрос о значительных инцидентах (major incident). Иногда потому, что тема управления ИТ-подразделением для них вообще новая и термин «значительный инцидент» слышится впервые, хотя в реальной жизни – это знакомая ситуация, иногда – потому что не совсем ясно, где провести границу между просто инцидентом и значительным инцидентом, и почти всегда – как с ним работать. О ключевых моментах, которые нужно учесть при работе со значительными инцидентами, пишет Neven Zitek в своей статье «Управление значительными инцидентами – когда становится горячо…» Что такое значительный инцидент? В теории значительный инцидент – это инцидент с самым высоким влиянием и…

Новостной поток, 18 июля 2016, последний комментарий 26 июля 2016

Управление событиями и рейтинги

Интересная идея была озвучена Аугусто Барросом (Augusto Barros), исследовательским директором Gartner в его недавней публикации в авторском блоге. Фокусом его интересов является информационная безопасность. В своей публикации он отмечает, что индустрия средств мониторинга событий и инцидентов безопасности изменилась за последние несколько лет. Ранее они работали следующим образом: одно или несколько средств отслеживания событий безопасности генерировали некоторый поток этих событий и присваивали им определенные степени критичности. Имелся некоторый пул сотрудников невысокой квалификации, которые в непрерывном режиме отслеживали этот поток и обрабатывали его в соответствии со скриптами, осуществляя требуемую эскалацию на профильные группы, а также проводя дополнительные расследования событий в силу своих возможностей. Очевидно, что с тотальной цифровизацией такой…

Опыт гибкого управления проблемами

Своим практическим опытом о том, как сочетать в одной организации методы гибкой разработки и классического процесса эксплуатации услуг, с нами делится Ян Джонс (Ian Jones), консультант KPMG Australia. В одной неназванной организации методы гибкой разработки были приняты как стандарт исполнения проектов и успешно применялись достаточное время. При реализации ITSM инициатив возникло желание использовать их и для организации процесса управления проблемами. Изначально организация использовала Scrum для координации этих работ, но этот подход показал себя не с лучшей стороны. После чего, была предпринята более успешная попытка применения "бережливой" практики Kanban. Для того, чтобы объяснить различия между этими двумя методиками приведем небольшую таблицу. Kanban Scrum Планирование работ В объеме…

Болевые точки управления проблемами

В группе BACK2ITSM опубликована заметка о "болевых точках" процесса управления проблемами, содержащая некоторые рекомендации по минимизации рисков, этими точками вызываемых. Автор, не углубляясь излишне в философские вопросы, напоминает нам перечень областей, применительно к которым в рамках управления проблемами необходимо осуществлять регулярный анализ. Эти области анализа следующие: выявленные события и полученные уведомления об ошибках в инфраструктуре, а также характер трендов в появлении событий и уведомлений; зарегистрированные инциденты и тренды в возникновении инцидентов; ИТ-сервисы, по которым были выявлены события, поступили уведомлениями, возникли инциденты. Если имеет место негативный тренд или негативное влияние на ИТ-услуги, как известно, необходимо подробно разобраться в проблемах – провести…

STAR WARS и Управление проблемами

Совсем недавно на нашем портале обсуждалось место процесса управления проблемами в организационной структуре, исходя из его назначения и задач. На смежную тему на портале компании EasyVista опубликована "трилогия" Кристофера Моргана (Cristopher Morgan) – "Зачем Дарту Вейдеру нужен менеджер процесса управления проблемами" ("Why Darth Vader Needed a Problem Manager"). Часть 1 Часть 2 Часть 3 В этой публикации Морган на примере катастрофы звезды смерти и других драматических сцен великой киносаги выделяет ключевые области, на которые необходимо обратить внимание при реализации этого процесса, а также ясно показывает что произойдет, если этого не сделать. Надеемся, это легкое и полезное тематическое чтение развлечет вас и если не поможет улучшить ваши процессы, то…

Новостной поток, 23 декабря 2015, последний комментарий 28 декабря 2015

Портал №1 по управлению цифровымии информационными технологиями

Управление проблемами

Портал №1 по управлению цифровыми
и информационными технологиями