Что такое DRP и Паспорт ИС
Паспорт информационной системы – это документ, содержащий описание всей критически важной информации о системе, ее назначении, области применения, с детализированной информацией как о программной, так и об аппаратной части.
План восстановления системы, или DRP, – это набор процедур, инструкций, сценариев восстановления и сценариев определения того, какой у нас все-таки произошел сбой и что нам делать.
Паспорт должен содержать действительно все и максимально детально. Цель в том, что мы создаем эти документы – паспорт и DRP, – и нам в критической ситуации не нужен тот человек или те люди, которые обычно занимаются поддержкой этой системы. Потому что они могут быть недоступны: могут быть в отпуске, могут уволиться, заболеть.
Поэтому мы должны максимально все описывать. Возможно, даже более подробно, чем кажется необходимым в тот момент, когда мы это описание составляем.
Мы должны перечислить все машины, их роли, версии операционных систем, версии каждого отдельного ПО, которое на этих машинах стоит.
Как мы начали писать эти документы
Наша компания – это продукт централизации функций IT. Компания зарегистрирована в конце 2019 года. Планировался быстрый старт по централизации IT в 2020 году, но наступил ковид. Поэтому в 2020 году все происходило не очень быстро, а в 2021–2022 годах компания все еще находилась в состоянии стартапа.
Хаотически находились айтишники, IT-системы, которые поддерживались на местах, в отдельных структурных подразделениях и отдельных юридических дочерних организациях. Все росло быстро, лавинообразно.
Мы поддерживаем более 900 информационных систем. Большая часть из них была найдена, обнаружена и принята на поддержку как раз в 2021–2022 годах.
Были какие-то условно локальные системы. Их централизовали, может быть, даже масштабировали на соседние организации и структурные подразделения. Но такую систему как раньше, так и сейчас мог поддерживать один человек. Один человек и еще какой-нибудь другой человек, который его подстраховывал во время отпуска.
И, конечно, если ты работаешь один и поддерживаешь свою систему, то не очень беспокоишься о том, чтобы ее документировать. Собственно говоря, для кого?
Но когда централизуешь функцию, собираешь большую компанию и хочешь диверсифицировать зависимость от человеческого ресурса, начинаешь говорить: «А давайте ты будешь поддерживать не только эту систему, но и пять других. А эту систему будут поддерживать еще пять человек».
И тогда уже возникает вопрос о том, что нужно передавать знания. Передавать знания рассказами, почтой и еще как-то тяжело. Надо документировать. Так мы и пришли к тому, что нужно все документировать.
Первые версии паспорта ИС
Кажется, в 2021 году у нас появилась первая версия паспорта информационной системы.
Паспорт занимал ровно одну страничку – небольшую таблицу. Были перечислены имена машин. Если это 1С, то называлась какая-нибудь базовая конфигурация, например типовая УТ. Указали УТ десятой версии, которая последние семь лет никогда не обновлялась.
Хорошо, если в принципе были перечислены все серверы. Если говорить про 1С, забывали указать, например, веб-сервер, если он был отдельный. Забывали указать имя сервера СУБД, имя базы. Нам казалось, что этого достаточно.
Начали заполнять. Казалось бы, документ один, несложно заполнить. Скопировал с другого документа, заполнил так же, как у него.
Но системы продолжали сбоить. В процессе централизации инфраструктура работала не очень хорошо, и это тоже было одной из предпосылок для централизации функции IT. Работало все плохо, постоянно происходили сбои.
И получалось так, что какая-нибудь очередная система вроде бы описана, паспорт шикарный, все есть. Сотрудник, который исторически всегда ее поддерживал, наконец говорит: «Ну теперь-то я могу пойти в отпуск. Я три года не был в отпуске, я его копил. Ребята, я на три месяца в отпуск и еще на какой-нибудь информационный детокс в горах Тибета, телефон оставлю дома».
И естественно, было очень сложно восстанавливать систему, если ты знаешь о ней только то, что она расположена на каких-то серверах.
А потом еще выясняется, что она с кем-то интегрирована. И для какой-то другой системы очень важны данные из твоей системы. А ты и не знал, что она вообще интегрирована. Ты даже не думал о том, что нужно позаботиться о веб-сервере после того, как обновил версию платформы.
Стало понятно, что нужно писать гораздо детальнее.
Мы обращались к другим людям, к другим компаниям, нам рассказывали, как они это делают. И спустя несколько лет экспериментов мы пришли к новому стандарту.
К какому составу документа мы пришли
Теперь документ бывает на 30 страниц и больше. Мы его шаблонизировали и определили достаточно четкий состав:
-
Назначение документа
-
Основные термины и определения, обозначения и сокращения
-
Общие сведения
-
Схема и описание используемых технических средств и программного обеспечения
-
Информационная безопасность
-
Настройки интеграции
-
Паспорт ролей в системе
-
Регламентные задания
-
Управление непрерывностью системы
4. Схема и описание используемых технических средств и программного обеспечения
В четвертом разделе с инфраструктурой мы все так же, как и в первой версии, перечисляем адреса и роли серверов. Только теперь уже не забываем про периферийные серверы.
4.1 Описание ландшафта
4.2 Адреса серверов и компоненты системы
4.3 Описание аппаратной составляющей инфраструктуры
4.4 Требования к каналам связи
4.5 Межсетевое взаимодействие
4.6 Используемые программные решения
4.7 Сетевая диаграмма среды продуктивной эксплуатации
4.8 Построение ландшафта разработки и тестирования ( DEV/TEST)
4.9 Построение ландшафта продуктивной эксплуатации
4.10 Система лицензирования
Мы не забываем про отдельно стоящий веб-сервер, про станцию потокового сканирования, про терминал, который работает с онлайн-кассами, и так далее.
И мы не просто указываем адрес кластера СУБД, а полностью описываем все его составляющие. Указываем и балансировщик, и ноды. Все это является составляющими компонентами системы.
Тут же мы описываем все сетевые правила. Все знают, что без информационной безопасности мы уже не живем, поэтому работаем в закрытых контурах СПД, где все запрещено и разрешены только определенные правила. Поэтому, если система когда-нибудь перестанет работать, сетевые правила тоже придется проверять. А раз мы должны их проверять, значит, должны их задокументировать.
Указываем абсолютно все. Рассказываем о том, как построены ландшафты, рисуем диаграммы, где и какие данные передаются.
Если у системы, кроме стандартного платформенного лицензирования, есть дополнительное лицензирование, мы его тоже указываем. Указываем места хранения пин-кодов для повторной активации. Даже указываем контактные данные текущего партнера по РКЛ: некоторые проблемы, возможно, мы сможем решить только с ним.
5. Информационная безопасность
Следующий раздел – информационная безопасность. Без нее никуда. Не то чтобы мы сильно этого хотели, конечно, но информационная безопасность считает, что мы без нее вообще ничего делать не должны.
5.1 Информационная безопасность в части программного обеспечения
5.2 Информационная безопасность в части управления полномочиями пользователя
5.2.1 Ролевая модель
5.2.2 Управление полномочиями пользователей
5.3 Информационная безопасность в части защиты информационных ресурсов
5.4 Антивирусная защита
Сначала мы перечисляем все требования нашей информационной безопасности к системам. Они могут меняться, поэтому нужно постоянно следить за ними и актуализировать информацию.
Указываем, требуется ли возможность подключения к нашим системам за пределами КСПД. Может быть, у нас есть какой-нибудь портал для поставщиков или что-то еще.
Указываем, есть ли чувствительные персональные данные. От этого тоже меняются требования информационной безопасности.
Описываем ролевую модель. В зависимости от ее объема она сама по себе может занять 30–50 страниц. Если информации в ролевой модели слишком много, мы выносим все это в отдельный документ – регламент предоставления доступа. Там детально описываем всю матрицу доступа, все профили групп доступа, группы доступа, все атомарные роли. И там же устанавливаем порядок получения этих доступов, включая привилегированные учетные записи администраторов.
6. Настройки интеграции
Для интеграций у нас два раздела.
Первый – интеграции с инфраструктурными сервисами. Это интеграции со службами каталогов, корпоративными мессенджерами, почтовым сервером и так далее.
Второй – интеграции с информационными системами. Чаще всего это наиболее емкий и объемный раздел.
Степень детализации здесь высокая. Мы не перечисляем атрибутивный состав, но указываем эндпоинты, учетные записи, места хранения паролей этих учетных записей, ответственных лиц со стороны поддержки второй системы. Естественно, указываем потоки.
И эти интеграции обязательно должны быть отражены в сетевых правилах.
9. Управление непрерывностью системы
Следующий блок – обеспечение непрерывности, управление непрерывностью системы, обеспечение надежности, резервное копирование и мониторинг.
Здесь мы описываем, как построены наши кластеры. И говорим не только о том, как построен кластер 1С, но и о том, как обеспечивается отказоустойчивость кластера СУБД. Все описываем детально.
Если говорить про 1С, указываем назначение функциональности, как она распределена, а в некоторых случаях описываем даже логику принятия таких решений.
Про резервное копирование тоже пишем. Обычно там не очень много текста: описываем схемы копирования, как часто делаются дифференциальные копии, как часто делаются полные бэкапы, делаются ли реплики. После этого переходим к мониторингу.
Раздел мониторинга мы постоянно пополняем, потому что мониторинг не стоит на месте, у него появляются новые возможности, а у нас появляются потребности в мониторинге новых триггеров. Мы описываем все эти триггеры и степень их важности.
О срабатывании каких-то триггеров необходимо уведомлять в режиме 24/7, звонить по телефону. Какие-то спокойно могут подождать начала рабочей недели.
Если у нас в субботу вечером резко упал Apdex с 0,9 до 0,8, наверное, можно потерпеть до понедельника. А если критически закончилось место на диске C на менеджере кластера, об этом уже надо звонить и срочно решать проблему.
План аварийного восстановления системы
Наконец мы переходим к заявленной теме статьи – плану аварийного восстановления системы.
Теперь мы все знаем про систему, всю ее описали. Осталось рассказать, как ее восстанавливать. С чего начать?
-
Определите команду восстановления системы
-
Не забудьте про бизнес-владельца системы
-
Не забудьте про смежные подразделения и внешних контрагентов
-
Зафиксируйте RPO и RTO
-
Перечислите все известные вам сценарии сбоев
-
Опишите в мельчайших деталях, как эти сбои устранять
-
Проведите испытания, убедитесь что RTO достижим
-
Готово!
-
Не забывайте актуализировать
Первое – команда восстановления. Это не только мы, специалисты по 1С. Это все смежные подразделения, которые помогают нам восстановить систему.
Естественно, должен быть лидер, который управляет восстановлением системы, совместно с экспертами определяет, какой сценарий восстановления нужно использовать, коммуницирует со всей остальной командой и координирует ее работу.
В команду восстановления нужно включить все необходимые подразделения. Это группа администрирования СУБД, группа системного администрирования, включая коллег, которые администрируют виртуализацию, если она используется, группа сетевого администрирования – помним про защищенные контуры и сетевые правила, – администраторы системы.
И немаловажный участник – бизнес-владелец системы. Потому что в какой-то момент мы можем понять, что теряем данные. То есть систему восстановить можем, но с потерей данных за последние X часов. И мы не можем принять такое решение, не поговорив об этом с владельцем продукта, с бизнес-владельцем. В каких-то случаях он скажет: «Лучше восстанавливайте дольше, но восстановите все данные». А в каких-то случаях скажет: «Потеряли четыре часа – да и бог с ними».
Поэтому еще до аварии вместе с бизнес-владельцем нужно зафиксировать RPO и RTO.
Самая главная суть плана восстановления системы – нам нужно придумать все мыслимые и немыслимые сценарии сбоев, их симптомы, признаки и описать, как после них восстанавливать систему.
Мы должны описать абсолютно все сценарии. От самых простых – чистки серверного кэша или кэша пользователей – до восстановления базы данных из бэкапа или восстановления виртуальной машины из бэкапа.
Если в нашем кластере требуется определенная последовательность перезагрузки сервисов, это тоже нужно описать.
Причем описать малейшие детали – так, чтобы в крайнем случае даже человек, далекий от 1С, мог восстановить ту составляющую, которой обычно занимается только один человек.
Не забываем указывать контрольные точки. Например, если мы написали, что нужно восстановить виртуальную машину, то после восстановления должны проверить сетевую связанность. Вдруг у нее поменялся IP-адрес?
Как в паспорте нужно указывать сетевые правила, так и здесь нужно написать: проверьте сетевые правила, проверьте имена и адреса машин.
Все, план написали. Остается проверить, достижимо ли то время восстановления системы, которое мы зафиксировали с бизнес-владельцем. Действительно ли у нас получится восстановить систему за это время в случае какого-нибудь глобального сбоя.
И казалось бы, теперь все – можно ехать в отпуск куда-нибудь без телефона.
Но нужно помнить, что это живые документы. Система постоянно меняется. Мы постоянно вносим в нее изменения, появляются новые интеграции. Поэтому нужно постоянно актуализировать и план восстановления, и паспорт информационной системы.
И еще одна ремарка: не забудьте DRP распечатать и положить себе в тумбочку. Если политика безопасности позволяет – еще и домой увезите распечатанный экземпляр. Потому что, когда инфраструктура перестанет работать, Word-файл на сетевом ресурсе может оказаться недоступен. И толку от того, что вы создали такой документ, будет немного.
Какую выгоду получаем уже сейчас
Теперь система у нас оцифрована, информация о ней не хранится в чьей-то конкретной голове, ею можно делиться.
И фактически у нас уже есть шаблон. С учетом того, что наш центр компетенций занимается исключительно системами 1С, этот шаблон копируется практически на 90%. Нам остается применять именно те составляющие, которые специфичны для конкретной системы.
По этому же шаблону мы можем создавать новые системы. Когда у нас появляются проекты, приходят проектные менеджеры и говорят: «Давайте вместе придумаем, что нам понадобится для этой системы, какие лицензии купить, какие вычислительные ресурсы запланировать и забронировать, где их поставить, в каком из ЦОДов».
Мы понимаем: эта система имеет такую нагрузку, будущая система будет иметь похожую нагрузку – пожалуйста, можно копировать. Мы уже описали в паспорте, сколько ядер используем, сколько оперативной памяти, сколько дискового пространства.
Но самая первичная, самая первая и самая главная наша цель была в том, чтобы систему мог восстановить практически любой. И ее мы как будто бы достигли.
Наши планы на развитие
Дальше мы хотим построить ресурсно-сервисную модель.
Хотим оцифровать базы данных, все наши программные и аппаратные компоненты, увязать их между собой и показать связи.
Связать интеграционными связями разные системы, связать системы с их физическим расположением, связать все это с каталогом пользовательских услуг из нашей ITSM-системы.
Чтобы наш мониторинг, который работает 24/7, понимая, что сломался какой-то коммутатор между площадками, сразу понимал и то, какая система сейчас перестанет получать данные, какие пользователи перестанут работать в этой системе, потому что у них не будет к ней доступа.
Это небольшие планы, но для нас, в условиях чуть менее чем тысячи систем, этого хватит надолго.
И еще раз: не забываем актуализировать наши живые документы – и уезжаем в отпуск.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.
