//N.B. mode on

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

Команда Servermall делает всё возможное, чтобы продолжать поставки серверов, адаптировать логистические цепочки к новым реалиям и осуществлять 5-летнее гарантийное обслуживание. Да, спрос огромный, срок доставок немного увеличился, но серверы есть и будут — это главное. И пускай обстановка изменилась, основной посыл статьи всё тот же — оценивайте любые риски и составляйте план действий до их наступления.

//N.B. mode off

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

Безопасности уровня air gap будет недостаточно. С нынешней политической конъюнктурой возможен любой сценарий: отключение России от Всемирной паутины, отсутствие возможности продления лицензий на ПО, срыв поставок оборудования и комплектующих, а также одностороннее расторжение контрактов с ключевыми иностранными партнёрами. Эти моменты нужно учитывать в управлении рисками любой организации. 

«Сбои — это неизбежность; в конечном итоге любая система со временем рухнет». — Werner Vogels.

К счастью, существует инструмент, способный мгновенно реагировать на форс-мажоры. Он кратно увеличивает отказоустойчивость IT-инфраструктуры и доводит аптаймы до высочайших показателей. Имя ему — Disaster Recovery.

Навигация по статье

• Что такое Disaster Recovery

• Без чего не обойтись: подготовка и DRP

  1. Состав штатной DR-команды

  2. Предварительная оценка рисков

  3. Определите критически важные бизнес-процессы и уровень доступности для них

  4. Заключите SLA — соглашение об уровне обслуживания

  5. Определите RPO и RTO

  6. Выбор конкретного решения DR

  7. Проверка работоспособности: тесты failover

• Почему вам нужен DRP, а одних бекапов может не хватить

• Выводы

Что такое Disaster Recovery

Disaster Recovery (DR) — катастрофоустойчивость или аварийное восстановление, инструмент реагирования на критические сбои в IT-инфраструктуре компании, направленный на быстрое восстановление работы всех систем. То есть отказ серверной или даже всего ЦОДа не должен надолго (в отдельных случаях речь о секундах) прерывать бизнес-процессы.

Реализация DR основана на управлении рисками (анализ, оценка, нужен ли вообще план восстановления, планирование). Один из вариантов — дублирующая инфраструктура, способная взять на себя всю нагрузку, если основная система откажет. В идеале ключевые узлы инфраструктуры должны работать по принципу георезервирования:

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

• Георезерв электросети — зачастую используют другие магистральные каналы. Например, выходит из строя местная электростанция, основной ЦОД переходит на дизельные генераторы, а запасной ЦОД продолжит питаться от ГЭС. Так как второй вариант дешевле, можно остановить работу первого ЦОДа, пока аварийные службы восстанавливают электропитание. Такой подход также используют и в рамках одного ЦОДа;

• Георезерв интернет каналов — другие магистральные интернет-провайдеры, каналы которых не проходят в одном месте. Если экскаватор пробьет один из каналов, когда будет копать рядом с ЦОДом, это не остановит работу.

Без чего не обойтись: подготовка и DRP

Всем без исключения нужен план аварийного восстановления DRP (Disaster Recovery Plan). Его составлением нужно заниматься комплексно: со стороны бизнеса и со стороны IT-инфраструктуры и специалистов. Даже малому бизнесу с одним сервером неплохо бы иметь план на салфетке, что делать, когда тот выйдет из строя, чтобы минимизировать финансовые потери.

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

Пункты, которые нужно проработать при составлении DRP:

• Состав штатной DR-команды и уровни доступа у сотрудников;

• Предварительная оценка рисков;

• Определение критически важных бизнес-процессов и данных;

• Бюджет;

• Необходимость в подрядчиках и поставщиках (услуг в том числе), а также их надежность;

• Используемые технологии;

• Необходимые уровни доступности;

• Нужен ли SLA (Service-Level Agreement), подробнее о том, что это такое и с чем едят — ниже;

• Быстрое восстановление или параллельная инфраструктура;

• В каком формате будет составлен DRP. Вы можете продумать свой документ с нуля или воспользоваться готовым шаблоном американской компании TechTarget (или любым другим). Ссылку оставлю здесь.

Разберём некоторые пункты поподробнее.

1. Состав штатной DR-команды

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

При этом нужно чётко определить необходимые уровни доступа для каждого специалиста, чтобы не случалось сюрпризов, когда у члена DR-команды нет доступа к северу или ЦОДу. Или наоборот, когда новый член команды будет иметь слишком много прав. Чуть подробнее о системах контроля и управления физическим доступом (СКУД), вы можете почитать в другой моей статье “Серверная моей мечты”, но и про логический (учётные записи, ключи и т.п.) забывать не стоит.

2. Предварительная оценка рисков

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

Внешние риски

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

