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

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

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

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

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

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

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

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

ITIL ITIL Intermediate: Service Offerings and Agreements

Учебный курс: проектирование и предоставление ИТ-услуг, SLA и SLM, экономика и финансы ИТ, управление поставщиками и подрядчиками — в ITIL и на практике.
 

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

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

  1. Роман Журавлёв

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

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

    Перефразируя изречение героя одной из любимых книг, «заказчик, который согласен договариваться — это в перспективе заказчик, который согласен». А о том, что очевидно важно и очевидно не согласовано, заказчик договаривается с куда большей охотой, чем о том, что не согласовано, но непонятно, когда и зачем понадобится.

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

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

Empty