Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
как составить грамотный Slа
Next
Download to read offline and view in fullscreen.

Share

Инциденты, проблемы, RFC, SR

Download to read offline

Мы в технической поддержке имеем дело с различными типами задач, запросов, обращений пользователей. Разные типы задач нужно обрабатывать по-разному. Здесь я расскажу об основных типах заявок и некоторых их особенностях. Я буду использовать классификацию, принятую в ITSM (IT Service Management).
Меня зовут Евгений Калинин, здравствуйте.

Но начну я не с обращений пользователей «у меня ничего не работает». Начну я с того, что же мы этим пользователям даем – а это не починка компьютеров. Пользователи – они потому и пользователи, что используют сервисы. А что мы будем делать, чтобы они смогли эти сервисы использовать – что-то чинить, или наоборот не давать ломаться – это уже наше дело.
На этом слайде перечислены основные сервисы, которые мы обычно даем пользователю. Здесь «мы» - это и мы сами, и ИТ-служба клиента, если таковая есть, и другие поставщики, и железки, которые в этом процессе участвуют.
У пользователя есть компьютер с операционной системой и офисом, есть место для хранения файлов (обычно на файловом сервере), есть электронная почта, доступ в интернет, телефонная связь. Он также пользуется какими-либо информационными системами – будь то 1С, банк-клиенты или что-то специфическое. Иногда в список сервисов также добавляют инфраструктуру – то есть, серверы, сетевое оборудование, кабельную систему – и службу HelpDesk, которая умеет отвечать на пользовательские вопросы.
Все это – сервисы, с которыми имеет дело пользователь, и которые нужны бизнесу нашего клиента.

Если у пользователя нет доступа к сервису, то он звонит нам и рассказывает, что у него сломалось. Такое обращение называется «инцидентом».
При возникновении инцидента наша задача – быстро восстановить работоспособность сервиса. Возможно, для этого мы сделаем какую-нибудь заплатку, например, перезагрузим сервер, а разбираться, почему он подвис, будем уже потом – на следующем слайде.
Каждому инциденту мы можем определить приоритет. Наиболее полная схема определения приоритета предполагает использование двух параметров: воздействие (impact) и срочность. Срочность может быть высокой, средней и низкой (1, 2, 3). Воздействие – все пользователи, несколько пользователей или один пользователь (тоже 1-2-3). Дальше мы их п

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

Инциденты, проблемы, RFC, SR

  1. 1. Инциденты Проблемы Запросы на изменение Запросы на обслуживание
  2. 2. Сервисы <ul><li>Рабочие станции и офисное ПО </li></ul><ul><li>Файловое хранилище </li></ul><ul><li>Электронная почта </li></ul><ul><li>Доступ в Интернет </li></ul><ul><li>Информационные системы </li></ul><ul><li>Телефония </li></ul><ul><li>HelpDesk </li></ul><ul><li>Инфраструктура </li></ul>
  3. 3. Инцидент <ul><li>У пользователя нет доступа к сервису </li></ul><ul><li>Задача: быстрое восстановление работоспособности </li></ul><ul><li>Приоритет: срочность, воздействие </li></ul><ul><li>Обязательства по срокам </li></ul><ul><li>Повторяющиеся инциденты, поток инцидентов, вызванных общей проблемой </li></ul>
  4. 4. Проблема <ul><li>Первопричина инцидента или группы инцидентов </li></ul><ul><li>Может приводить к возникновению инцидентов в будущем </li></ul><ul><li>Обязательная регистрация отдельного кейса. Префикс PRB: </li></ul><ul><li>Оценка важности исходя из степени риска </li></ul><ul><li>Устранение проблем значительно снижает количество инцидентов </li></ul>
  5. 5. Запрос на изменение ( RFC ) <ul><li>Изменение в конфигурации информационной системы или инфраструктуры, добавление/удаление компонентов </li></ul><ul><li>Требует согласований и тестирования </li></ul><ul><li>Обязательства по срокам </li></ul><ul><li>Должно отражаться в CMDB , складе, базе лицензий, счетах за обслуживание </li></ul>
  6. 6. Запрос на обслуживание (SR) <ul><li>Консультации, помощь пользователям </li></ul><ul><li>Мелкие изменения конфигурации, не требующие согласований и отражения в CMDB и бухгалтерии </li></ul><ul><li>Обязательства по срокам </li></ul>
  7. 7. SLA <ul><li>Service Level Agreement – Соглашение об уровне сервиса </li></ul><ul><li>Обязательства по срокам реакции (начала работ) и выполнения инцидентов, запросов на изменения и обслуживание </li></ul><ul><li>Привязка сроков к сервисам и приоритетам </li></ul><ul><li>Сроки до выполнения или до эскалации </li></ul>
  8. 8. SLA - пример * без учета времени эскалации 48 часов* 30 мин. Инфраструктура 30 мин. HelpDesk 2 часа* 30 мин. Телефония 3 часа* 48 часов* 30 мин. Информационные системы 3 часа 24 часа 30 мин. Файловое хранилище 2 часа 8 часов* 30 мин. Интернет 2 часа 24 часа* 30 мин. Электронная почта 2 раб.дня* 24 часа* 30 мин. Рабочие станции RFC, SR Инцидент Время реакции
  9. 9. <ul><li>Евгений Калинин </li></ul><ul><li>http:// mml.ru </li></ul>

Мы в технической поддержке имеем дело с различными типами задач, запросов, обращений пользователей. Разные типы задач нужно обрабатывать по-разному. Здесь я расскажу об основных типах заявок и некоторых их особенностях. Я буду использовать классификацию, принятую в ITSM (IT Service Management). Меня зовут Евгений Калинин, здравствуйте. Но начну я не с обращений пользователей «у меня ничего не работает». Начну я с того, что же мы этим пользователям даем – а это не починка компьютеров. Пользователи – они потому и пользователи, что используют сервисы. А что мы будем делать, чтобы они смогли эти сервисы использовать – что-то чинить, или наоборот не давать ломаться – это уже наше дело. На этом слайде перечислены основные сервисы, которые мы обычно даем пользователю. Здесь «мы» - это и мы сами, и ИТ-служба клиента, если таковая есть, и другие поставщики, и железки, которые в этом процессе участвуют. У пользователя есть компьютер с операционной системой и офисом, есть место для хранения файлов (обычно на файловом сервере), есть электронная почта, доступ в интернет, телефонная связь. Он также пользуется какими-либо информационными системами – будь то 1С, банк-клиенты или что-то специфическое. Иногда в список сервисов также добавляют инфраструктуру – то есть, серверы, сетевое оборудование, кабельную систему – и службу HelpDesk, которая умеет отвечать на пользовательские вопросы. Все это – сервисы, с которыми имеет дело пользователь, и которые нужны бизнесу нашего клиента. Если у пользователя нет доступа к сервису, то он звонит нам и рассказывает, что у него сломалось. Такое обращение называется «инцидентом». При возникновении инцидента наша задача – быстро восстановить работоспособность сервиса. Возможно, для этого мы сделаем какую-нибудь заплатку, например, перезагрузим сервер, а разбираться, почему он подвис, будем уже потом – на следующем слайде. Каждому инциденту мы можем определить приоритет. Наиболее полная схема определения приоритета предполагает использование двух параметров: воздействие (impact) и срочность. Срочность может быть высокой, средней и низкой (1, 2, 3). Воздействие – все пользователи, несколько пользователей или один пользователь (тоже 1-2-3). Дальше мы их п

Views

Total views

2,458

On Slideshare

0

From embeds

0

Number of embeds

45

Actions

Downloads

25

Shares

0

Comments

0

Likes

0

×