СПРАВКА
Источник публикации
М., 2022
Примечание к документу
Текст документа приведен в соответствии с публикацией на сайте https://platform.gov.ru/ по состоянию на 22.09.2023.
Название документа
"Единая цифровая платформа Российской Федерации "ГосТех" для создания, развития и эксплуатации государственных информационных систем. Методические рекомендации по эксплуатации государственных информационных систем на единой цифровой платформе Российской Федерации "ГосТех". Версия 1.0"
"Единая цифровая платформа Российской Федерации "ГосТех" для создания, развития и эксплуатации государственных информационных систем. Методические рекомендации по эксплуатации государственных информационных систем на единой цифровой платформе Российской Федерации "ГосТех". Версия 1.0"
Содержание
ДЛЯ СОЗДАНИЯ, РАЗВИТИЯ И ЭКСПЛУАТАЦИИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ
ПО ЭКСПЛУАТАЦИИ ГОСУДАРСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
НА ЕДИНОЙ ЦИФРОВОЙ ПЛАТФОРМЕ РОССИЙСКОЙ ФЕДЕРАЦИИ "ГосТех"
ВЕРСИЯ 1.0
Используемые в настоящем документе термины и основные понятия области автоматизированных систем определены действующим законодательством и ГОСТ Р 59853-2021 "Информационные технологии. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения".
В настоящем документе применены следующие сокращения:
Сокращение | Расшифровка |
ГИС | Государственная информационная система |
Платформа "ГосТех" | Единая цифровая платформа Российской Федерации "ГосТех" |
ЗНИ | Запрос на изменение |
КТС | Комплекс технических средств |
ППО | Прикладное программное обеспечение |
В настоящем документе применены следующие термины и сокращения с соответствующими определениями:
Термин | Определение |
Пользователь, Заказчик ГИС | Государственные органы и внебюджетные фонды, обеспечивающие создание, развитие, эксплуатацию ГИС на Платформе "ГосТех", в том числе отвечающие за разработку документации, хранение содержащейся в базах данных информации и осуществляющие иные функции |
Оператор ГИС | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, отвечающее за эксплуатацию, техническое сопровождение, организацию мероприятий по подготовке (актуализации) расчета стоимости затрат на эксплуатацию ГИС и (или) осуществляющее иные сопроводительные функции, в том числе по техническому сопровождению инфраструктуры и программно-аппаратного комплекса |
Разработчик ГИС | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, выполняющее функции по созданию или переработке (модернизации) ГИС на основании соответствующего договора |
Разработчик ППО | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, выполняющее функции по созданию или переработке (модернизации) ППО на основании соответствующего договора |
Оператор Платформы "ГосТех" | Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации или подведомственное ему казенное учреждение, которому переданы полномочия по осуществлению функций оператора Платформы "ГосТех" |
Платформа "ГосТех" | Цифровая экосистема создания, развития и эксплуатации ГИС, включающая в себя единую программно-аппаратную среду, цифровые продукты, информацию, информационные технологии, ГИС, необходимые для реализации функций Платформы "ГосТех", а также совокупность нормативных правовых, организационных, методологических правил и процедур, обеспечивающих деятельность участников отношений, возникающих в связи с созданием и функционированием Платформы "ГосТех" |
ГИС на Платформе "ГосТех" | Государственные информационные системы, создаваемые, развиваемые, эксплуатируемые с использованием программно-аппаратной среды, цифровых продуктов, включенных в каталог цифровых продуктов платформы "ГосТех" (далее - цифровые продукты платформы "ГосТех"), а также инструментов, информационных технологий платформы "ГосТех" |
Настоящий документ определяет минимальный набор организационно-технических требований к порядку эксплуатации ГИС, функционирующих на Платформе "ГосТех", требования к составу служб эксплуатации ГИС, основным технологическим операциям в ходе эксплуатации ГИС, показателям качества предоставления услуг по сопровождению ГИС, а также к составу и содержанию комплекта эксплуатационной документации на ГИС.
Условия эксплуатации отдельных ГИС, в том числе состав отчетных документов, порядок взаимодействия Заказчика ГИС и Исполнителя определяются условиями соответствующих договоров, в частности государственных контрактов, концессионных соглашений и соглашений о государственно-частном партнерстве о создании, развитии, эксплуатации, сопровождении ГИС с учетом положений настоящего документа.
Настоящий документ определяет правила взаимодействия служб эксплуатации и пользователей в целях предоставления услуг в ходе эксплуатации ГИС с заявленным уровнем обслуживания.
В состав настоящего документа входят следующие документы:
Регламент организации сопровождения;
Рекомендуемые шаблоны обязательных документов.Основанием для передачи ГИС в эксплуатацию является обязательное выполнение следующих условий:
успешное завершение этапа опытной эксплуатации ГИС;
оформление Заказчиком ГИС акта о вводе системы в эксплуатацию, согласно Постановлению Правительства Российской Федерации от 6 июля 2015 г. N 676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации" (далее - ПП N 676);
завершение разработки комплекта эксплуатационной документации с учетом требований пункта 2.1 настоящего документа;
соответствие состава служб эксплуатации Оператора ГИС требованиям пункта 2.2 настоящего документа;
передача Заказчиком ГИС комплекта эксплуатационной документации Оператору ГИС и при необходимости проведение соответствующего обучения сотрудников Оператора ГИС;
внедрение Оператором ГИС процессов эксплуатации с учетом требований пункта 3 настоящего документа;
предоставление Заказчиком ГИС по заявке Оператора ГИС доступа к ГИС и КТС в составе ГИС, достаточного для оказания услуг по эксплуатации и сопровождению ГИС. Доступ, в том числе удаленный, предоставляется в соответствии с порядком предоставления доступа, определяемым Заказчиком ГИС и в соответствии с проектным решением по защите информации ГИС;
между Заказчиком ГИС и Оператором ГИС заключен договор возмездного оказания услуг по эксплуатации ГИС.Минимальный пакет эксплуатационной документации, необходимый для передачи ГИС в эксплуатацию, должен включать в себя:
техническое задание на разработку;
регламент эксплуатации ГИС;
инструкции Пользователей;
руководство системного администратора (приложений/баз данных);
руководство по установке программных средств ГИС;
регламент управления доступностью и непрерывностью;
описание параметров мониторинга;
регламент резервного копирования;
акт приема передачи ГИС команде эксплуатации.Состав документов для конкретной ГИС является минимальным и может быть расширен Заказчиком ГИС в соответствии с требованиями соответствующего договора. При разработке документов также необходимо учитывать требования и ограничения документов, регламентирующих эксплуатацию Платформы "ГосТех" и иных связанных систем. Значения целевых показателей метрик качества ГИС не может быть выше аналогичных показателей, указанных в вышеуказанных документах.
По общему правилу, эксплуатация ГИС на Платформе "ГосТех" должна осуществляться в рамках существующих штатов специалистов (персонала) Оператора ГИС.
Персонал Оператора ГИС должен владеть:
общими навыками работы с персональными электронно-вычислительными машинами (ПЭВМ) и с современными средствами вычислительной техники, в том числе средствами защиты информации и средствами криптографической защиты информации;
специальной подготовкой для использования функциональности ГИС, технологического сопровождения, администрирования КТС в составе ГИС.Для обеспечения требуемой квалификации персонала Оператор ГИС должен проводить соответствующее обучение персонала. Порядок подготовки, контроль знаний и навыков должен определяться организационно-распорядительными документами Оператора ГИС.
Режим работы персонала должен определяться Оператором ГИС, исходя из установленных договором значений показателей качества оказываемых услуг.
Организация работы персонала должна соответствовать требованиям действующего законодательства Российской Федерации.
Деятельность персонала Оператора ГИС должна регулироваться должностными инструкциями и инструкциями по охране труда.
Организационно-штатная структура служб эксплуатации отдельной ГИС определяется Оператором ГИС в соответствии с организационно-распорядительными документами и с учетом требований к численности и квалификации персонала, указанных в проектной документации на ГИС.
В рамках эксплуатации ГИС осуществляются следующие процессы:
Основные процессы:
Управление инцидентами;
Управление проблемами;
Управление изменениями;
Резервирование и восстановление данных.Вспомогательные процессы:
Мониторинг системы;
Управление доступностью и непрерывностью.По всем процессам в качестве отчетного периода рекомендуется использовать календарный месяц.
Инцидентом является любое событие, выходящее за рамки штатной работы, ГИС, прямо, косвенно или потенциально ведущее к остановке процессов ГИС или негативно отражающееся на качестве функционирования ГИС.
Управление инцидентами включает в себя процесс скорейшего восстановления нормального функционирования ГИС и минимизацию воздействия инцидентов на автоматизированные процессы в ГИС.
Для оценки эффективности процесса управления инцидентами рекомендуется использовать следующие метрики:
N п/п | Метрика | Рекомендуемое расчетное значение метрики |
1 | Количество зарегистрированных инцидентов | Количество зарегистрированных за период инцидентов/количество пользователей ГИС >= 0,8 |
2 | Суммарное количество незакрытых инцидентов | Среднее количество поступающих за отчетный период обращений *5 |
3 | Процент инцидентов, разрешенных в согласованное время разрешения инцидентов | Должен составлять более 97% от общего количества регистрируемых за отчетный период инцидентов |
4 | Количество повторно открытых инцидентов | Должно составлять не более 5% от общего количества закрытых за период инцидентов |
Пример минимальных требований к составу и квалификации рабочей группы приведены в таблице 1. Конечный состав группы для конкретных ГИС определяется на этапе передачи ГИС в эксплуатацию и должен позволять обеспечивать выполнение целевых метрик качества предоставления услуг по сопровождению системы.
Таблица 1
рабочей группы по управлению инцидентами
Роль | Функция | Количество специалистов | Квалификация |
Специалист 1-й линии сопровождения | Прием и диспетчеризация заявок. Работа с обращениями Пользователей на основании типовых решений из базы знаний. Базовый мониторинг. Консультирование Пользователей по работе с системой | 2 | |
Специалист 2-й линии сопровождения | Решение сложных и нетиповых инцидентов. Анализ инцидентов, определение проблем | 2 | Опыт работы с БД, знание подхода SRE; знание прикладного функционала ГИС |
Специалист 3-й линии сопровождения | Устранение сбоев. Внесение изменений в систему с целью устранения ошибок | Количество специалистов должно позволять обеспечить выполнение SLA |
Рекомендации по организации процесса управления инцидентами установлены в разделе 3 регламента организации сопровождения.
Проблема - это неизвестная основная причина возникновения одного или нескольких инцидентов.
Управление проблемами - это процесс выявления причин инцидентов и управления этими причинами.
Целью процесса управления проблемами является предупреждение появления проблем, устранение причин появления повторяющихся инцидентов и минимизация влияния инцидентов, которые не могут быть предупреждены.
Процесс управления проблемами носит как реактивный, так и проактивный характер. Первый относится к разрешению проблем, связанных с уже возникшими инцидентами, второй направлен на выявление и устранение проблем, способных привести, но пока не приведших к возникновению инцидентов.
Для оценки эффективности процесса управления проблемами рекомендуется использовать следующие метрики:
N п/п | Метрика | Рекомендуемое расчетное значение метрики |
1 | Среднее время решения проблемы | Рекомендуемое значение пятикратному предельному времени решения инцидента среднего приоритета |
2 | Доля инцидентов, ассоциированных с записями о проблемах или известными ошибками | Не менее 10% |
3 | Доля своевременно решенных проблем | Не менее 75% от общего количества зарегистрированных |
4 | Доля повторно появляющихся проблем | Не более 5% |
5 | Доля "известных ошибок" (документированных процедур исправления повторяющихся проблем) | Не менее 20% |
6 | Доля нерешаемых проблем | Не более 5% |
Минимальные требования к составу и квалификации рабочей группы приведены в таблице 2. Конечный состав группы для конкретных ГИС определяется на этапе передачи ГИС в эксплуатацию и должен позволять обеспечивать выполнение целевых метрик качества предоставления услуг по управлению проблемами.
Таблица 2
рабочей группы по управлению проблемами
Роль | Функция | Количество специалистов | Квалификация |
Инициатор | Сотрудник сопровождения или Пользователь, определивший причинно-следственную связь повторяющихся инцидентов и зарегистрировавший в СОЗ соответствующее обращение | ||
Исполнитель | Сотрудник, ответственный за поиск обходного или постоянного решения проблемы | ||
Разработчик | Сотрудник, ответственный за реализацию изменений, необходимых для устранения основной причины проблемы |
Рекомендации по организации процесса управления проблемами описаны в разделе 4 регламента организации сопровождения.
Изменение - это добавление, изменение или удаление любых элементов, которое может прямо или косвенно повлиять на функционирование ГИС.
Управление изменениями - это процесс организации работ по внесению изменений в эксплуатируемые ГИС на Платформе "ГосТех".
Целями процесса управления изменениями является:
обеспечение гибкости изменений ГИС на Платформе "ГосТех", связанных с изменениями бизнес-процессов, в соответствии с требованиями законодательства Российской Федерации, внутренних и внешних контролирующих органов;
обеспечение прозрачности процесса планирования изменений ГИС;
обеспечение требуемых сроков реализации изменений ГИС в части устранения ошибок функциональности.Для оценки эффективности процесса по управлению изменениями рекомендуется использовать следующие метрики:
N п/п | Метрика | Рекомендуемое расчетное значение метрики |
1 | Доля внедренных изменений за период | Не менее 85% от общего количества зарегистрированных заявок на изменения |
В рамках процесса управления изменениями между участниками процесса закреплены следующие роли в соответствии с таблицей 3.
Таблица 3
рабочей группы по управлению изменениями
Роль | Функция | Количество специалистов | Квалификация |
Инициатор ЗНИ | Формирование требований к планируемым изменениям | ||
Менеджер по управлению изменениями | Контроль поступивших ЗНИ. Организация работ по реализации и документированию изменений | 1 | |
Исполнитель | Реализация изменений | 1 |
Рекомендации по организации процесса управления изменениями описаны в разделе 5 документа регламента организации сопровождения.
Резервное копирование - процесс создания копии данных на носителе, предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.
Целями процесса являются:
установление единых правил и требований к времени восстановления системы из резервной копии к процессу управления резервным копированием и восстановлением из резервной копии;
разграничение прав и обязанностей между участниками процесса;
установление требований к выполнению процесса резервного копирования;
установление требований к выполнению процесса восстановления из резервной копии;
установление требований к проведению контроля резервного копирования и восстановлению из резервной копии.Для оценки качества процесса "Резервирование и восстановление" рекомендуется использовать следующие метрики:
N п/п | Метрика | Рекомендуемое расчетное значение метрики |
1 | Периодичность выполнения резервного копирования | Определяется для каждой конкретной ГИС |
2 | Срок хранения резервных копий | |
3 | Время восстановления системы из резервной копии | |
4 | Успешное выполнение периодического контрольного восстановления ГИС и резервной копии | 100% от количества попыток |
Рекомендации по организации процесса резервного копирования и восстановления приведены в разделе 1 - 3 регламента резервного копирования, который входит в рекомендуемые шаблоны обязательных документов.
Мониторинг системы - это набор действий, позволяющий наблюдать за функционированием ГИС и осуществляемый с целью получения информации о функционировании критической инфраструктуры, систем, приложений, сетевых служб, использования системных ресурсов (системные журналы, процессоры), управления событиями и тенденциями.
Мониторинг можно разделить на:
Реактивный мониторинг - целью которого является оперативное обнаружение сбоев с одновременным указанием источника проблемы и возможностью информирования о ней конкретных людей или систем.
Проактивный мониторинг - основан на анализе собранных данных и его целью является прогнозирование возможных аварий и сбоев компонентов ГИС, что позволяет превентивно предпринять необходимые действия для предотвращения нежелательных событий в будущем.В целях организации мониторинга ГИС должна быть составлена технологическая карта, включающая в себя перечень технических и технологических показателей, подлежащих инфраструктурному и функциональному мониторингу и характеризующих качество функционирования ГИС, а также целевые значения показателей мониторинга для режима штатного функционирования и граничные значения показателей для двух уровней нештатных режимов с уровнем критичности "Средняя" и "Высокая".
Для нештатных режимов функционирования должны быть прописаны инструкции с описанием перечня мероприятий для восстановления штатного режима функционирования.
1. Определение списка критичных операций в ГИС, которые необходимо отслеживать.
2. Определение целевого времени отклика по каждой из критических операций.
3. Проведение замеров времени выполнения каждой операции для получения реальной статистики по ГИС при штатной нагрузке.
4. Анализ и интерпретация полученных результатов с целью установления целевых показателей производительности ГИС.
Для каждой ГИС должен быть определен набор показателей с граничными значениями.
Пример карты мониторинга ГИС:
Пример карты мониторинга ГИС: Параметры и время
реакции (отклика)
Команда | Время отклика, сек | Время исполнения, сек | Количество эмулируемых Пользователей |
Авторизация Пользователя | Не более 1 | Не более 20 | Не менее 450 |
Поиск информации по параметрам | Не более 1 | Не более 60 | Не менее 450 |
Отбор информации (наложение фильтров) по параметрам | Не более 1 | Не более 60 | Не менее 450 |
Открытие/закрытие формы, редактирование данных формы, сохранение, удаление данных | Не более 1 | Не более 5 | Не менее 450 |
Выход из ГИС | Не более 1 | Не более 20 | Не менее 450 |
Под временем реакции (отклика) понимается время между действием Пользователя и выводом на экранную форму любого служебного сообщения.
Система мониторинга для конкретных ГИС должна быть настроена с учетом специфики ППО и соответствовать следующим минимальным требованиям:
размещение ключевых компонентов системы мониторинга на отдельной от ГИС инфраструктуре;
надежность, функционал периодических проверок корректной работы системы мониторинга на основании эталонных данных;
простота и гибкость сведения данных и получения подробного вывода отчетов, а также возможность объединять данные и получать более подробную информацию о тех или иных областях мониторинга;
эффективная стратегия сохранения истории. Возможность определения типичных шаблонов сбоев, возможность анализа предыдущих данных за произвольный период. Рекомендуемый период сохранения данных - 1 год;
возможность корреляции факторов из разных источников;
простота добавления новых метрик или инфраструктур;
гибкая система оповещений: эта система должна обеспечивать отправку уведомлений по различным каналам в зависимости от приоритета события и условий.Управление доступностью - процесс, отвечающий за определение, анализ, планирование, измерение и улучшение всех аспектов доступности услуги. Управление доступностью отвечает за то, чтобы вся инфраструктура, процессы, средства, роли и т.д. соответствовали согласованным Целевым показателям уровня услуги в части Доступности. Взаимосвязь процессов при управлении доступностью приведена на рисунке 1.
Процесс управления доступностью состоит из обязательных процессов:
Мониторинг и отчетность по доступности - организация процесса сбора данных мониторинга и формирование отчетов по показателям доступности. Перечень и состав аналитик для каждой ГИС определяется отдельно.
Расследование недоступности - организация процесса расследования причин возникновения по каждому зафиксированному случаю недоступности. Состав рабочих групп по расследованию причин нарушений доступности разрабатывается индивидуально для каждой ГИС.
Внедрение дополнительных процессов проактивного управления позволит повысить отказоустойчивость системы.
Оценка рисков - организация процесса анализа причин возникновения и прогнозирование случаев потенциального возникновения случаев недоступности.
Реализация контрмер - комплекс мероприятий по предотвращению/минимизации рисков возникновения случаев недоступности.
Проектирование услуг с точки зрения доступности - комплекс мероприятий по оценке рисков возникновения причин недоступности на этапе проектирования ГИС.
Тестирование механизмов обеспечения доступности - комплекс мероприятий, направленный на минимизацию рисков возникновения случаев недоступности на уровне архитектурной проработки ГИС.
Оценка и совершенствование - процесс оценки результатов мероприятий предотвращения случаев возникновения недоступности и реализации новых инструментов снижения рисков таких случаев.
Управление непрерывностью - процесс, предусматривающий идентификацию потенциальных угроз и их воздействия на деятельность ГИС, который создает основу для повышения устойчивости ГИС к инцидентам прерывания деятельности.
В задачи управления непрерывностью входит минимизация ущерба, вызванного недоступностью функциональности.
Целью процесса является обеспечение гарантированного восстановления инфраструктуры, необходимой для продолжения функционирования ГИС в случае чрезвычайной ситуации.
Процесс управления непрерывностью обеспечивает анализ и управление рисками и позволяет организации постоянно поддерживать функционирование минимально допустимых производственных мощностей. Данный процесс помогает уменьшить степень риска до приемлемого уровня и разработать планы восстановления процессов на случай их повреждения во время чрезвычайной ситуации.
Для оценки качества процесса "Управление доступностью и непрерывностью" рекомендуется использовать следующие метрики:
N п/п | Метрика | Рекомендуемое расчетное значение метрики |
1 | Метрика "Доступность" | Целевой уровень доступности не может составлять менее 99,5%. Доступность рассчитывается как среднее между двумя показателями:  Показатель 1: AST (agreed service time) - установленное время работы, DT (downtime) - часы простоя, доступность услуги рассчитывается следующим образом: Доступность = (AST - DT)/AST*100% |
2 | Для обеспечения целевого уровня доступности необходимо организовать контроль следующих показателей:  количество простоев, независимо от их длительности; средняя наработка на отказ; среднее время подтверждения начала работ по восстановлению; среднее время исправления; среднее время разрешения включающее в себя не только время, затраченное на обнаружение сбоя, диагностику проблемы и ее устранение, но и время, затраченное на предотвращение повторения проблемы | Определяется для каждой конкретной ГИС. Рекомендуемые значения:  количество простоев, независимо от их длительности - 3; средняя наработка на отказ - 300 часов; среднее время подтверждения начала работ по восстановлению - 1 час; среднее время исправления - 3 часа; среднее время разрешения - 4 часа |
3 | Метрика "непрерывность" | Целевой уровень непрерывности не может составлять менее 99,5% от общего времени работы ГИС и выражается в процентном соотношении времени функционирования ГИС к полному времени предоставления услуги |
3.6.3. Требования к составу и квалификации рабочей группы процесса управления доступностью и непрерывностью
Пример рекомендуемых минимальных требований к составу и квалификации рабочей группы приведены в таблице 4.
Таблица 4
рабочей группы по управлению доступностью и непрерывностью
Роль | Функция | Количество специалистов | Квалификация |
Инженер по обеспечению надежности | Обеспечение работоспособности всех сред и инструментов разработки | 2 | |
Системный администратор | Обеспечение оптимальной работоспособности серверов и программного обеспечения | 2 | |
Дежурный специалист 3-й линии сопровождения | Реализация обновлений, необходимых для устранения критических ошибок функционала | 2 |
Для организации процесса необходимо обеспечить выполнение следующих задач:
Формирование и поддержка актуального плана мощностей, который отражает текущие и будущие потребности ГИС;
Предоставление консультаций и рекомендаций для смежных систем по вопросам доступности и непрерывности;
Обеспечение согласованного уровня доступности услуг за счет управления услугами и ресурсами, связанными с эксплуатацией;
Оказание помощи в диагностике и разрешении инцидентов и проблем, связанных с доступностью и непрерывностью;
Обеспечение оценки воздействия всех изменений плана доступности и непрерывности на потенциал всех служб и ресурсов;
Активный контроль принимаемых мер по улучшению доступности и непрерывности ГИС.МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ
КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ
ЕДИНАЯ ЦИФРОВАЯ ПЛАТФОРМА РОССИЙСКОЙ ФЕДЕРАЦИИ "ГосТех"
ДЛЯ СОЗДАНИЯ, РАЗВИТИЯ И ЭКСПЛУАТАЦИИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
РЕГЛАМЕНТ
ОРГАНИЗАЦИИ СОПРОВОЖДЕНИЯ
ГОСУДАРСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ
1. Перечень используемых терминов и сокращений
В настоящем документе применены следующие сокращения:
Сокращение | Расшифровка |
БД | База данных |
ГИС | Государственная информационная система |
ДО | Документ оценки |
ЗНИ | Запрос на изменение |
КТС | Комплекс технических средств |
Система | ГИС, принимаемая в эксплуатацию |
СОЗ | Система регистрации, учета и обработки обращений пользователей в службу сопровождения |
SLA | Соглашение об уровне обслуживания |
SRE | Инженер, обеспечивающий надежность и доступность системы |
В настоящем документе применены следующие термины и сокращения с соответствующими определениями:
Термин | Определение |
Пользователь, Заказчик ГИС | Государственные органы и внебюджетные фонды, обеспечивающие создание, развитие, эксплуатацию ГИС на Платформе "ГосТех", в том числе отвечающие за разработку документации, хранение содержащейся в базах данных информации и осуществляющие иные функции |
Оператор ГИС | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, отвечающее за эксплуатацию, техническое сопровождение, организацию мероприятий по подготовке (актуализации) расчета стоимости затрат на эксплуатацию ГИС и (или) осуществляющее иные сопроводительные функции, в том числе по техническому сопровождению инфраструктуры и программно-аппаратного комплекса |
Разработчик ГИС | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, выполняющее функции по созданию или переработке (модернизации) ГИС на основании соответствующего договора |
Разработчик ППО | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, выполняющее функции по созданию или переработке (модернизации) ППО на основании соответствующего договора |
Оператор Платформы "ГосТех" | Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации или подведомственное ему казенное учреждение, которому переданы полномочия по осуществлению функций оператора Платформы "ГосТех" |
Платформа "ГосТех" | Цифровая экосистема создания, развития и эксплуатации ГИС, включающая в себя единую программно-аппаратную среду, цифровые продукты, информацию, информационные технологии, ГИС, необходимые для реализации функций Платформы "ГосТех", а также совокупность нормативных правовых, организационных, методологических правил и процедур, обеспечивающих деятельность участников отношений, возникающих в связи с созданием и функционированием Платформы "ГосТех" |
ГИС на Платформе "ГосТех" | Государственные информационные системы, создаваемые, развиваемые, эксплуатируемые с использованием программно-аппаратной среды, цифровых продуктов, включенных в каталог цифровых продуктов платформы "ГосТех" (далее - цифровые продукты платформы "ГосТех"), а также инструментов, информационных технологий платформы "ГосТех" |
1.1. Цель документа
Настоящий регламент содержит рекомендации по организации сопровождения и технического обслуживания ГИС на Платформе "ГосТех".
Целью разработки рекомендаций является определение функций и статуса рабочих групп - участников процесса сопровождения в ходе эксплуатации ГИС на Платформе "ГосТех".
1.2. Область применения
Настоящий регламент определяет функции и статус участников процесса сопровождения в ходе эксплуатации ГИС на Платформе "ГосТех".
2. Цель процесса
Процесс сопровождения ГИС - процесс, целью которого является обеспечение корректного и бесперебойного функционирования ГИС, удобство ее использования и поддержка Пользователей.
2.1. Участники процесса
В процессе сопровождения ГИС участвуют следующие участники:
Заказчик ГИС;
Пользователь;
Оператор ГИС;
Оператор Платформы "ГосТех";
Оператор промышленной среды ГИС;
Разработчик ГИС.Контактная информация уполномоченных представителей рабочих групп - участников процесса сопровождения ГИС приведена в отдельном приложении к настоящему регламенту.
2.2. Функции участников процесса
В рамках процесса сопровождения и технического обслуживания ГИС можно выделить следующие обобщенные функции участников процесса:
оперативная поддержка Пользователей - поддержка Пользователей ГИС, в случае возникновения у них проблем с доступом или функционированием ГИС;
восстановление работоспособности - оперативное устранение нештатных ситуаций, повлекших ухудшение качества предоставляемых ГИС сервисов или их прерывание;
регламентное обслуживание и администрирование ГИС - выполнение работ, определенных в требованиях производителей компонентов ГИС; выполнение процедур администрирования программных и аппаратных компонентов;
обеспечение заданного уровня сопровождения - обеспечение соответствия текущего качества предоставляемых услуг по сопровождению ГИС, требованиям, определенным в договорах между Заказчиком ГИС и Оператором ГИС.Развитие системы - осуществление функций по доработке ГИС вследствие появившихся требований по изменению текущего и разработке нового функционала ГИС.
2.3. Взаимодействие участников процесса
ИС МЕГАНОРМ: примечание. Ячейки таблицы, выделенные серым цветом в официальном тексте документа, в электронной версии документа отмечены знаком "&". |
Реализация функций по сопровождению ГИС обеспечивается путем взаимодействия рабочих групп - участников процесса. В таблице 1 приведен возможный шаблон матрицы, характеризующей участие рабочих групп в процессах, и функции рабочих групп при взаимодействии. В матрице указываются рабочие группы, взаимодействующие между собой в ходе выполнения обобщенных функций процесса. Если рабочая группа осуществляет взаимодействие с другими рабочими группами в ходе выполнения обобщенной функции процесса, то ячейка, находящаяся на пересечении столбца рабочей группы и строки соответствующей обобщенной функции, заполняется символом "X" и выделяется серым цветом. В ином случае ячейка не заполняется.
Таблица 1
ИС МЕГАНОРМ: примечание. Текст в седьмой графе дан в соответствии с официальным текстом документа. |
Участники процесса | ФОИВ (Заказчик ГИС) | Разработчик ГИС | Оператор ГИС | Оператор промышленной среды ГИС | Оператор Платформы "ГосТех" | Документ, регламентирующий взаимодействие между |
Обобщенные функции | ||||||
Оказание технической поддержки | &X | &X | &X | &X | Договор возмездного оказания услуг по технической поддержке | |
Оперативная поддержка Пользователей | &X | &X | ||||
Восстановление работоспособности | &X | &X | ||||
Регламентное обслуживание и администрирование ГИС | &X | &X | &X | |||
Обеспечение заданного уровня сопровождения | &X | &X |
3. Управление инцидентами
Регламент управления инцидентами описывает процесс выполнения работ по устранению выявленных ошибок при эксплуатации ГИС на Платформе "ГосТех".
3.1. Основные цели процесса управления инцидентами
организация прозрачного процесса поддержки для всех его участников;
организация поддержки, решение инцидентов, возникающих при эксплуатации, ГИС;
подготовка и проведение обучения для Конечных пользователей Заказчика;
выполнение консультационных услуг.3.2. Основные цели администрирования ГИС
консультации по проблемам пользовательских компонентов;
ведение учетных записей Пользователей.3.3. Основные цели сопровождения приложений
анализ и устранение зарегистрированных инцидентов;
регламентные работы по администрированию приложений;
тестирование и документирование новой и (или) измененной функциональности.3.4. Основные цели управления компетенциями
консультирование пользователей по приложениям и процессам;
проведение обучения по требованию Заказчика.3.5. Основные цели ведения НСИ
ведение нормативно-справочной информации во всех системах учета по заявкам Конечных пользователей;
ведение иерархий признаков в многомерных структурах данных.3.6. Порядок оказания услуг
Услуги оказываются на территории Исполнителя и/или на иных территориях, согласованных Сторонами. Место выполнения конкретных услуг согласовывается в рабочем порядке между Сторонами.
Время оказания услуг по сопровождению определяется договором на сопровождение конкретной ГИС между Заказчиком ГИС и Оператором ГИС.
Перенос запросов в продуктивные системы осуществляется в вечернее время (после 22:00) для минимизации ошибок, возникающих у пользователей. Перенос запросов после окончания рабочего времени, а также в выходные и праздничные дни возможен по дополнительному запросу от Заказчика ГИС.
Исполнитель самостоятельно определяет необходимость и объем привлекаемых для оказания услуг специалистов с учетом требований методических рекомендаций по эксплуатации.
Все сроки, касающиеся обработки обращений, действительны только во время предоставления услуг.
Услуги оказываются на основе направляемых пользователями заявок.
Услуги сопровождения оказываются Исполнителем в рамках принятой на сопровождение функциональности.
Принятой на сопровождение функциональностью является функциональность ГИС, переданная Исполнителю и принятая Исполнителем в сопровождение по результатам проектных работ, исполняемых третьей Стороной.
Минимальный пакет эксплуатационной документации, необходимый для передачи ГИС в эксплуатацию, должен включать в себя:
техническое задание на разработку;
регламент эксплуатации ГИС;
инструкции пользователей ГИС;
руководство системного администратора (приложений/БД);
руководство по установке программных средств ГИС;
регламент управления доступностью и непрерывностью;
технологическая карта мониторинга;
регламент резервного копирования;
акт приема передачи ГИС Заказчику ГИС.Указанный состав документов для конкретной ГИС может быть расширен в соответствии с требованиями соответствующего договора.
3.7. Подача и прием заявок, регистрация и решение обращений
Заявки на оказание услуг, предусмотренных Договором, могут быть поданы Исполнителю следующими способами:
- через СОЗ Исполнителя (приоритетный);
- по электронной почте (резервный);
- по телефону (резервный).
Способы подачи заявок приведены в таблице 2.
Таблица 2
Способ | Краткое описание |
через СОЗ Исполнителя (приоритетный) | Заявитель самостоятельно заходит на Портал Технической поддержки пользователей по адресу (конечный адрес ресурса) и регистрирует запрос. Дальнейшая обработка запроса Исполнителем производится в соответствии с регламентирующими документами к системе |
по электронной почте (резервный) | При получении письма осуществляется автоматическая регистрация обращений в СОЗ. На почту заявителя отправляются уведомления:  ответное письмо с номером и временем регистрации обращения; назначение заявки на специалиста службы сопровождения с временем назначения и ФИО специалиста |
посредством телефонного звонка (резервный) | Оператор службы сопровождения регистрирует запрос в СОЗ на основании телефонного звонка заявителя. По окончании регистрации оператор сообщает заявителю номер зарегистрированного обращения. СОЗ отправляет на почту заявителя ответное письмо с уведомлением о регистрации обращения. В случае, когда со слов заявителя диагностировать проблему невозможно, или общение по телефону при регистрации запроса длится более 3 минут, оператор службы сопровождения вправе запросить заявителя переслать подробную информацию по возникшей проблеме через систему ITSM. Время обработки заявки и создания на ее основе обращения не должно превышать 10 минут |
При получении письма осуществляется автоматическая регистрация обращений в СОЗ.
На почту заявителя отправляются уведомления:
1) ответное письмо с номером и временем регистрации обращения;
2) назначение заявки на специалиста службы сопровождения с временем назначения и ФИО специалиста;
3) посредством телефонного звонка (резервный).
Оператор службы сопровождения регистрирует запрос в СОЗ на основании телефонного звонка заявителя. По окончании регистрации оператор сообщает заявителю номер зарегистрированного обращения. СОЗ отправляет на почту заявителя ответное письмо с уведомлением о регистрации обращения.
В случае, когда со слов заявителя диагностировать проблему невозможно или общение по телефону при регистрации запроса длится более трех минут, оператор службы сопровождения вправе запросить заявителя переслать подробную информацию по возникшей проблеме через СОЗ.
Время обработки заявки и создания на ее основе обращения не должно превышать 10 минут.
Заявки на оказание услуг принимаются от сотрудников Заказчика, в соответствии с функциональным и организационным объемом оказания услуг. В случае поступления заявки от Заявителя, не зарегистрированного на корпоративных почтовых серверах, такая заявка может быть отклонена.
Требования к информации, отраженной в обращении/запросе:
- указаны ФИО, организация, адрес рабочей электронной почты, контактный телефон Заявителя.
Требования к заявителю, соответствие которым необходимо для обработки обращения:
- имеет действующую учетную запись в ГИС с необходимыми полномочиями;
- имеет сконфигурированное рабочее место, с которого производится доступ в систему через работоспособную телекоммуникационную инфраструктуру.
Работоспособность системно-технических средств Платформы "ГосТех" находится вне зоны ответственности Исполнителя.
После получения обращения Исполнитель обязуется обработать зарегистрированное обращение согласно порядку обработки обращений и в сроки, удовлетворяющие SLA. Исполнитель обязуется решить не менее 97% обращений/заявок от общего количества, поступивших в отчетный период, решенных в пределах крайнего срока (см. п.п. 3.8). Исполнение данного параметра ежемесячно отслеживается по отчетам из системы управления инцидентами и стандартными запросами. Формат отчета предварительно согласуется, при нарушении данного параметра Заказчик вправе применить штрафные санкции.
Процесс обработки заявок, относящихся к событиям информационной безопасности, должен быть описан в отдельном документе.
Каждой заявке Исполнителем присваивается определенный приоритет. Присвоенный приоритет определяет последовательность обработки сообщений.
Время реакции - это время, в течение которого сотрудник СТП Исполнителя обязан на основании данных, указанных в обращении определить приоритет и группу ответственных за решение исполнителей от СТП. По факту назначения обращения на группу исполнителей СОЗ Исполнителя автоматически отправляет Заявителю информационное письмо с вышеуказанной информацией.
Время окончания решения обращения определяется по времени отсылки Заявителю решения из СОЗ.
Время решения обращения определяется как разность моментов регистрации и окончания исполнения обращения, за вычетом времени ожидания от Заявителя дополнительной информации, необходимой для исполнения обращения и не рабочего времени Пользователя ГИС. Время окончания решения обращения определяется по времени отсылки Заявителю решения из СОЗ.
Время решения обращения определяется как разность моментов окончания и начала исполнения обращения, за вычетом времени ожидания от Заявителя дополнительной информации, необходимой для исполнения обращения и не рабочего времени Пользователя ГИС. Рабочее время Пользователя ГИС принимается с 09:00 до 18:00 по местному времени (но не более чем с 02:00 до 19:00 по UTC+3). Целевые показатели процесса обработки обращений приведены в таблице 3.
Таблица 3
обработки обращений
Категория Обращения | Приоритет | График работы, рабочие часы | Время реакции, рабочие минуты | Время решения, рабочие часы |
Инцидент | Критический | 24 x 7, круглосуточно | 15 | 12 |
Высокий | 15 | 24 | ||
Средний | 9 x 5, с 9:00 до 18:00 | 15 | 45 | |
Низкий | 15 | 198 | ||
Запрос на обслуживание | Высокий | 9 x 5, с 9:00 до 18:00 | 30 | 9 |
Средний | 30 | 27 | ||
Низкий | 30 | 45 |
Окончательное закрытие обращения должно происходить только после того, как от Пользователя ГИС, сообщившего об инциденте, получено подтверждение, что этот инцидент устранен, и предоставление услуги восстановлено. В случае отсутствия подтверждения или замечаний Пользователя ГИС в течение трех рабочих дней обращение считается закрытым.
Для достижения целей и задач деятельности по ОКАиРКИ, связанные с информационными ресурсами Платформы "ГосТех", в обязанности Исполнителя входит предоставление доступа к СОЗ и системе мониторинга, для получения необходимой информации о функционировании ГИС, ответственным за обеспечение информационной безопасности ГИС кроме сведений ограниченного доступа.
Приоритизация инцидентов осуществляется на основе таблицы 4 всех компонентов ГИС, для каждого из которых должен быть определен уровень критичности. Например, уровни 1 и 2.
Таблица 4
Уровень критичности | Критерий |
Критический | - Инцидент, в результате которого стала невозможной эксплуатация всех функций ГИС (на сетевом уровне, на уровне технологического оборудования либо на уровне подсистемы виртуализации) |
Высокий | - Инцидент, в результате которого стала невозможной эксплуатация всех функций компонента(-ов) ГИС |
Средний | - Инцидент, в результате которого стала невозможной эксплуатация некоторых функций компонента(-ов) ГИС |
Низкий | - Инцидент, не подходящий под определение приоритета Критический, Высокий или Средний |
Приоритет запроса на обслуживание осуществляется на основе таблицы 5.
Таблица 5
запросов на обслуживание
Уровень критичности | Критерии |
Высокий | Зафиксированная потребность Заказчика в обслуживании в рамках предоставляемых ему Услуг, не связанная со сбоем или отказом в предоставлении Услуг. Срочные вопросы, возникающие при эксплуатации Услуги, оказывающие влияния на бизнес-процессы Пользователя ГИС (предоставление и корректировка прав доступа, корректировка, внесение и удаление данных) |
Средний | Зафиксированная потребность Заказчика в обслуживании в рамках предоставляемых ему Услуг, не связанная со сбоем или отказом в предоставлении Услуг. Консультации Пользователей ГИС по работе с Услугой, предоставление инструкций и обучающих материалов |
Низкий | Зафиксированная потребность Заказчика в обслуживании в рамках предоставляемых ему Услуг, не связанная со сбоем или отказом в предоставлении Услуг. Консультации по вопросам взаимодействия и регламентам, а также оказания консультаций |
3.9. Требования к процессам предоставления услуг
3.9.1. Общие требования к каталогу услуг
Для определения перечня всех услуг, которые будут предоставляться, должен быть сформирован Каталог Услуг. Он содержит все услуги, предоставляемые Исполнителем Заказчику в рамках договора.
Каталог услуг - это ключевой документ для регулирования ожиданий Заказчика. Пример каталога услуг представлен в таблице 6.
3.9.2. Состав и содержание услуг
Пример списка услуг, оказываемых в виде типовых сервисов, перечислен в таблице 6.
Таблица 6
Сервис | Перечень оказываемых услуг (вид услуги) |
Администрирование полномочий Пользователей | Администрирование учетных записей Пользователей |
Выполнение запросов на перенос в продуктивные системы | |
Консультация по проблемам пользовательских компонентов ГИС диспетчеризация проблем сетевого доступа | |
Согласование запросов на перенос от проектных команд | |
Сопровождение приложений (уровень 1) | Анализ и устранение выявленных ошибок, если это возможно, без внесения изменений в программный код и настройки системы |
Сопровождение функциональных обновлений системы | |
Работы по первоначальным настройкам новой структуры | |
Регламентные работы по загрузке данных из внешних систем | |
Размещение материалов информационного характера на Корпоративном Портале | |
Актуализация справочников ГИС | |
Регламентные работы по администрированию данных приложений | |
Сопровождение приложений (уровень 2) | Работы по проверке и согласованию транспортных запросов проектных команд на соответствие: регламентирующим документам и сохранению целостности ГИС |
Определение требований и правил внесения изменений в промышленную среду ГИС | |
Анализ и устранение ошибок, требующие внесения изменений в настройки и программный код | |
Доработка программных модулей Корпоративного Портала | |
Тестирование и документирование новой/измененной функциональности | |
Проведение в офисе Исполнителя очного консультирования Пользователей по работе в системе | |
Сопровождение приложений (уровень 3) | Разработка новой и изменение текущей функциональности сопровождаемых систем согласно требованиям и изменениям законодательства Российской Федерации |
Управление компетенциями | Консультирование по приложению и процессам (консультации по функционалу ГИС общей продолжительностью работ по одному обращению до 30 минут) |
Консультирование по приложению и процессам (вторая линия) (консультации по функционалу ГИС общей продолжительностью работ по одному обращению до 2 часов) | |
Консультирование по приложению и процессам (третья линия) (консультации по функционалу общей продолжительностью работ по одному обращению до 4 часов) | |
Ведение НСИ | Ведение иерархий признаков в многомерных структурах данных ГИС |
Ведение справочников |
Объем предоставляемых услуг указан в таблице 7.
Таблица 7
Сервис | Объем предоставления |
Администрирование | Без ограничений, по заявкам Пользователей |
Сопровождение приложений (уровень 1) | |
Управление компетенциями | |
Ведение НСИ | |
Сопровождение приложений (уровень 2) | |
Сопровождение приложений (уровень 3) | Без ограничений в соответствии с требованиями законодательства Российской Федерации |
В состав услуг по сервису "Сопровождение приложений (уровень 3)" входят также трудозатраты на выработку подходов и методов реализации, а также документирование соответствующих изменений. Услуга оказывается по обращениям Пользователей, после согласования куратором каждой из сопровождаемых систем или ответственным лицом по Договору.
Услуга сервиса "Сопровождение приложений (уровень 3)" относится к цифровым продуктам/системам и их компонентам/модулям, развернутым на базе Платформы "ГосТех", но также может применяться к работам, проводимым в рамках проектов, направленных на функциональное усовершенствование существующих систем, входящих в ГИС.
Общая схема процесса управления инцидентами приведена на рисунке 1.
4. Управление проблемами
Процесс "Управления проблемами" определяет задачи, порядок регистрации и обработки проблем, а также устанавливает права и обязанности участников процесса.
Требования настоящего регламента являются обязательными для исполнения всеми участниками процесса.
4.1. Основные цели процесса управления проблемами
Цель процесса "Управление проблемами" - это предотвращение возникновения проблем и инцидентов путем выявления повторяющихся инцидентов и минимизации отрицательного воздействия инцидентов, которые нельзя предотвратить.
4.2. Роли участников процесса "Управление проблемами"
Пример минимального набора ролей для осуществления процесса приведен в таблице 8.
Таблица 8
"Управления проблемами"
Наименование роли | Описание роли |
Инициатор | Сотрудник сопровождения или Пользователь, определивший причинно-следственную связь повторяющихся инцидентов и зарегистрировавший в СОЗ соответствующее обращение |
Исполнитель | Сотрудник, ответственный за поиск обходного или постоянного решения Проблемы, являющийся специалистом 2-й или 3-й линии Сопровождения конкретной ГИС |
Разработчик | Сотрудник, ответственный за реализацию изменений, необходимых для устранения корневой причины Проблемы, являющийся специалистом 3-й линии Сопровождения конкретной ГИС |
4.3. Взаимосвязь с другими процессами
Процесс "Управления проблемами" поддерживает процесс управления инцидентами, предоставляя ему обходные решения и быстрые исправления, но при этом не неся прямой ответственности за разрешение инцидента. Управление инцидентами помогает быстро исправить ошибку любыми доступными средствами, включая обходные решения, в то время как управление проблемами занимается поиском причины произошедшего и ее устранением. Инцидент может быть не классифицирован как проблема, однако в ходе решения инцидента, может быть выявлена связанная с ним проблема. Поэтому работа над проблемой может помочь в разрешении текущего инцидента, если он еще открыт.
ИС МЕГАНОРМ: примечание. Текст дан в соответствии с официальным текстом документа. |
Управление изменениями в части взаимодействия с процессом управления проблемами отвечает за контролируемое проведение изменений по ЗНИ для устранения проблем, предложенные в рамках процесса управления проблемами. Управление изменениями несет ответственность за определение степени воздействия изменения и ресурсов, необходимых для его реализации, а также за планирование, согласование и оценку запрашиваемых изменений. Кроме того, Управление изменениями информирует процесс управления проблемами о ходе работ и о завершении корректирующих изменений. Оценка этим изменениям дается совместно с процессом управления проблемами. Итогом работы является тестирование результатов внедрения изменений, после которого может быть закрыта известная ошибка, а также относящиеся к ней (открытые) инциденты.
4.4. Описание процесса
Процесс "Управление проблемами" включает действия, необходимые для идентификации и классификации проблем, диагностики основной причины инцидентов и определения способов устранения проблем.
Организация процесса управления проблемами включает операции, необходимые для предотвращения повторного возникновения или репликации инцидентов и известных ошибок и гарантирует, что:
существующие и регулярно возникающие ошибки идентифицированы, документированы и отслеживаются;
симптомы ошибок, постоянные или временные решения документируются;
подаются ЗНИ с целью модификации инфраструктуры или внесения изменений в ГИС;
предотвращается возникновение новых инцидентов, вызванных проблемами.Процесс "Управление проблемами" состоит из следующих шагов (таблица 9):
Выявление и регистрация проблем;
Исследование, поиск решений и устранение проблем;
Проверка и закрытие проблем.Таблица 9
Шаг процесса | Наименование выполняемых работ |
Регистрация | При регистрации Проблемы из Инцидента или отдельно стоящей Проблемы. Зарегистрировать проблему могут все участники процесса "Управление проблемами" |
Анализ и диагностика | На данной фазе выполняется формирование конечного списка работ по поиску корневой причины и решения Проблемы |
Устранение | На данной фазе выполняется подготовка постоянного и/или временного решения |
Формирование решения | На данной фазе выполняется проверка выработанного решения при следующих условиях:  поиск корневой причины закончен; причина указана или описана; проблема предположительно решена |
Мониторинг | На данной фазе ответственный выборочно связывается с Пользователями по инцидентам, с которыми связана "Проблема", чтобы удостовериться в том, что "Проблема" действительно устранена. Проверяется наличие новых инцидентов по тематике проблемы после ее устранения |
Закрытие | Закрытие инициатором или автоматическое закрытие спустя три дня после перевода на фазу "Проверка" |
Рекомендуемые метрики процесса "Управление проблемами":
Средняя длительность устранения проблем за период;
Процент инцидентов, относящихся (вызванных) к проблемам, по отношению к общему количеству инцидентов за период;
Количество известных ошибок, вошедших в базу знаний.Общая схема процесса "Управления проблемами" приведена на рисунке 2.
Входы процесса:
Инциденты высокого и наивысшего приоритетов, массовые инциденты;
Аналитический отчет по однотипным заявкам;
Аналитический отчет по системным ошибкам;
Информация от внешних источников о возможных проблемах (мониторинг, обходные решения, найденные в рамках процесса управления Инцидентами).Выходы процесса:
ЗНИ;
Новые известные ошибки (создание статей в базе знаний).Процесс управления проблемами включает следующие этапы:
регистрация, классификация и приоритизация проблем;
анализ и диагностика проблемы;
прогнозирование проблемы;
формирование временного решения;
разработка постоянного решения;
мониторинг актуальности решения проблемы;
закрытие проблемы;
предупреждение проблем.4.4.1. Регистрация, классификация и приоритизация проблем
Процесс регистрации проблем аналогичен с процессом регистрации инцидентов, но в случае проблемы не нужно включать в описание информацию о заявителе и прочие сведения и данные. Однако, при регистрации необходимо указывать связанные с проблемой инциденты.
4.4.2. Классификация и назначение
Проблемы можно классифицировать по областям (категориям). Классификация проблемы выполняется одновременно с анализом степени ее воздействия, т.е. уровня критичности проблемы и ее влияния на функционирование ГИС на основании экспертного мнения ответственного специалиста. На основании классификации проблемы присваивается приоритет точно так же, как в процессе управления инцидентами. На основе результатов классификации определяются ресурсы и время, необходимое для ее решения.
Классификация проблемы может включать в себя следующие аналитики:
категория - определение области (ГИС, платформа, аппаратное обеспечение);
степень воздействия на работоспособность ГИС;
срочность - допустимая задержка в решении проблемы;
приоритет - показатель, объединяющий срочность, степень воздействия, риск и необходимые ресурсы;
статус - например, проблема, известная ошибка и т.д.Классификация не является статичной, она может меняться на протяжении жизненного цикла проблемы. Например, наличие обходного решения или быстрого решения позволит снизить срочность проблемы, в то время как регистрация новых связанных инцидентов может привести к изменению степени воздействия проблемы.
4.4.3. Анализ и диагностика проблемы
Анализ и диагностика проблемы - это процесс, целью которого является определение корневых причин возникновения проблемы и выработка подхода к ее решению.
4.4.4. Формирование решения проблемы
После определения причины проблемы, проблеме присваивается статус "Известная ошибка" и начинается поиск ее решения. Участники процесса определяют, что необходимо сделать для разрешения известной ошибки, сравнивают различные решения, принимая во внимание влияние проблемы на SLA, возможные издержки и выгоды. Все работы по выработке решения должны быть зафиксированы.
Возможные результаты процесса:
1. Обходное решение - относительно быстрое и простое решение проблемы, применяемое для срочного устранения ее последствий, но не влияющее на причины ее возникновения. Обходное решение обычно является временным, требующим в дальнейшем замены на окончательное, более полное. Обходные решения применяются в случаях, когда радикальное решение по какой-то причине не может быть применено вообще или требует слишком много времени для реализации. Обходное решение применяется для срочного закрытия инцидентов, связанных с проблемой, в период реализации срочного исправления.
2. Срочное исправление - в случае если обходное решение по проблеме не было найдено, и известная ошибка приводит к возникновению серьезных инцидентов, инициируется выполнение срочного исправления. Регистрируется ЗНИ с критичным приоритетом, обработка которого ведется в рамках процесса управления изменениями с учетом критичности.
3. ЗНИ - если по проблеме найдено обходное решение или в случаях, когда известная ошибка не приводит к возникновению серьезных инцидентов, регистрируется ЗНИ, обработка которого ведется в рамках процесса управления изменениями.
4.4.5. Закрытие проблемы
После внедрения изменения, предназначенного для устранения известной ошибки, должен быть проведен анализ результатов внедрения до закрытия проблемы. Если изменение дало ожидаемый результат, проблема может быть закрыта. В случае если изменения не привели к устранению проблемы, процесс возвращается на шаг "Анализ и диагностика проблемы". При успешном применении изменения информация о закрытии проблемы должна быть доведена до участников процесса "Управление инцидентами" для закрытия связанных с этой проблемой инцидентов.
5. Управление Изменениями
Регламент управления изменениями описывает процесс выполнения работ по внесению изменений в эксплуатируемые ГИС на Платформе "ГосТех".
5.1. Основные цели процесса управления изменениями
обеспечение гибкости изменений ГИС на Платформе "ГосТех", связанных с изменениями бизнес-процессов, требованиями законодательства Российской Федерации, внутренних и внешних контролирующих органов;
обеспечение прозрачности процесса планирования изменений ГИС;
обеспечение требуемых сроков реализации изменений ГИС в части устранения ошибок функциональности.5.2. Участники процесса управления изменениями
В рамках процесса управления изменениями (ЗНИ) между участниками процесса закреплены следующие роли и объединения:
Инициатор ЗНИ;
Менеджер по управлению изменениями;ИС МЕГАНОРМ: примечание. Текст дан в соответствии с официальным текстом документа. |
Исполнитель (внешний или внутренний подрядчик, выполняющий работы для по внедрению изменений ГИС, являющийся специалистом 2-й или 3-й линии Сопровождения конкретной ГИС).5.3. Основные этапы выполнения работ:
5.3.1. Инициирование ЗНИ
В рамках данного шага проводится формирование требований по корректировке одной или нескольких подсистем со стороны Пользователя систем, корреляция с другими требованиями, находящимися в общем объеме планируемых Изменений подсистем.
5.3.2. Планирование ЗНИ
В рамках данного шага проводится планирование последовательности проведения изменений, осуществляется приоритизация ЗНИ, дополнительные уточнения по шагам работ с ЗНИ и т.п.
5.3.3. Оценка ЗНИ
В рамках данного шага проводится настройка и реализация ЗНИ на стороне Исполнителя с последующей передачей на тестирование реализованного функционала.
5.3.4. Передача ЗНИ в поддержку
В рамках данного шага проводится актуализация документации измененной или созданной при реализации ЗНИ функциональности. Базовые документы в ходе ЗНИ:
спецификация на реализацию;
результаты тестирования ЗНИ;
операционные инструкции пользователей;
операционные инструкции администратора ГИС, платформы.5.3.5. Процедура управления ЗНИ
Описание процедуры управления ЗНИ приведено в таблице 10.
Таблица 10
N | Шаг процесса | Метод и документирование | Описание бизнес-шага | ||||
1. | Инициирование ЗНИ | ||||||
1.1. | Создание ЗНИ | Входящие:  Изменение бизнес-процессов, бизнес-инструментовВыявление возможностей для оптимизации ИТ-решения Требования внешних контролирующих органов Результат:  ЗНИ создан Уведомление о переходе ЗНИ в статус "Новый".Участники шагов процесса:  Инициатор ЗНИ | Регистрация ЗНИ Инициатором. При регистрации ЗНИ Инициатор прикладывает документы, необходимые для постановки задачи и ее детализации, включая согласованные с вовлеченными структурными подразделениями методики и алгоритмы, а также определяет критичность ЗНИ: Высокая критичность - предполагает высокую степень срочности и важности для процесса, связанных с необходимостью исполнения требований законодательства РФ, нормативно-правовых актов, а также срочными требованиями, критичными для ключевых функциональных направлений и требованиями безопасности. Средняя критичность - потребность в изменениях, связана с оптимизацией существующих процессов и инструментов. Низкая критичность - изменение оправданно и целесообразно, связано с улучшением эргономики, визуализации. В результате регистрации ЗНИ в СОЗ формируется запись ЗНИ со статусом "Новый", вовлеченным участникам процесса направляется уведомление о регистрации ЗНИ | ||||
1.2. | Согласование ЗНИ | Входящие:  ЗНИ созданРезультат:  ЗНИ согласован ЗНИ не согласован (статус Уточнение информации) ЗНИ отмененУчастники шагов процесса: Инициатор ЗНИ Менеджер по изменениям | Осуществление анализа требований, сформулированных в ЗНИ на предмет: - корректности и достаточности сформулированных требований и приложенных документов; - наличия дублирующих ЗНИ или ЗНИ с пересекающимися требованиями (в рамках области своей ответственности; - противоречия требований в ЗНИ законодательным и/или локальным нормативным документам (в силу своей компетенции); - полноты указанных в ЗНИ процессов/функциональных областей (в соответствии со своими компетенциями).  Менеджер по изменениям ЗНИ утверждает ЗНИ на предмет необходимости реализации изменения, корректности определения критичности, корректности описанных методологических подходов; При необходимости дополнительного согласования любой из участников согласования может инициировать такое согласование | ||||
2. | Планирование ЗНИ | ||||||
2.1. | Оценка ЗНИ | Входящие:  ЗНИ согласован; Уведомление о переходе ЗНИ в статус "Создан"Результат:  ДО; ЗНИ в статусе - Оценка подготовленаЗапрос на согласование отмены ЗНИ. Участники шагов процесса: Инициатор ЗНИ Исполнитель ЗНИ | Уточнение бизнес-требований. Ответственный за оценку сотрудник производит анализ приложенных к ЗНИ требований на предмет полноты, достаточности для выполнения оценки, существенности, уровня влияния, условий осуществимости, выявления рисков. При необходимости ответственный за оценку направляет уточняющие вопросы Инициатору. При этом ЗНИ переводится Ответственным за оценку в статус "Запрос доп. информации" до получения уточняющей информации. Оценка ЗНИ. Исполнитель описывает техническую спецификацию реализации требований ЗНИ, оценивает влияние, риски реализации ЗНИ, трудозатраты на реализацию ЗНИ. Документ оценки проходит согласование в соответствии с внутренними регламентами Заказчика | ||||
| |||||||
2.2. | Согласование ДО ЗНИ | Входящие: ДО Результат: ДО согласован ЗНИ в статусе "Оценка согласована" ДО не согласован Участники шагов процесса: Инициатор ЗНИ Менеджер по управлению изменениями Исполнитель ЗНИ |  осуществляется контроль корректности и полноты подготовленного технического решения; осуществляет анализ влияния изменения на архитектурную целостность ИС, а также смежную с ним функциональность и другие ЗНИ; выполняет анализ корректности трудозатрат; контролирует полноту указанного перечня разрабатываемой/корректируемой документации по ЗНИ; в случае влияния ЗНИ на архитектуру ГИС, устанавливает в ЗНИ соответствующий признак.Менеджер по управлению изменениями:  проводит оценку необходимости перевода ЗНИ в проект. Оценка формируется на основании объема и характера (влияние на изменение бизнес-процессов и архитектуру решения) изменений; утверждает плановые трудозатраты.В случае потери актуальности бизнес-требований, указанных в ЗНИ, согласующие оставляют в СОЗ комментарии о причинах неактуальности/нецелесообразности реализации и инициируют его отмену. ЗНИ переходит в подпроцесс "Отмена ЗНИ". При наличии у согласующих замечаний к ДО они оставляют комментарий в СОЗ и отклоняют согласование ЗНИ. Если хотя бы один участник процесса его отклонил на этапе согласования ДО, то после завершения процедуры согласования всеми участниками ЗНИ возвращается в статус "В оценке". Инициатору направляется соответствующее уведомление. ЗНИ возвращается в подпроцесс "Оценка ЗНИ" | ||||
2.3. | Приоритизация ЗНИ | Входящие: ЗНИ в статусе - Оценка согласована; Согласованный ДО. Результат: Ранжированный перечень ЗНИ. Участники шагов процесса: Менеджер по управлению изменениями | Менеджер по изменениям производит приоритизацию оцененных, но не принятых в реализацию ЗНИ по следующим критериям:  Критичность; Длительность реализации; Риски реализации | ||||
2.4. | Планирование ЗНИ | Входящие: Актуальный ранжированный перечень ЗНИ (оцененных, но не принятых в реализацию) Результат: План реализации ЗНИ на следующий период (месяц) Статус ЗНИ - Запланирован Участники шагов процесса: Менеджер по управлению изменениями | На основе ранжированного перечня ЗНИ Менеджер по изменениям формирует План реализации ЗНИ на следующий период | ||||
2.5. | Отмена ЗНИ | Входящие: ЗНИ в разных статусах планирования; ДО Результат: ЗНИ отменен Участники шагов процесса:  Инициатор ЗНИ Менеджер по управлению изменениями | Если при планировании ЗНИ выявлена необходимость в отмене ЗНИ, ЗНИ переводится в статус "Отменен". Основанием для отмены ЗНИ на этапе планирования является ДО, где указаны причины отмены ЗНИ | ||||
3. | Реализация ЗНИ | ||||||
3.1. | Реализация ЗНИ | Входящие: ДО; ЗНИ (в статусе Запланирован) Результат: Статус ЗНИ - В тестировании; Спецификация на разработку Сценарий тестирования; Тестовый пример. Участники шагов процесса:  Исполнитель ЗНИ | Исполнитель обеспечивает реализацию ЗНИ в соответствии с ДО, перенос Пакета изменений в тестовую среду модифицируемой ГИС, выполнение работ по настройке тестовых примеров и подготовке сценария(ев) тестирования. Согласно плану проведения работ | ||||
3.2. | Тестирование ЗНИ | Входящие: Статус ЗНИ - В тестировании; Сценарий тестирования; Тестовый пример. Результат: Статус ЗНИ - Документирование, В работе, Выполнен; Реестр замечаний. Участники шагов процесса: Инициатор ЗНИ Исполнитель ЗНИ | Исполнитель и Инициатор выполняют действия, описанные в тестовом сценарии. Если тестирование отклонено хотя бы одним тестирующим, ЗНИ возвращается в статус "В работе". При возвращении в статус "В работе" к ЗНИ должен быть приложен реестр замечаний. В случае подтверждения теста всеми тестирующими ЗНИ переходят в статус "Документирование". В обоих случаях направляются соответствующие уведомления. Исполнитель обеспечивает перенос успешно протестированного Пакета изменений в продуктивную среду модифицируемой ГИС и контроль корректности (техническое тестирование) переноса изменений в продуктивную среду. При необходимости обеспечивает устранение ошибок и несоответствий, а также обеспечение выдачи необходимых полномочий Пользователям данного функционала в продуктивной среде | ||||
3.3. | Документирование | Входящие: Статус ЗНИ - Документирование Результат:  Разработанная/актуализированная эксплуатационная документация (операционные инструкции, инструкции администратора системы) Статус ЗНИ - ВыполненУчастники шагов процесса: Инициатор ЗНИ Исполнитель ЗНИ | Исполнитель разрабатывает/актуализирует документацию, указанную в ДО. Документация размещается (адрес ресурса). Инициатор согласовывает разработанную/актуализированную документацию | ||||
4. | Закрытие ЗНИ | ||||||
4.1. | Передача ЗНИ в поддержку | Входящие: Статус ЗНИ - Выполнен Результат: Статус ЗНИ - Закрыт Участники шагов процесса:  Менеджер по управлению изменениями | Сотрудники службы поддержки получают уведомления о переводе ЗНИ в статус "Выполнен". Если в течение трех дней от службы поддержки не поступило замечаний к технической реализации ЗНИ или к документации, ЗНИ автоматически переводится в статус "Закрыт". ЗНИ в статусе "Закрыт" включаются в Отчет о выполненных ЗНИ | ||||
Общая схема процесса управлениями изменениями приведена на рисунке 3.
МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ
КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ
ЕДИНАЯ ЦИФРОВАЯ ПЛАТФОРМА РОССИЙСКОЙ ФЕДЕРАЦИИ "ГосТех"
ДЛЯ СОЗДАНИЯ, РАЗВИТИЯ И ЭКСПЛУАТАЦИИ ГОСУДАРСТВЕННЫХ
ИНФОРМАЦИОННЫХ СИСТЕМ
РЕГЛАМЕНТ
ПО ОФОРМЛЕНИЮ ОБЯЗАТЕЛЬНЫХ
ЭКСПЛУАТАЦИОННЫХ ДОКУМЕНТОВ
1. Перечень используемых терминов и сокращений
В настоящем документе применены следующие сокращения:
Сокращение | Расшифровка |
БД | База данных |
БПО | Базовое программное обеспечение |
ГИС | Государственная информационная система |
ДО | Документ оценки |
ЗНИ | Запрос на изменение |
КТС | Комплекс технических средств |
ОС | Операционная система |
ПО | Программное обеспечение |
ППО | Прикладное программное обеспечение |
Система | ГИС, принимаемая в эксплуатацию |
СМЭВ | Система межведомственного электронного взаимодействия |
СОЗ | Система регистрации, учета и обработки обращений пользователей в службу сопровождения |
СПО | Специальное программное обеспечение |
СРК | Система резервного копирования |
СТП | Служба технической поддержки |
СУБД | Система управления базами данных |
SLA | Соглашение об уровне обслуживания |
SRE | Инженер, обеспечивающий надежность и доступность системы |
В настоящем документе применены следующие термины и сокращения с соответствующими определениями:
Термин | Определение |
Пользователь | Государственные органы и внебюджетные фонды, обеспечивающие создание, развитие, эксплуатацию ГИС на Платформе "ГосТех", в том числе отвечающие за разработку документации, хранение содержащейся в базах данных информации и осуществляющие иные функции |
Оператор ГИС | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, отвечающее за эксплуатацию, техническое сопровождение, организацию мероприятий по подготовке (актуализации) расчета стоимости затрат на эксплуатацию ГИС и (или) осуществляющее иные сопроводительные функции, в том числе по техническому сопровождению инфраструктуры и программно-аппаратного комплекса |
Разработчик ГИС | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, выполняющее функции по созданию или переработке (модернизации) ГИС на основании соответствующего договора |
Разработчик ППО | Юридическое лицо или физическое лицо, в том числе зарегистрированное в качестве индивидуального предпринимателя, выполняющее функции по созданию или переработке (модернизации) ППО на основании соответствующего договора |
Оператор Платформы "ГосТех" | Министерство цифрового развития, связи и массовых коммуникаций Российской Федерации или подведомственное ему казенное учреждение, которому переданы полномочия по осуществлению функций оператора Платформы "ГосТех" |
Платформа "ГосТех" | Цифровая экосистема создания, развития и эксплуатации ГИС, включающая в себя единую программно-аппаратную среду, цифровые продукты, информацию, информационные технологии, ГИС, необходимые для реализации функций Платформы "ГосТех", а также совокупность нормативных правовых, организационных, методологических правил и процедур, обеспечивающих деятельность участников отношений, возникающих в связи с созданием и функционированием Платформы "ГосТех" |
ГИС на Платформе "ГосТех" | Государственные информационные системы, создаваемые, развиваемые, эксплуатируемые с использованием программно-аппаратной среды, цифровых продуктов, включенных в каталог цифровых продуктов платформы "ГосТех" (далее - цифровые продукты платформы "ГосТех"), а также инструментов, информационных технологий платформы "ГосТех" |
1.1. Назначение регламента
Настоящий регламент устанавливает требования по оформлению обязательных эксплуатационных документов для ГИС на Платформе "ГосТех".
1.2. Регламент резервного копирования
Данный раздел содержит пример регламента резервного копирования. Для различных ГИС требования по резервному копированию могут различаться, поэтому допускается его пополнение.
1.3. Цели данного регламента
Настоящий регламент проведения резервного копирования и восстановления программ и данных разработан с целью:
определения порядка резервного копирования данных и ПО;
определения порядка восстановления информации из резервных копий при полной или частичной ее потере;
упорядочения работы должностных лиц, связанных с резервным копированием информации.1.4. Описание системы резервного копирования
1.4.1. Объекты, подлежащие резервному копированию
Периодическому, планируемому резервному копированию могут подлежать объекты, содержащие следующие каталоги и файлы на серверах:
ОС хоста сервера;
Конфигурационные и рабочие каталоги системы;
Файлы СУБД;
Файлы БД:
Файлы данных;
Журналы БД;
Управляющие файлы БД;
Файлы данных табличных пространств;
Оперативные журналы регистрации транзакций;
Архивные журналы регистрации транзакций.Объекты для каждой ГИС определяются исходя из архитектуры решения и должны быть достаточны для восстановления работоспособности ГИС на резервной площадке в плановые сроки.
2. Требования к системе резервного копирования
Требования, описанные в данном разделе, могут быть вынесены в отдельный документ, такой как политика резервного копирования, но обязательно должны учитываться:
Обеспечение возможности полного восстановления данных ППО.
Возможность восстановления состояния БД каждой из систем на любой момент времени в течение 30 календарных дней.
Резервное копирование объектов должно выполняться в автоматическом режиме.
СРК должна позволять запуск резервного копирования в автоматизированном и ручном режиме.
Резервное копирование объектов должно выполняться в режиме online.
СРК должна позволять запуск резервного копирования в режиме offline.
Регулярность проведения резервного копирования.
Минимальное время восстановления данных.
Резервное копирование должно проводиться во время минимальной загрузки системы.
Простота и надежность процедур резервного копирования и восстановления данных.
Для всех систем в ландшафте, в зависимости от объектов резервного копирования, должно применяться соответствующее, идентичное оборудование, типы носителей и программное обеспечение.
Для выполнения операций резервного копирования должно применяться программное обеспечение производителей, сертифицированных для выполнения резервного копирования.
СРК должна быть обеспечена инфраструктурой, не зависимой от основной.
Должны быть созданы альтернативные места хранения и обработки информации, включая отдельное аппаратное обеспечение (процессоры, память, устройства) и соответствующее программное обеспечение.2.1. Режимы, типы и методы выполнения резервного копирования
Режим резервного копирования, осуществляемого при работающей системе, называется online. При online резервном копировании система сохраняет доступность своих функций для пользователя.
Режим резервного копирования, для которого требуется остановка работающей системы, называется offline.
Тип резервного копирования может быть, как полным - выполняется полная копия данных, так и инкрементальное - выполняется копия только данных, изменившихся с момента последнего резервного копирования (полного или инкрементального).
Метод выполнения резервного копирования может быть:
автоматическим - резервное копирование выполняется по заранее заданному расписанию без участия администратора;
автоматизированным - резервное копирование выполняется с незначительным привлечением администратора, например, для планирования резервного копирования;
ручным - резервное копирование выполняется с привлечением и под наблюдением администратора.2.2. Используемое программное обеспечение
Для резервного копирования и восстановления ОС хостов, файлов транспортной системы, а также рабочих каталогов платформы, ППО и СУБД используется следующее ПО:
1 "Кибер Бэкап" (пример)
2
3Для резервного копирования и восстановления БД используется следующее ПО:
1 Кибер Бэкап" (пример)
2
3При формировании параметров резервного копирования должны учитываться следующие показатели, определяемые для конкретной ГИС:
"Целевая точка восстановления" (RPO) - максимальный период времени и соответствующий объем данных, который допустимо потерять;
"Допустимое время недоступности" (RTO) - максимальное время, в течение которого ГИС может быть недоступной до момента восстановления без критических последствий.
В таблице 1 приведен пример параметров резервного копирования объектов.
Таблица 1
Объект резервного копирования | Каталоги/файлы | Режим | Тип | Метод | Инициализация | Периодичность выполнения | Срок хранения | Используемое ПО |
1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 |
online | архивирование | автоматический | СРК | 1 раз в неделю | 1 месяц | |||
online | архивирование | автоматический | СРК | 1 раз в месяц | 1 год | |||
online | архивирование | автоматический | СРК | 1 раз в год | 3 года | |||
online | инкрементальное | автоматический | СРК | 1 раз в сутки | 7 дней | |||
online | архивирование | автоматический | СРК | 1 раз в неделю | 1 месяц | |||
online | архивирование | автоматический | СРК | 1 раз в месяц | 1 год | |||
online | архивирование | автоматический | СРК | 1 раз в год | 3 года | |||
online | инкрементальное | автоматический | СРК | 1 раз в сутки | 7 дней | |||
online | архивирование | автоматический | СРК | 1 раз в неделю | 1 месяц | |||
online | архивирование | автоматический | СРК | 1 раз в месяц | 1 год | |||
online | архивирование | автоматический | СРК | 1 раз в год | 3 года | |||
online | инкрементальное | автоматический | СРК | 1 раз в сутки | 7 дней | |||
online | архивирование | автоматический | СРК | 1 раз в неделю | 1 месяц | |||
online | архивирование | автоматический | СРК | 1 раз в месяц | 1 год | |||
online | архивирование | автоматический | СРК | 1 раз в год | 3 года |
3. Описание работ по резервному копированию объектов
Администратор СРК:
Осуществляет и участвует в первоначальной настройке механизма резервного копирования, для всех объектов резервного копирования, используя средства централизованной СРК;
Отвечает за мониторинг выполнения резервного копирования объектов: Конфигурационные и рабочие каталоги системы, Файлы транспортной системы, Файлы СУБД;
Проверка копий;
Контрольные восстановления;
Решает проблемы, связанные с работой СРК.Администратор платформы:
Осуществляет первоначальную настройку механизма резервного копирования для объекта: ОС хоста сервера;
Отвечает за мониторинг выполнения резервного копирования объекта: ОС хоста сервера;
Осуществляет настройку и контроль работы ОС, решение проблем, связанных с работой ОС.Администратор ППО:
Осуществляет первоначальную настройку механизма резервного копирования для объектов резервного копирования файлов БД и ППО;
Осуществляет контроль за корректностью выполнения резервного копирования файлов БД и ППО;
Решает проблемы, связанные с работой ППО.Все Администраторы входят в состав соответствующих групп исполнителей в качестве специалистов 3-й линии Сопровождения конкретной ГИС.
Для выполнения своих должностных обязанностей Администраторы могут привлекать соответствующих должностных лиц при возникновении такой необходимости.
Группа администраторов с участием Заказчика и Руководителя службы сопровождения составляет план восстановления с учетом требований к доступности и непрерывности.
3.2. Организация взаимодействий должностных лиц
Администраторы выполняют работы в рамках своих должностных обязанностей (в соответствии с разделом 1) на основании заявок от уполномоченных лиц.
Для выполнения регулярных регламентных работ по резервному копированию оформление заявки не требуется.
При установке обновлений ОС, переходе на новые версии ПО, переконфигурировании ОС/ПО, а также после устранения возникших в СРК ошибок Администратор ПО или Администратор ОС направляет заявку на внеплановое резервное копирование на электронный адрес службы сопровождения СРК.
Реализация внеплановых работ Администратором СРК (Восстановление и внеплановое резервное копирование объектов) выполняется в ручном режиме на основании зарегистрированной в службе сопровождения СРК заявки от Администратора ПО или Администратора ОС.
При обнаружении ошибок порядок действий Администраторов следующий:
При наличии ошибок, соответствующий Администратор принимает меры по устранению ошибки своими силами без влияния на работу функциональных систем платформы.
В зависимости от причин возникшей ошибки информация об ошибке (причинах ошибки) может быть эскалирована к другим Администраторам (в соответствии с разделом 3).
Если действия по устранению ошибок, а также их последствий, требуют остановки или ограничения в работе функциональных систем на базе платформы, то согласование возможности и времени проведения указанных действий эскалируется в адрес службы функционального сопровождения.
Если устранение ошибки повлекло восстановление системы или были устранены ошибки выполнения резервного копирования, то Администратором должно быть запланировано внеплановое резервное копирование объекта.3.4. Резервное копирование объектов: ОС хоста сервера, Конфигурационные и рабочие каталоги ППО, Файлы транспортной системы, Файлы СУБД
Вся виртуальная машина резервируется в автоматическом режиме средствами СРК, включая объекты резервного копирования:
ОС хоста сервера;
Конфигурационные и рабочие каталоги ППО;
Файлы СУБД.В процессе резервного копирования создаются четыре набора резервных копий:
Ежедневная копия (ежесуточно записывается инкрементальная копия, срок хранения - 7 дней с момента записи последней копии за неделю, копия хранится в СРК);
Недельная копия (еженедельно записывается полная копия, срок хранения - месяц, копия хранится в СРК);
Месячная копия (последняя недельная копия в месяце, срок хранения - год, копия хранится в специализированном хранилище);
Годовая копия (последняя месячная копия в году, срок хранения - 3 года, копия хранится в специализированном хранилище).3.5. Резервное копирование объектов: Файлы БД
Файлы БД резервируются онлайн в автоматическом режиме в СРК, согласно разделу 2.3.
4. Описание работ по восстановлению объектов
В случае частичной или полной потери данных в системах, необходимо:
Определиться с объектами резервного копирования, подлежащими восстановлению.
Восстановить необходимые объекты, используя пункты 0, 0 данного документа.4.1. Сопоставление объектов резервного копирования и видов серверов
Пример объектов резервного копирования, которые необходимо восстановить, приведен в таблице 2.
Таблица 2
и видов серверов
ID системы | Вид сервера системы | Объект резервного копирования, который необходимо восстановить |
1 | 2 | 3 |
TEST | Сервер приложений | ОС хоста сервера Конфигурационные и рабочие каталоги ППО |
Сервер БД | ОС хоста сервера Конфигурационные и рабочие каталоги ППО Файлы СУБД Файлы БД | |
Prod | Сервер приложений | ОС хоста сервера Конфигурационные и рабочие каталоги ППО |
Сервер БД | ОС хоста сервера Конфигурационные и рабочие каталоги ППО Файлы СУБД Файлы БД | |
TEST | Сервер приложений | ОС хоста сервера Конфигурационные и рабочие каталоги ППО |
Сервер БД | ОС хоста сервера Конфигурационные и рабочие каталоги ППО Файлы СУБД Файлы БД |
4.2. Последовательность действий администраторов при восстановлении системы
Администратор СРК восстанавливает объекты резервного копирования, основываясь на документации ПО СРК и таблице 2 данного документа.
Администратор ОС проверяет корректность и полноту восстановленных объектов, запускает и проверяет работоспособность виртуальной машины сервера.
Администратор ПО проверяет корректность и полноту восстановленных объектов.
Администратор ПО, основываясь на табл. 2, принимает решение о необходимости восстановления объектов резервного копирования и при необходимости выполняет п. 4.3 или п. 4.4 настоящего документа.
Администратор ПО проверяет работоспособность восстановленной системы.4.3. Порядок восстановления из резервной копии объектов: ОС хоста сервера, Конфигурационные и рабочие каталоги системы, Файлы транспортной системы, Файлы СУБД
Восстановление данных и приложений при полной или частичной их потере, вызванной сбоями или отказами аппаратного или программного обеспечения, ошибками пользователей, чрезвычайными обстоятельствами выполняется в ручном режиме Администратором СРК средствами ПО СРК на основании заявки от уполномоченных лиц служб Администратора ПО, Администратора ОС, Владельца ИС. При восстановлении можно восстанавливать как отдельные объекты резервного копирования, так и отдельные файлы в рамках объектов резервного копирования.
Администратор СРК восстанавливает объекты резервного копирования, основываясь на документации ПО СРК и Таблице 2 данного документа.
Восстановление объекта "Файлы БД" выполняется после утраты файлов данных, контрольного файла БД. Восстановление объекта выполняется в ручном режиме Администратором ПО на основании заявки от уполномоченных сотрудников Владельца ИС.
Требования:
Объекты: ОС хоста сервера, Конфигурационные и рабочие каталоги системы, Файлы СУБД не были подвержены утрате/порче или уже восстановлены.
Объект "Файлы БД" должен иметь резервную копию.4.5. Порядок внесения изменений
Изменения в настоящий документ вносятся при необходимости отразить в нем изменения, в части объектов резервного копирования, методик резервного копирования и восстановления, организации работ, описываемых в документе.
Инициатором изменений может быть любая сторона, участвующая в согласовании документа.
5. Руководство администратора ГИС
5.1. Введение
Документ Руководство администратора должен содержать все сведения, достаточные для установки, запуска, поддержки и остановки системы, требования к окружению, методы поиска и диагностики неисправностей.
Документ кратко описывает общие функции системы, полный перечень компонентов, логическую схему.
Отдельно документ должен описывать:
ППО:
Описание языка/ов разработки и методов взаимодействия.
СПО:
библиотеки и фреймворки, используемые ППО для обработкиинформации;
пакеты ПО, служащие для обеспечения функционирования прикладнойподсистемы;
пакеты ПО, предназначенные для обеспечения функций управления иэксплуатации прикладной подсистемы;
пакеты ПО, используемые для построения инфраструктурных сервисов(аутентификация/авторизация, службы каталогов и пр.);
скрипты, разрабатываемые для управления, автоматизации имониторинга ППО ИС;
БПО:
ПО системы виртуализации;
ОС виртуальных машин;
системы мониторинга;
сервисы БД.Отдельно стоит выделить и описать основные взаимодействия системы с другими ГИС.
5.2. Установка
Разделы установки в целом повторяют инструкцию по развертыванию системы и содержат пошаговое детальное руководство по настройке всех компонентов.
5.3. Запуск
Раздел по запуску подсистемы содержит информацию о процедуре запуска системы, состоящей из описания правильной последовательности запуска всех подсистем, остановки, а также проверки работоспособности каждой подсистемы.
Например:
Запуск
Портал запускается на ноде example-int-portal-01/10.10.5.13
Дистрибутив находится в директории portal-pages, требуется скопировать файлы в /opt/app.
Для запуска приложения будет использоваться nginx-proxy.
Порядок действий:
2 Добавьте конфигурационный файл приложения в конфигурацию nginx.
upstream int_proxy {
ip_hash;
server 10.10.5.183:8080;
}
server {
listen 80;
server_name_;
root /opt/app;
index index.html index.htm;
error_page 404 /index.html;
try_files $uri $uri/ /index.html;
access_log/var/log/nginx/puv_pages.access.log;
error_log/var/log/nginx/puv_pages.error.log;
location /api/ {
proxy_pass http://int_proxy/;
proxy_read_timeout 1440s;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
add_header Access-Control-Allow-Origin *;
add_header Access-Control-Allow-Methods "POST, GET, PATCH, DELETE, PUT, OPTIONS";
add_header Access-Conlrol-Allow-Headers "Origin, Authorization, Accept";
add_header Access-Control-Allow-Credentials true;
}
}
Перезапустите nginx:service nginx restart
После выполненных действий nginx начнет отдавать фронт PORTAL по адресу http://10.10.1.2
Остановка
Для остановки сервиса необходимо остановить веб-сервер Nginx:
service nginx stop
Проверка работоспособности
Для проверки работоспособности сервиса необходимо проверить, запущен ли веб-сервер Nginx:
service nginx status
Тестирование
Описание финальных тестов (юнит и интеграционное тестирование). Далее описание механизмов логирования. Процесса обновлений (если инструкция не поставляется вместе с обновлениями).
5.4. Диагностика, поиск и устранение неисправностей
Это основной рабочий раздел для администраторов, который описывает основные контрольные точки системы, рекомендации по мониторингу.
Пример краткой таблицы контрольных точек:
Контрольные точки и методы для поиска неисправностейКонтрольная точка | Метод для поиска неисправностей | Ожидаемый результат проверки |
Статус сервисов приложений | systemctl status "имя приложения" | Active: active (running) |
Проверка лог-файлов на наличие ошибок java | Journalctl --unit="имя приложения" | не должно быть ошибок |
Статус подключения к серверу RabbitMQ | Просмотр списка активных соединений по адресу http://10.10.5.15:15672/#/connections | Должны присутствовать соединения от Подсистема 1, Подсистема 2, Подсистема 3 |
Возможность регистрации на web-интерфейсах подсистем | Через ЕСИА для приложения кабинетов, через LDAP для остальных приложений | Попытка авторизации через веб-страницы должна быть успешной |
Кабинет администратора | 10.10.5.13:8090/admin | Страница открывается без ошибок |
6. Инструкция по развертыванию системы
6.1. Общее описание
Документ описывает корректный пошаговый процесс проверки предварительных условий, подготовки и развертыванию ГИС. Основные этапы развертывания системы (могут быть разбиты на более мелкие):
проверка предварительных условий;
подготовка к установке;
настройка окружения;
установка ППО.6.2. Проверка предварительных условий
В разделе описываются требования к средам виртуализации (если используется), каналам связи, подсистемам резервного копирования и мониторинга.
Ниже представлен пример:
Характеристики каналов связи основного ЦОД представлены в таблице.
Таблица
Состав каналов связи основного ЦОД
Характеристики каналов связи | Количество |
Канал Интернет | 2 |
Канал L2 | 2 |
Канал СМЭВ | 1 |
6.3. Подготовка к установке
В данном разделе описывается процесс сегментирования вычислительных ресурсов.
В каждом сегменте основного и резервного ЦОД необходимо выделить ВМ. Состав ВМ и количество ресурсов по каждой из них, указаны в таблице ниже.
Таблица
Ресурсы для ВМ
Название ВМ | IP Адрес | Роль, описание | vCPU | vRAM (GB) | SDD (GB) |
Подсистема 1 Основного ЦОД | |||||
Example-vm | 10.10.1.2 | Сервер (портал) | 4 | 32 | 50 |
Дополнительно можно составить адресный список всех виртуальных машин. Требования к организации внешнего доступа, если таковой предусмотрен.
6.4. Настройка окружения
В данном разделе описываются требования к настройке СПО и ППО.
Пример необходимого описания:
Чтобы настроить ОС:
На сервера приложений добавьте пользователя xx и разрешите исполнение программ от его имени в СКЗИ.
Добавьте пользователей с тем же uid и gid, что и пользователь xx, выполнив команду:useradd -ou xxx -g yyy zzz,
где xxx - uid пользователя xx; yyy - gid пользователя xx, zzz - имя нового пользователя.
Отключите SELinux. В файле /etc/selinux/config всех ВМ укажите SELINUX=disabled и перезагрузите ВМ.
Чтобы избежать длительных задержек на сервере RabbitMQ при подключении клиентов, убедитесь, что библиотека resolver в файле /etc/resolv.conf настроена верно, и производится как прямое разрешение имени хоста, так и обратное - адреса сетевого интерфейса. Для серверов внешнего и внутреннего контура указаны соответствующие сервера DNS:
nameserver <ip основного DNS>;
nameserver <ip дополнительного DNS>.
Отключите сервис NetworkManager для всех ВМ:
systemctl stop NetworkManager
systemctl disable NetworkManager.
На серверах приложений внутреннего контура выставьте в файле /etc/sysctl.conf параметр net.ipv4.tcp_tw_reuse=1.Предварительная установка пакетов
На все виртуальные машины необходимо установить следующие пакеты:
atop
bash-completion
curl
device-mapper-persistent-data
git
glibc
glibc-common.Также необходимо установить на сервера внешнего и внутреннего прокси Nginx пакеты:
openssl-libs-1.0.2k-12.el7.x86_64.rpm
openssl-1.0.2k-12.el7.x86_64.rpm
nginx-mod-http-xslt-filter-1.16.1-2.el7.x86_64.rpm
nginx-mod-mail-1.16.1-2.el7.x86_64.rpm
nginx-mod-stream-1.16.1-2.el7.x86_64.rpm1 Установка ГИС
Раздел детально описывает процесс установки и настройки всех компонентов и подсистем ГИС.
Пример описания на основе установки Kafka
Установка Kafka на example-kafka-server
1 Создайте пользователя с именем * kafka *:
sudo useradd kafka -m
Установите пароль с помощью + passwd +:sudo passwd kafka
Добавьте пользователя * kafka * в группу + wheel, чтобы у него были права, необходимые для установки зависимостей Kafka:sudo usermod -aG wheel kafka
Войдите в эту учетную запись kafka:su -l kafka
Для загрузки бинарных файлов Kafka нужно скачать дистрибутив kafka из папки packages в предоставленном дистрибутиве:kafka_2.13-2.6.0.tgz
Создайте каталог с именем + kafka + и перейдите в этот каталог. Это будет базовый каталог установки Kafka:mkdir ~/kafka && cd ~/kafka
Извлеките загруженный архив с помощью команды + tar +:tar -xvzf kafka_2.13-2.6.0.tgz
Добавьте параметр, который позволит удалять темы Kafka в конец файла:vi ~/kafka/config/server.properties
~/ Kafka / конфигурации / server.properties
delete.topic.enable = true
7. Рабочее задание и технологическая карта
Раздел содержит пример технологической карты. Технологические карты должны быть разработаны для любых работ, изменяющих состояние системы. Основанием для выполнения работ должен являться Запрос на обслуживание, соответствующим образом зарегистрированный в СОЗ.
Технологическая карта разрабатывается в целях согласования и утверждения:
Участка проведения работ и участков, затрагиваемых при их проведении;
Состава, последовательности и длительности технологических операций, выполняемых в ходе работ;
Ответственных Исполнителей и лиц, выполняющих технический надзор за проведением технологических операций;
Процедуры проверки работоспособности Системы после завершения работ;
Процедуры возврата Системы к исходному состоянию в случае неуспешного проведения работ.Пример карты и ее заполнения:
ИС МЕГАНОРМ: примечание. Сноски даны в соответствии с официальным текстом документа. |
Технологическая карта
На проведение работ по <1>: установке обновления подсистемы Подсистема1
Технологическая площадка: ТП N 3
Условия проведения работ (в рамках технологического окна, тех. окно не требуется):
в рамках технологического окна
Характер работ: с перерывом в работе сервисов
Причина проведения работ <3>: письмо ДИТ от ... ...
Планируемая дата/время проведения работ (начало, окончание): дд.мм.гггг, чч:мм - чч:мм
Планируемая дата/время перерыва в работе сервисов: дд.мм.гггг, чч:мм - чч:мм
Ответственный за проведение работ: ФИО
Дата последнего резервного копирования серверов БД: дд.мм.гггг
Дата последнего резервного копирования серверов приложений и прочих: дд.мм.гггг
Перечень недоступных в период выполнения работ подсистем и сервисов.
--------------------------------
<2> Указывается: "с перерывом в работе сервисов" или "без перерыва в работе сервисов".
<3> Указывается ссылка на пункт регламента эксплуатации Системы, реквизиты письма, номер заявки в АС ТП, прочие причины, определяющие необходимость работ.
N п/п | Технологическая операция | Время и длительность выполнения работ | Характер работ | Технадзор за производством работ (ФИО, организация) | Ответственный исполнитель (ФИО, организация) |
Подготовительные работы | |||||
Работы могут проводиться заранее (за несколько дней или часов) | С перерывом в работе сервисов/без перерыва в работе сервисов | ФИО, организация по каждому пункту работ | ФИО, организация по каждому пункту работ | ||
1. | Операция N 1 | 17:00 - 17:15 (15 мин) | Без перерыва | ФИО, организация | ФИО, организация |
2. | ... | ... | ... | ... | ... |
3. | ... | ... | ... | ... | ... |
4. | Операция N M | 17:45 - 18:00 (15 минут) | Без перерыва | ФИО, организация | ФИО, организация |
5. | Продолжительность работ | 1 час | |||
Основные работы | |||||
Подробное, по пунктам, описание производимых работ на основании рекомендаций, полученных от фирм-производителей | Указывается время и длительность проведения каждого пункта | С перерывом в работе сервисов/без перерыва в работе сервисов | ФИО, организация по каждому пункту работ | ФИО, организация по каждому пункту работ | |
6. | Доклад в ДИТ о начале и об окончании основных работ, результат | ФИО, организация | |||
7. | Операция N 1 | 18:00 - 18:30 (30 мин) | С перерывом | ФИО, организация | ФИО, организация |
8. | ... | ... | ... | ... | ... |
9. | ... | ... | ... | ... | ... |
10. | Операция N M | 19:45 - 20:00 (15 минут) | С перерывом | ФИО, организация | ФИО, организация |
11. | Продолжительность работ | 2 часа | |||
Процедура проверки работоспособности оборудования, подсистем, сервисов | |||||
Описание процедуры проверки работоспособности оборудования, подсистем, сервисов | Указывается время и длительность проведения каждого пункта | С перерывом в работе сервисов/без перерыва в работе сервисов | ФИО, организация по каждому пункту работ | ФИО, организация по каждому пункту работ | |
12. | Операция N 1 | 20:00 - 20:10 (10 мин) | С перерывом | ФИО, организация | ФИО, организация |
13. | ... | ... | ... | ... | ... |
14. | ... | ... | ... | ... | ... |
15. | Операция N M | 21:45 - 22:00 (15 минут) | Без перерыва | ФИО, организация | ФИО, организация |
Процедура возврата к исходной конфигурации | |||||
Подробное, по пунктам, описание производимых работ | Длительность проведения каждого пункта восстановительных работ | С перерывом в работе сервисов/без перерыва в работе сервисов | ФИО, организация по каждому пункту работ | ФИО, организация по каждому пункту работ | |
16. | Доклад в ДИТ о необходимости возврата Системы к исходной конфигурации | ФИО, организация | |||
17. | Операция N 1 | 18:00 - 18:30 (30 мин) | С перерывом | ФИО, организация | ФИО, организация |
18. | ... | ... | ... | ... | ... |
19. | ... | ... | ... | ... | ... |
20. | Операция N M | 15 минут | С перерывом | ФИО, организация | ФИО, организация |
21. | Продолжительность работ | 2 часа | |||
Должность | ФИО | Контактный телефон | Подпись | ||
Составил | |||||
Проверил Руководитель | |||||
Согласовано: | |||||
В рамках выполнения процедур проведения технологических работ Администратор ПО, в зоне ответственности которого проводятся технологические работы, направляет уведомление о предстоящих работах согласно Листу рассылки, закрепленному в Регламенте технической поддержки Системы:
не позднее чем за четыре часа до планируемого времени начала работ, в случае если в ходе технологических работ возникает перерыв в доступности сервисов СМЭВ;
не позднее чем за два часа до планируемого времени начала работ во всех остальных случаях.Общий контроль над проведением технологических работ осуществляет Начальник дежурной смены СТП. В рамках выполнения процедур проведения технологических работ Администратор:
уточняет готовность специалистов к проведению работ;
регистрирует рабочее задание на проведение работ в СТП;
осуществляет контроль сроков проведения работ;
направляет уведомления о продлении, завершении.8. Шаблон заявки на переработку (модификацию) программного обеспечения
Раздел содержит пример шаблона заявки на изменение (модификацию) программного обеспечения. План должен быть разработан для каждой ЗНИ отдельно.
Пример шаблона заявки:
Заявка N _____________________ ЗНИ N __________________
(Директор ИТ)
_____________________
(Аккаунт)
ЗАЯВКА
на изменение (модификацию) программного обеспечения
1. Обоснование необходимости изменений в ПО.
Описание цели изменения |
2. Заказчик.
Дирекция | Должность | Ф.И.О. | Телефон |
Пользовательские требования:
a. Как задача решается в настоящее время.
b. Как задача должна решаться.
Заказчик:
_________________________ _______________________ _______________________
(должность) (подпись) (ФИО)
_______________________
(дата)
_________________________ _______________________ _______________________
(должность) (подпись) (ФИО)
_______________________
(дата)
Функциональный директор:
_________________________ _______________________ _______________________
(должность) (подпись) (ФИО)
_______________________
(дата)
Отметка о приемке модифицированного ПО Заказчиком:
Должность Заказчика | Ф.И.О. Заказчика | Дата окончания тестирования Заказчиком | Предложение Заказчика по модифицированному ПО | Комментарии | Подпись Заказчика |