«Мы тут сервер уронили, ничего страшного?» – история одного переезда

Привет, на связи Дмитрий Бессольцев, руководитель компании ALP ITSM. В своей практике я часто сталкиваюсь с подходом «пока работает — не трогай». Это опасное заблуждение. ИТ-инфраструктура, как здоровье: можно долго игнорировать симптомы, но однажды она откажет в самый неподходящий момент.

Представьте: пятница, вечер. Ваша компания только что переехала в новый офис. Инженеры подключают серверы, вы нажимаете кнопку «Вкл»... и в ответ — тишина, прерываемая лишь зловещим треском жестких дисков. Это не сцена из хоррора, а реальность, с которой столкнулась одна торговая компания после переезда. Один неверный шаг грузчиков поставил под угрозу всю ИТ-инфраструктуру: почту, файловый архив, «1С» и годы накопленных данных.

И это не выдумка. «За 20 лет в ИТ я прошел путь от специалиста техподдержки до руководителя проектного офиса. Видел многое: и серверы, утопленные в канализации, и стойки, прикрученные к гипсокартону. Но история, о которой я расскажу, — это хрестоматийный пример того, как бизнес, игнорируя очевидные риски, сам подводит себя к катастрофе», — так начал свой рассказ Алексей Горюнов, руководитель проектного офиса команды ALP ITSM.

Эта история началась со срочного переезда и одной фразы, брошенной как бы невзначай сотрудником клиента: «А ничего страшного, если мы тут сервер уронили?». Эта фраза стала началом четырехдневной гонки со временем, в которой на кону стояли годы работы, репутация и будущее торговой компании.

Акт 1: Идеальный шторм и проигнорированное предупреждение

Все началось со звонка нашего давнего клиента — торговой компании. Арендодатель попросил срочно освободить помещение, и переезд превратился в спецоперацию. Наша задача была простой: подготовить сеть в новом офисе и подключить оборудование после того, как клиент перевезет его своими силами.

Наш предварительный аудит сразу подсветил «идеальный шторм» из рисков, о которых мы предупредили клиента:

• «Железо-ветеран» на грани отказа. Мы объяснили, что оборудование старше 10 лет может не пережить даже простого отключения и включения, не говоря уже о транспортировке.
• Все яйца в одной корзине. Мы указали на критическую уязвимость: резервные копии ключевых систем хранились на той же дисковой полке, что и основные данные.
• Недоверие к облакам. Клиент был категорически против облачных решений, опасаясь за безопасность данных и не желая «переплачивать».

Мы предложили единственное верное в такой ситуации решение: до переезда создать в облаке полную копию инфраструктуры. Это позволило бы в случае ЧП запуститься за пару часов. Однако, сославшись на бюджет и сжатые сроки, клиент сознательно принял риски на себя.

Мы отключили оборудование, аккуратно упаковали и передали его заказчику для перевозки. А через несколько часов проигнорированное предупреждение стало суровой реальностью.

Акт 2: Признание и обратный отсчет

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

Обратный отсчет пошел. У нас было 96 часов, чтобы поднять бизнес.

Акт 3: План «Б» и вынужденный апгрейд

Пытаться оживить «умершее» железо было бессмысленно. Мы отправили поврежденную полку в сервисный центр (без особой надежды) и приступили к плану «Б»: развертыванию инфраструктуры с нуля.

Шаг 1 (24-48 часов): Возвращение в онлайн. Первым делом нужно было восстановить коммуникации. Мы экстренно развернули в облаке почтовый сервис и контроллер домена. Уже к концу второго дня сотрудники клиента смогли общаться с партнерами и принимать заказы по электронной почте. Вынужденный переезд в облако, которого клиент так опасался, стал его спасением и единственным выходом из критической ситуации.

Шаг 2 (48-96 часов): Восстановление бизнес-процессов. Сервисный центр подтвердил, что данные с полки восстановить невозможно. Но нам повезло. Специалисты, обслуживающие «1С» клиента, делали собственные архивные копии. Самая свежая из них была месячной давности. Мы развернули «1С» из этой резервной копии. За пару дней бухгалтерия смогла актуализировать данные, загрузив недостающие документы из системы ЭДО (электронного документооборота).

Файловый сервер мы восстановили из отдельной резервной копии, которая хранилась на другом носителе.

Итог: За четыре дня клиент получил новую, гибридную инфраструктуру. Критически важные сервисы (почта и «1С») теперь работали в надежном облаке, а файловый сервер — локально. Фатальная ошибка стала точкой роста.

Как не повторить этих ошибок: 3 главных вывода

Эта история — лучшее доказательство того, что фраза «пока работает — не трогай» в ИТ ведет к потерям. Экономия на IT-инфраструктуре — это не сбережения, а всегда отложенный убыток. Вот 3 вопроса, которые стоит задать вашему IT-директору или системному администратору уже сегодня:

1. «Если наш офис завтра сгорит (или его затопит), через сколько часов мы сможем выставить первый счет?» Ответ на этот вопрос покажет, есть ли у вас внешние резервные копии (правило «3-2-1»). Это не какая-то сложная формула, а скорее здравый смысл, который помогает спать спокойно. Представьте его как свой личный план по спасению данных.

Вот что означают эти цифры:

• «3» — у вас должно быть три копии данных. Одна основная, с которой вы работаете, и две резервные. Это как с ключами от квартиры: глупо надеяться, что единственный экземпляр вас никогда не подведет.
• «2» — храните эти копии на двух разных типах носителей. Не стоит записывать все бэкапы на одинаковые диски одной и той же модели. Если у них обнаружится заводской брак, вы рискуете потерять все разом. Лучше комбинировать: например, сервер в офисе и сетевое хранилище (СХД) или облачное хранилище. Это диверсификация рисков.
• «1» — одна копия обязательно должна находиться за пределами офиса. Это ваш «золотой запас» на случай настоящей катастрофы: пожара, потопа или кражи оборудования. Та самая «банковская ячейка», которая может храниться в облаке или на удаленном сервере. Именно эта копия гарантирует, что даже если от офиса останутся одни стены, ваш бизнес сможет восстать из пепла за считаные часы, а не недели.

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

2. «Что мы будем делать, если наш основной сервер просто не включится?» Речь не о данных, а о самом «железе». Есть ли у нас план аварийного восстановления? Запасной сервер, договор с облачным провайдером, «горячий» резерв? Простой критически важен, и ожидание доставки нового оборудования может стоить целое состояние. У вас должен быть четкий ответ: куда восстанавливать данные, где взять новое оборудование, как быстро запустить критичные сервисы. «Теплый резерв» в облаке может спасти бизнес от многодневного простоя

Чтобы такой вопрос не застал вас врасплох, у компании должен быть четкий план аварийного восстановления (Disaster Recovery Plan). Мы подробно разбирали, как его составить, в статье «ИТ-катастрофа не по расписанию». А чтобы вы могли сразу приступить к делу, мы подготовили готовый шаблон этого плана, который можно скачать и адаптировать под свою компанию.

3. «Когда мы в последний раз проводили аудит и обновление оборудования?» Серверы — это не вино, с годами они не становятся лучше. Пятилетний рубеж — это уже повод задуматься о замене, потому что риск внезапного отказа растет в геометрической прогрессии.

Простой в бизнесе всегда стоит дороже, чем инвестиции в его надежность. И иногда, чтобы это осознать, нужно один раз что-нибудь уронить. Лучше, если это будет не ваш сервер.