План аварийного восстановления: за сколько вы реально поднимете инфраструктуру

План аварийного восстановления отвечает на два вопроса: сколько времени пройдёт от аварии до работающего сервиса и сколько данных вы за это время потеряете. Всё остальное в плане - способы уложиться в эти два числа. Если на вопрос «сгорел сервер, когда заработает почта?» вы отвечаете «ну, за день, наверное», плана у вас нет.

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

С чего начинать: список сервисов, а не список железа

Первая ошибка - начинать с инвентаризации оборудования. Пользователь не жалуется на диск, он жалуется на то, что не открывается 1С. Планировать надо от сервисов.

Соберите короткий список того, без чего предприятие встанет. У большинства компаний он выглядит скучно и предсказуемо: почта, телефония, файловое хранилище, 1С, интернет, печать. Дальше по каждому сервису отвечаете на один вопрос: сколько он может лежать, прежде чем начнутся настоящие потери?

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

Точки отказа: где именно ломается

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

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

Минимальный список мест, куда стоит заглянуть в любой инфраструктуре:

Отдельно отметьте зависимости между точками. Классика: умерла почтовая служба, следом отвалилась дисковая полка, а уведомления о ней приходили почтой - и вы узнаёте о второй аварии от пользователей через сутки. Или в шасси блейд-сервера отказало питание, и вместе с ним разом ушли все сервисы, которые вы считали независимыми.

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

Из чего складывается время восстановления

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

1. Обнаружение. От момента отказа до момента, когда о нём узнал человек, способный что-то сделать. Без мониторинга эта фаза длится до первой жалобы пользователя - а ночью до утра.
2. Локализация. Понять, что именно сломалось. Дольше всего обычно тянется именно она, особенно если отказ плавающий. Замена сдохшего блока питания занимает пятнадцать минут; понять, что дело в нём, можно за полдня.
3. Решение и эскалация. Кто чинит, чем чинит, надо ли будить начальника, есть ли деньги на срочную закупку.
4. Собственно работы. Замена, восстановление из копии, перенастройка.
5. Проверка и возврат в строй. Убедиться, что сервис действительно работает, а не «пингуется».

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

Две метрики, которыми это принято описывать, - RTO (за сколько поднимем) и RPO (за какой период потеряем данные). Считать их отдельно, по каждому критичному сервису, а не одно число на всю компанию. Как это делается на практике, мы разобрали в статье про RPO и RTO простыми словами - здесь повторяться не будем.

Что сокращает время восстановления в реальности:

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

Сколько стоит простой: от девяток к деньгам

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

Уровни доступности в год выглядят так:

Дальше арифметика простая. Возьмите выручку за рабочий день и прикиньте, какая её доля встанет вместе с сервисом. Не вся: при отказе печати компания работает, при отказе 1С в оптовой торговле - нет. Умножьте на часы из таблицы. Получившееся число и есть бюджет, в пределах которого резерв окупается.

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

Кто чинит: своя служба, подрядчик и правда про SLA

Дальше выясняется, что время восстановления зависит не столько от железа, сколько от того, кто и когда до него доберётся.

Внутренняя служба

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

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

Подрядчик и что написано в SLA мелким шрифтом

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

Три вещи, которые надо развести до подписания:

• Время реакции - через сколько вам ответят. Это не время восстановления, и подрядчики честно пишут именно реакцию.
• Время восстановления - через сколько сервис заработает. В договорах встречается заметно реже, а стоит заметно дороже.
• Часы обслуживания - 8×5, 24×7 или что-то между. Отказ в 19:05 при поддержке 8×5 попадает в следующее утро.

Отдельно про сервисные контракты на оборудование. Строка NBD (Next Business Day) означает поставку запчасти к следующему рабочему дню, а не восстановление сервера к следующему рабочему дню. Выезд инженера в базовый NBD-контракт чаще всего не входит и покупается отдельно. Между «запчасть приедет завтра» и «сервер заработает завтра» помещается ещё вся ваша фаза работ - и она ваша, а не вендорская.

Если подрядчик уже есть и SLA вас не устраивает, вариантов немного: пробовать пересогласовать условия вместе с правом на проверочные обращения, менять подрядчика, добавлять второго про запас. Иногда вы имеете дело с монополистом, который на нужные условия не пойдёт, - тогда честнее донести это до руководства и строить собственный запас прочности, а не надеяться на договор.

Резервы: холодный, тёплый, горячий

Резерв - это способ купить время. Чем быстрее он вступает в работу, тем дороже стоит.

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

Тёплый резерв - машина стоит включённой, настроенной, с более-менее свежими данными. Переключение занимает минуты, но железо всё это время потребляет питание и требует обслуживания.

Горячий резерв - нагрузка распределена, отказ узла пользователь не замечает. Дороже всего, зато время восстановления стремится к нулю. Как это устроено на уровне серверов, разбирали в статье про отказоустойчивый кластер.

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

Что в план не влезет

Планирование не покрывает всё, и делать вид, что покрывает, вредно. За рамки обычно выходят два класса событий.

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

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

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

Как проверить, что план работает

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

1. Восстановить один сервис из резервной копии на тестовом железе и засечь время. Сравнить с тем, что записано в плане.
2. Проверить, что контакты в плане живые: телефоны подрядчика, ответственные, доступы к личным кабинетам провайдеров.
3. Прогнать один сценарий «вслух»: собрать причастных и по шагам проговорить, кто что делает при отказе конкретной точки. Половина дыр вылезает уже здесь, бесплатно.
4. Проверить, что резервное оборудование включается. Полежавший год на полке блок питания - тоже точка отказа.

После каждой реальной аварии план правится. Записывать надо конкретику: сколько заняла каждая фаза и что мешало. Формулировка «всё прошло хорошо» плану не даёт ничего.

Частые вопросы

Что такое план аварийного восстановления простыми словами?
Это документ, который отвечает, за сколько и как вы поднимете каждый критичный сервис после сбоя. В нём: список сервисов и допустимое время простоя по каждому, точки отказа и их зависимости, кто чинит и в какие сроки, какие резервы есть, откуда берутся данные.

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

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

Что гарантирует контракт NBD?
Поставку запчасти к следующему рабочему дню. Не восстановление системы и не приезд инженера - выезд специалиста обычно оплачивается отдельно. Планируйте так, что после доставки запчасти работы вы ведёте сами.

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

Нужен ли малому бизнесу дублирующий ЦОД?
Почти никогда. Для компании на 20-50 человек разумный порядок такой: мониторинг, проверенные бэкапы в нескольких местах, холодный резерв по критичным точкам, сервисный контракт на критичное железо. Резервная площадка обсуждается, когда простой стоит дороже её содержания.

По теме: Что делать, если удалённый сервер замолчал · Безопасность серверной