Однажды поручили разработать нам 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 — здания и сооружения. Возможно, уровень мониторинга надо стартовать ещё раньше.
Пишите в комментарии — какие-то слои добавить или есть причины поменять порядок.
Серверы антивирусной защиты и СЗИ нужно до доступа в интернет, imho.
Первый пункт дорогой, долгий, часто зависит от внешних подрядчиков.
Т.е. для нового DС — все верно, для срочного восстановления инфраструктуры которую ждут, если его оставить первым — можно очень долго стартовать.
Я бы его попытался размазать плавно по всему процессу.
Последний пункт тоже размазать.
Это опыт многолетней практики (может быть моей лично) если бэкапы оставить на потом, они и будут когда-нибудь потом…
Мое мнение, пока резервная копия сервиса не внедрена — сервис не считается запущенным.
Ну и с мониторингом тоже что-то подобное, но для DR, может и можно чуть отложить…
Список линейный, а многие работы могут выполняться паралельно. После того, как подняли. СХД и гипервизоры, практически вс5 можно поднимать паралельно. СРК ИМХО должна подниматься после сети хранения данных.
2KroKoKot
кто-то за ИТ, а кто-то за ИБ!
2Alex
Мы по мониторингу отслеживаем как поднялись сервисы, поэтому приходится довольно рано его поднимать.
2Сергей
Линейность поднятии обеспечивает разрешение зависимостей, чтобы сервисы не перезапускать, если предыдущие не успели стартнуть.