Непрерывность с примером

Мало кто из ИТ-сотрудников компаний знают, что такое непрерывность бизнеса, и тем более занимаются конкретными процессами восстановления отдельных сервисов. Для того чтобы понять с какой стороны подойти к внедрению этих процессов, я всегда руководствовался следующими простыми правилами – нужно ответить на следующие вопросы:

·         что случится, если ПК сотрудника отдела «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (и так по всем сотрудникам);

·         что случится, если сервер «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (по всем серверам);

·         что случится, если сетевое оборудование «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (по всему оборудованию).

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

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

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

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

·         что случится, если не работает отдел «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  отделам);

·         что случится, если не работает филиал «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  филиалам);

·         что случится, если не работает технологический или бизнес процесс «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  процессам).

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

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

Случай произошел, когда я работал системным администратором в средней по размерам консалтинговой компании. Стояла задача миграции инфраструктурных решений на базе Microsoft Active Directory (AD) и Lotus Notes/Domino (Lotus)со старых версий на новые. Руководством было принято решение, что миграцией AD будем заниматься мы сами, а миграцией Lotus Notes займется ИТ-интегратор, у которого есть опыт подобной работы. Риски второй задаче заключались в том, что Lotus использовался в качестве корпоративной информационной системы и в нем присутствует важная информация.

По поводу первой задачи ИТ отдел подготовился следующим образом:

·         купили специальную литературу;

·         меня отправили на курсы Microsoft;

·         создали тестовую среду, повторяющую существующую;

·         сделали необходимые резервные копии;

·         провели пробную миграцию в тестовой среде;

·         провели миграцию в продуктивной среде.

Сама миграция происходила с выходные дни. За исключением каких-то мелочей все прошло гладко. Все пришедшие в понедельник на работу сотрудники также как обычно вошли в сеть и продолжили работу.

По поводу второй задачи руководством ИТ было выбрана следующая тактика:

·         поставили задачу интегратору;

·         интегратор провел мини обследование;

·         интегратор составил мини-план миграции;

·         интегратор провел неудачную миграцию.

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

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

Какие ошибки были допущены, и как их можно было избежать?

·         не сохранились данные за последний час работы пятницы – нужно было сделать резервную копию после окончания работы всех сотрудников;

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

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