Плановый простой в контексте SLA

Интересно наблюдать, как под воздействием накопленного опыта развиваются интересы и трансформируются приоритеты коллег, с кем выпадает удовольствие работать и не меньшее удовольствие обмениваться опытом в рамках курсов обучения, периодически проходящих у нас в Cleverics. Недавно вышло так, что близкие по содержанию вопросы поднимались слушателями курса «Управление изменениями и релизами ИТ-услуг» (ITIL RCV) и коллегами по проекту. Вопросы касались планирования простоев услуг, необходимых для внедрения изменений.

Один из вопросов был следующий: нужно ли, согласно хорошим практиками, учитывать внеплановые простои, во время которых внедрялись изменения, трактуемые бизнесом как «безотлагательные», в отчётности?

Отвечу в соответствии со своим пониманием. Если коротко — в отчётность нужно включать всё. А вот про что хотелось бы поговорить чуть подробнее, это про те самые «внеплановые простои». Если речь идёт конкретно об изменениях, то важно помнить, что в случае вынужденного «выхода» за пределы согласованных технологических окон возникают риски. Но риски — это ещё не «китайский файрволл». В том смысле, что уволить всех сразу за провальную политику в части изменений в отдельных случаях могут, конечно (как, например, в деловой игре Grab@Pizza), но вообще принятие отдельных рисков — это ещё и способ заработать.

В современных условиях новый функционал необходим бизнесу всё быстрее и быстрее. Если для вашего заказчика критически важно, чтобы какой-то новый функционал стал доступен пользователям ранее следующего технологического окна, важно согласовать с ним риски и обновить документ, который в ITIL называется «Планируемый простой услуг» (Projected Service Outage, PSO). За формирование и актуализацию этого документа отвечает процесс управления изменениями. Но не только он.

При согласовании поправок в графике плановых простоев никак не обойтись без процессов управления уровнем услуг (Service Level Management, SLM) и управления доступностью (Availability Management). Задачи этих двоих следующие: SLM отвечает за обсуждение и согласование с заказчиком целевых показателей доступности, а управление доступностью — за проверку соответствия плановой доступности целевым значениям. Всё упомянутое не только «разовая» работа при внедрении новых услуг, но и постоянная деятельность, запускаемая «текущими» изменениями. В частности, деятельность по уточнению текущих целевых показателей в связи с необходимостью проведения изменений.

Это я всё к тому, что целевые значения показателей на период, когда необходимо внедрить какое-то конкретное безотлагательное изменение, могут быть и пересмотрены, если такая необходимость действительно есть и все заинтересованные стороны готовы её согласовать. Регистрировать ли при этом собственно факт простоя? Получается, что да. Ведь простой происходит вне базового календаря, пусть для него и согласовано отдельное «окно». А постоянная корректировка базового календаря быстро приведёт к неконтролируемому хаосу.  Но вот включать ли такой дополнительный (он ведь уже не совсем «внеплановый», если со всеми согласован) простой в отчётность, а конкретнее — учитывать ли при расчёте показателей доступности? Вопрос несколько дискуссионный, но мне кажется, что в таком случае полезно смотреть на показатель в нескольких разрезах. То есть и с учётом, и без учёта дополнительных простоев, вызванных безотлагательными изменениями. Чтобы можно было оценить влияние таких изменений на доступность в целом.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ДЕК
18
Учебный курс:
Основы DevOps
ДЕК
20
Учебный курс:
Основы ITIL (очно)