Статьи здесь

Выступления здесь

Обеспечение непрерывности бизнеса

Виктор Галактионов
к.т.н., вице-президент, главный системный архитектор, ОАО «Альфа-банк»

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

Многим руководителям знакомы еще со времен советской эпохи внутренние распоряжения, издаваемые, как правило, перед очередными праздниками. примерно следующего содержания «1. На период праздников назначаются следующие дежурные: [далее идет перечисление ответственных лиц достаточно высокого ранга расписанных по датам]. 2. В случае наступления чрезвычайных ситуаций принимать неотложные меры по из ликвидации»… Если вы, изучая эти распоряжения, задавались вопросами, а почему такая особая забота проявляется исключительно по праздникам, разве в обычные выходные дни не нужно выключать чайники из сети? А что значат «чрезвычайные ситуации» – это обесточивание здания, это прорыв канализации, это землетрясение? Что значит «принимать неотложные меры по их ликвидации» – как может вице-президент пусть даже очень большой компании ликвидировать землетрясение? Как определить адекватность и степень неотложности принимаемых мер с уровнем критичности возникшей ситуации? Если вы задавались этими вопросами, то эта статья для вас.

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

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

Главная цель плана обеспечения непрерывности – обеспечение поддержки работы ключевых бизнесообразующих подразделений компании. Поэтому часто план обеспечения непрерывности называется «планом продолжения бизнеса». Если на план смотреть с позиций событий, которые несут существенную угрозу остановки части или всего бизнеса компании, то употребляют термин «план восстановления бизнеса». Аварийные планы, сфокусированные на преодолении повреждений или разрушений оборудования в результате наводнений, пожаров и других стихийных бедствий, известны как «аварийно-восстановительные планы». В литературе и в практике также встречаются другие названия: аварийный план (crash plan), чрезвычайный план (disaster plan), планом продолжения (contingency plan), план восстановления (recovery plan). Как правило, чтобы подчеркнуть важность решаемых планом задач, в названии плана всегда фигурирует слово business (business contingency plan, business recovery plan). Термин же «план обеспечения непрерывности бизнеса» является наиболее общим и более всего соответствует конечным целям любого такого плана – целям непрерывности и сохранения бизнеса при наступлении чрезвычайных ситуаций, а также восстановления бизнеса после выхода из чрезвычайной ситуации.

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

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

Что такое «План обеспечения непрерывности бизнеса» и кто его составляет?

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

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

Проекты этих планов должны быть переданы руководству компании, а так же внутренним заказчикам и поставщикам. В некоторых случаях они так же должны быть предоставлены внешним заказчикам и поставщикам (однако, в этом случае необходимо решить определенные юридические вопросы). Это делается для того, чтобы рассмотреть планы с как можно большего числа точек зрения. Руководство компании, например, может посчитать, что некоторые услуги не должны предоставляться вручную (даже если это возможно) с тем, чтобы персонал мог подключиться к работе других подразделений, продолжение нормальной работы которых более приоритетно. Поставщики и заказчики должны видеть, какие действия планируются в их отношении, равно, как и ИТ подразделения должны понимать и учитывать их планы. Такой итеративный процесс дает гарантию, что планируемые действия – это, безусловно, «лучшее, что можно предпринять» в случае наступления чрезвычайных ситуаций, в случае неполадок в информационной системе.

С чего начать?

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

Аспекты для включения в план

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

·         Упрощенное обслуживание – Можно ли упростить процессы обслуживания? Позволит ли это поддержать процесс обслуживания на достаточном функциональном уровне?

·         Новые приемы работы – Например, поможет ли распределение клиентов между большим количеством обслуживающего персонала существенным образом снизить объем выполняемой каждым работником ручной работы и, таким образом, продолжить обслуживание клиентов?

·         Зажатие входного потока – Можно ли «зажать» входной поток клиентский поручений/заявок с целью снижения его интенсивности? Можно ли провести ранжирование заявок по степени важности и срочности? Можно ли провести ранжирование услуг/операций с целью продолжения реализации тех услуг, которые не задеты чрезвычайной ситуаций? Можно ли часть отложить обслуживание части заявок и на основании какого критерия? При реальной угрозе потери клиентов необходимо ответить на вопрос, можно ли провести ранжирование клиентов по степени важности для организации? Каких клиентов нужно сохранить ценой потери других клиентов?

·         Тренировка – В какой тренировке и практике нуждается персонал, чтобы выполнить эти ручные процедуры?

·         Тестирование – Каким образом можно и нужно протестировать ручные процедуры?

