На недавнем курсе слушатели, работающие в крупном системном интеграторе, смогли найти в ITIL V3 очередное противоречие. Их находкой хочу поделиться с вами. Итак: два понятия.
Первое – это SLA: соглашение между поставщиком ИТ-услуг и заказчиком. Соглашение об уровне услуг описывает ИТ-услугу, документирует целевые показатели уровня услуги, указывает зоны ответственности сторон – поставщика ИТ-услуг и заказчика.
А второе – это часть определения инцидента из книги Service Operation: …Сбой конфигурационной единицы, который еще не повлиял на услугу, также является инцидентом, как, например, сбой одного диска из массива зеркалирования… (отличное слово, кстати: женщины перед походом в театр зеркалируют часами).
Для моих слушателей SLA – очень понятная штука, ведь это обязательства, которые их организация юридически берёт на себя. И "целевые показатели уровня услуги", такие как сроки устранения инцидентов и доступность, для них не абстрактные слова, а именно то, за что они получают деньги.
И вдруг, ITIL, всё про SLA хорошо объяснив и подтвердив практический опыт, огорошил их: несмотря на то, что устранение инцидентов может предоставляться дискретно (например, только днём, с 9 до 18), инцидент, обнаруженный в «нерабочее» время, следует устранять немедленно. Или, если взять "зеркалирование" – то придётся восстанавливать диск за свой счёт, а пользователи и заказчик вообще ничего об этом не узнают.
Получается, поставщик услуг, чтобы устранить инцидент, еще не оказавший влияния на пользователей, понесёт дополнительные расходы на устранение инцидента, не заложенные в SLA. Неужели работать себе в убыток, только ради того, чтобы пользователи и не узнали о том, что что-то ломалось?!
«А город подумал – ученья идут…». Но геройствовать, вслед за лучшими практиками, мои слушатели не хотят.
Как быть? Кто прав?
Константин, давайте пытаться искать логику.
SLA – документ, определяющий уровень и условия предоставления услуг по согласованию заказчика и ИТ-организации.
Инцидент – событие в ИТ-инфраструктуре, которое повлияло или может повлиять на снижение качества предоставляемых ИТ-услуг.
В SLA вам ITIL не запрещает написать что угодно. В т.ч. “мы устраняем только те инциденты, которые привели к недоступности услуги для пользователя”. В таком случае пользователи наступают на грабли, вы честно всё чините.
Есть ли в этом польза? Счастливы ли пользователи? Движется ли бизнес в такой модели поведения, помогаете ли вы ему?
ITIL много говорит о проактивности и об управлении рисками. Если у вас случился инцидент, который может повлиять на снижение качества услуг (например, упала резервная нода в кластере), разве ж ваш реальный заказчик не будет её чинить? Безотносительно существования каких бы то ни было SLA и т.д. – Ведь будет же. Здесь в процессе управления инцидентами есть определенная проактивность, на мой взгляд, хотя ITIL явным образом не разделяет этот процесс на реактивную и проактивную составляющую.
И ещё два слова о дополнительных расходах: если так рассуждать, что нам не нужны дополнительные расходы, то процессы управления проблемами, управления доступностью, управления мощностями вообще не нужны. Это же тоже дополнительные расходы, не связанные с реальными неприятностями, уже случившимися у пользователей. Зачем этим всем вообще заниматься тогда?
Все дополнительные расходы нужно закладывать в себестоимость услуг, и в цену для заказчика в итоге. Иначе, как у вас и получается, ИТ придётся с бизнесом подписывать SLA и брать деньги не за работающую услугу или систему, а за каждый инцидент. И тогда действительно – никакой проактивности, лишь бы оно почаще ломалось, а мы доблестно с этими поломками боролись.