17 губительных ошибок при переезде ЦОД

За более чем 27-ми летнюю историю Компания ВИЗАРД реализовала сотни проектов. И большая часть в этих проектах связана с миграцией инфраструктуры Заказчиков в новую локацию. Конечно, практически всегда услуги по миграции Заказчику предлагают и другие игроки ИТ-рынка. Но все равно вся ответственность за работу бизнес-процессов лежит на внутренней команде ДИТ. В этой статье мы собрали ключевые риски, которые могут привести к серьезным последствиям – простоям приложений, потери части данных и даже невозможности восстановления бизнес-функций. Итак, вот наш АНТИхит-парад:

1. Не делайте и не проверяйте бэкап. Вам ведь просто перевести оборудование – тут выключили, там включили! Абсолютно нормальным считается, если в процессе переезда от 0,1 до 1 % оборудования начинает сбоить или не включается штатно. Даже процесс вынимания из стойки старого сервера может привести к попаданию старой пыли в разъем или вентилятор.

- - Важно обязательно проверять корректность проведения самого процесса восстановления данных до миграции
  - Проверить, что вы знаете все учетные записи, начиная от уровня BIOS и до приложений и сервисов

2. Перевозить и инфраструктуру и backup (дисковый) в одной машине. Автоаварии в мегаполисах не редкость. Достаточно сильного толчка, чтобы опрокинуть тяжелую стойку. И тогда восстановление станет невозможным в принципе

- - Обязательно оставляйте копию полного бэкапа в старом офисе

3. Иметь формальный план Б или не иметь вовсе, надеясь на штрафы подрядчику. Ну просто все вернется на место, если что. Не редки случаи, когда при откручивании вентилей со старой системы кондиционирования или пожаротушения можно повредить трубку, или повредить кабель, наездом стойки или случайно вырвать кабель «с корнем»

- - Важно составить карту рисков, рассчитать стоимость, вероятность и возможный ущерб
  - Только после этого уже четко прописывать действия коллектива проекта, предельные сроки, когда принимается решение об откате или изменении процесса

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

- - Важно с провайдером договориться о временном увеличении емкости канала в 2-10 раз на 2 недели в процессе переезда

5. Не обеспечивать резервное питание. Часто даже в подготовленных ЦОДах подключение не идет гладко

- - Запас мощности подменного ИБП позволит ускорить процесс запуска инфраструктуры на площадке

6. Не иметь запасных мощностей

- - Смотрим пункт 1. Да, сбои возможны. Важно иметь холодный подготовленный комплект (вычислитель, ОС, дисковая система, бэкап), чтобы не искать в ночи жертву из собственного «стада» и выкачивать дистрибутив из сети. Лучше включить это в стоимость переезда и сделать подготовленные комплекты заранее. На складах дистрибуторов и интегратора всегда есть запас ключевых компонентов

7. Не использовать Облако

- - Часто Заказчики сначала мигрируют данные в Облако, перевозят оборудование, проверяют его полностью и потом уже мигрируют из Облака. Это сокращает время простоев и риск фатальной остановки сервиса

8. Соглашаться с бизнесом на минимальное окно downtime

- - Миграция – это сложнейший процесс и важно согласовывать окно не только на лучший вариант развития событий, но и на худший сценарий. Ведь бизнесу тоже нужно подготовить реакцию на такие обстоятельства
  - Обязательно нужно иметь в команде бизнес-партнера по кризисным коммуникациям, чтобы не отвлекать команду ИТ от прямой работы

9. Не иметь кабельных журналов, лейблов и фотографий подключений и инфраструктуры. Тогда нам останется только надежда 😊

- - В сложной инфраструктуре изменения проходят постоянно. И даже перед миграцией важно абсолютно точно иметь мораторий на изменения и фотографии не только самих контактов, но и укладки кабелей

10. Не отследить весь путь прохождения и проезда оборудования. В дорогих решениях часто устанавливаются датчики вибрации и наклона – система просто не запустится и будет снята с гарантии. Кроме того, оборудование может просто не пройти и задеть важные элементы здания (трубы, кабели, дизайнерские объекты….)

- - Обязательно проехать и задокументировать весь маршрут, отследить такие объекты как:

11. Не иметь связанного графика остановки и запуска серверов, служб и сервисов

- - Лучше для этого использовать скрипты. Это снизит вероятность ошибок
  - Важно иметь проверочные процедуры, чтобы не исправлять ошибки последовательности запуска
  - Журнал всех необходимых учетных записей, электронных ключей (вдруг они используются на обеих площадках)

12. Не проверять настройки сегментации и IP-адресации. Часто сервисы могут быть жестко настроены на статические адреса и просто перестать функционировать в другой подсети

- - Проверяйте настройки правил внутренних и внешних FireWalls
  - Проверяйте возможность удаленного доступа из других подсетей

13. Не проверять гарантийные контракты на оборудование и ПО. Многие вендоры в договоре поддержки прописывают адрес поддержки. Перевезете без их ведома – там не будут поддерживать. Что-то сломается при переезде – ваши проблемы. Не работает поддержка с новым пространством адресов

- - Обязательно официально получайте письма от вендоров и партнеров о сохранении или изменении гарантийных обязательств

14. Не использовать упаковку. Это вопрос не только грязи и пыли. Это вопрос сохранения целостности конструкции при переносе (винтов, дисков и другой съемной фурнитуры оборудования). От толчка из дисковой полки может высыпаться не только проклятья администратора, но и ваша трудовая книжка (шутка) И физической безопасности!

- - Используйте плотную пленку и правильно защищайте углы и другие выступающие детали

15. Использовать обычные автомобили для перевозки. Уровень вибрации на таких автомобилях контролировать нельзя

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

16. Складывать сервера пачкой

- - Корпуса серверов не предназначены для поддержки большой нагрузки. Ведь они в стойке не давят друг на друга, а держатся в полозьях
  - Обязательно использование поролоновых прокладок.
  - Предельное количество в такой стопке – 3 штуки. Далее риск неприемлем

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

- - Запаковывайте критичное оборудование в жесткие строительные пакеты и фиксируйте стяжкой с несъемной разрушающейся биркой
  - Создайте ответственную роль и процесс передачи, приемки и ответственного вскрытия упаковки

17 губительных ошибок при переезде ЦОД

Наши специалисты с удовольствием поделятся нашим опытом и помогут с гарантированным профессиональным переездом. Вот список наших проектов: