Se ha denunciado esta presentación.
Se está descargando tu SlideShare. ×

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

Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio
Anuncio

Eche un vistazo a continuación

1 de 9 Anuncio

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

Descargar para leer sin conexión

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

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

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

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

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

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

Anuncio
Anuncio

Más Contenido Relacionado

A los espectadores también les gustó (20)

Similares a Инциденты, проблемы, RFC, SR (20)

Anuncio

Más de Eugene Kalinin (12)

Más reciente (20)

Anuncio

Инциденты, проблемы, 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>

×