Единая цифровая платформа Российской Федерации «ГосТех» для создания, развития и эксплуатации государственных информационных систем. Методические рекомендации по эксплуатации государственных информационных систем на единой цифровой платформе Российской Федерации «ГосТех». Версия 1.0

ЕДИНАЯ ЦИФРОВАЯ ПЛАТФОРМА РОССИЙСКОЙ ФЕДЕРАЦИИ «ГосТех» ДЛЯ СОЗДАНИЯ, РАЗВИТИЯ И ЭКСПЛУАТАЦИИ ГОСУДАРСТВЕННЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ

1. Перечень используемых терминов и сокращений

В настоящем документе применены следующие термины и сокращения с соответствующими определениями:

1.1. Назначение документа

Настоящий документ определяет минимальный набор организационно-технических требований к порядку эксплуатации ГИС, функционирующих на Платформе «ГосТех», требования к составу служб эксплуатации ГИС, основным технологическим операциям в ходе эксплуатации ГИС, показателям качества предоставления услуг по сопровождению ГИС, а также к составу и содержанию комплекта эксплуатационной документации на ГИС.

Условия эксплуатации отдельных ГИС, в том числе состав отчетных документов, порядок взаимодействия Заказчика ГИС и Исполнителя определяются условиями соответствующих договоров, в частности государственных контрактов, концессионных соглашений и соглашений о государственно-частном партнерстве о создании, развитии, эксплуатации, сопровождении ГИС с учетом положений настоящего документа.

Настоящий документ определяет правила взаимодействия служб эксплуатации и пользователей в целях предоставления услуг в ходе эксплуатации ГИС с заявленным уровнем обслуживания.

В состав настоящего документа входят следующие документы:

\cdot Регламент организации сопровождения;

\cdot Рекомендуемые шаблоны обязательных документов.

2. Передача ГИС в эксплуатацию

Основанием для передачи ГИС в эксплуатацию является обязательное выполнение следующих условий:

\cdot успешное завершение этапа опытной эксплуатации ГИС;

\cdot оформление Заказчиком ГИС акта о вводе системы в эксплуатацию, согласно Постановлению Правительства Российской Федерации от 6 июля 2015 г. № 676 «О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации» (далее — ПП № 676);

\cdot завершение разработки комплекта эксплуатационной документации с учетом требований пункта 2.1 настоящего документа;

\cdot соответствие состава служб эксплуатации Оператора ГИС требованиям пункта 2.2 настоящего документа;

\cdot передача Заказчиком ГИС комплекта эксплуатационной документации Оператору ГИС и при необходимости проведение соответствующего обучения сотрудников Оператора ГИС;

\cdot внедрение Оператором ГИС процессов эксплуатации с учетом требований пункта 3 настоящего документа;

\cdot предоставление Заказчиком ГИС по заявке Оператора ГИС доступа к ГИС и КТС в составе ГИС, достаточного для оказания услуг по эксплуатации и сопровождению ГИС. Доступ, в том числе удаленный, предоставляется в соответствии с порядком предоставления доступа, определяемым Заказчиком ГИС и в соответствии с проектным решением по защите информации ГИС;

\cdot между Заказчиком ГИС и Оператором ГИС заключен договор возмездного оказания услуг по эксплуатации ГИС.

2.1. Требования к составу документов

Минимальный пакет эксплуатационной документации, необходимый для передачи ГИС в эксплуатацию, должен включать в себя:

\cdot техническое задание на разработку;

\cdot регламент эксплуатации ГИС;

\cdot инструкции Пользователей;

\cdot руководство системного администратора (приложений/баз данных);

\cdot руководство по установке программных средств ГИС;

\cdot регламент управления доступностью и непрерывностью;

\cdot описание параметров мониторинга;

\cdot регламент резервного копирования;

\cdot акт приема передачи ГИС команде эксплуатации.

Состав документов для конкретной ГИС является минимальным и может быть расширен Заказчиком ГИС в соответствии с требованиями соответствующего договора. При разработке документов также необходимо учитывать требования и ограничения документов, регламентирующих эксплуатацию Платформы «ГосТех» и иных связанных систем. Значения целевых показателей метрик качества ГИС не может быть выше аналогичных показателей, указанных в вышеуказанных документах.

2.2. Требования к команде эксплуатации

По общему правилу, эксплуатация ГИС на Платформе «ГосТех» должна осуществляться в рамках существующих штатов специалистов (персонала) Оператора ГИС.

Персонал Оператора ГИС должен владеть:

\cdot общими навыками работы с персональными электронно-вычислительными машинами (ПЭВМ) и с современными средствами вычислительной техники, в том числе средствами защиты информации и средствами криптографической защиты информации;

\cdot специальной подготовкой для использования функциональности ГИС, технологического сопровождения, администрирования КТС в составе ГИС.

Для обеспечения требуемой квалификации персонала Оператор ГИС должен проводить соответствующее обучение персонала. Порядок подготовки, контроль знаний и навыков должен определяться организационно-распорядительными документами Оператора ГИС.

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

Организация работы персонала должна соответствовать требованиям действующего законодательства Российской Федерации.

Деятельность персонала Оператора ГИС должна регулироваться должностными инструкциями и инструкциями по охране труда.

Организационно-штатная структура служб эксплуатации отдельной ГИС определяется Оператором ГИС в соответствии с организационно-распорядительными документами и с учетом требований к численности и квалификации персонала, указанных в проектной документации на ГИС.

3. Процессы эксплуатации

В рамках эксплуатации ГИС осуществляются следующие процессы:

Основные процессы:

\cdot Управление инцидентами;

\cdot Управление проблемами;

\cdot Управление изменениями;

\cdot Резервирование и восстановление данных.

Вспомогательные процессы:

\cdot Мониторинг системы;

\cdot Управление доступностью и непрерывностью.

По всем процессам в качестве отчетного периода рекомендуется использовать календарный месяц.

3.1. Управление инцидентами

3.1.1. Описание и цели процесса управления инцидентами

Инцидентом является любое событие, выходящее за рамки штатной работы, ГИС, прямо, косвенно или потенциально ведущее к остановке процессов ГИС или негативно отражающееся на качестве функционирования ГИС.

Управление инцидентами включает в себя процесс скорейшего восстановления нормального функционирования ГИС и минимизацию воздействия инцидентов на автоматизированные процессы в ГИС.

3.1.2. Целевые метрики качества предоставления услуг по сопровождению ГИС

Для оценки эффективности процесса управления инцидентами рекомендуется использовать следующие метрики:

3.1.3. Требования к составу и квалификации рабочей группы по управлению инцидентами

Пример минимальных требований к составу и квалификации рабочей группы приведены в таблице 1. Конечный состав группы для конкретных ГИС определяется на этапе передачи ГИС в эксплуатацию и должен позволять обеспечивать выполнение целевых метрик качества предоставления услуг по сопровождению системы.

Таблица 1

3.1.4. Рекомендации по организации процесса управления инцидентами

Рекомендации по организации процесса управления инцидентами установлены в разделе 3 регламента организации сопровождения.

3.2. Управление проблемами

3.2.1. Описание и цели процесса управления проблемами

Проблема — это неизвестная основная причина возникновения одного или нескольких инцидентов.

Управление проблемами — это процесс выявления причин инцидентов и управления этими причинами.

Целью процесса управления проблемами является предупреждение появления проблем, устранение причин появления повторяющихся инцидентов и минимизация влияния инцидентов, которые не могут быть предупреждены.

Процесс управления проблемами носит как реактивный, так и проактивный характер. Первый относится к разрешению проблем, связанных с уже возникшими инцидентами, второй направлен на выявление и устранение проблем, способных привести, но пока не приведших к возникновению инцидентов.

3.2.2. Целевые метрики качества организации процесса управления проблемами

Для оценки эффективности процесса управления проблемами рекомендуется использовать следующие метрики:

3.2.3. Требования к составу и квалификации рабочей группы по управлению проблемами

Минимальные требования к составу и квалификации рабочей группы приведены в таблице 2. Конечный состав группы для конкретных ГИС определяется на этапе передачи ГИС в эксплуатацию и должен позволять обеспечивать выполнение целевых метрик качества предоставления услуг по управлению проблемами.

3.2.4. Рекомендации по организации процесса управления проблемами

Рекомендации по организации процесса управления проблемами описаны в разделе 4 регламента организации сопровождения.

3.3. Управление изменениями

3.3.1. Описание и цели процесса управления изменениями

Изменение - это добавление, изменение или удаление любых элементов, которое может прямо или косвенно повлиять на функционирование ГИС.

Управление изменениями - это процесс организации работ по внесению изменений в эксплуатируемые ГИС на Платформе "ГосТех".

Целями процесса управления изменениями является:

\cdot обеспечение гибкости изменений ГИС на Платформе "ГосТех", связанных с изменениями бизнес-процессов, в соответствии с требованиями законодательства Российской Федерации, внутренних и внешних контролирующих органов;

\cdot обеспечение прозрачности процесса планирования изменений ГИС;

\cdot обеспечение требуемых сроков реализации изменений ГИС в части устранения ошибок функциональности.

3.3.2. Целевые метрики качества процесса по управлению изменениями

Для оценки эффективности процесса по управлению изменениями рекомендуется использовать следующие метрики:

3.3.3. Требование к составу и квалификации рабочей группы по управлению изменениями

В рамках процесса управления изменениями между участниками процесса закреплены следующие роли в соответствии с таблицей 3.

3.3.4. Рекомендации по организации процесса управления изменениями

Рекомендации по организации процесса управления изменениями описаны в разделе 5 документа регламента организации сопровождения.

3.4. Резервирование и восстановление данных

3.4.1. Описание и цели процесса "Резервирование и восстановление"

Резервное копирование - процесс создания копии данных на носителе, предназначенном для восстановления данных в оригинальном или новом месте их расположения в случае их повреждения или разрушения.

Целями процесса являются:

\cdot установление единых правил и требований к времени восстановления системы из резервной копии к процессу управления резервным копированием и восстановлением из резервной копии;

\cdot разграничение прав и обязанностей между участниками процесса;

\cdot установление требований к выполнению процесса резервного копирования;

\cdot установление требований к выполнению процесса восстановления из резервной копии;

\cdot установление требований к проведению контроля резервного копирования и восстановлению из резервной копии.

3.4.2. Целевые метрики качества процесса "Резервное копирование и восстановление"

Для оценки качества процесса "Резервирование и восстановление" рекомендуется использовать следующие метрики:

3.4.3. Рекомендации по организации процесса "Резервное копирование и восстановление"

Рекомендации по организации процесса резервного копирования и восстановления приведены в разделе 1 - 3 регламента резервного копирования, который входит в рекомендуемые шаблоны обязательных документов.

3.5. Мониторинг системы

3.5.1. Описание и цели процесса "Мониторинг системы"

Мониторинг системы - это набор действий, позволяющий наблюдать за функционированием ГИС и осуществляемый с целью получения информации о функционировании критической инфраструктуры, систем, приложений, сетевых служб, использования системных ресурсов (системные журналы, процессоры), управления событиями и тенденциями.

Мониторинг можно разделить на:

\cdot Реактивный мониторинг - целью которого является оперативное обнаружение сбоев с одновременным указанием источника проблемы и возможностью информирования о ней конкретных людей или систем.

\cdot Проактивный мониторинг - основан на анализе собранных данных и его целью является прогнозирование возможных аварий и сбоев компонентов ГИС, что позволяет превентивно предпринять необходимые действия для предотвращения нежелательных событий в будущем.

В целях организации мониторинга ГИС должна быть составлена технологическая карта, включающая в себя перечень технических и технологических показателей, подлежащих инфраструктурному и функциональному мониторингу и характеризующих качество функционирования ГИС, а также целевые значения показателей мониторинга для режима штатного функционирования и граничные значения показателей для двух уровней нештатных режимов с уровнем критичности "Средняя" и "Высокая".

Для нештатных режимов функционирования должны быть прописаны инструкции с описанием перечня мероприятий для восстановления штатного режима функционирования.

3.5.2. Рекомендации по организации мониторинга производительности ГИС

1. Определение списка критичных операций в ГИС, которые необходимо отслеживать.

2. Определение целевого времени отклика по каждой из критических операций.

3. Проведение замеров времени выполнения каждой операции для получения реальной статистики по ГИС при штатной нагрузке.

4. Анализ и интерпретация полученных результатов с целью установления целевых показателей производительности ГИС.

Для каждой ГИС должен быть определен набор показателей с граничными значениями.

Пример карты мониторинга ГИС:

Под временем реакции (отклика) понимается время между действием Пользователя и выводом на экранную форму любого служебного сообщения.

3.5.3. Рекомендации по организации процесса мониторинга

Система мониторинга для конкретных ГИС должна быть настроена с учетом специфики ППО и соответствовать следующим минимальным требованиям:

\cdot размещение ключевых компонентов системы мониторинга на отдельной от ГИС инфраструктуре;

\cdot надежность, функционал периодических проверок корректной работы системы мониторинга на основании эталонных данных;

\cdot простота и гибкость сведения данных и получения подробного вывода отчетов, а также возможность объединять данные и получать более подробную информацию о тех или иных областях мониторинга;

\cdot эффективная стратегия сохранения истории. Возможность определения типичных шаблонов сбоев, возможность анализа предыдущих данных за произвольный период. Рекомендуемый период сохранения данных - 1 год;

\cdot возможность корреляции факторов из разных источников;

\cdot простота добавления новых метрик или инфраструктур;

\cdot гибкая система оповещений: эта система должна обеспечивать отправку уведомлений по различным каналам в зависимости от приоритета события и условий.

3.6. Управление доступностью и непрерывностью

3.6.1. Описание и цели процесса управления доступностью и непрерывностью