Санкции против IT-сектора.

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

И не забывайте про привычные вам облачные сервисы: Gmail, Slack, Jira, Discord, YouGile, Google Docs и многие другие. Даже если их не заблокируют, то могут возникнуть проблемы с оплатой, продлением и т.д. Молчу про окирпиченное сетевое оборудование и удаление учётных записей Microsoft. Список почти бесконечный.  

Поэтому критиковать импортозамещение также легко, как и вернуться на уровень развития девяностых-нулевых.

Другие риски.

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

Пример оценки геологических и экологических рисков Санкт-Петербурга:

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

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

Вам может показаться, что риски, такие как наводнение, явление крайне редкое. Тогда посмотрите, как в сентябре 2009 года за несколько минут затопило офис и ЦОД Vodafone. Вряд ли админы думали в тот момент: “Сейчас поднимем бэкапы и пойдём пить кофе”.

Disaster Recovery Plan не защитит серверное оборудование от потопа или пожара, но позволит спрогнозировать форс-мажор и быстро вернуться к работе бизнес-процессов.

Внутренние риски

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

• Риски человеческого фактора

  Невозможно на 100% процентов быть уверенным в ком-то. Человек может недобросовестно работать, устать, допустить ошибку, обидеться, внезапно уволиться, заболеть, взять отгул по семейным обстоятельствам, переоценить/недооценить свои возможности и т.д. Поэтому человеческий фактор всегда стоит закладывать в оценку рисков. Это не значит, что у вас будут точные цифры. Скорее вы будете готовы к тому, что даже бульдозер могут перевернуть на ровном месте, а значит было бы неплохо иметь второй.

• Технические риски

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

• Технологические риски

  Технологические риски связаны с типом используемого оборудования, ПО, интенсивностью нагрузок т.д. Стоит учесть, что продукция крупных вендоров-пионеров заслуживает бóльшего доверия: она проверена временем, оснащена проприетарными разработками, да и технологии тестирования и производства более совершенны, так как на отладку всех процессов ушли десятилетия. У серверов от Dell, HPE и Lenovo выше показатели надежности MTBF (Mean Time Between Failures) — это время, в течение которого не ожидается сбоев. Подоброне о MTBF можно почитать в нашем блоге на Хабре. Поэтому мы продаём серверы только этих вендоров, так как уверены, что они легко переживут нашу гарантию 5 лет.

Покупайте релевантные задачам инструменты. Лучше один КАМАЗ для перевозки щебня, чем 5 легковушек. И наоборот, если мы перевозим людей. Учитывайте качество, надёжность, гарантию и уровень сервиса. Сервер, собранный на железе ПК или купленный на авито — не лучшее решение для требовательных к отказоустойчивости бизнес-процессов.

Как оценить внутренние риски?

Вряд ли вам удастся с точностью до процента определить, какова вероятность возникновения человеческого фактора; насколько сервер Dell или HPE будет отличаться надёжностью от серверов Atos, NEC или Supermicro; как часто выходит из строя оборудование, обслуживаемое по регламенту и без. Разве что вы целенаправленно не собирали статистику лет 5-10 по всем направлениям.

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

3. Определите критически важные бизнес-процессы и уровень доступности для них

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

1. Высокий. Даже несколько минут простоя могут привести к большим и(или) необратимым потерям и негативным последствиям. Бизнес-процессы должны вернуться к работе как можно быстрее — от нескольких секунд, до нескольких минут.

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

   Примеры бизнес-процессов компании: банковские транзакции, производство процессоров, работа СКУД в охраняемой зоне.

2. Средний. Бизнесу требуется быстрое восстановление, но он может пережить простой от нескольких минут до часа без существенных потерь. 

   Примеры компаний: розничные магазины, производитель мебели, печатное издательство.

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

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

   Примеры компаний: малый бизнес, небольшие компании и предприятия.

   Примеры бизнес-процессов внутри компании: бухгалтерский учёт, составление рабочего расписания, архив данных, обновление базы 1С.

Когда вы закончите с приоритетностью бизнес-процессов, можно приступать к определению уровня доступности системы:

• Постоянная доступность (continuous availability). Если речь, например, об электронном движении капитала, то инфраструктура должна быть готова к запланированным и незапланированным простоям, а также непрерывно работать 24/7 годами.

  Для обеспечения постоянной доступности IT-системам присваивают статус Mission Critical. Инфраструктура этого уровня всесторонне резервируется и геораспределяется, а также работает в режиме постоянного дежурства и должна полностью восстановиться в течение минут после аварии.

• Непрерывный режим работы (continuous operations). Чуть менее доступная инфраструктура, не готовая к авариям на всех узлах, но по-прежнему работающая 24/7 годами, если не возникает сбоев.

  Для обеспечения непрерывного режима работы IT-системам присваивают статус Business Critical. Инфраструктура этого уровня частично резервируется и геораспределяется на важных точках отказа, а также работает в режиме непрерывной готовности и должна полностью восстановиться в течение 1-2 часов после аварии.

