«Мы тут сервер уронили, ничего страшного?» – история одного переезда
Представьте себе картину: вечер пятницы, суматоха переезда в новый офис позади. Инженеры подключают оборудование, вы с замиранием сердца нажимаете кнопку «Вкл»... и в ответ — тишина. Звенящая, пугающая тишина, которую нарушает лишь зловещий треск умирающих жестких дисков. Это не триллер, а реальный кейс, который наглядно показывает, как один неловкий шаг может поставить под угрозу всё: почту, бухгалтерию, архивы и годы работы.


Автор: Алексей Горюнов, руководитель проектного офиса ALP ITSM
За 20 лет в IT я повидал всякое. И серверы, утопленные в прорванной канализации, и стойки, прикрученные к гипсокартону на честном слове. Но эта история — хрестоматийный пример того, как бизнес, упорно закрывая глаза на риски, сам загоняет себя в ловушку.
История началась со срочного переезда и одной фразы, брошенной как бы невзначай сотрудником клиента: «А ничего страшного, если мы тут сервер уронили?». Эта фраза стала началом четырехдневной гонки со временем, в которой на кону стояли годы работы, репутация и будущее торговой компании.
Как назревала катастрофа: комбинация губительных факторов
Все началось со срочного переезда. Наш давний клиент, торговая компания, получил уведомление от арендодателя: нужно как можно скорее освободить помещение. Нашей команде поставили задачу подготовить IT-инфраструктуру в новом офисе и подключить оборудование после того, как клиент перевезет его своими силами.
Уже на этапе предварительного аудита мы увидели идеальный шторм из трех факторов риска, о которых сразу же предупредили клиента:
- Оборудование на последнем издыхании. Серверы и дисковая полка, отметившие десятилетний юбилей, могли не пережить даже простого выключения, не говоря уже о тряске при перевозке. Это была бомба с часовым механизмом.
- Все яйца в одной корзине. Мы обнаружили критическую уязвимость: резервные копии всех ключевых систем хранились на том же физическом диске, что и основные данные. В случае поломки «железа» компания теряла абсолютно всё.
- Недоверие к «облакам». Руководство клиента наотрез отказывалось от облачных решений, ссылаясь на соображения безопасности и нежелание «переплачивать за воздух».
Мы предложили единственно верное решение: еще до переезда развернуть в облаке полную копию инфраструктуры. Это создало бы «запасной аэродром», который позволил бы запуститься за пару часов при любом ЧП. Но, сославшись на сжатые сроки и бюджет, клиент решил рискнуть. Мы аккуратно отключили и упаковали оборудование, передав его в руки заказчика. А спустя несколько часов риск превратился в катастрофу.
Гром грянул: 96 часов на спасение
Когда наши инженеры в новом офисе попытались запустить систему, их встретил черный экран. Пазл сложился мгновенно. Неловкость грузчиков, удар, старые диски... Цепная реакция разрушила файловую систему. А поскольку бэкап лежал там же, компания в один миг лишилась доступа к почте, документам, базам данных и самой возможности работать.
Обратный отсчет пошел. У нас было всего 96 часов, чтобы вернуть бизнес к жизни.
План «Б» в действии: от хаоса к современной инфраструктуре
Пытаться реанимировать «умершее» железо было бессмысленно. Мы отправили поврежденную дисковую полку в лабораторию по восстановлению данных (без особой надежды) и немедленно приступили к плану «Б» — развертыванию всей инфраструктуры с нуля.
Шаг 1: Возвращение в онлайн (первые 48 часов). Первым делом нужно было восстановить связь с внешним миром. Мы экстренно развернули в облаке почтовый сервис и контроллер домена. Уже к концу второго дня сотрудники смогли общаться с клиентами и принимать заказы. Ирония судьбы: облако, которого так боялся клиент, стало его единственным спасением.
Шаг 2: Восстановление бизнес-процессов (следующие 48 часов). Из лаборатории пришел неутешительный вердикт: данные восстановить невозможно. Но тут нам улыбнулась удача. Выяснилось, что специалисты, обслуживающие «1С», делали собственные архивные копии. Самая свежая была месячной давности — не идеально, но это был шанс. Мы развернули «1С» из этого бэкапа, а бухгалтерия за пару дней вручную внесла недостающие операции из системы электронного документооборота. Файловый сервер удалось поднять из другой резервной копии, которая по счастливому стечению обстоятельств хранилась на отдельном носителе.
Итог: За четыре дня клиент не просто вернулся к работе, а получил новую, гибридную и куда более надежную ИТ-инфраструктуру. Критически важные сервисы теперь работали в защищенном облаке, а менее значимые — локально. Фатальная ошибка, как это часто бывает, стала точкой роста.
Чему нас учит эта история? 3 вопроса вашему ИТ-директору
Этот кейс — лучшее доказательство того, что принцип «пока работает — не трогай» в IT ведет к катастрофе. Экономия на инфраструктуре — это не сбережения, а отложенный на время убыток. Задайте своему IT-специалисту три простых вопроса уже сегодня:
«Если наш офис завтра исчезнет (сгорит, затонет, улетит в космос), через сколько часов мы сможем выставить первый счет?»
Ответ на этот вопрос покажет, есть ли у вас план аварийного восстановления и внешние резервные копии, организованные по правилу «3-2-1». Это не магия, а здравый смысл:
3 копии данных: одна рабочая и две резервные.
2 разных носителя: например, сервер и внешний диск, чтобы сбой одного типа оборудования не уничтожил всё.
1 копия за пределами офиса: в облаке или дата-центре. Это ваш «золотой запас» на случай локальной катастрофы.
«Что мы будем делать, если наш основной сервер просто не включится?»
Речь не о данных, а о «железе». Есть ли у вас план, куда эти данные восстанавливать? Запасной сервер, договор с облачным провайдером, «горячий» резерв? Простой в несколько дней, пока вы ждете доставку нового оборудования, может стоить целое состояние.
Чтобы такой вопрос не застал вас врасплох, у компании должен быть четкий план аварийного восстановления (Disaster Recovery Plan). Мы подробно разбирали, как его составить, в статье «ИТ-катастрофа не по расписанию». А чтобы вы могли сразу приступить к делу, мы подготовили готовый шаблон этого плана, который можно скачать и адаптировать под свою компанию.

На рисунке шаблон плана восстановления.
Заполните форму — на email отправим шаблон DRP плана, который мы разработали для своих клиентов.
«Когда мы в последний раз проводили аудит и думали об обновлении?»
Серверы — это не вино, с годами они не становятся лучше. Пятилетний рубеж — это уже не просто повод задуматься, а сигнал к действию. Риск внезапного отказа после этого срока растет в геометрической прогрессии.
Простой в бизнесе всегда стоит дороже, чем инвестиции в его надежность. И иногда, чтобы это осознать, нужно один раз что-нибудь уронить. Лучше, если это будет не ваш сервер.