ITPARK.ru - ERP форум  - ITIL форум  
ITSM база знаний и Форум Параметры  |  Регистрация  |  Посетители  |  Поиск  |  Помощь
    |- Service support > Service desk, Incident management и Problem management Разместить новый топик   Post A Reply
Инциденты <-> проблемы на простом примере Показать принтер версию
next newest post | next oldest post
Автор Сообщение
Дмитрий Исайченко
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 10, 2004 @ 19:07:07  

Помогите разобраться, пожалуйста, в практическом вопросе по организации процессов управления инцидентами и проблемами. В качестве примера рассмотрим ситуацию с поражением сети каким-нибудь червяком, ну пусть будет Lovesan. И так:

1) В службу IM поступает звонок - компьютер пользователя сам перезагрузился. Регистрируется инцидент. Потом еще, и еще обращение. В зависимости от реализации, специалисты по техподдержке либо регистрируют новые инциденты (связанные с предыдущим), либо - что скорее всего - линкуют к нему все новые CI, поднимая тем самым Impact и, следовательно, Priority.

2) Очень скоро (минут 10) обнаруживается что да, есть такая уязвимость MS03-026/039 и ее эксплуатируют различные нехорошие программы, что приводит к массовому падежу компьютеров. Решение? Очень простое - поставить патч, но это RFC. Обходные решения? Хороших нет. Ну можно отключить на всех рабочих станциях DCOM массовой правкой реестра, но это же опять RFC, да еще какой!! Короче, очень быстро становится ясно что есть проблема, а точнее даже известная ошибка, но известная пока не для группы управления проблемами (PM) компании.

Вопрос 1: Да, я помню что инцидент никогда не становится проблемой. И потому вопрос - как правильнее выполнить регистрацию и открытие проблемы? IM обращается в PM и докладает обстановку? IM сам заводит проблему (с каким-нибудь временным статусом или еще что-нибудь вроде этого), связывает с ней инцидент и уведомляет PM? Используется ли здесь веритикальная эскалация? Или IM самостоятельно подает RFC - но в данном случае это, наверное не правильно, поскольку проблема тогда вообще "останется за бортом".

3) Идем дальше. Проблема зарегистрирована, решение известно, поэтому проблема получает статус Known Error и переходит в область управления Error Control. Выдан (срочный) RFC на установку патча. А инцидент, естественно, пока не решен.

Вопрос 2: В каком состоянии находится инцидент в это время? Open/Assigned видимо не очень логично, ведь эти статусы предполагают активную работу над инцидентом, а тут всей работы - утешать пользователей и ждать отмашки на развертывание патча. Resolved ясное дело тоже не годится. Может быть suspended?

4) Наконец (еще через 20 минут) команда ставить патч, латать дыры! Ясно что этобывает по-разному, но предположим худшее - специалисты IM побежали со всех ног по рабочим станциям (ну а кто-то еще по серверам). Но инцидент все еще не решен.

Вопрос 3: А сейчас какой статус у инцидента? Если Active, тот как его отличить от состояния когда решение еще только искали, а не внедряли?

Такие вот вопросы. Ответов "нефиг думать про ITIL пока антивирусы не поставили" не предлагать :)

Евгений Крылов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 10, 2004 @ 22:36:39  

Quote:
Originally posted by Дмитрий Исайченко

Помогите разобраться, пожалуйста, в практическом вопросе по организации процессов управления инцидентами и проблемами. В качестве примера рассмотрим ситуацию с поражением сети каким-нибудь червяком, ну пусть будет Lovesan. И так:

1) В службу IM поступает звонок - компьютер пользователя сам перезагрузился. Регистрируется инцидент. Потом еще, и еще обращение. В зависимости от реализации, специалисты по техподдержке либо регистрируют новые инциденты (связанные с предыдущим), либо - что скорее всего - линкуют к нему все новые CI, поднимая тем самым Impact и, следовательно, Priority.

2) Очень скоро (минут 10) обнаруживается что да, есть такая уязвимость MS03-026/039 и ее эксплуатируют различные нехорошие программы, что приводит к массовому падежу компьютеров. Решение? Очень простое - поставить патч, но это RFC. Обходные решения? Хороших нет. Ну можно отключить на всех рабочих станциях DCOM массовой правкой реестра, но это же опять RFC, да еще какой!! Короче, очень быстро становится ясно что есть проблема, а точнее даже известная ошибка, но известная пока не для группы управления проблемами (PM) компании.

Вопрос 1: Да, я помню что инцидент никогда не становится проблемой. И потому вопрос - как правильнее выполнить регистрацию и открытие проблемы? IM обращается в PM и докладает обстановку? IM сам заводит проблему (с каким-нибудь временным статусом или еще что-нибудь вроде этого), связывает с ней инцидент и уведомляет PM? Используется ли здесь веритикальная эскалация? Или IM самостоятельно подает RFC - но в данном случае это, наверное не правильно, поскольку проблема тогда вообще "останется за бортом".

3) Идем дальше. Проблема зарегистрирована, решение известно, поэтому проблема получает статус Known Error и переходит в область управления Error Control. Выдан (срочный) RFC на установку патча. А инцидент, естественно, пока не решен.

Вопрос 2: В каком состоянии находится инцидент в это время? Open/Assigned видимо не очень логично, ведь эти статусы предполагают активную работу над инцидентом, а тут всей работы - утешать пользователей и ждать отмашки на развертывание патча. Resolved ясное дело тоже не годится. Может быть suspended?

4) Наконец (еще через 20 минут) команда ставить патч, латать дыры! Ясно что этобывает по-разному, но предположим худшее - специалисты IM побежали со всех ног по рабочим станциям (ну а кто-то еще по серверам). Но инцидент все еще не решен.

Вопрос 3: А сейчас какой статус у инцидента? Если Active, тот как его отличить от состояния когда решение еще только искали, а не внедряли?

Такие вот вопросы. Ответов "нефиг думать про ITIL пока антивирусы не поставили" не предлагать :)


В модели ISM:
"В ISM, реактивные действия, относимые ITIL к процессу «Управления Проблемами», всегда подпадают под управление процесса «Обработки инцидентов», независимо от рассматриваемых инцидентов. "
http://www.real-time-enterprise.ru/technology/it/article/ismru12.html
На практике это удобно и легко внедряется.

--------------------

Владимир Вильчинский
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Март 11, 2004 @ 11:36:16  

Ответ 1: Никто и ничто не запрещает из IM подавать RFC. Кроме того, и IM, и PM - это деятельность, а не группы или орг. структуры. В Вашем примере PM уже отработал в другом месте (в Microsoft'е). Нужно ли выполнять самим какую-то деятельность, чтобы получить уже известное решение?

Ответ 2 и 3: Статус инцидента - дело Ваше, можете придумать любой, например: "в процессе устранения"/ "under recovering". Те статусы, которые Вы упомянули относятся скорее к состоянию заявки (trouble ticket), а не к состоянию самого инцидента. Вы можете привязать статус инцидента к IM activities...

Дмитрий Исайченко
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Март 11, 2004 @ 13:29:54  

Владимиру Вильчинскому:

Quote:
Ответ 1: Никто и ничто не запрещает из IM подавать RFC. Кроме того, и IM, и PM - это деятельность, а не группы или орг. структуры. В Вашем примере PM уже отработал в другом месте (в Microsoft'е). Нужно ли выполнять самим какую-то деятельность, чтобы получить уже известное решение?

На счет подачи RFC из IM - я в этом не сомневаюсь. Вопрос в том кто запишет исследованную Microsoft проблему в качестве известной ошибки во внутреннюю базу (и для матчинга последующих инцидентов, и для выявления недостатков/предложений по улучшению, например о внедрении системы управления обновлениями ПО - ведь не IM это будет делать...) и кто будет осуществлять последующий Error Control.

Quote:
Ответ 2 и 3: Статус инцидента - дело Ваше, можете придумать любой, например: "в процессе устранения"/ "under recovering". Те статусы, которые Вы упомянули относятся скорее к состоянию заявки (trouble ticket), а не к состоянию самого инцидента. Вы можете привязать статус инцидента к IM activities...

Вот с этим согласен.
Илья Шибаев
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Март 11, 2004 @ 14:51:50  

Quote:

На счет подачи RFC из IM - я в этом не сомневаюсь. Вопрос в том кто запишет исследованную Microsoft проблему в качестве известной ошибки во внутреннюю базу (и для матчинга последующих инцидентов, и для выявления недостатков/предложений по улучшению, например о внедрении системы управления обновлениями ПО - ведь не IM это будет делать...) и кто будет осуществлять последующий Error Control.

Оригинал размещен Дмитрий Исайченко


Соответственно, делать будет человек уполномоченный на это. Наверно логичнее всего эту обязанность дать менеджеру РМ

[Редактировал Илья Шибаев on Четверг, Март 11, 2004 @ 14:59:39]

--------------------

Владимир Вильчинский
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Четверг, Март 11, 2004 @ 17:22:14  

Quote:

На счет подачи RFC из IM - я в этом не сомневаюсь. Вопрос в том кто запишет исследованную Microsoft проблему в качестве известной ошибки во внутреннюю базу (и для матчинга последующих инцидентов, и для выявления недостатков/предложений по улучшению, например о внедрении системы управления обновлениями ПО - ведь не IM это будет делать...) и кто будет осуществлять последующий Error Control.

Оригинал размещен Дмитрий Исайченко

Quote:
Оригинал размещен Илья Шибаев

Соответственно, делать будет человек уполномоченный на это. Наверно логичнее всего эту обязанность дать менеджеру РМ

Записывать проблему в любом случае будет исполнитель соответствующей роли. Эту роль в подобных случаях может исполнять и тот инженер, который устраняет инциденты.
КАк это выглядит в реальности.
1. Сообщение перезагрузках.
2. Человек подозревает, что дело в вирусе. Ищет в интернете решение. Находит.
3. "Оформляет" проблему и RFC...
4. Проблема, а заодно и инциденты устраняются...

Собственно в Вашем случае такой деятельности, как Error Control, и не будет. Причина известна, решение имеется, проводится обычный Change. В ChngM будет выполняться reviewing, если там что-то обнаружится, может появиться проблема.

Василий Аксенов
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Вторник, Март 16, 2004 @ 01:06:40  

А главное не забыть открыть Проблему, что вовремя не поставили патч.

--------------------

Владимир Вильчинский
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 17, 2004 @ 12:07:15  

У Микрософта патчи появляются после вирусной атаки...
(не в обиду Володе Бахметьеву)
Владимир Бахметьев
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 17, 2004 @ 20:17:28  

Статистика такова: в среднем Microsoft выпускает патч через 3-4 недели после обнаружения уязвимости, а вирусы появляются примерно через два месяца с того же момента. Проблема не в патчах, а в способности их оперативно распространять. Одну известную российскую компанию Slammer "догнал" через год после своего возникновения.

[Edit by Владимир Бахметьев on Среда, Март 17, 2004 @ 20:21:55]

Владимир Вильчинский
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 17, 2004 @ 20:30:15  

Владимир! Это конечно злостный ОФФ.
Но как, кто обнаруживает уязвимость? Я считал, что вирусописатели. А, если не они, то как они об этих уязвимостях узнают?
Владимир Бахметьев
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 17, 2004 @ 23:32:03  

Я вам не скажу за всю Одессу, но есть некоторое количество добропорядочных фирм, которые занимаются отысканием проблем на постоянной основе. В комментариях к патчам периодически появляются слова "Благодарим г-на Х, обнаружившего эту проблему и с которым мы вместе работали над ее устранением". Ну а слухами земля полнится - информация постепенно расходится и тогда ...
Дмитрий Исайченко
Unregistered
Редактировать или удалить сообщение Reply w/Quote
Posted Среда, Март 17, 2004 @ 23:34:31  

Quote:
Статистика такова: в среднем Microsoft выпускает патч через 3-4 недели после обнаружения уязвимости, а вирусы появляются примерно через два месяца с того же момента.

К сожалению, зачастую это бывает не так. Хоть это и тема отдельной беседы, уязвимость MS04-007, например, была обнаружена в июле 2003, а устранена через 6 с лишним месяцев 10 февраля 2004. А первый эксплойт появился спустя 4 дня после публикации об уязвимости! Так что с этим еще связана и проблема применения срочных изменений в ChgMgmt.

Quote:
Проблема не в патчах, а в способности их оперативно распространять.

Абсолютно согласен!

Коллеги, большое спасибо за ответы :)

Разместить новый топик   Post A Reply Перейти к:
Написать вебмастеру | ИТСМ форум | Политика Privacy All times are GMT +4 Hours.
Добро пожаловать на форум, Guest!  
Login
Имя :
Пароль :
Чтобы пользоваться нашим форум необходимо зарегистрироваться! Пришлите заявку.В заявке необходимо указать имя и фамилию, и желательно место работы.

Уведомление о регистрации вас на форуме и логин будут высланы на ваш E-mail!
Имя и пароль регистрозависимы!
Правила форума здесь.
Forum Rules & Description
Who Can Read The Forum? Any registered user or guest
Who Can Post New Topics? Any registered user
Who Can Post Replies? Any registered user
Who Can Edit Posts? Any original author
Одно подразделение и два процесса. Часто именно с Service Desk и начинают.
Текущих активных посетителей: 22
Всего текущих 0 посетителей и 22 гостей на сайте. | Большинство пользователей когда-либо было 167 on 04-10-2008 22:55:22
Поиск на этом форуме
Поисковые слова: Искать за:
Powered by CuteCast v2.0 BETA 2
Copyright © 2001-2003 ArtsCore Studios
Все права защищены.
GALPRO ©2003-2018

Яндекс.Метрика