• Высокая доступность (high availability). Режим работы инфраструктуры, при котором система периодически останавливается в нерабочие дни или на запланированное обслуживание с предварительным уведомлением пользователей. Режим работы определяется работой организации: 8/5, 8/7, 12/5, 12/7 и т.д.

  Для обеспечения высокой доступности IT-системам присваивают статус Business Operational. Инфраструктура этого уровня частично резервируется (сети, данные, электропитание), а также работает в режиме повышенной готовности и должна полностью восстановиться в течение 4-6 часов после аварии.

• Обычная доступность.

  Если высокой доступности и(или) сохранности данных не требуется, IT-системам присваивают статус Office Production. Инфраструктура этого уровня может не резервироваться или резервироваться на самых простых уровнях под конкретные задачи. Время восстановления от одного до нескольких дней. 

Важно! Высокая доступность не равноценна DR, так как включает в себя отказоустойчивость отдельных (или всех) узлов IT-инфраструктуры, но не рассчитана на катастрофы. То есть она готова к отказу магистральной электросети, серверной стойки или интернет-сети, но если что-то серьёзно полыхнёт или взорвётся, то тут полномочия высокой доступности — всё.

4. Заключите SLA — соглашение об уровне обслуживания

SLA (Service-Level Agreement) — это единый документ, договор между поставщиком и клиентом, в котором закрепляются конкретные услуги и их объем, ожидания сторон, их обязанности, точки контактов для решения проблем, метрики эффективности, а также время исправления инцидента (Время реакции на аварию + Время решения проблемы = Время исправления инцидента).

Метрики SLA (цифры, которым должен соответствовать бизнес-процесс).

В третьем пункте я рассказал, как определиться с необходимым уровнем доступности бизнес-процессов, часть из которых зависит от партнёров и подрядчиков, что привносит фактор неопределённости в DRP. И здесь есть две стороны:

1. Ваш внутренний уровень SLA, который выставляется (как требование) сотрудникам и внутренним бизнес-процессам.

2. Уровень SLA, который требуется от контрагентов.

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

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

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

5. Определите RPO и RTO

Важными параметрами аварийного восстановления являются RPO (Recovery Point Objective) и RTO (Recovery Time Objective). Требования по ним идут от бизнеса — директоров, руководителей и менеджеров, а IT-команда пытается максимально приблизиться к требуемым показателям, учитывая бюджет и реальное положение дел

• RPO — это целевая точка восстановления, которая устанавливается после определения точки безубыточности: затраты на сохранность актуальных данных не должны превышать ущерба от их потери. Если RPO равен 1-ой минуте, значит резервная копия будет обновляться каждую минуту. При этом копия будет только одна.

• RTO — это целевое время восстановления. Устанавливается, чтобы понимать, за какой отрезок времени бизнес-процесс должен вернуться к полноценной работе. Если RTO установили в полчаса, значит через 30 минут система должна работать в штатном режиме — ни минутой позже.

Как это выглядит на практике. IT-команда запрашивает у бизнеса требуемые показатели RPO\RTO, получает ответ и “смеётся”. Далее специалисты считают бюджет, и теперь смеётся бизнес (или плачет), после чего показатели корректируются до приемлемых. 

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

6. Выбор конкретного решения DR

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

1. Бэкапы и быстрое восстановление из облака (DRaaS Backup & Restore).

Это компромиссный и относительно недорогой вариант, поскольку не приходится покупать, настраивать и обслуживать дублирующую инфраструктуру; стоимость такого решения минимальна, а платить нужно только за объем данных в облаке и за временное использование виртуальных машин в случае ЧС. Быстрое восстановление допускает непродолжительную остановку бизнес-процессов. 

Чаще всего малый и средний бизнес делает так: бэкапируют систему в облако (получается георезервирование минимальными усилиями), в котором можно быстро восстановиться. Если нагрянет локальный апокалипсис, то запустятся (автоматически или по команде) виртуальные машины, которые возьмут на себя текущие нагрузки. Следом восстанавливают основную IT-систему и переносят нагрузки на неё; виртуалки закрывают, а в облако копируют последующие бэкапы на случай новой аварии. Таким образом показатели RTO/RPO достигают нескольких часов.

Существуют готовые решения DR в облаке:

• Veeam Disaster Recovery Orchestrator;

• Mail.ru Cloud DRaaS;

• CloudMTS Disaster Recovery;

• Множество других DRaaS сервисов.

2. Параллельная инфраструктура (Multi-Site Solution)

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

