1. Составляем список критичных пользовательских ит-сервисов

Цель планирования аварийного восстановления — обеспечить оперативное восстановление работы конечного сервиса, который получает пользователь, а не какой-то конкретной железки или программы. Пользователю не важно, работает или сломан его принтер – ему важно может он отпечатать документы или нет. Жаловаться пользователь будет не на то, что в сервере отказал жесткий диск, а на то, что у него не работает «1С-ка» или «почта». По этой причине первое, что мы делаем – определяем список критичных пользовательских ИТ-сервисов, для которых будем планировать аварийное восстановление. Обычно это:

• Электронная почта,

• Телефонная связь,

• Система управления предприятием,

• Совместная работа с документами,

• Печать документов,

• Доступ в Интернет,

• И так далее.

По сути, пользовательские сервисы – это те рабочие инструменты, которые покупает бизнес, вкладывая деньги в железо, ПО и зарплаты специалистов и которые критичны для его функционирования.

2. Определяем точки отказа пользовательских сервисов

Если пользователь будет жаловаться на проблемы в каком-то конечном сервисе, то чинить все равно придется конкретный элемент в ИТ-инфраструктуре. Поэтому на данном этапе необходимо обнаружить все системы, приложения и ИТ-сервисы, отказ в работе которых неминуемо приведет к остановке или снижению качества работы критичных пользовательских сервисов. Проще говоря, ваша задача найти все точки отказа. Под точкой отказа мы подразумеваем ту инфраструктурную единицу, о которой мы не можем сказать больше, чем «оно не работает». К примеру, если ваш маршрутизатор модульный, то в нем может отказать как само шасси, так и вставляемые в него модули. Если вашей компетенции достаточно для локализации и замены отказавших блоков в случае сбоя – у вас несколько точек отказа в одном устройства, если нет – то точка отказа одна. Так, у сервиса «Электронная почта» могут быть следующие точки отказа (включая, но не ограничиваясь):

• Серверная ОС,

• Серверное почтовое приложение,

• Коммутатор ядра,

• Электроснабжение,

• Внешняя зона DNS,

• Попадание в «черные списки»,

• Кондиционирование серверной.

Важно! Не надо исключать из точек отказа сверхнадежное оборудование, с которым «точно ничего не случится».

3. Определяем зависимости точек отказа

Сбои в работе некоторых точек отказа могут провоцировать сбои в работе других. К примеру, отказ ИБП приведет к остановке в работе серверов и, как следствие, при восстановлении электроснабжения у вас может не заработать что-то еще. Также и остановка гипервизора может вызвать ошибки в работе виртуальных серверов, размещавшихся на нем. В то же время, отказ клиентского коммутатора не влияет на работу другого оборудования или сервисов, и при его корректной замене все будет работать, как и раньше.

Следующий шаг – опираясь на информацию о точках отказа определить минимально возможные сроки устранения инцидентов, которые могут обеспечить технические специалисты при наличии всех необходимых ресурсов. 1. Готовимся быстро обнаруживать сбойные элементы – составляем процедуры локализации

Самые большие простои случаются тогда, когда специалист техподдержки упорно пытается починить почтовый клиент на компьютере обратившегося пользователя, в то время как надо чинить сам почтовый сервер. Наша задача на данном этапе сделать так, чтобы информация о критичных сбоях оперативно находила нужных специалистов, способных провести работы по восстановлению сервиса, не беспокоя при этом их по пустякам. Для этого мы:

• Создаем процедуры проверки работы пользовательских сервисов и точек отказа. В рамках схемы зависимости, специалист техподдержки должен иметь возможность провести диагностику работы как пользовательского сервиса, так и точек отказа, от которых зависит его работа.

• Настраиваем мониторинг точек отказа. В некоторых ситуациях он раньше пользователей может сообщить о проблемах. В других – позволит исключить часть точек отказа из списка подозреваемых.

• Определяем правила эскалации. В случае выявления проблем, влияющих на бизнес, – немедленно сообщить дежурному системному администратору. Влияющих на подразделение – провести локализацию (не более 5 минут) и привлечь соответствующих специалистов для восстановления или сообщить дежурному системному администратору, если локализовать причину сбоя не удалось и т.д.

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

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