Вчера присутствовал на курсе "Process management and improvement", который вёл Роман Журавлёв. На курсе в очередной раз была поднята тема «Что писать в SLA, когда мы только запускаем SLM, и бизнес не готов формулировать требования»? Конечно, обсудили типичные «ходы»: запуск не по всем, а только по наиболее критичным услугам (где выше потребность и понимание сторон), оценка необходимости SLM до внедрения (ибо, в отличие от поддержки пользователей, этот процесс управления «показан» далеко не всем организациям) и так далее.
Однако недавний инцидент у нас в компании навёл меня на дельный совет: пишите требования к резервированию и восстановлению данных. Это тема очень понятна заказчикам и вполне проработана для того, чтобы правильно задавать наводящие вопросы:
- охват резервного копирования;
- приемлемое время восстановления;
- сколько данных допустимо потерять (и как / кем они будут восстанавливаться);
- нужно ли восстановление данных только на точку сбоя или необходима возможность восстановления данных на какие-то заданные точки времени в прошлом (архивный цикл);
- точность восстановления (вся база, отдельный файл / документ / почтовый ящик / …).
И так далее, всем понятно.
Наличие бэкапов, которые предсказуемо (без сюрпризов для владельцев информационных ресурсов) позволяют восстанавливать данные, значимо не только для заказчиков, но и для ИТ-шников. Если без процессов управления ещё как-то спится по ночам (только вечера и выходные почему-то загружены), то без бэкапов – вообще не жизнь. Вот с этого и можно начать. А если эти требования уже когда-то и где-то зафиксированы, можно проверить их актуальность и зафиксировать «as is».
Опыт показывает, что потребность в восстановлении данных зачастую возникает не в связи с глобальными отказами, а из-за банальных человеческих ошибок. Их не исключить, остаётся только страховаться. Именно такая ошибка и привела к серьёзному нарушению целостности одной из баз данных у нас в компании. Перекрестились и восстановили, в соответствии с договорённостями (письменных SLA нет, но тему проговаривали и согласованные требования остались). Свят-свят…
Неожиданный поворот, однако.
Позволю себе обобщение: Пишите о том, что болит сильнее всего. Апеллируйте к инцидентам, которые были замечены заказчиками. Выявляйте важное-но-не-описанное и старайтесь договориться и описать.
Перефразируя изречение героя одной из любимых книг, “заказчик, который согласен договариваться – это в перспективе заказчик, который согласен”. А о том, что очевидно важно и очевидно не согласовано, заказчик договаривается с куда большей охотой, чем о том, что не согласовано, но непонятно, когда и зачем понадобится.