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