Статья рассчитана на ИТ персонал и владельцев малого и среднего бизнеса, для которых важны бесперебойность и результативность работы их предприятий. Статья для тех, кто задумывается о Планировании Непрерывности их Бизнеса (business continuity plan или BCP).

Что Вы узнаете из этой статьи: это краткое тематическое вступление и несколько технических моментов (tips), которые должны помочь повысить надежность Ваших ИТ систем и бизнеса вообще.

Важность данного вопрос заключается в том, что некоторые  IT-менеджеры и владельцы бизнеса уверены, что "ничего подобного не происходило ранее" ну или “мы каждый месяц делаем копии”. Либо есть менеджеры, которые пока что не знают, как построить стратегию восстановления бизнеса после аварий. В любом случае, это часто приводит к неготовности быстрого восстановления бизнеса после сбоев.

Некоторой аналогией будет автострахование. Авторы связались с руководством крупнейшей страховой компании Украины и с удивлением узнали, что менее 20% владельцев грузовых автомобилей инвестируют средства в страхование КАСКО. Это означает, что в случае поломок и аварий  только у каждого пятого такого автовладельца есть возможность быстро восстановить свой бизнес.

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

Что это такое

План аварийного восстановления (disaster recovery plan, DRP) является частью плана обеспечения? (я бы сказал организации) непрерывности бизнеса (business continuity plan, BCP) и определяет порядок очередности решения проблем, которые могут возникать в IT-системах из-за возможных сбоев и даже катастроф.

Если я являюсь ИТ-консультантом, то BCP включает в себя вопросы здоровья (страховка), вопросы связи (телефонная и мессенджеры) и  аппаратного обеспечения, резервирование и восстановление данных (к примеру - ssh ключей), юридические и налоговые вопросы, контакты клиентов  и так далее.  

Соответственно, в DRP должны быть отражены только вопросы восстановления ИТ составляющей бизнеса (моб. связь, интернет и прочее).  

Разработка и внедрение таких планов - не такой дорогой вопрос, как кажется. Для ИТ-консультанта может быть  достаточно приобретение запасного канала в Интернет, регулярное резервирование данных (и их восстановление), приобретение UPS, бакапы телефонной книги и знание адреса ближайшей пиццерии, где есть бесплатный wi-fi :)

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

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

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

В качестве примера будет приведена фирма “Автотрейд” (название и некоторые обстоятельства изменены). Пример основан на реальных событиях. Фирма занимается поставками и продажей автозапчастей и инструментов для станций техобслуживания легковых и грузовых автомобилей. Имеет бекэнд-офис (15 человек), неплохой склад недалеко от главного офиса (10 работников) и несколько удаленных точек.

Владельцам фирмы нравится их бизнес (и род занятий достойный и, кажется, есть неплохой доход). Они готовы инвестировать определенные ресурсы в Непрерывность их Бизнеса.

Через несколько лет после создания первоначального плана аварийного восстановления (disaster recovery plan, DRP) у фирмы произошла  неприятность, но благодаря наличию такого плана это существенно не повлияло на бизнес (речь об этом будет идти дальше).

Этапы

 

Узнайте Ваш бизнес

Наиболее важным и трудным шагом является оценка, как незапланированные отключения тех или иных сервисов повлияют на работу организации. Этот шаг называется анализом влияния на бизнес (business impact analysis  или BIA). Не имея возможности определить воздействие незапланированных  отключений, невозможно создать адекватную текущей ситуации стратегию восстановления.

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

Основные  вопросы, на которые нужно найти ответы:

1. Насколько важна каждая функция для организации. Ответ, естественно, зависит от того, насколько сервис влияет на доходы организации.

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

3. Сколько реальных и потенциальных клиентов могут быть потеряны без серьезного  влияния на бизнес?

И последним вопросом будет

4. От каких IT-структур зависит бизнес.

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

Это означало, что в случае аварии/катастрофы в первую очередь должны быть восстановлены:

• 1С + система клиент-банк
• телефоны отдела продаж
• печать товарных накладных и налоговых накладных (выдаются одновременно с товаром)

Второй по важности была функция приобретения товаров у партнеров. Для этого использовались электронная почта и ICQ (Skype был в те времена слабо распространен).

Эти данные были использованы при разработке стратегии восстановления --  в первую очередь восстанавливались те бизнес-функции, которые приносили деньги. Менее важные функции (файл-сервер с внутренними документами) восстанавливались в последнюю очередь.

Результаты этого этапа были документированы и стали основой для дальнейшей работы. Хочется подчеркнуть, что документировать следует каждый этап, а не только собственно процедуры восстановления, оценивать следует в реальных единицах (деньги, часы, клиенты), а не в абстрактных единицах (“много клиентов” или “это важная вещь”). И такой анализ невозможно провести без участия финансовых служб организации.

Суммарные затраты на этом этапе были  - около 20 часов работы персонала и пакет кофе + гонорар  консультанту :)

Для внесения заметок использовались офисный пакет (openoffice.org) и карта памяти (kdissert).

Оцените риски

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

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

Риски делят на две группы:

Естественные, как-то Штормы, Ураганы, Грозы, Затопления, Землетрясения и Цунами.

Искусственные (умышленные и неумышленные). К ним можно отнести Взлом, Мошенничество, Забастовки персонала, Терроризм, Пожары, Ошибки в ПО, сбои аппаратного обеспечения, ошибки персонала, сбои питания и даже падение канала в Интернет.

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

В “Автотрейде”, к счастью, был журнал заявок (тогда это была обычная электронная таблица) и его анализ позволил понять, что основными проблемами были вирусы (в отделе продаж) и регулярно горящие блоки питания.

Также была установлена система мониторинга Nagios и описаны процедуры реагирования на алерты#, что позволило системному администратору увидеть некоторые сбои еще до того, как это повлияло бы на бизнес. К примеру, можно было увидеть, что заканчивается место на диске рабочей станции.

Чтоб уменьшить риски от вирусов, отдел продаж (7 человек) еще на этом этапе был переведен на Linux с возможностью подключения к терминальному серверу Windows. Это позволило в будущем упростить  восстановление данных -- все данные были на сервере.

При оценке рисков следует исходить из здравого смысла. К примеру, для организации, расположенной на самом побережье моря (примером будет при-портовая организация где-нибудь в Одессе) вероятность  события “Шторм” намного выше, чем для офисов, расположенных в Киеве. А расположение офисов в горячих точках планеты намного повышает риск “Терроризм” или “Бомбежка”. Риск “Кража” в хорошо охраняемом офисном центре намного ниже, чем в помещении на территории неработающего завода.

Чем грозят те или иные риски?

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

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

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

Что важнее - должен решать именно бизнес.

На практике, в процессе оценки рисков наиболее сложным было оценить вероятность того или иного события и последствия.

Разговор с управляющим позволил предположить, что риск пожара в головном офисе достаточно велик (“Автотрейд” арендовал помещения в производственном здании одного из заводов), а вот риск захвата предприятия был относительно невелик, так как предприятие в те времена не выделялось размерами среди множества  других.

Основными рисками были искуственные. Те, которые приводили к потере данных (к примеру - Пожар).

Для автора статьи было интересным открытием, что [в отличие от аутсорсинговых фирм],  текучесть кадров значительно не влияла на бизнес. Дело было в том, что из 7 сотрудников отдела продаж пятеро были фактически операторами, фиксирующими заявки. Понимание этого момента позволило упростить процедуру восстановления (в первую очередь должны были быть восстановлены рабочие места именно двух ценных сотрудников).

Как и в прошлом этапе, основные затраты это рабочее время финансового директора   и владельцев организации.

Использовались офисный пакет (openoffice.org) и карта памяти (kdissert), ALT Linux, Nagios + несколько самописных скриптов.

Разработайте стратегию восстановления

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

Ключевым фактором разработки должно быть понимание,  что общая стоимость восстановления не может превышать потери, которые она призвана предотвратить.

Следует учитывать географическое  расположение некоторых сервисов. К примеру, расположение вебсервера у хостера означает, что разработать стратегию восстановления  достаточно сложно. Или изменение места расположения организации означает невозможность быстрой организации интернет-каналов посредством ВОЛС или DSL, поэтому необходимо учесть приобретение 3G оборудования

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

Первый лист Стратегии состоял примерно из таких пунктов:

1. информирование о проблеме владельцев и управляющего фирмы
   требовало создания соответствующей процедуры;
2. приобретение у постоянного поставщика оборудования подходящего сервера , минимум 1 рабочей станции и принтера требовало предварительной договоренности с поставщиком;
3. установка оборудования на складе и размещение там персонала
   требовало размещения дополнительных 3 столов и протягивания локальной сети;
4. установка системного и прикладного ПО на сервер требовало наличия бакапов, полного списка ПО и чек-листов;
5. восстановление реальных 1С (в те времена версии 6) требовало регулярных бакапов и чек-листов;
6.  установка ПО клиент-банк требовало договоренности с Банком;
7.  использование бесплатных почтовых ящиков на время полного восстановления ИТсистемы требовало заранее уведомить Заказчиков и Партнеров о наличии резервных почтовых ящиков и ведения списка контактов клиентов

Важное замечание: стоимость восстановления не должна быть дороже, чем стоимость нанесенного ущерба. Это важно, так как системы должны быть экономически выгодны, они должны поддерживать бизнес, а не “тянуть из него соки”.

К примеру, если удаленная рабочая точка приносит чистой прибыли 50 гривен в день, то восстановление можно произвести “в плановом” порядке - к примеру, во время еженедельного регулярного посещения. И наоборот - если простой интернет-магазина приводит к потерям 5000 гривен в сутки, то DRP должен предусматривать восстановление в течении короткого времени и стоимостью до этой суммы. А для системы онлайн-бронирования билетов вполне может быть выгодным построение HA кластера.

Формализуйте

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

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

На "высоком уровне" (hight point of view), план аварийного восстановления должен обозначить приоритеты для восстановления систем, оценивать примерное время восстановления, процедуры восстановления, а также расположение резервных копий данных и контактов для ключевых вовлеченных сотрудников. Легализация состоит в том, что иногда требуется разрешение на доступ на территорию организации в любое время. ИТ персоналу могут понадобиться полномочия вызвать бухгалтеров для проверки восстановленных систем.

Вспоминая “Автотрейд” следует, сказать, что на “этапе документирования” было сделано практически также вложение в аппаратное обеспечение:

• По результатам стратегии были написаны куча инструкций, чек-листов, приказов и списков (не менее полусотни листов).
• Было приобретено запасное оборудование: мощная машина (“бакап сервер” и она же -- “сервер на время сбоев”), два запасных винчестера (для бакапов) и несколько метров кабеля UTP.
• На склад был проведен резервный канал в Интернет, причем от другого провайдера.
• Была переделана система резервного копирования -- данные из одного офиса копировались в другой ежедневно. Были сняты примерные (образцовые) образы системных дисков и написаны инструкции по быстрой установке на новое оборудование.
• И в бэк-офисе и на складе было оборудовано по три запасных рабочих места (по факту -- проведена локальная сеть и подготовлены запасные стулья)
• Суммарные затраты на оборудование на этом этапе превысили  оплату 1,5 месяца работы местного сисадмина. Конечно, при использовании проприетарного ПО сумма выросла б в несколько раз.

Использовалось только свободное ПО под Linux и Windows. Это были офисный пакет (openoffice.org) и карта памяти (kdissert) для создания документов, а также ПО для создания резервных копий и восстановления данных.

Регулярно тренируйтесь

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

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

Первый же тест в “Автотрейде” показал наличие узких мест в DRP. Было несколько крупных недостатков, из самых смешных:

- восстановить сервер из образов диска с использованием LiveLinux сложно при наличии всего лишь одного  CDROM привода (откуда читать образ оригинального системного диска?)

- работать на “новом сервере” было неудобно, так как просто забыли , что к нему нужно  подключить монитор :)

-  не были продуманы вопросы лицензионного характера

Однако в целом, тренировка прошла успешно:

- “новый офис” был запущен за 1 день (с 10 утра до 4 дня)

- В 1С попали  все “вчерашние” платежи