Управление доступностью - процесс, отвечающий за определение, анализ, планирование, измерение и улучшение всех аспектов доступности услуги. Управление доступностью отвечает за то, чтобы вся инфраструктура, процессы, средства, роли и т.д. соответствовали согласованным Целевым показателям уровня услуги в части Доступности. Взаимосвязь процессов при управлении доступностью приведена на рисунке 1.

Мониторинг и отчетность по доступности - организация процесса сбора данных мониторинга и формирование отчетов по показателям доступности. Перечень и состав аналитик для каждой ГИС определяется отдельно.

Расследование недоступности - организация процесса расследования причин возникновения по каждому зафиксированному случаю недоступности. Состав рабочих групп по расследованию причин нарушений доступности разрабатывается индивидуально для каждой ГИС.

Внедрение дополнительных процессов проактивного управления позволит повысить отказоустойчивость системы.

Оценка рисков - организация процесса анализа причин возникновения и прогнозирование случаев потенциального возникновения случаев недоступности.

Реализация контрмер - комплекс мероприятий по предотвращению/минимизации рисков возникновения случаев недоступности.

Проектирование услуг с точки зрения доступности - комплекс мероприятий по оценке рисков возникновения причин недоступности на этапе проектирования ГИС.

Тестирование механизмов обеспечения доступности - комплекс мероприятий, направленный на минимизацию рисков возникновения случаев недоступности на уровне архитектурной проработки ГИС.

Оценка и совершенствование - процесс оценки результатов мероприятий предотвращения случаев возникновения недоступности и реализации новых инструментов снижения рисков таких случаев.

Управление непрерывностью - процесс, предусматривающий идентификацию потенциальных угроз и их воздействия на деятельность ГИС, который создает основу для повышения устойчивости ГИС к инцидентам прерывания деятельности.

В задачи управления непрерывностью входит минимизация ущерба, вызванного недоступностью функциональности.

Целью процесса является обеспечение гарантированного восстановления инфраструктуры, необходимой для продолжения функционирования ГИС в случае чрезвычайной ситуации.

Процесс управления непрерывностью обеспечивает анализ и управление рисками и позволяет организации постоянно поддерживать функционирование минимально допустимых производственных мощностей. Данный процесс помогает уменьшить степень риска до приемлемого уровня и разработать планы восстановления процессов на случай их повреждения во время чрезвычайной ситуации.

3.6.2. Целевые метрики качества процесса управления доступностью и непрерывностью

Для оценки качества процесса "Управление доступностью и непрерывностью" рекомендуется использовать следующие метрики:

3.6.3. Требования к составу и квалификации рабочей группы процесса управления доступностью и непрерывностью

Пример рекомендуемых минимальных требований к составу и квалификации рабочей группы приведены в таблице 4.

3.6.4. Рекомендации по организации процесса управления доступностью и непрерывностью

Для организации процесса необходимо обеспечить выполнение следующих задач:

\cdot Формирование и поддержка актуального плана мощностей, который отражает текущие и будущие потребности ГИС;

\cdot Предоставление консультаций и рекомендаций для смежных систем по вопросам доступности и непрерывности;

\cdot Обеспечение согласованного уровня доступности услуг за счет управления услугами и ресурсами, связанными с эксплуатацией;

\cdot Оказание помощи в диагностике и разрешении инцидентов и проблем, связанных с доступностью и непрерывностью;

\cdot Обеспечение оценки воздействия всех изменений плана доступности и непрерывности на потенциал всех служб и ресурсов;

\cdot Активный контроль принимаемых мер по улучшению доступности и непрерывности ГИС.

Приложение 1

1. Перечень используемых терминов и сокращений

В настоящем документе применены следующие сокращения:

В настоящем документе применены следующие термины и сокращения с соответствующими определениями:

1.1 Цель документа

Настоящий регламент содержит рекомендации по организации сопровождения и технического обслуживания ГИС на Платформе "ГосТех".

Целью разработки рекомендаций является определение функций и статуса рабочих групп - участников процесса сопровождения в ходе эксплуатации ГИС на Платформе "ГосТех".

1.2 Область применения

Настоящий регламент определяет функции и статус участников процесса сопровождения в ходе эксплуатации ГИС на Платформе "ГосТех".

2. Цель процесса

Процесс сопровождения ГИС - процесс, целью которого является обеспечение корректного и бесперебойного функционирования ГИС, удобство ее использования и поддержка Пользователей.

2.1 Участники процесса

В процессе сопровождения ГИС участвуют следующие участники:

\cdot Заказчик ГИС;

\cdot Пользователь;

\cdot Оператор ГИС;

\cdot Оператор Платформы "ГосТех";

\cdot Оператор промышленной среды ГИС;

\cdot Разработчик ГИС.

Контактная информация уполномоченных представителей рабочих групп - участников процесса сопровождения ГИС приведена в отдельном приложении к настоящему регламенту.

2.2 Функции участников процесса

В рамках процесса сопровождения и технического обслуживания ГИС можно выделить следующие обобщенные функции участников процесса:

\cdot оперативная поддержка Пользователей - поддержка Пользователей ГИС, в случае возникновения у них проблем с доступом или функционированием ГИС;

\cdot восстановление работоспособности - оперативное устранение нештатных ситуаций, повлекших ухудшение качества предоставляемых ГИС сервисов или их прерывание;

\cdot регламентное обслуживание и администрирование ГИС - выполнение работ, определенных в требованиях производителей компонентов ГИС; выполнение процедур администрирования программных и аппаратных компонентов;

\cdot обеспечение заданного уровня сопровождения - обеспечение соответствия текущего качества предоставляемых услуг по сопровождению ГИС, требованиям, определенным в договорах между Заказчиком ГИС и Оператором ГИС.

Развитие системы - осуществление функций по доработке ГИС вследствие появившихся требований по изменению текущего и разработке нового функционала ГИС.

2.3 Взаимодействие участников процесса

Реализация функций по сопровождению ГИС обеспечивается путем взаимодействия рабочих групп - участников процесса. В таблице 1 приведен возможный шаблон матрицы, характеризующей участие рабочих групп в процессах, и функции рабочих групп при взаимодействии. В матрице указываются рабочие группы, взаимодействующие между собой в ходе выполнения обобщенных функций процесса. Если рабочая группа осуществляет взаимодействие с другими рабочими группами в ходе выполнения обобщенной функции процесса, то ячейка, находящаяся на пересечении столбца рабочей группы и строки соответствующей обобщенной функции, заполняется символом "X" и выделяется серым цветом. В ином случае ячейка не заполняется.

Таблица 1

Пример матрицы взаимодействия рабочих групп

Участники процесса

ФОИВ (Заказчик ГИС)

3.1 Основные цели процесса управления инцидентами

3.2 Основные цели администрирования ГИС

3.3 Основные цели сопровождения приложений

\cdot тестирование и документирование новой и (или) измененной функциональности.

3.4 Основные цели управления компетенциями

\cdot консультирование пользователей по приложениям и процессам;

\cdot проведение обучения по требованию Заказчика.

3.5 Основные цели ведения НСИ

\cdot ведение нормативно-справочной информации во всех системах учета по заявкам Конечных пользователей;

\cdot ведение иерархий признаков в многомерных структурах данных.

3.6 Порядок оказания услуг

Услуги оказываются на территории Исполнителя и/или на иных территориях, согласованных Сторонами. Место выполнения конкретных услуг согласовывается в рабочем порядке между Сторонами.

Время оказания услуг по сопровождению определяется договором на сопровождение конкретной ГИС между Заказчиком ГИС и Оператором ГИС.

Перенос запросов в продуктивные системы осуществляется в вечернее время (после 22:00) для минимизации ошибок, возникающих у пользователей. Перенос запросов после окончания рабочего времени, а также в выходные и праздничные дни возможен по дополнительному запросу от Заказчика ГИС.

Исполнитель самостоятельно определяет необходимость и объем привлекаемых для оказания услуг специалистов с учетом требований методических рекомендаций по эксплуатации.

Все сроки, касающиеся обработки обращений, действительны только во время предоставления услуг.

Услуги оказываются на основе направляемых пользователями заявок.

Услуги сопровождения оказываются Исполнителем в рамках принятой на сопровождение функциональности.

Принятой на сопровождение функциональностью является функциональность ГИС, переданная Исполнителю и принятая Исполнителем в сопровождение по результатам проектных работ, исполняемых третьей Стороной.

Минимальный пакет эксплуатационной документации, необходимый для передачи ГИС в эксплуатацию, должен включать в себя:

\cdot техническое задание на разработку;

\cdot регламент эксплуатации ГИС;

\cdot инструкции пользователей ГИС;

\cdot руководство системного администратора (приложений/БД);

\cdot руководство по установке программных средств ГИС;

\cdot регламент управления доступностью и непрерывностью;

\cdot технологическая карта мониторинга;

\cdot регламент резервного копирования;

\cdot акт приема передачи ГИС Заказчику ГИС.

Указанный состав документов для конкретной ГИС может быть расширен в соответствии с требованиями соответствующего договора.

3.7 Подача и прием заявок, регистрация и решение обращений

Заявки на оказание услуг, предусмотренных Договором, могут быть поданы Исполнителю следующими способами:

• через СОЗ Исполнителя (приоритетный);
• по электронной почте (резервный);
• по телефону (резервный).

Способы подачи заявок приведены в таблице 2.

Таблица 2

Способы подачи заявок

При получении письма осуществляется автоматическая регистрация обращений в СОЗ.

На почту заявителя отправляются уведомления:

1. ответное письмо с номером и временем регистрации обращения;

2. назначение заявки на специалиста службы сопровождения с временем назначения и ФИО специалиста;

3. посредством телефонного звонка (резервный).

Оператор службы сопровождения регистрирует запрос в СОЗ на основании телефонного звонка заявителя. По окончании регистрации оператор сообщает заявителю номер зарегистрированного обращения. СОЗ отправляет на почту заявителя ответное письмо с уведомлением о регистрации обращения.

В случае, когда со слов заявителя диагностировать проблему невозможно или общение по телефону при регистрации запроса длится более трех минут, оператор службы сопровождения вправе запросить заявителя переслать подробную информацию по возникшей проблеме через СОЗ.

Время обработки заявки и создания на ее основе обращения не должно превышать 10 минут.

Заявки на оказание услуг принимаются от сотрудников Заказчика, в соответствии с функциональным и организационным объемом оказания услуг. В случае поступления заявки от Заявителя, не зарегистрированного на корпоративных почтовых серверах, такая заявка может быть отклонена.

Требования к информации, отраженной в обращении/запросе:

• указаны ФИО, организация, адрес рабочей электронной почты, контактный телефон Заявителя.

Требования к заявителю, соответствие которым необходимо для обработки обращения:

• имеет действующую учетную запись в ГИС с необходимыми полномочиями;
• имеет сконфигурированное рабочее место, с которого производится доступ в систему через работоспособную телекоммуникационную инфраструктуру.

Работоспособность системно-технических средств Платформы "ГосТех" находится вне зоны ответственности Исполнителя.

После получения обращения Исполнитель обязуется обработать зарегистрированное обращение согласно порядку обработки обращений и в сроки, удовлетворяющие SLA. Исполнитель обязуется решить не менее 97% обращений/заявок от общего количества, поступивших в отчетный период, решенных в пределах крайнего срока (см. п.п. 3.8). Исполнение данного параметра ежемесячно отслеживается по отчетам из системы управления инцидентами и стандартными запросами. Формат отчета предварительно согласуется, при нарушении данного параметра Заказчик вправе применить штрафные санкции.

Процесс обработки заявок, относящихся к событиям информационной безопасности, должен быть описан в отдельном документе.

3.8 Категоризация и приоритизация заявок

Каждой заявке Исполнителем присваивается определенный приоритет. Присвоенный приоритет определяет последовательность обработки сообщений.

Время реакции - это время, в течение которого сотрудник СТП Исполнителя обязан на основании данных, указанных в обращении определить приоритет и группу ответственных за решение исполнителей от СТП. По факту назначения обращения на группу исполнителей СОЗ Исполнителя автоматически отправляет Заявителю информационное письмо с вышеуказанной информацией.

Время окончания решения обращения определяется по времени отсылки Заявителю решения из СОЗ.

Время решения обращения определяется как разность моментов регистрации и окончания исполнения обращения, за вычетом времени ожидания от Заявителя дополнительной информации, необходимой для исполнения обращения и не рабочего времени Пользователя ГИС. Время окончания решения обращения определяется по времени отсылки Заявителю решения из СОЗ.

Время решения обращения определяется как разность моментов окончания и начала исполнения обращения, за вычетом времени ожидания от Заявителя дополнительной информации, необходимой для исполнения обращения и не рабочего времени Пользователя ГИС. Рабочее время Пользователя ГИС принимается с 09:00 до 18:00 по местному времени (но не более чем с 02:00 до 19:00 по UTC+3). Целевые показатели процесса обработки обращений приведены в таблице 3.

Окончательное закрытие обращения должно происходить только после того, как от Пользователя ГИС, сообщившего об инциденте, получено подтверждение, что этот инцидент устранен, и предоставление услуги восстановлено. В случае отсутствия подтверждения или замечаний Пользователя ГИС в течение трех рабочих дней обращение считается закрытым.

Для достижения целей и задач деятельности по ОКАиРКИ, связанные с информационными ресурсами Платформы "ГосТех", в обязанности Исполнителя входит предоставление доступа к СОЗ и системе мониторинга, для получения необходимой информации о функционировании ГИС, ответственным за обеспечение информационной безопасности ГИС кроме сведений ограниченного доступа.

Приоритизация инцидентов осуществляется на основе таблицы 4 всех компонентов ГИС, для каждого из которых должен быть определен уровень критичности. Например, уровни 1 и 2.

3.9 Требования к процессам предоставления услуг

