Это собирательный сценарий: он сложен из нескольких похожих случаев и показывает разницу, которую трудно объяснить словами. Одна и та же авария — отказ диска на сервере небольшого магазина — в одном случае решается за двадцать минут, в другом растягивается на три дня. Отличается не мастерство инженера в момент аварии. Отличается то, что было сделано до неё.
Что произошло
Вечер пятницы. Сервер перестал отвечать. Хостинг подтвердил: отказ дискового массива, данные на этой машине недоступны, сроки восстановления неизвестны.
Ситуация, в которой обычно начинается паника: заказы не принимаются, клиенты не могут оплатить, а телефон уже звонит.
Двадцать минут по шагам
- 0–2 минуты. Мониторинг прислал уведомление раньше, чем о проблеме сообщил клиент. Инженер уже смотрел, в чём дело.
- 2–5 минут. Проверили: сервер не отвечает, хостинг подтвердил аппаратную проблему без сроков. Решение приняли сразу — не ждём, разворачиваемся на запасной площадке.
- 5–12 минут. Развернули последнюю копию на подготовленный сервер у другого провайдера. Копия ночная, плюс отдельная копия базы за час до аварии.
- 12–15 минут. Проверили руками: сайт открывается, каталог на месте, тестовый заказ проходит, письма отправляются.
- 15–20 минут. Переключили DNS. TTL был выставлен низкий заранее, поэтому посетители начали попадать на рабочий сервер почти сразу.
Потери составили несколько заказов, оформленных в последний час перед аварией. Их восстановили вручную — из писем-уведомлений, которые магазин отправляет владельцу при каждом заказе.
Почему получилось быстро
Ни один шаг выше не был импровизацией. Каждый опирался на то, что сделали заранее и в спокойное время.
- Мониторинг заметил раньше людей. Это выигрывает первые минуты, а в аварии первые минуты стоят дороже всех остальных.
- Копии лежали не на том же сервере. Диск умер вместе с машиной — и, если бы бэкапы хранились там же, они умерли бы вместе с ним.
- Копии проверяли. Инженер знал, что архив развернётся, потому что уже разворачивал его на тесте двумя месяцами раньше.
- Была запасная площадка. Не вторая работающая копия магазина, а просто подготовленный сервер с нужными версиями ПО, куда есть куда развернуться.
- Низкий TTL у DNS. Настройка на пять минут, которая в аварии экономит часы.
- Был план. Никто не обсуждал, что делать. Решение «разворачиваемся» приняли на третьей минуте, потому что критерий согласовали заранее.
Та же авария без подготовки
Теперь тот же вечер пятницы, но у проекта, которым системно никто не занимался.
Проблему замечают через час-полтора — когда напишет первый клиент. Дальше выясняется, что резервные копии делает плагин и складывает их на тот же сервер, то есть они недоступны вместе с ним. Находится копия месячной давности у кого-то на ноутбуке. Разворачивать её некуда: новый сервер надо заказать, настроить, поставить нужные версии. Доступы к панели регистратора домена — у подрядчика, который делал сайт три года назад. TTL у DNS — сутки.
Три дня в такой ситуации — не преувеличение, а обычный срок.
Что можно сделать у себя
Не обязательно строить всё сразу. Порядок примерно по отдаче на вложенные усилия:
- Убрать резервные копии с того же сервера — хотя бы в облачное хранилище.
- Один раз развернуть копию на тестовой площадке и засечь время.
- Снизить TTL у DNS до 300 секунд. Это бесплатно и делается за пять минут.
- Собрать в одном месте доступы: хостинг, домен, панель управления, почта. И убедиться, что они есть у вас, а не только у подрядчика.
- Записать на одну страницу, что делать при отказе сервера и кто принимает решение.
Коротко
Разница между двадцатью минутами и тремя днями — это примерно один рабочий день подготовки, потраченный заранее, когда ничего не горит.
С новыми клиентами мы обычно начинаем именно с этого: смотрим, куда падают копии, разворачиваем одну на тесте и считаем реальное время восстановления. Часто это самое полезное, что можно сделать за первую неделю работы.