Порядок восстановления ИТ-инфраструктуры

Однажды поручили разработать нам DRP (Disaster Recovery Plan) – План восстановления деятельности после кризисной ситуации. План как план, таких мильон.

Но один раздел запал мне в душу – Порядок восстановления ИТ-инфраструктуры.

В моём видении, базирующемся на опыте переездов ЦОДов, порядок получился таким:

Наименование Описание Порядок восстановления
Инженерные системы ЦОД Энергоснабжение и источники бесперебойного питания, системы вентиляции и кондиционирования, автоматического пожаротушения, охранной сигнализации и контроля доступа, видеонаблюдения 1
Ядро сети Базовая инфраструктура сети, уровень ядра 2
Коммутаторы и маршрутизаторы системы передачи данных Базовая инфраструктура сети на уровнях распределения и доступа 3
Коммутаторы сети хранения данных Базовая инфраструктура сети хранения данных 4
Системы хранения данных Базовая инфраструктура хранения данных 5
Аппаратные серверы Базовая вычислительная инфраструктура 6
Гипервизоры Абстракция базовой вычислительной инфраструктуры 7
Операционные системы Системное программное обеспечение и операционные системы 8
DNS, DHCP, CA, DC/ADFS Система доменных имен, сервис динамического конфигурирования сетей хостов, центр сертификатов, службы каталогов 9
Оборудование IP-телефония Телефония 10
Узлы доступа в Интернет Доступ в Интернет 11
Почтовые серверы Электронная почта 12
Системы мониторинга ИТ-сервисов Контроль работы ИТ-сервисов 13
Серверы антивирусной защиты и СЗИ Антивирусная защита и средства защиты информации 14
Серверы СУБД Серверы систем управления базами данных 15
Серверы приложений и файловых сервисов Прикладное программное обеспечение 16
Прочие сервисы Системы резервного копирования, системы обновления, распространения и конфигурирования программного обеспечения и прочее 17

P.S. Опущен уровень ниже 1 – здания и  сооружения. Возможно, уровень мониторинга надо стартовать ещё раньше.

Пишите в комментарии – какие-то слои добавить или есть причины поменять порядок.

4 thoughts on “Порядок восстановления ИТ-инфраструктуры”

  1. Серверы антивирусной защиты и СЗИ нужно до доступа в интернет, imho.

  2. Первый пункт дорогой, долгий, часто зависит от внешних подрядчиков.
    Т.е. для нового DС – все верно, для срочного восстановления инфраструктуры которую ждут, если его оставить первым – можно очень долго стартовать.
    Я бы его попытался размазать плавно по всему процессу.

    Последний пункт тоже размазать.
    Это опыт многолетней практики (может быть моей лично) если бэкапы оставить на потом, они и будут когда-нибудь потом…
    Мое мнение, пока резервная копия сервиса не внедрена – сервис не считается запущенным.

    Ну и с мониторингом тоже что-то подобное, но для DR, может и можно чуть отложить…

  3. Список линейный, а многие работы могут выполняться паралельно. После того, как подняли. СХД и гипервизоры, практически вс5 можно поднимать паралельно. СРК ИМХО должна подниматься после сети хранения данных.

  4. 2KroKoKot
    кто-то за ИТ, а кто-то за ИБ!

    2Alex
    Мы по мониторингу отслеживаем как поднялись сервисы, поэтому приходится довольно рано его поднимать.

    2Сергей
    Линейность поднятии обеспечивает разрешение зависимостей, чтобы сервисы не перезапускать, если предыдущие не успели стартнуть.

Leave a Reply

Your email address will not be published. Required fields are marked *