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

«Дело умных — предвидеть беду, пока она не пришла; дело храбрых — управляться с бедой, когда она пришла».

Питтак

Так уж сложилось, что сегодня ни одно рассмотрение проблематики обеспечения катастрофоустойчивости и аварийного планирования ЦОД не обходится без ссылки на трагедию 11 сентября 2001 г., когда был разрушен Международный торговый центр в Нью-Йорке, в результате чего работа компаний, имевших свои офисы в WTC, была парализована на длительный срок. Одна из основных причин — отсутствие возможности оперативно восстановить уничтоженную корпоративную информацию, пусть даже на альтернативной площадке. В большинстве же случаев данные вообще оказались безвозвратно утерянными.

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

Закономерен вопрос: почему одним удается справляться с негативными воздействиями, а другим нет? Есть ли шанс обеспечить непрерывную работу всех служб или остается довериться случаю, поскольку в полной мере риски учесть невозможно? Очевидно, что все возможные инциденты предусмотреть сложно. Тем не менее необходимо уметь определять, какие бизнес-процессы и, соответственно, активы являются критически важными с точки зрения обеспечения непрерывности работы предприятия. Сегодня — это одна из главных задач, стоящих перед сотрудниками различных структурных подразделений современного предприятия. Реальный опыт показывает, что компании, которые заранее пытаются оценить и смоделировать негативные сценарии развития событий, имеют больше шансов сохранить свою работоспособность, пусть даже за счет определенных издержек.

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

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

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

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

СОГЛАСОВАННОСТЬ ВСЕХ И КАЖДОГО

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

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

Таким образом, мы можем выделить два основных вида негативного воздействия на работу ЦОД:

  • контролируемое;
  • неконтролируемое.

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

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

Даже при наличии хорошо продуманной технической архитектуры ЦОД несогласованность действий может обернуться остановкой любых бизнес-процессов на длительное время. Довольно часто возникающая неразбериха в принимаемых решениях приводит к еще худшим результатам. Чтобы этого не произошло необходим единый план действий. Хорошо, если зафиксирован документально в виде «Плана аварийного восстановления». От степени его продуманности зависит то, насколько предприятие в целом и ЦОД в частности готовы к нештатным ситуациям.

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

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

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

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

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

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

ТЯЖЕЛО В УЧЕНИИ

От теоретических аспектов составления плана аварийного восстановления перейдем к его практической части, а именно к этапу проведения учений.

Основная цель учений состоит в следующем:

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

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

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

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

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

ЧТО УЧЕСТЬ В ПЛАНЕ?

Довольно часто руководство компании сталкивается с дилеммой — кому доверить создание аварийного плана. Практика показывает, что основным разработчиком выступает подразделение, отвечающее за бесперебойное функционирование высокотехнологичных систем, от которых зависит непрерывность работы ЦОД. При этом обязательно следует назначить главного координатора работ. Ему придется предпринять немалые усилия для того, чтобы необходимый документ был подготовлен в установленный срок: проводить интервью, осуществлять сбор и анализ информации от различных подразделений внутри предприятия.

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

  • контроль ситуации с корпоративной политикой компании;
  • периодическая актуализация плана аварийного восстановления;
  • отслеживание изменений в производственной структуре предприятия;
  • учет перестановок в организационной структуре предприятия;
  • контроль перемен в кадровой политике предприятия;
  • отслеживание потребностей в необходимом программном обеспечении для предприятия;
  • фиксация изменений в технической архитектуре вычислительной сети, каналах связи и установленных вычислительных комплексах на предприятии (ЦОД и другие подразделения, а также рабочие места пользователей);
  • сбор информации о политике резервирования и восстановления корпоративных данных;
  • согласование вопросов с соответствующими внутренними службами, а также государственными службами, о порядке взаимодействия в случае возникновения чрезвычайных ситуаций.

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

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

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

СИСТЕМНАЯ ЗАЩИТА ОТ КАТАСТРОФ

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

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

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

Для контроля ситуации внутри предприятия и ЦОД и снижения риска катастрофических последствий следует предусмотреть ряд систем:

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

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

ЦЕНТРАЛИЗАЦИЯ И ДЕЦЕНТРАЛИЗАЦИЯ ЦОД

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

Как правило, основное ядро ЦОД составляет один или несколько мощных серверов, а технический персонал уделяет им повышенное внимание с момента их запуска. Это вполне объяснимо — нетрудно догадаться, какие последствия может вызвать остановка основного сервера, даже на непродолжительное время. Естественно, в этих условиях технической архитектурой должно предусматриваться наличие резерва — кластера серверов высокой надежности. Важно отметить, что в большинстве случаев резервный сервер находится в том же здании, а порой и в той же серверной комнате. С точки зрения обеспечения надежности выполняемых приложений и работы бизнес-процессов такое решение до настоящего времени считалось само собой разумеющимся. Однако является ли оно катастрофоустойчивым?

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

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

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

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

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

  • какие приложения важны, а какие критически необходимы для осуществления бизнес-процессов;
  • каким минимальным требованиям должно отвечать аппаратное обеспечение для достижения непрерывности необходимых бизнес-процессов;
  • какое количество пользователей вовлечено в бизнес-процессы;
  • какие аппаратные резервы имеются в ЦОД и вне его.

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

КАК ЭТО ПРОИСХОДИТ НА ДЕЛЕ

В качестве примера рассмотрим один из проектов, при реализации которого были задействованы элементы стратегии защиты от катастроф. Целью проекта было создание резервного ЦОД для обеспечения непрерывной работы системы ERP на базе SAP R/3. Проект реализован в крупной телекоммуникационной компании Республики Казахстан. Исходными требованиями жестко определялось максимально допустимое время остановки служб SAP R/3 (20 мин) при самом неблагоприятном негативном воздействии на ЦОД. К неблагоприятным внешним воздействиям были отнесены сход селевых потоков, землетрясения, пожары, теракты и т. п.

Техническая архитектура разрабатывалась с целью обеспечения непрерывной работы служб, предоставляемых системой SAP/R3 (см. Рисунок 2). Актуальные копии резервируемой системы размещались на площадках ЦОД и РЦОД. Важно отметить, что заключительным этапом проекта предусматривалась разработка плана аварийного восстановления, а также проведение учений. Определенную сложность придавало то обстоятельство, что компания имеет разветвленную сеть офисов, распределенных по всей территории республики, а также и то, что расстояние между основным (г. Алматы) и резервным ЦОД (г. Астана) составляет свыше 1500 км.

Первый этап проекта предусматривал разработку концепции организации резервного ЦОД, которая включала в себя требования, касающиеся анализа и дальнейшего развития стратегии защиты данных от катастроф. Акцент был сделан на непрерывность сервисов, предоставляемых системой SAP R/3.

В результате область, охватываемая проектом, была определена следующим образом:

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

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

В качестве основы для анализа были взяты следующие варианты решений:

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

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

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

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

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

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

В завершение реализации проекта были проведены учения, включающие следующие мероприятия:

  • согласование времени проведения учений;
  • «жесткую» остановку основных серверов SAP R/3 ЦОД г. Алматы) для имитации их аппаратного отказа;
  • подтверждение отказа служб на основной площадке ЦОД (г. Алматы);
  • подтверждение запуска и запуск служб в РЦОД (г. Астана);
  • оповещение и переключение пользователей для работы с РЦОД г. Астана);
  • контроль работы РЦОД (г. Астана) и подготовка к запуску ЦОД (г. Алматы);
  • оповещение пользователей перед остановкой РЦОД (г. Астана);
  • подтверждение и остановка служб РЦОД (г. Астана);
  • подтверждение и запуск служб ЦОД (г. Алматы);
  • оповещение и переключение пользователей для работы с ЦОД (г. Алматы);
  • контроль работы ЦОД (г. Алматы) и РЦОД (г. Астана);
  • завершение учений и анализ полученных результатов.

Ранее было отмечено, что специфика организации резервного ЦОД заключалась в его значительном удалении от основного ЦОД. Это было учтено при планировании учений. Принимая во внимание высокую круглосуточную нагрузку на службы SAP R/3, выбранный вариант предусматривал минимальное отвлечение основного персонала компании. В учениях был задействован главным образом технический персонал, частично взявший на себя роль конечных пользователей. При этом на этапе №6, когда осуществлялось восстановление данных, предусматривалась транспортная доставка их актуальной копии из РЦОД на основную площадку, для чего техническому специалисту компании пришлось совершить перелет авиарейсом из г. Алматы в г. Астану и обратно.

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

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

Вячеслав Ковалев — начальник отдела ЦОД компании «Открытые Технологии».