Аналогично первому пункту можно организовать всё в облаке, но тогда стоит посчитать: в какие затраты это выльется за несколько лет. Возможно, в перспективе 5-10 лет на аренду вы потратите соизмеримую с покупкой и обслуживанием сумму, но владеть ничем не будете. Параллельная инфраструктура позволяет восстановиться очень быстро — от пары секунд до нескольких минут.

Существует две основных стратегии репликации:

• Пассивная репликация:

  

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

• Активная репликация:

  

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

Даже реализуя параллельную инфраструктуру есть несколько вариантов хранения, копирования и резервирования данных:

1. Основная и параллельная системы имеют общую отказоустойчивую СХД, а потому данные всегда поддерживаются в актуальном состоянии. Надёжность, как вы понимаете, зависит от отказоустойчивости СХД;

2. Данные хранятся в разных хранилищах, но сначала записываются в рабочую систему, а потом копируются из основной в резервную. В случае аварии возможна потеря копируемых данных;

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

7. Проверка работоспособности: учения и тесты failover

Будет обидно, если вы заранее побеспокоитесь об аварийном восстановлении, но система не запустится в критической ситуации, так как никто не проводил тесты. И важно учесть, что единоразовым начальным тестированием тут не отделаешься. Сформированная ответственная группа должна постоянно проводить учения и поддерживать актуальное состояние DR-системы, чтобы соответствовать меняющимся внешним и внутренним рискам.

Учения чаще всего проводят отдельно для каждого риска. Например, DR-команда отключает сетевой кабель и тестирует падение интернет-провайдера. Другой сценарий — оценивают влияние человеческого фактора, когда сисадмин пропал (не вышел на работу, не вернулся с обеда). Аналогично проводят и учения по ИБ (информационной безопасности), имитируя различные кибератаки и вмешательства.

Такой подход называется Chaos Engineering (хаос-инженерия).

Например, в 2011 году Netflix создала инструмент Chaos Monkey для тестирования своей IT-инфраструктуры. Основная идея — намеренное отключение серверов и компьютеров в сети Netflix, чтобы проверить работоспособность оставшихся систем. 

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

Важнейшим инструментом Disaster Recovery является работающее аварийное переключение или failover. Чтобы процесс запускался автоматически и максимально быстро, основная и резервная системы должны постоянно обмениваться так называемым “пульсом” — специальным периодическим сигналом. Как только резервная система не получает сообщений от основной в течение заданного времени, запускается протокол failover. 

Как вы уже догадались, канал, по которому передаётся “пульс” должен быть стабильным, надёжным и дублироваться, чтобы избежать ложных переключений. Когда тесты/восстановление закончатся, основная система должна вернуться к штатному режиму работы. Таким образом запускается протокол обратный от failover, называемый failback.

Почему вам нужен DRP, а одних бекапов может не хватить

Некоторые организации ограничиваются бэкапами в вопросах отказоустойчивости. Если в оценках рисков предприятия этого достаточно — окей, но важно, донести информацию до владельцев бизнеса и IT-директора, чтобы не было сюрпризов и полетевших голов после аварии. Даже надёжная схема бэкапирования 3-2-1 — не панацея, хоть и может выступать единственной мерой DRP при ограниченном бюджете.

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

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

Disaster Recovery Plan разрабатывается, чтобы при катастрофах максимально снизить уровень недоступности системы или её части, чтобы ни цепочка сбоев, ни внезапная антропогенная катастрофа не остановили важные бизнес-процессы. Да, в отдельных случаях это требует значительных финансовых вложений, но потому мы и обсуждали оценку рисков — затраты не должны превышать возможных потерь.

Рассмотрим в таблице, какие преимущества даёт полноценная катастрофоустойчивая инфраструктура.

Выводы

Мы начали с того, что непрерывность бизнеса и аварийное восстановление — это две стороны одной медали. Но стоит дополнить, что есть компании, жизнь которых напрямую зависит от наличия этой медали. Если IT-инфраструктура крупного федерального банка откажет на день, то это приведёт к таким колоссальным потерям, что даже представить страшно.

Если ЦОД встанет хотя бы на сутки, то это нанесёт огромный репутационный и финансовый ущерб владельцам, а также приведёт к оттоку клиентов. В марте 2021 года сгорел ЦОД хостинг-провайдера OVH в Страсбурге. Этот инцидент показал, что даже colocation в дата-центрах не даёт полной защиты. Поэтому всегда нужно иметь собственный DRP, хотя бы элементарный в заметках, чтобы не рвать волосы на голове в случае аварии — хотя и это иногда учитывают в DRP: отводят 15 минут на крики, панику и суету :)

Да, введение плана DRP в действие — это крайняя мера, к которой не хочется прибегать, но спать с закрытой дверью в доме спокойнее, чем без двери вовсе.