·         Клиенты и прочие запросы – Если вы планируете приостановить или существенно ограничить обслуживание, запланированы ли адекватные ресурсы для ответов на вопросы клиентов? Как предполагается отвечать на вопросы дирекции и средств массовой информации?

·         Альтернативные поставщики – Существуют ли альтернативные поставщики услуг, на которых можно оперативно переключиться в случае возникновения проблем у основных поставщиков?

·         Пиковые нагрузки – Существуют ли пиковые нагрузки в графике обслуживания, которые не позволят выполнять процесс вручную? Не будет ли  лучше в этом случае вообще прекратить обслуживание либо сократить спектр предоставляемых услуг? Если ДА, то регламентируйте два режима ручного обслуживания – при нормальной и при пиковой нагрузке.

·         Бланки – Существуют ли в достаточном количестве необходимые для ручной работы бланки, формы, конверты и т.п.?

·         Диагностика – Требуется ли персоналу специальная диагностика приложений при выполнении ручных процедур?

·         Переработки – Потребуются ли переработки или изменение графика работы для выполнения ручных процедур? Если ДА, то достаточно ли персонала необходимой квалификации для укомплектования всех смен?

·         Дополнительные ресурсы – В тех случаях, когда для выполнения ручных процедур потребуется дополнительный персонал, будут ли нужны дополнительные столы, телефоны и прочее конторское оборудование? Следует ли дополнительное оборудование подготовить заранее?

·         Переводы – Потребуется ли перевод персонала в другие подразделения для выполнения (вручную) высокоприоритетных процедур обслуживания?

·         Отсутствие персонала – Каковы ваши действия в случае отсутствия ключевых работников по болезни или другим причинам?

·         Системы клиентов и поставщиков – Взаимодействуете ли вы с  системами клиентов или поставщиков? Можете ли вы что-то предпринять сейчас, чтобы продолжить обслуживание в случае, когда ваша система работает, а у клиента (или поставщика) нет? Обсуждали ли вы с клиентами (поставщиками) ваши планы продолжения бизнеса? Правильно ли они их понимают? Предоставлены ли вам планы продолжения бизнеса ваших клиентов и поставщиков? Правильно ли вы их понимаете? Все разногласия в этих вопросах должны быть устранены до наступления чрезвычайных обстоятельств. Помните, что непрямые, последовательные и каскадные аварии и их взаимосвязи могут привести к таким ситуациям, которые вы не в силах предусмотреть.

·         Другое оборудование – Используются ли у вас кассовые аппараты, кредитные карты или другое оборудование, которое невозможно протестировать в полной мере? Будут ли приложения работать без этого оборудования? Будет ли оборудование работать без приложений?

·         Настольные приложения – Настольные приложения, такие как электронная почта, интернет, электронные таблицы, локальные базы данных, текстовые процессоры (вместе с их документами, индексами, таблицами и т.д) так же могут быть недоступны; или ваш настольный компьютер работает, но не подключен к сети; или имеются проблемы с сетью. Помните, что большинство ваших рабочих файлов расположено на сетевых устройствах. Должны ли быть предусмотрены процедуры резервирования (копирования) критических файлов на локальные диски? Помните также, что большинство принтеров – это сетевые принтеры. Проблемы с сетью лишат вас возможности что-либо распечатать даже при исправном компьютере и принтере.

·         Компоненты собственной разработки – Где используются неформально разработанные программные компоненты? На сколько эти разработки критичны для бизнеса? Смогут ли разработчики подобных программ совмещать их исправление с ручным выполнением процедур? Что более важно – скорейшее исправление программы или выполнение аналогичных операций вручную?

·         Восстановление – После того, как приложение вновь стало доступным, какие процедуры необходимо выполнить, чтобы проверить и интегрировать в общую базу вручную введенные данные? Требуется ли тщательная проверка данных, которые НЕ были разрушены в результате локального сбоя? Требуется ли снижение рабочей нагрузки на период восстановления? Требуется ли дополнительный персонал, чтобы поддержать уровень рабочей нагрузки на период восстановления? Требуется ли ограничение доступа к обновляемым (восстанавливаемым) базам данных? Есть ли для этого средства или требуется перепрограммировать контроль доступа?

Сценарии чрезвычайных ситуаций

На непрерывность бизнеса оказывают влияние два типа угроз.

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

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

