Восстановление после катастроф
Восстановление после катастроф — совокупность политик, инструментов и процедур, которые позволяют восстановить или продолжить функционирование критически важной технологической инфраструктуры и систем после стихийного бедствия или техногенной катастрофы[1]. Аварийное восстановление фокусируется на информационных технологиях (ИТ) или технологических системах, поддерживающих критически важные бизнес-функции, в отличие от обеспечения непрерывности бизнеса, предполагающего сохранение всех основных аспектов деятельности компании независимо от серьёзных сбоев в работе. Поэтому восстановление после катастроф рассматривается как подмножество обеспечения непрерывности бизнеса[2][3]. В большинстве случаев подразумевается, что существенная часть изначально работавшей ИТ-инфраструктуры не подлежит восстановлению в течение некоторого времени, а сам процесс восстановления происходит на уцелевших или резервных площадках, что отличается от полного восстановления системы на исходное место.
Непрерывность предоставления IT-услуг
Планирование непрерывности ИТ-услуг (англ. IT service continuity, ITSC)[4][5] — подмножество планирования непрерывности бизнеса (англ. business continuity planning, BCP)[6], основной акцент в котором делается на определении целевой точки восстановления (RPO) и целевого времени восстановления (RTO). В этот процесс входят два типа планирования: аварийного восстановления ИТ и более широкого планирования устойчивости ИТ. Кроме того, в рамках ITSC рассматриваются аспекты управления ИТ-инфраструктурой, включая коммуникационные услуги (например, телефония и передача данных).
История
Планирование аварийного восстановления и информационных технологий начало развиваться в середине и конце 1970-х годов, когда руководители компьютерных центров стали осознавать зависимость своих организаций от работы компьютерных систем.
На тот момент большинство систем были мейнфреймами, предназначенными для пакетной обработки. Другой удалённый мейнфрейм можно было загрузить с резервных лент в ожидании восстановления основной площадки, и простой обычно не был критичным.
Появилась индустрия аварийного восстановления — в частности, поставщики резервных компьютерных центров. Один из первых таких центров был открыт компанией Sungard Availability Services в Шри-Ланке в 1978 году[7][8][9][10].
В 1980-х и 1990-х годах с ростом объёмов интерактивных данных и появлением обработки в реальном времени повысились требования к доступности ИТ-систем.
Непрерывность ИТ-услуг стала ключевой частью внедрения управления непрерывностью бизнеса (BCM) и управления информационной безопасностью (ICM), а также требованиям стандартов ISO/IEC 27001 и ISO 22301.
С распространением облачных вычислений с 2010 года ещё более снизилась значимость физического расположения вычислительных ресурсов — главное стало обеспечение достаточной сетевой надёжности. Концепция «восстановления как услуги» (RaaS) обрела актуальность в рамках облачных вычислений, в том числе по линии Cloud Security Alliance[11].
Классификация катастроф
Катастрофы можно разделить на три основные группы угроз. К первой относятся стихийные бедствия: наводнения, ураганы, торнадо, землетрясения, эпидемии.
Вторая категория — технологические опасности, включая аварии или сбои инфраструктуры: взрывы трубопроводов, транспортные происшествия, отключения коммунальных служб, разрушения плотин, случайные выбросы опасных материалов.
Третья категория — антропогенные угрозы, то есть преднамеренные действия: атаки злоумышленников, химические или биологические атаки, кибератаки, саботаж. Подготовка ко всем видам чрезвычайных ситуаций включает пять миссий: предотвращение, защиту, смягчение последствий, реагирование и восстановление[12].
Принципы резервирования площадок
Планирование предусматривает организацию резервных (горячих, тёплых, холодных) площадок и соответствующей инфраструктуры для поддержки непрерывности работы.
В 2008 году Британский институт стандартов выпустил стандарт BS25777 для ИТ-непрерывности как дополнение к BS 25999. В 2011 году BS25777 был заменён международным стандартом ISO/IEC 27031 «Руководство по обеспечению готовности ИКТ к непрерывности бизнеса»[13].
Термины, связанные с резервированием, также определяет ITIL[14].
Цель по времени восстановления
Цель по времени восстановления (англ. Recovery Time Objective, RTO)[15][16] — верхний порог времени и уровень сервиса, в пределах которых бизнес-процесс должен быть восстановлен после сбоя или аварии, чтобы избежать неприемлемых последствий для бизнеса[17].
RTO определяется в ходе анализа воздействия на бизнес (BIA) владельцами процессов, с указанием временных рамок для внедрения альтернатив и обходных путей.
В литературе RTO рассматривается в паре с целевой точкой восстановления (RPO) как одна из границ допустимого простоя ITSC. RTO и RPO отражают производительность ITSC с точки зрения максимально допустимых потерь времени и данных соответственно[17][18].
Фактическое время восстановления
По данным Forbes[15], фактическое время восстановления (англ. Recovery Time Actual, RTA) — практический показатель, важный для оценки готовности процессов восстановления. Его определяют на основе репетиций, замеров и мониторинга.
Целевая точка восстановления
Целевая точка восстановления (англ. Recovery Point Objective, RPO) — наибольший допустимый период, в течение которого могут быть безвозвратно утеряны транзакционные данные вследствие аварии[17].
Если RPO измеряется минутами или часами, требуется поддержка постоянных удалённых зеркальных резервных копий, так как ежедневного резервного копирования недостаточно[19].
Отношение к цели по времени восстановления
Восстановление, не осуществляемое мгновенно, приводит к утрате части данных за определённый период — эта величина определяется RPO, а не временем резервного копирования. Корректное планирование требует анализа влияния на бизнес для постановки RPO, а не простого принятия текущих графиков резервирования[18].
Точки синхронизации данных
Точка синхронизации данных (также момент резервного копирования)[20] — момент времени, когда выполняется резервное копирование. В современных системах резервное копирование часто реализуется с помощью снимков, параллельно с обработкой данных. Резервная копия отражает состояние данных на момент создания снимка, а не при их переносе на внешний носитель[21].
Как значения RTO и RPO влияют на дизайн компьютерной системы
RTO и RPO должны определяться в соответствии с бизнес-рисками и возможностями организации, что влияет на архитектуру системы.
RPO зависит от графика и технологии резервирования. Синхронное копирование данных на внешнее зеркало может обеспечить высокую устойчивость, тогда как перенос лент за пределы площадки обеспечивает минимальный уровень защиты по низкой цене. Для больших объёмов данных оборудование обычно геораспределяют для максимальной надёжности[22].
Другие характеристики процесса восстановления
В более детальных схемах восстановления используются также понятия DOO (англ. Degraded Operations Objective — максимальное допустимое снижение производительности) и NRO (англ. Network Recovery Objective — минимальная полоса пропускания сети для поддержания работоспособности)[23].
Важность планирования аварийного восстановления
Исследования показывают, что превентивное планирование и смягчение рисков более выгодно экономически: каждый доллар, вложенный в мероприятия по смягчению последствий катастроф (например, аварийное восстановление), позволяет сэкономить в среднем четыре доллара на ликвидации последствий[24].
По данным 2015 года, час простоя системы может стоить:
- малому бизнесу — до $8 000;
- среднему — $74 000;
- крупному предприятию — $700 000[25].
Поскольку роль ИТ для бизнеса и экономики растёт, возрастает и значимость планирования восстановления: 43% компаний не открываются вновь после серьёзной утраты данных, а 29% закрываются в течение двух лет. Следовательно, инвестиции во внедрение эффективных планов — критический вопрос для организаций[26].
Меры борьбы
Меры борьбы — действия и инструменты, минимизирующие или устраняющие угрозы для организаций. В плане аварийного восстановления (англ. disaster recovery plan, DRP) они классифицируются как:
- превентивные — меры по предотвращению событий;
- меры обнаружения — для оперативного выявления нежелательных событий;
- корректирующие — для устранения последствий и восстановления рабочих процессов[27].
Эффективные планы аварийного восстановления требуют внедрения, документирования и регулярной проверки всех трёх типов контроля.
Стратегии восстановления
Перед выбором стратегии аварийного восстановления ответственность лежит на планировщике, который должен опираться на показатели RTO и RPO, определённые в плане обеспечения непрерывности бизнеса[28]. Далее проводится сопоставление требований с реальными возможностями и пересмотр ИТ-бюджета с учётом допустимых затрат[29].
Отсутствие корректного планирования повышает негативные последствия катастроф[30].
Рекомендованные стратегии включают[31]:
- резервное копирование на ленты и их вывоз за пределы офиса;
- копирование на локальные и внешние диски;
- репликация данных в удалённые центры, часто с использованием SAN;
- частные облачные решения с хранением конфигураций и шаблонов (например, OVF);
- гибридные облачные решения для работы как на локальных, так и удалённых площадках;
- построение систем высокой доступности с постоянной репликацией и возможностью «безостановочного» переключения.
Практикуется привлечение внешних поставщиков услуг аварийного восстановления, в том числе с применением облачных технологий.
Дополнительно применяются превентивные меры:
- работающие параллельно экземпляры систем (зеркалирование, RAID);
- сетевые фильтры и ИБП/генераторы;
- системы пожарной сигнализации;
- антивирусы и другие меры информационной безопасности.
Классификация планов аварийного восстановления
Характерная классификация — семиуровневая шкала, предложенная в конце 1980-х годов комитетом SHARE совместно с IBM (уровни 0–6 и расширения), отражающая разнообразие решений и технологий восстановления. Существуют и альтернативные классификации (например, Wiboobratr и Kosavisutee), ориентированные на современный спектр услуг DRaaS.
| Уровень | SHARE/IBM[32][33][34] | Hitachi[35] | Wiboonratr и Kosavisutte[36] | Novell[37] | Xiotech[38] |
|---|---|---|---|---|---|
| 0 | План аварийного восстановления отсутствует. | ||||
| 1 | Резервное копирование с вывозом копий вне здания, «Pickup Truck Access Method (PTAM)»[23]. | Резервное копирование на ленту вне площадки. | Возможность восстановления на определённый момент. | Резервное копирование на ленту/ручное восстановление. | Уровень 4: Резервные копии по расписанию на «холодной» площадке. |
| 2 | Резервное копирование с наличием горячей резервной площадки (PTAM+hotsite)[23]. | Резервное копирование на ленту на основной или резервной площадке. | Доставка копий на подготовленную резервную площадку. | Традиционное восстановление образа диска. | |
| 3 | «Электронное хранилище» (electronic vaulting); регулярное копирование и возможное восстановление за 24 часа[32]. | То же, что у SHARE/IBM. | Дисковые копии в несколько локаций с точкой восстановления. | Гибкое восстановление выбранных файлов и версий. | Уровень 3: Быстрое восстановление асинхронно или по расписанию на «тёплой» площадке. |
| 4 | Копии, позволяющие восстановление на определённое время. | Единичная резервная копия на диск. | Удалённое журналирование. | Виртуализированное резервное копирование и восстановление. | |
| 5 | Транзакционная целостность данных. | Консолидация файлов с разных образов дисков. | Параллельные теневые копии рабочей базы данных. | Кластерные серверные решения. | Уровень 2: Быстрое восстановление на горячую площадку. |
| 6 | Минимальные или нулевые потери данных. | Данные на разделяемом диске между основным/резервным центром. | Удалённое копирование данных. | ||
| 7 | Высокоавтоматизированное восстановление. | Зеркалирование дисков между основным и резервным системами. | Удалённое отказоустойчивое копирование данных. | Уровень 1: Мгновенное восстановление из синхронной копии на горячую площадку. | |
| 8 | Полное дублирование данных. | ||||
Каждый последующий уровень расширяет или заменяет предыдущий.
Восстановление как услуга
Восстановление после катастроф как услуга (англ. Disaster Recovery as a Service, DRaaS) — сервисное соглашение с внешней организацией, поставщиком услуг и/или оборудования[39]. Обычно предлагается как часть портфеля облачных и инфраструктурных услуг (например, развертывание модульных датацентров).