Восстановление после сбоев в работе ИТ (также просто восстановление после сбоев (DR) ) — это процесс поддержания или восстановления жизненно важной инфраструктуры и систем после стихийного бедствия или антропогенной катастрофы , например, шторма или сражения. DR использует политики, инструменты и процедуры с упором на ИТ-системы, поддерживающие критически важные бизнес-функции. [1] Это подразумевает поддержание всех основных аспектов функционирования бизнеса, несмотря на значительные разрушительные события; поэтому его можно считать подмножеством непрерывности бизнеса (BC). [2] [3] DR предполагает, что первичный сайт не подлежит немедленному восстановлению, и восстанавливает данные и услуги на вторичном сайте.
Непрерывность ИТ-услуг (ITSC) является подмножеством BCP, [4] которое опирается на метрики (часто используемые в качестве ключевых индикаторов риска ) целей точки/времени восстановления. Оно охватывает планирование восстановления после сбоев ИТ и более широкое планирование устойчивости ИТ . Оно также включает ИТ-инфраструктуру и услуги , связанные с коммуникациями , такие как телефония и передача данных . [5] [6]
Планирование включает организацию резервных площадок, которые могут быть «горячими» (работающими до аварии), «теплыми» (готовыми к началу работы) или «холодными» (требующими значительных работ для начала работы), а также резервных площадок с оборудованием, необходимым для обеспечения непрерывности работы.
В 2008 году Британский институт стандартов запустил специальный стандарт, поддерживающий стандарт непрерывности бизнеса BS 25999 , названный BS25777, специально для согласования непрерывности компьютеров с непрерывностью бизнеса. Он был отозван после публикации в марте 2011 года стандарта ISO/IEC 27031 «Методы безопасности — Руководящие принципы по готовности информационных и коммуникационных технологий к непрерывности бизнеса». [7]
ITIL определил некоторые из этих терминов. [8]
Целевое время восстановления (RTO) [9] [10] — это целевая продолжительность времени и уровень обслуживания, в течение которых бизнес-процесс должен быть восстановлен после сбоя, чтобы избежать нарушения непрерывности бизнеса. [11]
Согласно методологии планирования непрерывности бизнеса, RTO устанавливается в ходе анализа влияния на бизнес (BIA) владельцем(ами) процесса, включая определение временных рамок для альтернативных или ручных обходных решений.
RTO является дополнением RPO. Пределы приемлемой или «терпимой» производительности ITSC измеряются RTO и RPO с точки зрения времени, потерянного при нормальном функционировании бизнес-процесса, и данных, потерянных или не сохраненных в течение этого периода. [11] [12]
Фактическое время восстановления (RTA) является критически важным показателем для обеспечения непрерывности бизнеса и восстановления после сбоев. [9]
Группа обеспечения непрерывности бизнеса проводит хронометрированные репетиции (или фактические испытания), в ходе которых RTA определяется и уточняется по мере необходимости. [9]
Целевая точка восстановления ( RPO ) — это максимально допустимый интервал, в течение которого транзакционные данные теряются из ИТ-службы. [11]
Например, если RPO измеряется в минутах, то на практике необходимо постоянно поддерживать внешние зеркальные резервные копии , поскольку ежедневного внешнего резервного копирования будет недостаточно. [13]
Восстановление, которое не является мгновенным, восстанавливает транзакционные данные в течение некоторого интервала времени без возникновения значительных рисков или потерь. [11]
RPO измеряет максимальное время, в течение которого последние данные могли быть навсегда утеряны, а не является прямой мерой количества потерь. Например, если план BC заключается в восстановлении до последней доступной резервной копии, то RPO — это интервал между такими резервными копиями.
RPO не определяется существующим режимом резервного копирования. Вместо этого BIA определяет RPO для каждой службы. Когда требуются данные за пределами площадки, период, в течение которого данные могут быть утеряны, может начинаться с момента подготовки резервных копий, а не с момента их размещения за пределами площадки. [12]
Метрики восстановления можно преобразовать в/использовать вместе с метриками отказов . Обычные измерения включают среднее время между отказами (MTBF), среднее время до первого отказа (MTFF), среднее время ремонта (MTTR) и среднее время простоя (MDT).
Точка синхронизации данных [14] — это завершение резервного копирования. Она останавливает обработку обновления, пока копирование с диска на диск завершено. Резервная копия [15] отражает более раннюю версию операции копирования; не тогда, когда данные копируются на ленту или передаются в другое место.
RTO и RPO должны быть сбалансированы с учетом бизнес-рисков, а также других критериев проектирования системы. [16]
RPO привязан к времени, в течение которого резервные копии защищены вне офиса. Отправка синхронных копий на зеркало вне офиса позволяет предотвращать большинство непредвиденных событий. Использование физической транспортировки для лент (или других переносимых носителей) является обычным явлением. Восстановление может быть активировано на заранее определенном сайте. Совместное внешнее пространство и оборудование завершают пакет. [17]
Для больших объемов ценных транзакционных данных оборудование можно распределить по нескольким площадкам.
Планирование восстановления после сбоев и информационные технологии (ИТ) получили развитие в середине-конце 1970-х годов, когда руководители компьютерных центров начали осознавать зависимость своих организаций от компьютерных систем.
В то время большинство систем были пакетно-ориентированными мэйнфреймами . Мэйнфрейм, находящийся вне офиса, мог загружаться с резервных лент в ожидании восстановления основного сайта; время простоя было относительно менее критичным.
Индустрия аварийного восстановления [18] [19] развивалась для предоставления резервных компьютерных центров. Sungard Availability Services был одним из первых таких центров, расположенным в Шри-Ланке (1978). [20] [21]
В 1980-х и 90-х годах вычисления росли экспоненциально, включая внутреннее корпоративное разделение времени, онлайн-ввод данных и обработку в реальном времени . Доступность ИТ-систем стала более важной.
В дело вмешались регулирующие органы; часто устанавливались целевые показатели доступности в 2, 3, 4 или 5 девяток (99,999%), и искались решения высокой доступности для объектов с горячими участками . [ необходима цитата ]
Непрерывность ИТ-услуг стала неотъемлемой частью управления непрерывностью бизнеса (BCM) и управления информационной безопасностью (ICM), как указано в стандартах ISO/IEC 27001 и ISO 22301 соответственно.
Рост облачных вычислений с 2010 года создал новые возможности для устойчивости системы. Поставщики услуг взяли на себя ответственность за поддержание высокого уровня обслуживания, включая доступность и надежность. Они предложили высокоустойчивые сетевые конструкции. Восстановление как услуга (RaaS) широко доступно и продвигается Cloud Security Alliance . [22]
Катастрофы могут быть результатом трех основных категорий угроз и опасностей.
Меры по обеспечению готовности ко всем категориям и типам бедствий подразделяются на пять направлений: предотвращение, защита, смягчение последствий, реагирование и восстановление. [23]
Исследования подтверждают идею о том, что реализация более целостного подхода к планированию до стихийных бедствий более рентабельна. Каждый 1 доллар, потраченный на смягчение последствий опасности (например, план восстановления после стихийных бедствий ), экономит обществу 4 доллара на реагировании и расходах на восстановление. [24]
Статистика аварийного восстановления за 2015 год показывает, что простой в течение одного часа может стоить [25]
Поскольку ИТ-системы стали играть все более важную роль в бесперебойной работе компании и, возможно, экономики в целом, возросла важность обеспечения непрерывной работы этих систем и их быстрого восстановления. [26]
Меры контроля — это шаги или механизмы, которые могут уменьшить или устранить угрозы. Выбор механизмов отражается в плане восстановления после сбоя (DRP).
Меры контроля можно классифицировать как меры, направленные на предотвращение возникновения события, меры, направленные на обнаружение или обнаружение нежелательных событий, и меры, направленные на исправление или восстановление системы после аварии или события.
Эти проверки документируются и регулярно проводятся с использованием так называемых «тестов DR».
Стратегия аварийного восстановления вытекает из плана обеспечения непрерывности бизнеса. [27] Метрики для бизнес-процессов затем сопоставляются с системами и инфраструктурой. [28] Анализ затрат и выгод показывает, какие меры аварийного восстановления являются подходящими. Различные стратегии имеют смысл на основе стоимости простоя по сравнению со стоимостью внедрения конкретной стратегии.
Распространенные стратегии включают в себя:
Меры предосторожности могут включать:
Аварийное восстановление как услуга (DRaaS) — это соглашение со сторонним поставщиком о выполнении некоторых или всех функций DR для таких сценариев, как отключение электроэнергии, отказы оборудования, кибератаки и стихийные бедствия. [30]
в режиме реального времени ... обеспечить избыточность и резервное копирование ...
.. истории болезни пациентов
...индустрия восстановления после стихийных бедствий выросла до
Sungard .. основана в 1978 г.
SunGard ... Будущее Шри-Ланки.