Портал №1 по управлению цифровыми
и информационными технологиями

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

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

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

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

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

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

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

«VAP: Управление изменениями и конфигурациями в ИТ»
Повысить долю успешных изменений, снизить риски, знать всё про конфигурации

Комментариев: 2

  • Андрей Вишняков

    Projected Service Outage 🙂

    • Артем Мукосеев

      Андрей, спасибо!
      Это опечатка ))


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM