Компания
267,01
рейтинг
15 мая 2012 в 14:05

Разное → Катастрофоустойчивые IT-системы: как внедрить в своей компании

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

  • 93% компаний, которые теряли свой ЦОД на 10 и более дней из-за катастрофы, стали банкротами в течение года (National Archives & Records Administration in Washington)
  • Каждую неделю в США выходит из строя 140 000 жестких дисков (Mozy Online Backup)
  • У 75% компаний нет решений для аварийного восстановления (Forrester Research, Inc.)
  • 34% компаний не тестируют резервные копии.
  • 77% тех, кто тестируют, обнаруживали нечитаемые накопители в своих библиотеках.

В предыдущих постах (раз и два) я писал про организационные меры, которые ускорят и облегчат восстановление ИТ-систем и связанных с ними процессов компании при чрезвычайной ситуации.



Сейчас поговорим про технические решения, которые в этом помогут. Их стоимость разнится от нескольких тысяч до сотен тысяч долларов.

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


Очень часто решения для высокой доступности (HA – High Availability) и аварийного восстановления (DR – Disaster Recovery) путают. Прежде всего, когда мы говорим о непрерывности бизнеса, мы имеем в виду резервную площадку. Применительно к ИТ – резервный ЦОД. Непрерывность бизнеса — это не про резервное копирование на библиотеку в соседней стойке (что тоже очень важно). Это про то, что основное здание компании сгорит, и мы через несколько часов или дней сможем возобновить работу, развернувшись на новом месте:
Высокая доступность
Аварийное восстановление
Решение в пределах одного ЦОД
Включает в себя несколько удаленных ЦОД
Время восстановления < 30 минут
Восстановление может занимать часы и даже дни
Нулевая или близкая к нулю потеря данных
Потеря данных может достигать многих часов
Требует ежеквартального тестирования
Требует ежегодного тестирования
Значит, нужен резервный ЦОД. Какие есть варианты? Обычно выделяют три: горячий, теплый и холодный резервы.

Холодный резерв


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

Теплый резерв


Это значит, что у нас функционирует альтернативная площадка, в которой есть активные интернет и WAN-каналы, базовая телекоммуникационная и вычислительная инфраструктура. Она всегда «слабее» основной по вычислительным мощностям, некоторое оборудование там может отсутствовать. Самое важное – чтобы на площадке всегда была актуальная резервная копия данных. Действуя «по старинке» можно организовать регулярное перемещение туда резервных копий на лентах. Современный метод – репликация бэкапов по сети из основного ЦОДа. Использование бэкапа с дедупликацией позволит оперативно передавать резервные копии даже по «тонкому» каналу между ЦОДами.

Горячий резерв


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

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

Три волшебных слова


Перед тем, как перейти непосредственно к технологиям катастрофоустойчивости ИТ-сервисов, напомню три «волшебных» слова, которые определяют стоимость любого DR-решения: RTO, RPO, RCO.
  • RTO (Recovery time objective) – время, за которое возможно восстановить ИТ-систему
  • RPO (Recovery point objective) – сколько данных будет потеряно при аварийном восстановлении
  • RCO (Recovery capacity objective) – какую часть нагрузки должна обеспечивать резервная система. Этот показатель может измеряться в процентах, транзакциях ИТ-систем и прочих величинах.


RPO


Первое деление, которое мы можем провести между всем многообразием ИТ-решений для обеспечения катастрофоустойчивости – обеспечивают ли они нулевое RPO или нет. Отсутствие потери данных при сбое обеспечивается синхронной репликацией. Чаще всего, это делается на уровне СХД, но возможно реализовать и на уровне СУБД или сервера (при помощи продвинутого LVM). В первом случае сервер не получает от СХД, с которой он работает, подтверждения об успешности записи, пока СХД не передала эту транзакцию второй системе и не получила от нее подтверждение, что запись прошла успешно.



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

RPO в несколько минут может обеспечить асинронная репликация на уровне СХД, ПО управления томами сервера (LVM – Logical volume manager), либо СУБД. До сих пор standby-копия базы данных остается одним из наиболее популярных решений для DR. Чаще всего функционал “log shipping”, как это называется у администраторов СУБД, не лицензируется производителем отдельно. Если у вас пролицензирована БД – реплицируйте на здоровье. Стоимость асинхронной репликации для серверов и СХД не отличается от синхронной, см. предыдущий пункт.

Если мы говорим об RPO в несколько часов, чаще это репликация резервных копий с одной площадки на другую. Большинство дисковых библиотек умеют делать это, часть ПО для резервного копирования – тоже. Как я уже говорил, при таком варианте здорово поможет дедупликация. Вы не только будете меньше загружать канал передачей резервных копий, но и сделаете это намного быстрее — каждый передаваемый бэкап будет занимать в десятки или сотни раз меньше времени, чем в реальности. С другой стороны, надо помнить, что первый бэкап при дедупликации все равно должен передать в систему массу уникальных данных. «Настоящую» дедупликацию вы увидите после недельного цикла резервного копирования. При синхронизации дисковых библиотек — то же самое. Если расчетное время передачи при вашей ширине канала между ЦОД составляет несколько дней и даже недель (что может и стоить немало), есть смысл сначала поставить вторую библиотеку рядом, выполнить синхронизацию и увезти ее в резервный ЦОД.


Синхронизация резервных копий между ЦОД

RTO


Когда стоит задача минимизации времени восстановления (RTO), процесс должен быть максимально документирован и автоматизирован. Одно из лучших и наиболее универсальных решений – HA-кластеры с территориально разнесенными узлами. Чаще всего, такие решения строятся на базе репликации СХД, но возможны и другие варианты. Лидирующие продукты в этой области, например, Symantec Veritas Cluster, имеют в своем составе модули по работе с СХД, переключающие направление репликации, когда необходимо перезапустить сервис на резервном узле. Для менее продвинутых кластеров (например Microsoft Cluster Services, встроенный в Windows) основные производители СХД (IBM, EMC, HP) предлагают надстройки, делая из обычного HA-кластера катастрофоустойчивый.


Географически распределенный кластер

Редко кто задумывается про интересную особенность подавляющего большинством решений по репликации данных – их «однозарядность». Вы можете получить на резервной площадке только одно состояние данных. Если система с этими данными по какой-то причине не стартовала – переходим к плану «Б». Чаще всего это восстановление из резервной копии с большой потерей данных. Из перечисленных мной технологий исключение составит только репликация тех же бэкапов. Ответом здесь является использование класса решений Continuous Data Protection. Их суть в том, что все записи, приходящие от сервера, помечаются и сохраняются в определенном журнальном томе на резервной площадке. При восстановлении системы можно выбрать любую точку из этого журнала и получить состояние не только на момент аварии, в которой данные были испорчены, но и за несколько секунд. Такие решения защищают от внутренней угрозы – удаления данных пользователями. В случае репликации СХД – ей все равно, что передавать – пустой том или вашу наиболее критичную БД. При использовании CDP можно выбрать момент прямо перед удалением информации и восстановиться на него. Стоимость систем CDP обычно – десятки тысяч долларов. Один из наиболее удачных примеров, на мой взгляд – EMC RecoverPoint.


Схема решения на основе RecoverPoint

В последнее время набирают популярность системы виртуализации СХД. Помимо своей основной функции – объединения массивов разных вендоров в единый пул ресурсов – они могут сильно помочь и в организации распределенного ЦОДа. Суть виртуализации СХД в том, что между серверами и системами хранения появляется промежуточный слой контроллеров, пропускающих сквозь себя весь трафик. Тома с СХД презентуются не напрямую серверам, а этим виртуализаторам. Они, в свою очередь, раздают их хостам. В слое виртуализации можно делать репликацию данных между разными СХД, а зачастую есть и более продвинутые возможности — снэпшоты, многоуровневое хранение и т. д. При этом самая базовая функция виртуализаторов является самой нужной для целей DR. Если у нас есть две СХД в разных ЦОДах, соединенных оптической магистралью, мы берем тома с каждой из них и собираем «зеркало» на уровне виртуализатора. В итоге мы получаем один виртуальный том на два ЦОДа, который и видят серверы. Если эти серверы виртуальные – начинает работать Live Migration виртуальных машин и можете «на ходу» переводить задачи между ЦОДами – пользователи ничего не заметят.



Полная потеря ЦОДа будет отработана обычным HA-кластером в автоматическом режиме за несколько минут. Пожалуй, виртуализация разнесенных СХД позволяет обеспечить минимальное время восстановления для большинства приложений. Для CУБД есть непревзойденный Oracle RAC и его аналоги, но стоимость заставляет задуматься. Виртуализация SAN пока тоже не дешева, для небольших объемов СХД стоимость решения может быть меньше $100К, но в большинстве случаев цена выше. На мой взгляд, наиболее проверенным решением является IBM SAN Volume Controller (SVC), наиболее технически совершенным – EMC VPLEX.

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

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

Последний, но очень важный момент, о котором нельзя забывать при проектировании катастрофоустойчивой ИТ-инфраструктуры – рабочие места пользователей. То, что поднялась база данных, не означает возобновления бизнес-процесса. Пользователь должен иметь возможность выполнять свою работу. Даже полноценный резервный офис, в котором стоят выключенные компьютеры для ключевых сотрудников – не идеальное решение. У человека на утраченном рабочем месте могут быть справочные материалы, макросы, и проч., полноценная работа без которых невозможна. Для наиболее важных для компании пользователей разумным выглядит переход на виртуальные рабочие места (VDI). Тогда на рабочем месте (будь то обычный ПК или модный «тонкий» клиент) не хранятся никакие данные, он используется только как терминал, чтобы достучаться до Windows XP или Windows 7, работающей на виртуальной машине в ЦОДе. Доступ к такому рабочему месту легко организовать из дома или из любого компьютера в филиальной сети. Например, если у вас несколько зданий и одно из них недоступно, ключевые пользователи могут приехать в соседний офис и сесть на рабочие места «менее ключевых». Затем они спокойно логинятся в систему, попадают в свою виртуальную машину и фирма оживает!

В завершение, вот основные вопросы, которые стоит задать при оценке DR-решения:
  • От каких сбоев защищает?
  • Какие RPO/RTO/RCO обеспечивает?
  • Сколько стоит?
  • Насколько сложна эксплуатация?

Катастрофоустойчивых решений бесчисленное множество – как коробочных, так и тех, которые можно сделать практически своими руками. Пожалуйста, поделитесь в комментариях что есть у вас и историями, как эти решения вас выручали. Если у вас работает что-то из описанных выше систем или их аналоги – оставляйте отзывы, насколько спокойно вы спите, когда ИТ-системы под их защитой.
Автор: @Dmitry_Doshaniy
КРОК
рейтинг 267,01

Комментарии (17)

  • +2
    Если эти серверы виртуальные – начинает работать Live Migration виртуальных машин и можете «на ходу» переводить задачи между ЦОДами

    Live Migration между ЦОДами — в теории круто, на на практике слабо выполнимо. Уж больно колоссальные у него требования к пропускной способности сети даже при штатном запуске. А резко перетащить сотню виртуалок на другую площадку методом live migration вообще невозможно, это потребует сотен гигабит емкости между площадками. Проще уж застопить машину и переместить ее диски. А при постоянной репликации СХД и диски тащить не надо, просто подмапил LUN на другом гипервизоре и вперед. А при грамотном использовании балансировщиков падение одной площадки целиком может вообще не потребовать никаких телодвижений. Но такое редко удается сделать.

    Ну и L2 DCI (безусловное требование для любых видов VM mobility) — нечто, от чего лучше держаться подальше, если только в нем нет абсолютной необходимости (а обычно ее нет). Не очень здорово даже когда один VLAN растянут на целый ЦОД.
    • 0
      ну если географически распределенный — это стойки в соседних комнатах с двумя 10Gb линками между блейдовыми свитчами…

      но им надо отработать по схеме продавца: «запугивание, запугивание, решение, дорогое, очень дорогое решение, оооочень дорогое решение, сказка, блаженство.» через обратную призму этого статья выглядит полезной.
      • 0
        [blockquote]ну если географически распределенный — это стойки в соседних комнатах с двумя 10Gb линками между блейдовыми свитчами…[/blockquote]
        Да, в таких условиях можно перетаскивать виртуалки без их остановки, не спеша, по две-три :)
    • +1
      > Live Migration между ЦОДами — в теории круто, на на практике слабо выполнимо
      Почему нет? В указанном пункте диски уже единые между двумя ЦОД, так что переместить необходимо только данные в памяти вирт. машины — это единицы гигабайт.
      А т.к. для организации полной репликации дисков и так используется канал уровня 8-10G, то прокинуть пару гигабайт там не проблема.

      Когда я участвовал в строительстве распределенного ЦОД, у нас была темная оптика между площадками, 16 волокн. 4 штуки ушло под FC, еще 4 под Ethernet, 8 под холодный резерв (не считая более медленных vpn каналов через сторонних провайдеров на самый крайний случай)
      • 0
        Да, расстояние было порядка 15-20 км, что бы не было рассуждений, что ЦОД за соседней стенкой :)
      • 0
        В указанном пункте диски уже единые между двумя ЦОД, так что переместить необходимо только данные в памяти вирт. машины — это единицы гигабайт.

        Так и диски обычно не сказать чтобы большие… Диски статичны, в отличие от памяти.
        Но спору нет, при наличии 40G езернета live migration единичных машин не проблема. Вопрос — в том распределенном ЦОДе на практике таскали рабочие машины между площадками?
        • 0
          Диски как раз самое большое и есть. Общий объем — единицы/десятки терабайт. Такое точно не реально переместить одномоментно. Но если хранилища у нас синхронизированы, то максимум, что нужно переместить — это память вирт.машины, что составляет на порядок меньше — единицы/десятки гигабайт, а не терабайт.
          В крайнем случае, если машины на той площадке просто умерли — они запустятся на другой, перемещать вообще ничего не надо.

          В то время виртуальные машины в организации не использовались.
          Решалось средствами приложения/базы, тестовые аварии отрабатывало нормально.
          • 0
            Речь не про хранилища (базы данных и прочее), а про системный раздел виртуалки. Он обычно небольшой и статичный у практически любой системы. А вот память у нагруженной виртуалки по идее меняется настолько быстро, что и 5гб/с может хватить с трудом.
            • 0
              В моем текущем кластере в.машины переносятся с хоста на хост за ~30-120 секунд, имея из сети только 2xFC 4G + 2x1Gb Ethernet.
              При условии, что хранилище синхронно, перенос машины относительно дешевая операция, разницы между локальными хостами и удаленным не будет.
    • 0
      Ну и L2 DCI (безусловное требование для любых видов VM mobility) — нечто, от чего лучше держаться подальше, если только в нем нет абсолютной необходимости (а обычно ее нет). Не очень здорово даже когда один VLAN растянут на целый ЦОД.


      Тем не менее, такой тренд есть. И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками.

      Касательно Live Migration между ЦОД.
      Если клиент задумывает о миграции между ЦОД, то однозначно у него будет некая кластеризированная СХД с полностью реплицированной информацией. Иначе нет смысла мигрировать в другой ЦОД при Disaster Recovery. Если мигрировать в другой ЦОД для выполнения там вычислительных операций, а хранилище иметь в начальном ЦОДе, то вариант возможен, но очень глупый. Исходя из этого, в другой ЦОД необходимо будет перетянуть только состояние оперативной памяти, диски там уже будут, причем в максимально актуальном состоянии.
      • 0
        Опять же, live migration сотен виртуалок разом — нонсенс в любом случае. А если произошла (или вот-вот должна произойти) катастрофа, то тем более любой нормальный человек отбросит понты и просто поднимет виртуалки с реплицированного хранилища на новой площадке.

        Но все-таки как сетевик я терпеть не могу L2, особенно когда он сильно спанится.
        1) Делать простой транк между площадками — безумие. Авария на одном ЦОДе имеет шанс положить и соседа. Да и даже без аварий на транке будет гулять слишком много мусора. И нужны костыли, чтобы сервер на каждой из площадок выбирал правильного next hop'а. Так что надеюсь, так никто никогда не делает.
        2) OTV к примеру гарантирует, что broadcast и unknown unicast трафик не будут бегать между ЦОДами, и скорее всего авария одной площадки не затронет другую («скорее всего» — полную гарантию даст только L3). Но он дорого стоит (Nexus 7k), и все равно трафик будет ходить абсолютно неоптимально.

        Потому наиболее красивое решение — чтобы by design не было нужды перемещать машину с площадки на площадку с сохранением IP адреса. Пусть будут по две занятые общим делом машины в двух разных ЦОДах. В пределах ЦОДа можно делать балансировку средствами ACE. Между ЦОДами — GSS. Да можно хоть включить route injection — клиенты обращаются к VIP адресу ресурса, и этот VIP анонсируется как /32 маршрут тем балансировщиком, который является активным, а при смерти ЦОДа этот /32 маршрут через несколько секунд всплывет в другом месте. И уже неважно, какие у серверов адреса. И нет никакой нагрузки на сеть в момент переезда.
        Все эти решения значительно лучше, чем «VLAN растянут на 2 ЦОДа».

        Но в принципе, существует типичный конфликт непонимания между «server guys» и «network guys».

        «И судя по тому, сколько усилий в этот направлении тратят производители сетевого оборудования и платформ виртуализации, функционал востребован заказчиками. „
        Основные усилия тратятся производителями платформ виртуализации и направлены на промывание мозгов серверных админов. И часто бывает, что те загораются новой идеей и начинают давить на сетевиков, не понимая возникающих на уровне сети проблем. И тут сетевые вендоры присасываются к кормушке и выпускают костыли, убирающие часть проблем.
        И мало кто акцентирует внимание на L3 технологиях, потому что тут в восторге будут сетевики, но не будет никаких killer-фич для server guys.
        • 0
          Тут я с Вами соглашусь, маркетинг дело подлое. И гонку вооружений никто не отменял.
  • +2
    Местами соленое сравнивается с мягким. С точки зрения понимания на уровне ликбеза это допустимо, но солидные внедренцы всё-таки не допускают ошибок в такого рода статьях.

    К сожалению, наша площадка еще не достроена и описания её на хабре нет. Однако часть инженеров IBM, мой опыт и здравый смысл цепляется за много моментов, которые вы сочли «легкими».
    «Полная потеря ЦОДа будет отработана обычным HA-кластером в автоматическом режиме за несколько минут. Пожалуй, виртуализация разнесенных СХД позволяет обеспечить минимальное время восстановления для большинства приложений.»
    Вот такого рода предложения обычно поясняют или приводят примеры. Кластеры, которые восстанавливаются после гибели ЦОДа, как показывает новейшая история, даже у гугла не отрабатывают корректно.
    • +3
      Это действительно обзорный пост. Посмотрев на обратную связь, я планировал более подробно написать о некоторых из упомянутых решений подробно, в контексте референсных архитектур. Что касается конкретного кейса с HA-кластерами, описанный мной сценарий возможен, в случае того же VPLEX. Условием корректной отработки полного отказа ЦОДа со стороны VPLEX (т.е. подсистемы хранения данных, с точки зрения сервера) является наличие специальной виртуальной машины-наблюдателя, где-то в третьей локации. Она видит по IP контроллеры VPLEX в обоих ЦОДах, и позволяет отличить ситуацию отказа коммуникаций между двумя ЦОДами (когда внутри площадки все живо), от отказа ЦОДа целиком. Если контроллер не видит своего собрата, но видит наблюдателя и со стороны наблюдателя картина та же — все тома забираются в выживший ЦОД. В случае SVC возможен такой же наблюдатель, но он должен видеть все узлы по оптике. Другой вопрос, что в жизни могут быть нарушены и коммуникации с третьей площадкой-наблюдателем. Всегда возможна ситуация, когда самый продуманный кластер не отработает. Надо просто выбрать наилучшую технологию из имеющихся на рынке.
      При всем при этом, ценность любого геокластера в «ручном» режиме работы не намного меньше, чем в автоматическом. Отказы ЦОДов целиком случаются редко, главное, чтобы когда человек разобрался, что делать и принял решение — его выполнение прошло максимально быстро. Оснобенно, когда надо переводить на резервную площадку десятки систем. Десятки минут простоя при этом абсолютно нормальны, главное, чтобы они не превратились в многие часы и дни.
      • 0
        > специальной виртуальной машины-наблюдателя
        Обычно называют «арбитр».
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Совершенно справедливый комментарий, спасибо. В этом посте я не затрагивал очень важную тему построения отказоустойчивых сетей LAN, WAN, SAN между ЦОДами. Постараюсь написать об этом один из следующих постов.
      Ситуация с авариями как детонаторами перемен мне знакома. Если руководство воспринимает только это — важно предлагать варианты решения по горячим следам, не ждать, пока время вылечит. Непосредственно с Корбиной и Скартелом/Yota не работал, кстати.
      Очень важен общий уровень риск-менеджмента в компании и взаимодействия профильного подразделения с ИТ. Во некоторых наших бурно растущих бизнесах процессы отстают от масштаба деятельности. Я считаю, что донести до риск-менеджеров и руководства в целом мысль о важности инвестиций в непрерывность бизнеса можно. Главное, как следует подготовиться — собрать примеры последствий отказов у ваших конкурентов и в вашей собственной инфраструктуре, попытаться грубо оценить стоимость простоя. Взглянуть на ситуацию со стороны бизнеса, одним словом.

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

Самое читаемое Разное