План непрерывности ИТ: что делать при сбое сервера

Сервер выходит из строя в четверг после обеда. Резервная копия есть, администратор проверяет её раз в месяц, никто не волнуется — пока не выясняется, что полное восстановление занимает три дня, а не три часа, потому что процесс никто и никогда не засекал от начала до конца. Эти три дня выставление счетов стоит, заказы записываются на бумаге, а клиенты звонят спросить, что случилось. Компания не потеряла данные. Она потеряла время, деньги и, у части клиентов, терпение. Разница между таким сценарием и тем, что решается за несколько часов, — не в бюджете на ИТ, а в том, что кто-то заранее записал, что восстанавливается первым и сколько времени на это допустимо.

Почему резервная копия — это не план непрерывности

Резервная копия отвечает на один вопрос: если данные потеряются, есть ли они ещё где-то? План непрерывности отвечает на другой, более неудобный вопрос: сколько времени компания может работать без этой системы, и что она делает в это время? Эти два понятия легко путают, потому что они кажутся частью одной темы — защиты данных, — но проверенная резервная копия без протестированного вокруг неё плана восстановления гарантирует лишь то, что данные не потеряны навсегда, а не то, что компания не остановится. У многих малых компаний в Молдове резервные копии уже есть; мало кто хоть раз засекал, сколько на самом деле занимает вернуть критичную систему в рабочее состояние с нуля.

Что такое ИТ-непрерывность для небольшой компании на практике

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

RTO и RPO: два вопроса, которые на самом деле важны

За любым планом непрерывности стоят два простых вопроса, известных в отрасли под аббревиатурами RTO и RPO. RTO (recovery time objective) — это максимально допустимое время простоя системы, после которого остановка становится серьёзной проблемой для бизнеса: для выставления счетов или сайта интернет-магазина это время обычно короткое, а для архива старых документов — может быть несколько дней без практических последствий. RPO (recovery point objective) — это сколько из самых свежих данных компания готова потерять: если последняя резервная копия сделана 24 часа назад, а система падает, всё, что было введено за эти 24 часа, при восстановлении теряется. Компании, которые никогда не задавали себе эти два вопроса, обычно узнают ответ уже во время реального сбоя, когда это уже не решение, а только потеря.

Что инвентаризировать перед тем, как писать план

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

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

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

Недорогие меры, которые снижают риск без большого бюджета

Не вся защита стоит дорого. ИБП (источник бесперебойного питания) для сервера или роутера компании стоит относительно немного и устраняет самую частую банальную причину простоя — короткое отключение электричества, которое сбрасывает всё сетевое оборудование. Второе подключение к интернету, пусть даже мобильный роутер в качестве резерва, покрывает ситуацию, когда проблема не в компании, а у интернет-провайдера. Резервная копия, хранящаяся за пределами офиса — в облачном сервисе или физически в другом месте, — защищает именно тот сценарий, когда проблема касается всего здания, а не одного устройства. И, пожалуй, самый дешёвый шаг из всех: письменные процедуры на одной странице, доступные любому в команде, а не только тому человеку, который «знает, как устроен сервер» — потому что этот человек может быть в отпуске, на больничном или уже не работать в компании именно тогда, когда возникнет проблема.

Тестирование плана: почему непротестированный план так же рискован, как его отсутствие

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

Частые ошибки

Самая частая ошибка — путать наличие резервной копии с наличием плана: у компании есть копии, но никто никогда не считал, сколько занимает полное восстановление. Вторая — сосредоточение всех знаний у одного человека без единой письменной процедуры: если с этим человеком нельзя связаться, плана фактически не существует, как бы хорошо он ни работал у него в голове. Третья — игнорирование коротких сбоев как слишком мелких, чтобы о них думать заранее, — именно такие мелкие сбои случаются чаще всего и без минимальной процедуры могут длиться намного дольше, чем должны, просто из-за импровизации. Четвёртая — отношение к удалённому доступу как к наспех настроенному аварийному решению: импровизированное VPN-подключение без обслуживания само может стать точкой отказа именно тогда, когда оно нужнее всего.

Кто занимается этим на практике

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

Запросите бесплатную консультацию об инфраструктуре вашей компании и узнайте, сколько реально займёт восстановление — не просто есть ли резервная копия, а работает ли она на практике.