- почта и интернет работали, можно было по ICQ/почте общаться с партнерами/заказчиками

Конечно, план был улучшен. Задача была выполнена. Для восстановления использовалось только свободное ПО (KNOPPIX-UA) + скрипты, разработанные для клиента.

Давайте подсчитаем, во что обошлось создание плана:

• гонорар консультантам (около двухмесячной оплаты местного сисадмина)
• приобретение дополнительного оборудования (мощный десктоп + монитор, внешние винчестеры)
• приобретение запасного канала в Интернет, создание дополнительных портов ЛВС в обоих офисах
• приобретение пары столов и стульев, много кофе для консультантов
• и около 80 часов работы персонала фирмы “Автотрейд”.

Что получил заказчик?

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

Вместо послесловия

История “Автотрейд” имела продолжение...

Через некоторое время фирма реорганизовала сайт-визитку в нечто типа он-лайн каталога продукции/он-лайн системы заказа.

Соответственно, план должен был быть изменен.

Обновленный план включал  раздел “Восстановление Портала”. Были описаны соответствующие процедуры , создано и установлено ПО на веб-сервере и в бекофисе. И ровно через год, весной прошлого года план пришлось привести в исполнение - был сильный пожар у крупного одесского хостера, где сайт и жил.

Ниже приведена хронология событий со стороны “Автотрейд”:

1. День первый:
   1. система мониторинга прислала сообщение “сайт не доступен”. Это было критично, так как с сайта приходила значительная часть заказов.
   2. в течение часа сисадмин пытался безуспешно дозвониться до провайдера. После этого было информировано руководство фирмы. Так как это был выходной день, было решено отложить решение на сутки.
   3. День второй

 .             в воскресенье была запущена процедура “Восстановление Портала”

1. из ежедневных копий базы данных были извлечены данные о всех клиентах. Клиенты были информированы электронной почтой о проблеме с сайтом и предложено производить заказ по электронной почте. Это позволило разгрузить телефоны и не потерять клиентов
2. DNS (располагался у другого провайдера) был повернут на сайт-заглушку с теми же рекомендациями (сайт андер констракшен, однако контора работает. Прием заказов по тому же мылу что и всегда)
   1. День третий (понедельник)

 .             утром был куплен в заранее присмотренном месте  хостинг  

1. в обед из ежедневных бакапов был полностью восстановлен сайт и повернут DNS
2. вечером в понедельник сайт полностью функционировал
3. все зарегистрированные клиенты были оповещены о том, что сайт полностью работает

“Автотрейд” - B2B фирма, средняя сумма одного заказа намного превышает 1000 гривен. Именно поэтому при разработке DRP было решено, что срок восстановления сайта не более 1 рабочего дня.

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

Интересно, сколько денег в день потеряли и теряют фирмы, которые не имеют DRP и попадают в такие же ситуации?

Послесловие

К сожалению, в нашем регионе привыкли полагаться "на авось".  Ярким примером будет страхование КАСКО, упомянутое в начале статьи. Проведенный авторами опрос показал, что менее 5% небольших организаций и фирм инвестировали ресурсы в создание и поддержку DRP. В конце-концов, это окупается только после сбоя. Видимо поэтому аутсорсинговые фирмы не предлагают подобных услуг, а конечные потребители не так часто задумываются об этом.

Но по мере взросления бизнеса этот вопрос становится все более актуальным. Однако даже серьезный бизнес заинтересован внедрять экономически обоснованные Планы Восстановления Бизнеса.

Снизить стоимость инвестиций в DRP поможет использование opensource систем (отличное качество решений и продуктов при отсутствии платы за право использования) и широкий обмен практическим опытом.  

Для тех, кто хочет узнать больше уже сегодня, информацию можно найти по адресу http://www.disaster-recovery-guide.com/ - Guide to getting started with Disaster Recovery. Сайт выглядит протухшим, однако методология и ключевые моменты изложены компактно и полно.

Wad V Mashckoff aka Adiel,   IT philosopher
ICQ 201205466   E-mail: adiel@nospam.kiev.ua
Linux.Kiev.UA * OpenOffice.org * migration.OSDN.org.ua