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

С чего начать SLA

Опубликовано 30 августа 2011
Рубрики: SLA, SLM, BRM, Практика и опыт
Комментарии

Вчера присутствовал на курсе "Process management and improvement", который вёл Роман Журавлёв. На курсе в очередной раз была поднята тема «Что писать в SLA, когда мы только запускаем SLM, и бизнес не готов формулировать требования»? Конечно, обсудили типичные «ходы»: запуск не по всем, а только по наиболее критичным услугам (где выше потребность и понимание сторон), оценка необходимости SLM до внедрения (ибо, в отличие от поддержки пользователей, этот процесс управления «показан» далеко не всем организациям) и так далее.

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

  • охват резервного копирования;
  • приемлемое время восстановления;
  • сколько данных допустимо потерять (и как / кем они будут восстанавливаться);
  • нужно ли восстановление данных только на точку сбоя или необходима возможность восстановления данных на какие-то заданные точки времени в прошлом (архивный цикл);
  • точность восстановления (вся база, отдельный файл / документ / почтовый ящик / …).

И так далее, всем понятно.

Наличие бэкапов, которые предсказуемо (без сюрпризов для владельцев информационных ресурсов) позволяют восстанавливать данные, значимо не только для заказчиков, но и для ИТ-шников. Если без процессов управления ещё как-то спится по ночам (только вечера и выходные почему-то загружены), то без бэкапов – вообще не жизнь. Вот с этого и можно начать. А если эти требования уже когда-то и где-то зафиксированы, можно проверить их актуальность и зафиксировать «as is».

Опыт показывает, что потребность в восстановлении данных зачастую возникает не в связи с глобальными отказами, а из-за банальных человеческих ошибок. Их не исключить, остаётся только страховаться. Именно такая ошибка и привела к серьёзному нарушению целостности одной из баз данных у нас в компании. Перекрестились и восстановили, в соответствии с договорённостями (письменных SLA нет, но тему проговаривали и согласованные требования остались). Свят-свят…

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

  • Неожиданный поворот, однако.

    Позволю себе обобщение: Пишите о том, что болит сильнее всего. Апеллируйте к инцидентам, которые были замечены заказчиками. Выявляйте важное-но-не-описанное и старайтесь договориться и описать.
    Перефразируя изречение героя одной из любимых книг, “заказчик, который согласен договариваться – это в перспективе заказчик, который согласен”. А о том, что очевидно важно и очевидно не согласовано, заказчик договаривается с куда большей охотой, чем о том, что не согласовано, но непонятно, когда и зачем понадобится.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM