Как правильно спланировать аварийное восстановление: определение и предупреждение угроз

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

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

Однако в этой статье мы рассмотрим сроки восстановления IT-инфраструктуры. Как же определить время, которое вам понадобится на работу над сбоем?

Процедуры локализации

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

Для этого нужно будет:

• Создать процедуры проверки пользовательских приложений и точек отказа. Это значит, что сотрудник технической поддержки должен иметь возможность диагностировать как приложение, так и актуальные для него точки отказа.
• Мониторить точки отказа - мониторинг может помочь предупредить сбой еще до того, как пользователи столкнутся с проблемами. Кроме того, информация от мониторинга очень важна в поиске поломки.
• Утвердить правила эскалации. Если выявлена проблема, о ней мгновенно должен узнать дежурный сисадмин, а ответственные лица (как правило речь идет о начальнике отдела) должны привлечь для восстановления соответствующих специалистов и локализовать проблему. О результате локализации также должен как можно скорее узнать дежурный сисадмин.
• Обучить сотрудников технической поддержки тому, какие элементы инфраструктуры обеспечивают те или иные пользовательские сервисы и как в соответствии с этой информацией диагностировать точки отказа.
• Оценить время на локализацию сбоя относительно каждой из известных точек отказа. Больше всего времени будет уходить на локализацию, и для дальнейших расчетов количество этого времени нам пригодится.

Ресурсы и условия восстановления

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

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

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

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

Выясняем время восстановления

Итак, чтобы понять, какое время вы затратите на восстановление сервиса, вам необходимо сначала определить гарантированное время восстановления точки отказа (с такой неопределенной переменной, как ее нахождение). Как правило, ошибка исправляется гораздо быстрее, чем проводится полное восстановление системы, но гарантировать сроки можно только по второму сценарию, так что давайте ориентироваться на него.

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

Можно оптимизировать сроки восстановления:

• Подумать о сокращении исследования инцидентов (так мы увеличим риск потери данных).
• Изменить архитектуру так, чтобы точки отказа не были созависимы.
• Заранее подготовиться к тем или иным отказам - сделать закупки резервного оборудования.

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

Ищем слабые места

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

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

Однако вы можете смягчить удар.

Главное - это, конечно, бэкапы. Расположите их в офисе, вне офиса, в облаке, в банковской ячейке - продумайте перекрестное резервное копирование. То же самое и с резервами - если не хранить их в разных местах, то хотя бы обезопасить от форс-мажора можно.

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