3.9.1 Общие требования к каталогу услуг

3.9.2 Состав и содержание услуг

Таблица 6

Пример каталога услуг

Объем предоставляемых услуг указан в таблице 7.

Таблица 7

Объемы предоставляемых услуг

В состав услуг по сервису "Сопровождение приложений (уровень 3)" входят также трудозатраты на выработку подходов и методов реализации, а также документирование соответствующих изменений. Услуга оказывается по обращениям Пользователей, после согласования куратором каждой из сопровождаемых систем или ответственным лицом по Договору.

Услуга сервиса "Сопровождение приложений (уровень 3)" относится к цифровым продуктам/системам и их компонентам/модулям, развернутым на базе Платформы "ГосТех", но также может применяться к работам, проводимым в рамках проектов, направленных на функциональное усовершенствование существующих систем, входящих в ГИС.

Процесс "Управления проблемами" определяет задачи, порядок регистрации и обработки проблем, а также устанавливает права и обязанности участников процесса.

Требования настоящего регламента являются обязательными для исполнения всеми участниками процесса.

4.1 Основные цели процесса управления проблемами

Цель процесса "Управление проблемами" - это предотвращение возникновения проблем и инцидентов путем выявления повторяющихся инцидентов и минимизации отрицательного воздействия инцидентов, которые нельзя предотвратить.

4.2 Роли участников процесса "Управление проблемами"

4.3 Взаимосвязь с другими процессами

4.4 Описание процесса

Процесс "Управление проблемами" включает действия, необходимые для идентификации и классификации проблем, диагностики основной причины инцидентов и определения способов устранения проблем.

Организация процесса управления проблемами включает операции, необходимые для предотвращения повторного возникновения или репликации инцидентов и известных ошибок и гарантирует, что:

\circ существующие и регулярно возникающие ошибки идентифицированы, документированы и отслеживаются;

\circ симптомы ошибок, постоянные или временные решения документируются;

\circ подаются ЗНИ с целью модификации инфраструктуры или внесения изменений в ГИС;

\circ предотвращается возникновение новых инцидентов, вызванных проблемами.

Процесс "Управление проблемами" состоит из следующих шагов (таблица 9):

Выявление и регистрация проблем;

Исследование, поиск решений и устранение проблем;

Проверка и закрытие проблем.

Таблица 9

Перечень шагов процесса управления проблемами

Рекомендуемые метрики процесса "Управление проблемами":

\cdot Средняя длительность устранения проблем за период;

\cdot Процент инцидентов, относящихся (вызванных) к проблемам, по отношению к общему количеству инцидентов за период;

\cdot Количество известных ошибок, вошедших в базу знаний.

Общая схема процесса "Управления проблемами" приведена на рисунке 2.

Рисунок 2. Общая схема процесса "Управление проблемами"

Входы процесса:

\circ Инциденты высокого и наивысшего приоритетов, массовые инциденты;

\circ Аналитический отчет по однотипным заявкам;

\circ Аналитический отчет по системным ошибкам;

\circ Информация от внешних источников о возможных проблемах (мониторинг, обходные решения, найденные в рамках процесса управления Инцидентами).

Выходы процесса:

\circ ЗНИ;

\circ Новые известные ошибки (создание статей в базе знаний).

Процесс управления проблемами включает следующие этапы:

\cdot регистрация, классификация и приоритизация проблем;

\cdot анализ и диагностика проблемы;

\cdot прогнозирование проблемы;

\cdot формирование временного решения;

\cdot разработка постоянного решения;

\cdot мониторинг актуальности решения проблемы;

\cdot закрытие проблемы;

4.4.1 Регистрация, классификация и приоритизация проблем

4.4.2 Классификация и назначение

\circ степень воздействия на работоспособность ГИС;

\circ срочность - допустимая задержка в решении проблемы;

\circ приоритет - показатель, объединяющий срочность, степень воздействия, риск и необходимые ресурсы;

\circ статус - например, проблема, известная ошибка и т.д.

Классификация не является статичной, она может меняться на протяжении жизненного цикла проблемы. Например, наличие обходного решения или быстрого решения позволит снизить срочность проблемы, в то время как регистрация новых связанных инцидентов может привести к изменению степени воздействия проблемы.

4.4.3 Анализ и диагностика проблемы

Анализ и диагностика проблемы - это процесс, целью которого является определение корневых причин возникновения проблемы и выработка подхода к ее решению.

4.4.4 Формирование решения проблемы

После определения причины проблемы, проблеме присваивается статус "Известная ошибка" и начинается поиск ее решения. Участники процесса определяют, что необходимо сделать для разрешения известной ошибки, сравнивают различные решения, принимая во внимание влияние проблемы на SLA, возможные издержки и выгоды. Все работы по выработке решения должны быть зафиксированы.

Возможные результаты процесса:

1. Обходное решение - относительно быстрое и простое решение проблемы, применяемое для срочного устранения ее последствий, но не влияющее на причины ее возникновения. Обходное решение обычно является временным, требующим в дальнейшем замены на окончательное, более полное. Обходные решения применяются в случаях, когда радикальное решение по какой-то причине не может быть применено вообще или требует слишком много времени для реализации. Обходное решение применяется для срочного закрытия инцидентов, связанных с проблемой, в период реализации срочного исправления.

2. Срочное исправление - в случае если обходное решение по проблеме не было найдено, и известная ошибка приводит к возникновению серьезных инцидентов, инициируется выполнение срочного исправления. Регистрируется ЗНИ с критичным приоритетом, обработка которого ведется в рамках процесса управления изменениями с учетом критичности.

3. ЗНИ - если по проблеме найдено обходное решение или в случаях, когда известная ошибка не приводит к возникновению серьезных инцидентов, регистрируется ЗНИ, обработка которого ведется в рамках процесса управления изменениями.

4.4.5 Закрытие проблемы

5. Управление Изменениями

Регламент управления изменениями описывает процесс выполнения работ по внесению изменений в эксплуатируемые ГИС на Платформе "ГосТех".

5.1 Основные цели процесса управления изменениями

\cdot обеспечение гибкости изменений ГИС на Платформе "ГосТех", связанных с изменениями бизнес-процессов, требованиями законодательства Российской Федерации, внутренних и внешних контролирующих органов;

\cdot обеспечение прозрачности процесса планирования изменений ГИС;

\cdot обеспечение требуемых сроков реализации изменений ГИС в части устранения ошибок функциональности.

5.2 Участники процесса управления изменениями

В рамках процесса управления изменениями (ЗНИ) между участниками процесса закреплены следующие роли и объединения:

\cdot Инициатор ЗНИ;

\cdot Менеджер по управлению изменениями;

\cdot Исполнитель (внешний или внутренний подрядчик, выполняющий работы для по внедрению изменений ГИС, являющийся специалистом 2-й или 3-й линии Сопровождения конкретной ГИС).

5.3 Основные этапы выполнения работ:

5.3.1 Инициирование ЗНИ

В рамках данного шага проводится формирование требований по корректировке одной или нескольких подсистем со стороны Пользователя систем, корреляция с другими требованиями, находящимися в общем объеме планируемых Изменений подсистем.

5.3.2 Планирование ЗНИ

В рамках данного шага проводится планирование последовательности проведения изменений, осуществляется приоритизация ЗНИ, дополнительные уточнения по шагам работ с ЗНИ и т.п.

5.3.3 Оценка ЗНИ

В рамках данного шага проводится настройка и реализация ЗНИ на стороне Исполнителя с последующей передачей на тестирование реализованного функционала.

5.3.4 Передача ЗНИ в поддержку

В рамках данного шага проводится актуализация документации измененной или созданной при реализации ЗНИ функциональности. Базовые документы в ходе ЗНИ:

\cdot спецификация на реализацию;

\cdot результаты тестирования ЗНИ;

\cdot операционные инструкции пользователей;

\cdot операционные инструкции администратора ГИС, платформы.

5.3.5 Процедура управления ЗНИ

Описание процедуры управления ЗНИ приведено в таблице 10.

Таблица 10

Приложение 2

МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

В настоящем документе применены следующие термины и сокращения с соответствующими определениями:

1.1 Назначение регламента

Настоящий регламент устанавливает требования по оформлению обязательных эксплуатационных документов для ГИС на Платформе "ГосТех".

1.2 Регламент резервного копирования

Данный раздел содержит пример регламента резервного копирования. Для различных ГИС требования по резервному копированию могут различаться, поэтому допускается его пополнение.

1.3 Цели данного регламента

Настоящий регламент проведения резервного копирования и восстановления программ и данных разработан с целью:

\cdot определения порядка резервного копирования данных и ПО;

\cdot определения порядка восстановления информации из резервных копий при полной или частичной ее потере;

\cdot упорядочения работы должностных лиц, связанных с резервным копированием информации.

1.4 Описание системы резервного копирования

1.4.1 Объекты, подлежащие резервному копированию

Периодическому, планируемому резервному копированию могут подлежать объекты, содержащие следующие каталоги и файлы на серверах:

\cdot ОС хоста сервера;

\cdot Конфигурационные и рабочие каталоги системы;

\cdot Файлы СУБД;

\cdot Файлы БД:

Файлы данных;

Журналы БД;

Управляющие файлы БД;

Файлы данных табличных пространств;

Оперативные журналы регистрации транзакций;

Архивные журналы регистрации транзакций.

Объекты для каждой ГИС определяются исходя из архитектуры решения и должны быть достаточны для восстановления работоспособности ГИС на резервной площадке в плановые сроки.

2. Требования к системе резервного копирования

Требования, описанные в данном разделе, могут быть вынесены в отдельный документ, такой как политика резервного копирования, но обязательно должны учитываться:

\cdot Обеспечение возможности полного восстановления данных ППО.

\cdot Возможность восстановления состояния БД каждой из систем на любой момент времени в течение 30 календарных дней.

\cdot Резервное копирование объектов должно выполняться в автоматическом режиме.

\cdot СРК должна позволять запуск резервного копирования в автоматизированном и ручном режиме.

\cdot Резервное копирование объектов должно выполняться в режиме online.

\cdot СРК должна позволять запуск резервного копирования в режиме offline.

\cdot Регулярность проведения резервного копирования.

\cdot Минимальное время восстановления данных.

\cdot Резервное копирование должно проводиться во время минимальной загрузки системы.

\cdot Простота и надежность процедур резервного копирования и восстановления данных.

\cdot Для всех систем в ландшафте, в зависимости от объектов резервного копирования, должно применяться соответствующее, идентичное оборудование, типы носителей и программное обеспечение.

\cdot Для выполнения операций резервного копирования должно применяться программное обеспечение производителей, сертифицированных для выполнения резервного копирования.

\cdot СРК должна быть обеспечена инфраструктурой, не зависимой от основной.

\cdot Должны быть созданы альтернативные места хранения и обработки информации, включая отдельное аппаратное обеспечение (процессоры, память, устройства) и соответствующее программное обеспечение.

2.1 Режимы, типы и методы выполнения резервного копирования

Режим резервного копирования, осуществляемого при работающей системе, называется online. При online резервном копировании система сохраняет доступность своих функций для пользователя.

Режим резервного копирования, для которого требуется остановка работающей системы, называется offline.

Тип резервного копирования может быть, как полным - выполняется полная копия данных, так и инкрементальное - выполняется копия только данных, изменившихся с момента последнего резервного копирования (полного или инкрементального).

Метод выполнения резервного копирования может быть:

\cdot автоматическим - резервное копирование выполняется по заранее заданному расписанию без участия администратора;

\cdot автоматизированным - резервное копирование выполняется с незначительным привлечением администратора, например, для планирования резервного копирования;

\cdot ручным - резервное копирование выполняется с привлечением и под наблюдением администратора.

2.2 Используемое программное обеспечение

Для резервного копирования и восстановления ОС хостов, файлов транспортной системы, а также рабочих каталогов платформы, ППО и СУБД используется следующее ПО:

\cdot 1 "Кибер Бэкап" (пример)

\cdot 2

\cdot 3

Для резервного копирования и восстановления БД используется следующее ПО:

\cdot 1 Кибер Бэкап" (пример)

\cdot 2

\cdot 3

2.3 Параметры резервного копирования объектов

При формировании параметров резервного копирования должны учитываться следующие показатели, определяемые для конкретной ГИС:

"Целевая точка восстановления" (RPO) - максимальный период времени и соответствующий объем данных, который допустимо потерять;

"Допустимое время недоступности" (RTO) - максимальное время, в течение которого ГИС может быть недоступной до момента восстановления без критических последствий.

В таблице 1 приведен пример параметров резервного копирования объектов.

3. Описание работ по резервному копированию объектов

3.1 Должностные лица и обязанности

Администратор СРК:

\cdot Осуществляет и участвует в первоначальной настройке механизма резервного копирования, для всех объектов резервного копирования, используя средства централизованной СРК;

\cdot Отвечает за мониторинг выполнения резервного копирования объектов: Конфигурационные и рабочие каталоги системы, Файлы транспортной системы, Файлы СУБД;

\cdot Проверка копий;

\cdot Контрольные восстановления;

\cdot Решает проблемы, связанные с работой СРК.

Администратор платформы:

\cdot Осуществляет первоначальную настройку механизма резервного копирования для объекта: ОС хоста сервера;

\cdot Отвечает за мониторинг выполнения резервного копирования объекта: ОС хоста сервера;

\cdot Осуществляет настройку и контроль работы ОС, решение проблем, связанных с работой ОС.

Администратор ППО:

\cdot Осуществляет первоначальную настройку механизма резервного копирования для объектов резервного копирования файлов БД и ППО;

\cdot Осуществляет контроль за корректностью выполнения резервного копирования файлов БД и ППО;

\cdot Решает проблемы, связанные с работой ППО.

Все Администраторы входят в состав соответствующих групп исполнителей в качестве специалистов 3-й линии Сопровождения конкретной ГИС.

Для выполнения своих должностных обязанностей Администраторы могут привлекать соответствующих должностных лиц при возникновении такой необходимости.

Группа администраторов с участием Заказчика и Руководителя службы сопровождения составляет план восстановления с учетом требований к доступности и непрерывности.

3.2 Организация взаимодействий должностных лиц

Администраторы выполняют работы в рамках своих должностных обязанностей (в соответствии с разделом 1) на основании заявок от уполномоченных лиц.

Для выполнения регулярных регламентных работ по резервному копированию оформление заявки не требуется.

При установке обновлений ОС, переходе на новые версии ПО, переконфигурировании ОС/ПО, а также после устранения возникших в СРК ошибок Администратор ПО или Администратор ОС направляет заявку на внеплановое резервное копирование на электронный адрес службы сопровождения СРК.

Реализация внеплановых работ Администратором СРК (Восстановление и внеплановое резервное копирование объектов) выполняется в ручном режиме на основании зарегистрированной в службе сопровождения СРК заявки от Администратора ПО или Администратора ОС.

3.3 Эскалация информации о проблемах

При обнаружении ошибок порядок действий Администраторов следующий:

\cdot При наличии ошибок, соответствующий Администратор принимает меры по устранению ошибки своими силами без влияния на работу функциональных систем платформы.

\cdot В зависимости от причин возникшей ошибки информация об ошибке (причинах ошибки) может быть эскалирована к другим Администраторам (в соответствии с разделом 3).

\cdot Если действия по устранению ошибок, а также их последствий, требуют остановки или ограничения в работе функциональных систем на базе платформы, то согласование возможности и времени проведения указанных действий эскалируется в адрес службы функционального сопровождения.

\cdot Если устранение ошибки повлекло восстановление системы или были устранены ошибки выполнения резервного копирования, то Администратором должно быть запланировано внеплановое резервное копирование объекта.

3.4. Резервное копирование объектов: ОС хоста сервера, Конфигурационные и рабочие каталоги ППО, Файлы транспортной системы, Файлы СУБД

Вся виртуальная машина резервируется в автоматическом режиме средствами СРК, включая объекты резервного копирования:

\cdot ОС хоста сервера;

\cdot Конфигурационные и рабочие каталоги ППО;

\cdot Файлы СУБД.

В процессе резервного копирования создаются четыре набора резервных копий:

\cdot Ежедневная копия (ежесуточно записывается инкрементальная копия, срок хранения - 7 дней с момента записи последней копии за неделю, копия хранится в СРК);

\cdot Недельная копия (еженедельно записывается полная копия, срок хранения - месяц, копия хранится в СРК);

\cdot Месячная копия (последняя недельная копия в месяце, срок хранения - год, копия хранится в специализированном хранилище);

\cdot Годовая копия (последняя месячная копия в году, срок хранения - 3 года, копия хранится в специализированном хранилище).

3.5 Резервное копирование объектов: Файлы БД

Файлы БД резервируются онлайн в автоматическом режиме в СРК, согласно разделу 2.3.

4. Описание работ по восстановлению объектов

В случае частичной или полной потери данных в системах, необходимо:

\cdot Определиться с объектами резервного копирования, подлежащими восстановлению.

\cdot Восстановить необходимые объекты, используя пункты 0, 0 данного документа.

4.1 Сопоставление объектов резервного копирования и видов серверов

Пример объектов резервного копирования, которые необходимо восстановить, приведен в таблице 2.

Таблица 2

Сопоставление объектов резервного копирования и видов серверов

4.2 Последовательность действий администраторов при восстановлении системы

\cdot Администратор СРК восстанавливает объекты резервного копирования, основываясь на документации ПО СРК и таблице 2 данного документа.

\cdot Администратор ОС проверяет корректность и полноту восстановленных объектов, запускает и проверяет работоспособность виртуальной машины сервера.

\cdot Администратор ПО проверяет корректность и полноту восстановленных объектов.

\cdot Администратор ПО, основываясь на табл. 2, принимает решение о необходимости восстановления объектов резервного копирования и при необходимости выполняет п. 4.3 или п. 4.4 настоящего документа.

\cdot Администратор ПО проверяет работоспособность восстановленной системы.

4.3. Порядок восстановления из резервной копии объектов: ОС хоста сервера, Конфигурационные и рабочие каталоги системы, Файлы транспортной системы, Файлы СУБД

Восстановление данных и приложений при полной или частичной их потере, вызванной сбоями или отказами аппаратного или программного обеспечения, ошибками пользователей, чрезвычайными обстоятельствами выполняется в ручном режиме Администратором СРК средствами ПО СРК на основании заявки от уполномоченных лиц служб Администратора ПО, Администратора ОС, Владельца ИС. При восстановлении можно восстанавливать как отдельные объекты резервного копирования, так и отдельные файлы в рамках объектов резервного копирования.

Администратор СРК восстанавливает объекты резервного копирования, основываясь на документации ПО СРК и Таблице 2 данного документа.

4.4 Порядок восстановления из резервной копии объекта: Файлы БД

Восстановление объекта "Файлы БД" выполняется после утраты файлов данных, контрольного файла БД. Восстановление объекта выполняется в ручном режиме Администратором ПО на основании заявки от уполномоченных сотрудников Владельца ИС.

Требования:

\cdot Объекты: ОС хоста сервера, Конфигурационные и рабочие каталоги системы, Файлы СУБД не были подвержены утрате/порче или уже восстановлены.

\cdot Объект "Файлы БД" должен иметь резервную копию.

4.5 Порядок внесения изменений

Изменения в настоящий документ вносятся при необходимости отразить в нем изменения, в части объектов резервного копирования, методик резервного копирования и восстановления, организации работ, описываемых в документе.

Инициатором изменений может быть любая сторона, участвующая в согласовании документа.

5. Руководство администратора ГИС

5.1 Введение

Документ Руководство администратора должен содержать все сведения, достаточные для установки, запуска, поддержки и остановки системы, требования к окружению, методы поиска и диагностики неисправностей.

Документ кратко описывает общие функции системы, полный перечень компонентов, логическую схему.

Отдельно документ должен описывать:

\cdot ППО:

\cdot Описание языка/ов разработки и методов взаимодействия.

\cdot СПО:

\cdot библиотеки и фреймворки, используемые ППО для обработки

информации;

\cdot пакеты ПО, служащие для обеспечения функционирования прикладной

подсистемы;

\cdot пакеты ПО, предназначенные для обеспечения функций управления и

эксплуатации прикладной подсистемы;

\cdot пакеты ПО, используемые для построения инфраструктурных сервисов

(аутентификация/авторизация, службы каталогов и пр.);

\cdot скрипты, разрабатываемые для управления, автоматизации и

мониторинга ППО ИС;

\cdot БПО:

\cdot ПО системы виртуализации;

\cdot ОС виртуальных машин;

\cdot системы мониторинга;

\cdot сервисы БД.

Отдельно стоит выделить и описать основные взаимодействия системы с другими ГИС.

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;

}

}

\cdot Перезапустите nginx:

service nginx restart

После выполненных действий nginx начнет отдавать фронт PORTAL по адресу http://10.10.1.2

Остановка

Для остановки сервиса необходимо остановить веб-сервер Nginx:

service nginx stop

Проверка работоспособности

Для проверки работоспособности сервиса необходимо проверить, запущен ли веб-сервер Nginx:

service nginx status

Тестирование

Описание финальных тестов (юнит и интеграционное тестирование). Далее описание механизмов логирования. Процесса обновлений (если инструкция не поставляется вместе с обновлениями).

5.4 Диагностика, поиск и устранение неисправностей

Это основной рабочий раздел для администраторов, который описывает основные контрольные точки системы, рекомендации по мониторингу.

Пример краткой таблицы контрольных точек:

\cdot Контрольные точки и методы для поиска неисправностей

6. Инструкция по развертыванию системы

6.1 Общее описание

Документ описывает корректный пошаговый процесс проверки предварительных условий, подготовки и развертыванию ГИС. Основные этапы развертывания системы (могут быть разбиты на более мелкие):

\cdot проверка предварительных условий;

\cdot подготовка к установке;

\cdot настройка окружения;

\cdot установка ППО.

6.2 Проверка предварительных условий

В разделе описываются требования к средам виртуализации (если используется), каналам связи, подсистемам резервного копирования и мониторинга.

Ниже представлен пример:

Характеристики каналов связи основного ЦОД представлены в таблице.

Таблица

Состав каналов связи основного ЦОД

6.3 Подготовка к установке

Дополнительно можно составить адресный список всех виртуальных машин. Требования к организации внешнего доступа, если таковой предусмотрен.

6.4 Настройка окружения

В данном разделе описываются требования к настройке СПО и ППО.

Пример необходимого описания:

Чтобы настроить ОС:

\cdot На сервера приложений добавьте пользователя xx и разрешите исполнение программ от его имени в СКЗИ.

\cdot Добавьте пользователей с тем же uid и gid, что и пользователь xx, выполнив команду:

useradd -ou xxx -g yyy zzz,

где xxx - uid пользователя xx; yyy - gid пользователя xx, zzz - имя нового пользователя.

\cdot Отключите SELinux. В файле /etc/selinux/config всех ВМ укажите SELINUX=disabled и перезагрузите ВМ.

\cdot Чтобы избежать длительных задержек на сервере RabbitMQ при подключении клиентов, убедитесь, что библиотека resolver в файле /etc/resolv.conf настроена верно, и производится как прямое разрешение имени хоста, так и обратное - адреса сетевого интерфейса. Для серверов внешнего и внутреннего контура указаны соответствующие сервера DNS:

nameserver <ip основного DNS>;

nameserver <ip дополнительного DNS>.

\cdot Отключите сервис NetworkManager для всех ВМ:

systemctl stop NetworkManager

systemctl disable NetworkManager.

\cdot На серверах приложений внутреннего контура выставьте в файле /etc/sysctl.conf параметр net.ipv4.tcp_tw_reuse=1.

\cdot nginx-mod-http-xslt-filter-1.16.1-2.el7.x86_64.rpm

\cdot nginx-mod-mail-1.16.1-2.el7.x86_64.rpm

\cdot nginx-mod-stream-1.16.1-2.el7.x86_64.rpm

1 Установка ГИС

Раздел детально описывает процесс установки и настройки всех компонентов и подсистем ГИС.

Пример описания на основе установки Kafka

Установка Kafka на example-kafka-server

\cdot Состава, последовательности и длительности технологических операций, выполняемых в ходе работ;

\cdot Ответственных Исполнителей и лиц, выполняющих технический надзор за проведением технологических операций;

\cdot Процедуры проверки работоспособности Системы после завершения работ;

\cdot Процедуры возврата Системы к исходному состоянию в случае неуспешного проведения работ.

Пример карты и ее заполнения:

Технологическая карта

На проведение работ по <1>: установке обновления подсистемы Подсистема1

Технологическая площадка: ТП N 3

Условия проведения работ (в рамках технологического окна, тех. окно не требуется):

в рамках технологического окна

Характер работ: с перерывом в работе сервисов

Причина проведения работ <3>: письмо ДИТ от ... ...

Планируемая дата/время проведения работ (начало, окончание): дд.мм.гггг, чч:мм - чч:мм

Планируемая дата/время перерыва в работе сервисов: дд.мм.гггг, чч:мм - чч:мм

Ответственный за проведение работ: ФИО

Дата последнего резервного копирования серверов БД: дд.мм.гггг

Дата последнего резервного копирования серверов приложений и прочих: дд.мм.гггг

Перечень недоступных в период выполнения работ подсистем и сервисов.

<1> Указывается суть работ, включая наименование Системы, подсистемы, компонента или оборудования.

<2> Указывается: "с перерывом в работе сервисов" или "без перерыва в работе сервисов".

<3> Указывается ссылка на пункт регламента эксплуатации Системы, реквизиты письма, номер заявки в АС ТП, прочие причины, определяющие необходимость работ.

В рамках выполнения процедур проведения технологических работ Администратор ПО, в зоне ответственности которого проводятся технологические работы, направляет уведомление о предстоящих работах согласно Листу рассылки, закрепленному в Регламенте технической поддержки Системы:

\cdot не позднее чем за четыре часа до планируемого времени начала работ, в случае если в ходе технологических работ возникает перерыв в доступности сервисов СМЭВ;

\cdot не позднее чем за два часа до планируемого времени начала работ во всех остальных случаях.

Общий контроль над проведением технологических работ осуществляет Начальник дежурной смены СТП. В рамках выполнения процедур проведения технологических работ Администратор:

\cdot уточняет готовность специалистов к проведению работ;

\cdot регистрирует рабочее задание на проведение работ в СТП;

\cdot осуществляет контроль сроков проведения работ;

\cdot направляет уведомления о продлении, завершении.

8. Шаблон заявки на переработку (модификацию) программного обеспечения

Раздел содержит пример шаблона заявки на изменение (модификацию) программного обеспечения. План должен быть разработан для каждой ЗНИ отдельно.

Пример шаблона заявки:

Заявка N _____________________ ЗНИ N __________________ (Директор ИТ) _____________________ (Аккаунт)

ЗАЯВКА на изменение (модификацию) программного обеспечения

2. Заказчик.

Пользовательские требования:

a. Как задача решается в настоящее время.

b. Как задача должна решаться.

Заказчик:

_________________________  _______________________  _______________________
       (должность)                (подпись)                  (ФИО)

                                                _______________________
                                                         (дата)

_________________________  _______________________  _______________________
       (должность)                (подпись)                  (ФИО)

                                                _______________________
                                                         (дата)
Функциональный директор:

_________________________  _______________________  _______________________
       (должность)                (подпись)                  (ФИО)

                                                _______________________
                                                         (дата)