Риски второй категории значительно сложнее учитывать и зачастую невозможно решить в рамках одного проекта, если в компании параллельно с одним проектом ведется целая проектная программа из несколько взаимозависимых проектов. Проекты, связанные с ИТ, зачастую имеют сильный уклон в технические аспкты. Безусловно, проектная команда может и должна разработать превентивные меры: например, продублировать канал информационного взаимодействия, разработать процедуры копирования критической информации на внешние носители  и передачи этого носителя в смежное подразделение через курьера, процедуры перехода с выделенных каналов связи на коммутируемые с потерей скорости передачи данных в 50-100-200 раз. Но зачастую отдельно взятый ИТ проект не может ответить на более общие интегральные бизнес вопросы:

·         насколько уменьшилась производительность (пропускная способность) отдельного бизнес-подразделения в связи с падением основного программного комплекса и(или) переходом на резервные механизмы.

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

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

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

Вымышленный, но, тем не менее, вполне реальный случай. В запланированный день «Икс» после запуска системы расчетов в боевую эксплуатацию в самом начале все находится под контролем и функционирует в полном соответствии с бизнес требованиями заказчика. В какой то момент падает сервер приложений (безусловно, в этом случае виновный будет найдет и он встанет к стенке ;-) или, что существенно хуже, падает сама система расчетов (в этом случае, смею заверить, виновного тоже найдут, но вопрос не в том кто будет объявлен виновным, а что делать дальше). Программисты, зажав зубами провода, героически ложатся стопками под швейцарский поезд, идущий строго по расписанию. Система продолжает работать на резервных механизмах, но производительность уже не та или уже вообще равна нулю. Платежи не уходят или уходят не по 10000 макетов в рейс, а по 100. При этом очереди исходящих платежных документов растут. Рано или поздно встанет вопрос: уходить назад или продолжать дальше? Программисты знают точно, что устранение проблемы может быть проведено только ночью, когда все бизнес процессы будут остановлены. Они также знают, что для того, чтобы вернуться назад, им нужно, например, один час и сорок три минуты работы. Руководитель проекта в момент принятия эпохального решения об откате назад должен иметь четкое представление, будут ли до 8 часов вечера при сложившейся производительности очереди платежных документов обработаны или нет. Кто скомандует бизнесу прекратить работу на один час сорок три минуты и даст программистам отмашку возвращать все «взад»? Очевидно руководитель проекта, но этот главнобизнесокомандующий должен не столько иметь для этого полномочия, сколько иметь полномочия приостановить работу смежных зависимых подразделений. Итак, представим себе, что работа по откату закипела. Но в это время фронты и дополнительные офисы продолжают в штатном режиме принимать платежные документы, совершать сделки, заключать договора по "межбанку" даже не ведая, что система расчетов стоит и вовсе не факт, что принятый сегодня к исполнению платеж уйдет сегодня же. В теории управления в случае выхода из строя одного из звеньев системы остальные должны или должным образом перестроиться, чтобы локализовать и устранить сбойный элемент, и продолжить функционирование в штатном режиме, или принудительно понизить интенсивность входного потока ("зажать" входной поток), хотя бы с частичным отказом в обслуживании отдельным категориям входящих заявок, чтобы не остановить работоспособность всей системы в целом. В нашем примере банку лучше отказать среднестатистическому клиенту в обслуживании – клиент поворчит и придет завтра, или лучше не разместить средства – получить, извините за каламбур, недополученную прибыль, чем завтра платить многомиллионные штрафы. Но эти вопросы уже выходят за рамки компетенции руководителя центра расчетов. Вот здесь возникают общие вопросы: кто, когда, на основании чего примет решение о "зажиме" входящего потока, каким образом и кого известит об этом? Какие операции относятся к низкоприоритетным и должны "зажиматься" в первую очередь? Какие – во вторую очередь? Но ведь после устранения первопричин и возврата системы в штатный режим работы нужно и бизнес вернуть в штатный режим работы? Кто должен будет в последствии отдать эти приказы для перехода в штатный режим? Формально бизнес не починяется ИТ, поэтому даже CIO не уполномочен давать таких указаний. Хотя, безусловно, ИТ принимает в этом самое непосредственное участие.

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

Вопросы управления проектными рисками являются темой другой статьи и далее не рассматриваются.

Содержание Планов обеспечения непрерывности

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

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

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

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

Требования к составу

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

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

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

·         С другой стороны, проблемно-ориентированный раздел имеет дело с управлением операционными рисками. Он готовится пользователями системы при консультационном участии проектировщиков системы, операторов и персонала поддержки. Раздел содержит процедуры, которые должны быть выполнены пользователями системы непосредственно до, во время и сразу после отработки определенной проблемы. Примерами такого рода проблем могут быть сбои питания, аварии системы, несовместимые данные, потеря коммуникаций и т.п.

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

Заключение

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

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

Последнее обновление 15.08.2007