Скептик неспешно читает ITILv3 Service Operation.
... и неожиданно обнаруживает, что в процедурах Управления Инцидентами нет сопоставления Услуги Инциденту. А значит, нет и сопоставления SLA. Интересно, а чего он ожидал?
Кто не верит - смотрите в процедуру 4.2.5.2 Incident logging (а потом все прочие) и попробуйте найти там явно упомянутое поле Service или SLA. Соответственно, никакого анализа воздействия на услугу в Управлении Инцидентами тоже провести не получится. Ну и Каталога Услуг, по-видимому, тоже нет.
четверг, 27 августа 2009 г.
Очередная ошибка в ITILv3
Подписаться на:
Комментарии к сообщению (Atom)
4 комментария:
Позволю себе прокомментировать.
Думаю, ни для кого не секрет, что ITIL надо читать и понимать на разных уровнях. Так уж исторически сложилось. Так вот, на «первом уровне» понимания, казалось бы, действительно, как же так — инцидент не привязывается к услуге и SLA?
На самом же деле я полностью поддерживаю отсутствие такой прямой связи. Поясню: один инцидент может влиять на работоспособность нескольких услуг сразу.
Пример: мыши перегрызли оптику между дата-центром и удалённым офисом. Какие услуги получает этот офис? Никакие, ничего не работает. Сколько произошло инцидентов? Правильно, один, с мышами и оптикой.
Резонный вопрос: а как же быть, и как всё правильно связать? Разумеется, через нашу любимую ресурсно-сервисную модель. Инцидент привязываем к КЕ (CI), который через ресурсно-сервисную модель влияет на работоспособность различных услуг.
А к услугам и SLA напрямую было бы целесообразно привязывать скорее обращения (хотя в ITIL такой сущности и нет в явном виде).
Надо понимать, что в SLA могут быть разные типы SLO (Service Level Objectives) - например, по времени выполнения обращения (тут нам пригодилась бы привязка обращений к услугам и SLA) и по доступности (а вот тут уже работает ресурсно-сервисная модель и пробивка инцидентов с отдельно взятыми CI на услуги, которые от этого CI в той или иной степени зависят).
А отсюда уже и следует разновсяческий анализ инцидентов и их влияния (хотя он проводится, понятное дело, не только в рамках процесса Управления инцидентами, но и в Управлении доступностью, Управлении проблемами, мощностями и т.д.)
Так что, по моему глубокому убеждению, ITIL совершенно правильно говорит.
Антон, приветствую! Столь подробный и интересный ответ требует комментария.
По пунктам.
Конечно, относиться к ITIL можно по-разному. Мне по душе подход: брать лучшее, однако не скрывать и не затенять недостатков. Коллеги часто отмечали, что я зря требую от ITILv3 излишней логичности и стройности. А разве не логическая связность в первую очередь определяет качество стандарта, модели, обобщения хороших практик, в конце концов? Есть связность и стройность изложения - текст качественный. Нет - извините.
Назвать ITILv3 качественным и связным текстом, увы, не могу. Даже в контексте советов (лучших практик). К примеру, есть ли прямой совет о возможности использования нескольких услуг для классификации инцидента? Его нет.
Возьмем предлагаемую тобой модель (Incident - CI - Service[s]). Сама модель интересная, но достаточно спорная - это тема отдельного разговора. Допустим для чистоты эксперименты, что именно это и имели ввиду разработчики ITILv3 (хотя я и бритва Оккама так не думаем). Давай прикинем, кроме аналитики - зачем нужна Услуга (Service) в классификации Инцидента? Назначение параметров выполнения (простейший из которых - плановый срок). Чем будут определяться параметры выполнения Инцидента, который затрагивает несколько услуг? Самым "лучшим" уровнем сервиса из всех услуг, "худшим"? Неким усредненным? Или уровнем сервиса какой-либо операционной услуги, поддерживающей все затронутые бизнес-услуги? А подскажи, почему бы это не написать прямо в тексте?
Я мыслю просто - если этого в тексте нет, то это явная недоработка. Конечно, трактовок можно придумать изрядное количество. Но ведь мы не прозу за авторством Нострадамуса читаем, а обобщенный опыт индустрии. Который, между прочим, в практике нам же использовать.
Любая двумысленность, относящаясь к завленному охвату библиотеки, допускающая двойное толкование - это прямая недоработка авторов библиотеки.
Я всегда воспринимал и воспринимаю ITIL как:
(а) свод лучших практик, но никак не стандарт и вряд ли как модель;
(б) некую «книгу тайн», которую нужно читать и воспринимать на разных уровнях; допустим, ты прочитал, понял и реализовал рекомендации ITIL на одном уровне понимания, потом понял что-то, получил определённый уровень просветления, и затем читаешь и понимаешь тот же самый ITIL на другом уровне.
Исходя из этого, я:
(а) считаю, что не нужно ожидать от ITIL строгости и всеобъемлющего изложения, т.е. если что-то не изложено и не уточнено, значит, возможно, в этой части best practices отсутствуют;
(б) пытаюсь читать «между строк» и думать о том, что говорит ITIL, так сказать, будучи open minded.
Что касается твоих конкретных вопросов и предположений, то я думаю, что указание услуги в инциденте — это нормальное решение, возможно, самое простое из возможных, но есть более красивые варианты, хотя и более сложные. Поэтому ITIL молодец, что не ставит рамок. А разработчики софта молодцы, что придумывают разные способы реализовать ресурсно-сервисно-SLA-ную связь, оставаясь ITIL compliant.
Ну и нам есть о чём подумать… Что тоже приятно.
Все-таки, Антон, у нас с тобой настолько разный подход к тексту ITIL, что спорить-то по сути и не о чем!
Надо бы написать об этом отдельно 8)
Отправить комментарий