DR-план для небольшой компании: как восстановить IT-инфраструктуру после сбоя за минимальное время

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

Почему «мы что-нибудь придумаем» — это не план

У одного клиента, юрфирмы на 22 человека, в пятницу вечером сдох RAID-контроллер на файловом сервере. Именно в пятницу — они всегда ломаются в пятницу. Диски живы, данные вроде тоже, но сервер не грузится. Директор звонит мне в панике: «Что делать?!» А делать особо нечего — потому что никто заранее не проверял, где лежит бэкап, кто имеет права его развернуть и на каком железе. В итоге восстанавливались трое суток. Три дня без доступа к документам по действующим делам. Посчитайте сами, во сколько это встало в часах юристов по 3-5 тысяч рублей.

А вот другая история, с тем же исходным сбоем. Медицинская клиника, 12 рабочих мест, тоже отказ диска на сервере с 1С и картотекой пациентов. У них уже был план — простой, на двух страницах, но был. Через 40 минут после звонка мы подняли резервную копию на запасном мини-сервере, который специально держали в шкафу «на всякий случай» за 45 тысяч рублей. Регистратура работала весь день, только на резервных мощностях. Разница не в деньгах на технику — она была почти одинаковая у обеих компаний. Разница в том, что один раз кто-то сел и подумал наперёд.

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

Что вообще такое DR-план — без умных слов

DR расшифровывается как Disaster Recovery — восстановление после катастрофы. Звучит громко, но катастрофой в масштабах компании на 20-40 человек может быть что угодно: сдох сервер, зашифровал всё вирус-шифровальщик, электрик обесточил офис и сгорел блок питания, бухгалтер случайно удалила базу 1С за квартал. У меня в практике самая частая причина — банальный отказ диска и человеческий фактор, а вовсе не хакеры и не пожар, хотя про пожар я тоже расскажу ниже.

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

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

Шаг первый: составьте список того, что вообще есть

Удивительно, но большинство директоров не могут с ходу перечислить все критичные IT-сервисы своей же компании. Спрашиваю: «А CRM у вас где крутится?» — «Ну... где-то в облаке, Марина знает». А Марина в отпуске. Поэтому первый шаг — не хитрый, а нудный: сесть и выписать реально всё. 1С (и на каком сервере, локально или в облаке типа SBIS или 1cfresh), файловый сервер с общими папками, почта (свой сервер или Яндекс 360/облако), сайт и его хостинг, CRM, программа складского учёта, система видеонаблюдения, если критична для бизнеса, домен Active Directory, если есть.

У торговой компании из 30 человек, с которой я работал в прошлом году, в этом списке оказалось 11 отдельных сервисов. Директор был уверен, что их пять. Остальные шесть годами держались на честном слове и на том, что «оно само работает». А оно работает, пока не перестаёт — и тогда выясняется, что пароль от админки CRM знал только уволившийся полгода назад сисадмин.

По каждому сервису сразу пишите: где физически стоит железо (свой сервер, VPS, облако), кто провайдер (если это аренда), какой логин у ответственного за доступ. Без этой карты дальше двигаться бессмысленно — вы просто не поймёте, что и в каком порядке спасать.

Шаг второй: расставьте приоритеты — RTO и RPO по-человечески

Есть два умных термина, которые на самом деле простые. RTO — это сколько времени вы готовы терпеть простой сервиса. RPO — это сколько данных вы готовы потерять, если бэкап делался не только что. Для 1С с проводками за сегодня RPO обычно должен быть не больше 4 часов — то есть бэкап минимум четыре раза в день, а лучше каждый час через штатные механизмы записи журнала транзакций. Для файлового архива пятилетней давности RPO хоть сутки — там ничего критичного не поменяется за день.

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

Разбейте все сервисы из вашего списка на три группы: критично (встали — теряем деньги в первый же час), важно (можно потерпеть день), не срочно (неделя погоды не сделает). У большинства компаний до 50 рабочих мест в первой группе оказывается всего два-три сервиса, максимум четыре. Именно на них и тратьте основные усилия — тестируйте резервные копии, держите запасное железо, прописывайте пошаговые инструкции. Остальное можно восстанавливать без спешки, обычным порядком.

