Как правильно спланировать аварийное восстановление: определение уязвимых мест

Нет абсолютно устойчивых инфраструктур. Причина сбоя может быть внутри системы, снаружи, в человеке, в железе, в конкуренте, во внезапной катастрофе - восстанавливать работу все равно придется вам, причем максимально оперативно. Чтобы правильно спланировать аварийное восстановление системы сначала нужно определить ее уязвимые места.

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

Итак, с чего же начать?

Критические сервисы

Зачем нужна оперативность в восстановлении инфраструктуры? Чтобы восстановить нормальную работу предприятия. А какие сервисы критичны для этой работы? Вот это-то и главное для восстановления системы! Работа пользователей. Если у вас в сервере откажет жесткий диск, но мгновенно вступит в работу резервный, а пользователь даже не заметит этого, то и восстанавливать систему не нужно будет - ввести, разве что, новый резервный диск взамен отказавшего. А вот если резерва сломанной комплектующей нет, то жаловаться на нее пользователь не станет - он пожалуется на отказавший сервис. Обычно это:

• почта,
• телефония,
• принтеры,
• интернет,
• файловое хранилище,
• 1С и т.д.

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

Точки отказа

Итак, отказывает критически важный сервис, но чинить нам придется не его, а какой-то участок IT-инфраструктуры. Участки, которые приводят к такой ситуации, которые в случае отказа останавливают или серьезно замедляют или ухудшают работу критических приложений, называются "точками отказа". Наша задача - найти их все!

Это, впрочем, может быть и неподъемной задачей - зависит от вашей компетенции. Например, если у вас ее хватает, вы можете локализовать в модульном маршрутизаторе несколько блоков, которые в случае аварии можно заменить, а если не хватает, то пометить точкой отказа сам маршрутизатор.

Так что в этом поиске вам нужно будет найти золотую середину самостоятельно, но вам точно нужно будет поискать точки отказа в:

• Оперативной системе сервера.
• Почтовом приложении сервера.
• Коммутаторе ядра.
• Внешней DNS-зоне.
• Системе электроснабжения.
• Системе кондиционирования.

Само собой, это те опасности, которым подвержены вообще все инфраструктуры, и вы, конечно, найдете в своей еще множество точек отказа.

Уточняем зависимости

Некоторые точки отказа могут быть созависимы. Например, при дурном стечении обстоятельств у вас может выйти из строя сначала почтовая служба сервера, а потом какая-нибудь важная комплектующая - и вы не получите об этом почтового извещения.

Или же у вас может "умереть" система электроснабжения в шасси терминального блейд-сервера - все сервисы на нем, естественно, остановятся.

Чтобы иметь возможность противодействовать таким сбоям, вам нужно будет составить "карту" точек отказа, отдельно пометив среди них взаимозависимые.