4. Определяем факторы риска процедуры аварийного восстановления и планируем мероприятия по их контролю

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

• проверка корректности создания резервных копий,

• проверка качества работы резервных каналов связи,

• контроль наличия необходимых резервов оборудования,

• контроль состояния источников бесперебойного питания и генераторов,

• анализ соответствия планов полного восстановления текущему положению дел,

• и т.д.,

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

5. Определяем ситуации, выходящие за рамки планирования

Самое сильное негативное влияние на бизнес оказывают не единичные (или последовательные) отказы, к которым технические специалисты готовы в той или иной мере, а форс-мажорные ситуации, приводящие к параллельному падению нескольких одинаковых систем. Пожары, сильные перепады напряжения, вирусные атаки и даже неправомерные действия третьих лиц могут не только нанести сильный урон, но и стать фатальными для бизнеса. В таких ситуациях сложно применять термин «оперативное восстановление», но есть ряд мероприятий, которые позволяют смягчить удар:

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

• Определить приоритетность восстановления пользовательских сервисов. Всегда есть что-то единственное, без чего бизнес не выживет – все остальное подождет.

• Обезопасить резервы от влияния форс-мажорных факторов. Если резервы укомплектованы в полном объеме, то как минимум один сервис вы на них запустите.

• Подготовить (ну или хотя бы наметить) резервную площадку для развертывания. Хоть в квартире генерального директора – на войне все средства хороши.

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

2. ACL (access control list) — это строго говоря, механизм для выбора из всего потока трафика какой-то части, по заданным критериям. Например, через маршрутизатор проходит множество пакетов, и вот такой ACL выбирает из множества только те пакеты, которые идут из подсети 192.168.1.0/24:

access-list 1 permit 192.168.1.0

Что дальше делать с этим трафиком — пока неизвестно. Например, трафик, попавший под ACL может заворачиваться в VPN тоннель, или, подвергаться трансляции адресов (NAT). В курсе CCNA рассматривается два способа использования ACL: основной — это фильтрация трафика, второй — использование ACL при настройке NAT. Важно следующее: не имеет значения, где и для каких целей мы будем использовать ACL, правила написания ACL от этого не меняются. Кроме того, если мы только создали ACL, то он пока ни на что не влияет. ACL — это просто несколько неработающих строчек в конфиге, пока мы его не применим, например, на интерфейс, для фильтрации трафика.