Шаг третий: назначьте ответственных поимённо, а не «айтишников»

Самая частая ошибка в самодельных планах — фраза «восстановлением занимается IT-отдел». А если в IT-отделе один человек, и он в этот момент едет из отпуска с моря, кто восстанавливает? По каждому критичному сервису в плане должно быть написано конкретное имя и телефон — основной ответственный и запасной. Плюс контакты внешнего подрядчика, если своего сисадмина нет вообще (и это, кстати, абсолютно нормальная ситуация для компании до 30 человек — держать штатного айтишника ради одной аварии в год невыгодно).

У клиента-бухгалтерской компании план выглядел так: «1С — восстанавливает Игорь (моб. +7...), если недоступен — звонить в АйТи-Фреш по договору техподдержки, там знают пароли и топологию сети, время реакции по SLA два часа». Просто, конкретно, работает. Никакой неопределённости в три часа ночи, когда сервер решил не грузиться после планового обновления Windows.

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

Шаг четвёртый: протестируйте план, пока всё хорошо

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

Тестировать нужно не реже раза в квартал, и это не «посмотреть, что файл бэкапа весит правильный размер». Это реальное развёртывание копии на тестовом железе или в отдельной виртуалке и проверка, что 1С открывается, база не битая, документы на месте. Занимает часа полтора-два для среднего клиента. Дешевле, чем потом восстанавливать вслепую и материться, почему ничего не работает.

Хорошая практика — раз в год устраивать что-то вроде учебной тревоги: без предупреждения сотрудников (или с предупреждением, если коллектив нервный) отключить основной сервер и посмотреть, за сколько реально поднимается резервный контур по написанному плану. У торговой компании из примера выше первая такая тревога показала, что «запасной ноутбук с копией базы» на самом деле находится дома у уволенного полгода назад менеджера. Лучше узнать это на учениях, чем в реальной аварии.

Что делать, если плана нет вообще — с чего начать сегодня

Не пытайтесь сразу написать идеальный документ на 20 страниц с диаграммами — вы его бросите на второй странице. Возьмите лист бумаги, а лучше файл в общей папке, и минимум на сегодня пропишите три вещи по самому критичному сервису — обычно это 1С или файловый сервер с документами. Где лежит последний рабочий бэкап (проверьте прямо сейчас, что он вообще существует и открывается). Кто умеет его развернуть. Куда звонить, если этот человек недоступен.

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

И последнее: если своими силами тяжело — это нормально повод обратиться к аутсорсеру именно за составлением плана, даже разово, без постоянного обслуживания. Час-два консультации с грамотным айтишником, который задаст правильные вопросы про ваши сервисы, стоит в разы дешевле одного дня простоя. Мы в АйТи-Фреш делаем такой аудит под ключ примерно за 1-2 рабочих дня для компании на 30-40 рабочих мест, включая тестовое восстановление одного критичного сервиса — чтобы план не остался просто бумажкой.

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

Сколько стоит составить DR-план для небольшой компании?
Если делать своими силами по шагам из статьи — почти бесплатно, только время. Если привлекать подрядчика для аудита и написания плана под ключ, для компании на 20-40 рабочих мест это обычно укладывается в стоимость одного-двух дней работы IT-специалиста, разово, без абонентского обслуживания.

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

Как часто нужно тестировать план восстановления?
Минимум раз в квартал проверяйте, что бэкапы реально разворачиваются и данные целые. Раз в год стоит устроить полноценные учения с отключением рабочего сервера, чтобы проверить не только технику, но и то, что все ответственные знают свою роль.

С чего начать, если раньше про DR-план вообще не думали?
Начните с одного самого критичного сервиса — обычно это 1С или файловый сервер. Прямо сегодня проверьте, что бэкап существует и открывается, запишите, кто умеет его восстановить и куда звонить, если этот человек недоступен. Остальные сервисы добавляйте по одному в неделю.