Комментарии 19
Вы взорвали мой ридер своей картинкой
Ваши примеры вырваны из окружения: если для описанных ситуаций в компании предусмотрен порядок действий — это запрос, если нет — инцидент, ключевое слово здесь — незапланированное в определении инцидента.
Не соглашусь, т.к. у вас может быть четкий порядок действий по устранению инцидентов, особенно это касается т.н. аварий или кризисных ситуаций, когда подобные действия зачастую регламентированы и они, фактически, направлены на устранение инцидента.
Я для себя условно когда-то разделил по источнику возникновения события. Грубо, если источник — человек (субъект воздействующий на систему) (в примере — человек забыл), то это сервис-реквест. Если источник система (объект воздействия) (система аутентификации недоступна) — инциндент.
В грубом приближении для сортировки хватает.
В грубом приближении для сортировки хватает.
Схема неверная. А что если пришел алерт: заканчивается место на жестком диске, с предполагаемыми действиями — надо архивировать старое и чистить диск пока не возникли никакие проблемы? Это вполне себе «сервис-реквест», хотя конкретный человек тут может быть и не причем. Или, сотрудник сделал «что-то не то» и удалил файл, который был базой отдела — это инцидент, хотя источник человек. Я оставляю за скобками разумность настройки системы, и какие слова надо сказать конкретному админу, примеры просто так, для иллюстрации схемы.
Неверно полагать, что схема неверная, основываясь на домыслах:) В первом случае источник — субъект просто ваша система мониторинга создает уведомление за клиента. А во втором, если это один из вариантов развития событий, это тоже СР. А инцидент — сбой системы авторизации, если такой имел место.
По первому: ну в таком случае все вокруг нас создано руками человека.
По второму: ни разу нет.
По второму: ни разу нет.
Соглашусь с тем, что по первому примеру это типичный сервисный запрос, просто сгенерированный за пользователя, т.к. по факту ему ничего не мешало самостоятельно проверить место на диске и сделать такой же запрос. По второму — это однозначный инцидент, причем вполне себе массовый, т.к. сервис не предоставляется и в принципе не важно, кто сломал систему: пользователь или любые другие внешние факторы. С т.з. бизнес-процесса — это инцидент.
Я вам в нижнем ответ писал, да телефон завис :( В ¨моей¨ классификации, это всеж СР восстановить работу…, а инцидент в данном случае — сбой системы, которая не давала удалять, а тут хлоп — и дала непонятно почему.
Тогда резонный вопрос, кто будет заниматься анализом причин неполадок в системе? Работа по СР это не подразумевает, т.к. там все прямо — надо восстановить работу, как только задача выполнена — СР закрывается. При этом причины возникновения этой ситуации не анализируются и никто не гарантирует повторения в будущем. А из инцидента мог бы лего возникнуть problem record :)
Я вам на конкретном примере приведу, с вашего позволения.
Обращение от клиента:
«не работает электронная почта»
— агент выпытывает из клиента: почтовый клиент выдает «какое-то» сообщение, «я ввел свой пароль, а оно говорит неправильное имя или пароль»
— агент классифицирует как СР, проверяет с клиентом настройки учетной записи и сбрасывает пароль (т.к. клиент его забыл, например :)) Т.е. отрабатываются определенные сценарии.
— проблема не устранена, проблема переквалифицируется в инцидент и пушается дальше
— агент 2 видит, что завис saslauthd. Он устраняет проблему и сообщает клиенту о дальнейших действиях или (возвращает тикет первому агенту). В общем случае это может быть и один человек.
— Проблема решена.
Т.е., по сути, сначала отработаны «дешевые» действия, потом «дорогие». И, наверно, вы не узнаете, что существует проблема, если стандартным сценарием перекроете проблему. И, конечно, даже стандартные проблемы должны анализироватся, т.к. могут послужить причиной каких-то изменений.
— В вашем примере (клиент удалил файл, доступ к которому для него ограничен) конечно, двояко.
Если будет обращение типа «я удалил файл, верните взад», то о проблеме авторизации вы, скорее всего, быстро не узнаете, поскольку покроете стандартным сценарием (напр — восстановите из корзинки).
Если будет отбращение «я зашел на шару, а файла нет», и в корзинке его нет, и глазки не балуются, и откат из какой-то шедоукопии привел к потере данных за какой-то период, то тикет может быть переквалифицирован в инцидент.
Это достаточно индивидуально, поскольку не робо ты ж сидят на местах агентов.
Но в любом случае, анализируя обращения, вы рано или позно проблему вскроете.
А насчет анализирования — дело в том, что действия агентов стоят денег. И если даже какой-то СР приходится выполнять по сто раз на дню, это тратит ресурс, т.е. деньги. Значит требуется доп. анализ для выявления того, что можно еще автоматихировать.
Я еще раз повторюсь, что мой вариант — не панацея, и, возможно, чьи-то практики более вразумительные. Просто вариант, который предложил и использую я меня устраивает в настоящий момент :)
Обращение от клиента:
«не работает электронная почта»
— агент выпытывает из клиента: почтовый клиент выдает «какое-то» сообщение, «я ввел свой пароль, а оно говорит неправильное имя или пароль»
— агент классифицирует как СР, проверяет с клиентом настройки учетной записи и сбрасывает пароль (т.к. клиент его забыл, например :)) Т.е. отрабатываются определенные сценарии.
— проблема не устранена, проблема переквалифицируется в инцидент и пушается дальше
— агент 2 видит, что завис saslauthd. Он устраняет проблему и сообщает клиенту о дальнейших действиях или (возвращает тикет первому агенту). В общем случае это может быть и один человек.
— Проблема решена.
Т.е., по сути, сначала отработаны «дешевые» действия, потом «дорогие». И, наверно, вы не узнаете, что существует проблема, если стандартным сценарием перекроете проблему. И, конечно, даже стандартные проблемы должны анализироватся, т.к. могут послужить причиной каких-то изменений.
— В вашем примере (клиент удалил файл, доступ к которому для него ограничен) конечно, двояко.
Если будет обращение типа «я удалил файл, верните взад», то о проблеме авторизации вы, скорее всего, быстро не узнаете, поскольку покроете стандартным сценарием (напр — восстановите из корзинки).
Если будет отбращение «я зашел на шару, а файла нет», и в корзинке его нет, и глазки не балуются, и откат из какой-то шедоукопии привел к потере данных за какой-то период, то тикет может быть переквалифицирован в инцидент.
Это достаточно индивидуально, поскольку не робо ты ж сидят на местах агентов.
Но в любом случае, анализируя обращения, вы рано или позно проблему вскроете.
А насчет анализирования — дело в том, что действия агентов стоят денег. И если даже какой-то СР приходится выполнять по сто раз на дню, это тратит ресурс, т.е. деньги. Значит требуется доп. анализ для выявления того, что можно еще автоматихировать.
Я еще раз повторюсь, что мой вариант — не панацея, и, возможно, чьи-то практики более вразумительные. Просто вариант, который предложил и использую я меня устраивает в настоящий момент :)
Не пойму, что вы мне доказать пытаетесь :) трактуйте итил так, как вам нравится, это, благо, не возбороняется.
Это Игорю, веточкой промахнулся.
Это Игорю, веточкой промахнулся.
А как тогда быть с проблемами «кривых рук» когда пользователи сами себе ломают/удаляют/перенастраивают? По факту это же недоступность сервиса, а соответственно инцидент. При этом вся работа специалиста ИТ сводится к перенастройке, что очень напоминает предусмотренный в сервисном запросе порядок действий, о котором говорилось выше.
Если ссылаетесь на Глоссарий ITIL то, пожалуйста, соблюдайте принятую в нем терминологию: service request = запрос на обслуживание.
НЛО прилетело и опубликовало эту надпись здесь
ITIL это конечно хорошо, но удобств в нём маловато, конкретики нет например. Лично мне больше нравиться MOF и 3 и 4 версии обе удобны. Вот согласно ему оба пункта и 1) и 2) классифицируются как запрос на информацию.
Вообще там расписано примерно следующее:
SD обрабатывает следующие запросы:
— запрос на устранение инцидентов (техобслуживание, устранение проблем, сглаживание проблем, нахождение обходных решений)
— запрос на изменение (модернизация КЕ, изменение условий работы, улучшение качества)
— запрос на информацию (предоставление доступа, поиск, отчётность)
Опять же это в рамках только SD, под HD это не совсем подходит (но ведь MOF и не для этого создан :)
Вообще там расписано примерно следующее:
SD обрабатывает следующие запросы:
— запрос на устранение инцидентов (техобслуживание, устранение проблем, сглаживание проблем, нахождение обходных решений)
— запрос на изменение (модернизация КЕ, изменение условий работы, улучшение качества)
— запрос на информацию (предоставление доступа, поиск, отчётность)
Опять же это в рамках только SD, под HD это не совсем подходит (но ведь MOF и не для этого создан :)
В понятие «запрос на информацию» входит и пароли сбросить/предоставить и порты открыть и доступ на сайты разблокировать и помочь найти что-нибудь запрятанное в недрах интернета, БД и прочего контента. А также клиента почтового настроить если уж на то пошло. И не важно чья вина, просто это запрос не на обслуживание изначально.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
В очередной раз об инцидентах и сервисных запросах