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

Однажды поручили разработать нам 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 комментария к “Порядок восстановления ИТ-инфраструктуры”

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

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

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

  2. Сергей

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

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

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

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

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *