суббота, 22 октября 2011 г.

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

Мало кто из ИТ-сотрудников компаний знают, что такое непрерывность бизнеса, и тем более занимаются конкретными процессами восстановления отдельных сервисов. Для того чтобы понять с какой стороны подойти к внедрению этих процессов, я всегда руководствовался следующими простыми правилами – нужно ответить на следующие вопросы:
·         что случится, если ПК сотрудника отдела «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (и так по всем сотрудникам);
·         что случится, если сервер «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (по всем серверам);
·         что случится, если сетевое оборудование «X» выйдет из строя и сколько времени допустимо на восстановление его работоспособности? (по всему оборудованию).
Конечно, нужно рассматривать только критичные ПК, например те, на которых работают сотрудники бизнес подразделений, с которых ведутся платежи и др. в зависимости от направления компании. Точно такой же подход должен быть с серверами – важными могут быть серверы электронной почты, серверы с данными клиентов, серверы бизнес-приложений. Из сетевого оборудования важными всегда являются  маршрутизаторы и коммутаторы уровня ядра, а также оборудование, через которое происходят подключения с сетями клиентов.
Для этого нужно разработать план восстановления (оборудования, ПО, системы и т.д.) в зависимости от типа неработоспособности, внедрить в организации этот процесс и, что самое важное, регулярно проводить тестирование данного плана, по результатам которого вносить в него корректировки.
Само собой, что процессы резервного копирования на уровне данных и восстановление данных из резервных копий никто не отменял. Более того из этого следует, что в компаниях должен быть резерв типовых компонентов на случай выхода из строя существующего оборудования. Имеет смысл в резерве держать только то, без чего нельзя обойтись: процессоры, память, диски. Все остальное должно быть доступно для оперативной покупки в случае возникновения нештатной ситуации.
Если же компания имеет территориально распределенную структуру, нужно мыслить более масштабно. В этом случае помимо вышеуказанных категорий добавляются следующие:
·         что случится, если не работает отдел «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  отделам);
·         что случится, если не работает филиал «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  филиалам);
·         что случится, если не работает технологический или бизнес процесс «X» и сколько времени допустимо на восстановление работоспособности (и так по всем  процессам).
Тут важно понимать, что эффективнее делать в подобных ситуациях: восстанавливать работоспособность в текущем месте, в другом месте, на существующих или на других ресурсах. В каких-то случаях можно заключить договор о взаимопомощи с дружественной организацией. Такая организация должна
В моей практике было несколько примеров восстановления функционирования критичных сервисов, об одном из которых я хочу рассказать.
Случай произошел, когда я работал системным администратором в средней по размерам консалтинговой компании. Стояла задача миграции инфраструктурных решений на базе Microsoft Active Directory (AD) и Lotus Notes/Domino (Lotus)со старых версий на новые. Руководством было принято решение, что миграцией AD будем заниматься мы сами, а миграцией Lotus Notes займется ИТ-интегратор, у которого есть опыт подобной работы. Риски второй задаче заключались в том, что Lotus использовался в качестве корпоративной информационной системы и в нем присутствует важная информация.
По поводу первой задачи ИТ отдел подготовился следующим образом:
·         купили специальную литературу;
·         меня отправили на курсы Microsoft;
·         создали тестовую среду, повторяющую существующую;
·         сделали необходимые резервные копии;
·         провели пробную миграцию в тестовой среде;
·         провели миграцию в продуктивной среде.
Сама миграция происходила с выходные дни. За исключением каких-то мелочей все прошло гладко. Все пришедшие в понедельник на работу сотрудники также как обычно вошли в сеть и продолжили работу.
По поводу второй задачи руководством ИТ было выбрана следующая тактика:
·         поставили задачу интегратору;
·         интегратор провел мини обследование;
·         интегратор составил мини-план миграции;
·         интегратор провел неудачную миграцию.
Стоит рассказать, что же произошло, и как мы выбирались из этой ситуации. Lotus состоял из сервера приложений и сервера баз данных. С целью минимизации затрат было решено не трогать базу данных, а ограничиться только заменой сервера приложений. Интегратором был установлен и настроен новый сервер приложений, однако когда пришло время подключаться к серверу баз данных, выяснилось, что он функционирует как-то не правильно. При ближайшем рассмотрении выяснилось, что его массив вышел из строя, и с ним нужно было что-то делать. Интегратор заверил нас, что это частое явление, и они это сейчас исправят. После того как они поменяли диски местами, установили новый диск и запустили восстановление массива - все поняли, что данные уже не вернуть. Хорошо, что мы сделали на всякий случай резервную копию данных, но, к сожалению, не по фактическому завершению всеми сотрудниками работы, а в 19:00. Далее сотрудники интегратора заявили, что, во-первых, восстановление сервера в их функции не входит, а во-вторых, работа во внеурочное время им не будет оплачена и удалились.
Нам пришлось с нуля восстанавливать сервер баз данных, устанавливать на него все необходимые приложения и восстанавливать данные из резервной копии. Это все было проделано в субботу.  Замечу, что сотрудники интегратора успешно отдыхали все выходные дни.  Полностью работы были доделаны лишь к концу понедельника. Таким образом, частичный простой для компании или, как еще можно выразиться, ее неэффективная работа, продолжалась в целом 1 рабочий день. Также мы потеряли небольшую часть данных, которые восстанавливались до конца понедельника.
Какие ошибки были допущены, и как их можно было избежать?
·         не сохранились данные за последний час работы пятницы – нужно было сделать резервную копию после окончания работы всех сотрудников;
·         вышел из строя массив сервера базы данных – нужно было проверить и подготовить сервер к работам заранее, возможно следовало бы купить новый сервер.
·         часть дня понедельника было потрачено на завершение работ – нужно было предусмотреть в договоре работу интегратора во внеурочное время.

Комментариев нет:

Отправить комментарий