Формуляр¶

Полное наименование: Центральный модуль управления данными и распределёнными вычислениями Обозначение: LPI-VAP-CORE Краткое наименование (для работы с документом): «Центральный модуль» Программный продукт: «Vizorlabs Platform 4.0» («Визорлабс Платформа 4.0») Стандарт: ГОСТ 19.501-79

Титульный лист и лист утверждения¶

Таблица — Реквизиты титульного листа.

Подписи оформляются при выпуске утверждаемой редакции документа.

Таблица — Лист утверждения.

1. Общие указания¶

1.1. Введение¶

Центральный модуль управления данными и распределёнными вычислениями (LPI-VAP-CORE) — компонент программного продукта «Vizorlabs Platform 4.0», предназначенный для централизованного ведения данных видеоаналитики, организации распределённой обработки видеопотоков и отдельных кадров, регистрации событий и нарушений и представления результатов пользователю.

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

Назначение, функции, логическая структура, технические средства и данные компонента приведены в описании программы; порядок развёртывания и обслуживания — в руководстве администратора; порядок работы пользователя — в руководстве пользователя.

1.2. Порядок ведения формуляра¶

1. Формуляр заполняется предприятием-изготовителем при выпуске поставки и передаётся заказчику вместе с изделием.
2. В ходе эксплуатации записи в разделы 6–11 вносит ответственное лицо, назначенное заказчиком.
3. Каждая запись содержит дату, содержание записи, должность, фамилию и подпись лица, внёсшего запись.
4. Формуляр хранится вместе с эксплуатационной документацией на изделие в течение всего срока его эксплуатации.
5. При утрате формуляра оформляется дубликат в порядке, принятом у заказчика, с отметкой «Дубликат» и восстановлением записей по имеющимся документам.

2. Общие сведения¶

2.1. Наименование и обозначение изделия¶

Таблица 2.1.1 — Наименование и обозначение изделия.

2.2. Предприятие-изготовитель¶

Таблица 2.2.1 — Сведения о предприятии-изготовителе.

2.3. Дата выпуска¶

Таблица 2.3.1 — Даты выпуска и ввода в эксплуатацию.

2.4. Гарантийные обязательства¶

Гарантийные обязательства установлены техническим заданием на поставку программного обеспечения (раздел «Объём и сроки гарантий качества») и Регламентом гарантийного обслуживания — приложением 4 к нему. Условия гарантийного обслуживания приведены в таблице 2.4.1.

Таблица 2.4.1 — Гарантийные обязательства.

2.4.1. Порядок обращения за гарантийным обслуживанием¶

Таблица 2.4.2 — Порядок обращения за гарантийным обслуживанием.

2.4.2. Классификация инцидентов и допустимая длительность выполнения¶

Таблица 2.4.3 — Классификация влияния инцидентов и допустимая длительность выполнения.

Длительность выполнения указана без учёта времени устранения проблем инфраструктурного уровня. Инциденты влияния 1 и 2 обрабатываются ежедневно в круглосуточном режиме, инциденты влияния 3 и 4 — пять рабочих дней в неделю, за исключением выходных и праздничных дней.

Качество гарантийного обслуживания оценивается получателем по отчётным периодам: 18 отчётных периодов по 60 календарных дней (последний — 75 календарных дней), для каждого из которых Регламентом установлено допустимое время внеплановой недоступности, накапливаемое с начала гарантийного периода. Инциденты, решённые обходным путём, при оценке не учитываются; инциденты, вызванные проблемами инфраструктуры или стороннего программного обеспечения получателя, выносятся за расчёт.

2.4.3. Случаи, на которые гарантийные обязательства не распространяются¶

1. Несоответствие оборудования, операционной системы, системного программного обеспечения или сетевой инфраструктуры получателя требованиям раздела 3 настоящего формуляра и эксплуатационной документации изделия.
2. Внесение изменений в изделие получателем или третьими лицами без письменного согласования с изготовителем.
3. Наступление обстоятельств непреодолимой силы: пожары, аварии, сбои электропитания, отказы локальной вычислительной сети и подобные события.

3. Основные характеристики¶

3.1. Технические характеристики¶

Минимальные вычислительные ресурсы, предоставляемые изделию, приведены в таблице 3.1.1.

Таблица 3.1.1 — Минимальная конфигурация технических средств.

Ресурсы приведены суммарно для минимальной конфигурации из одной мастер-ноды и одной вычислительной ноды; распределение по типам узлов приведено в подразделе 4.3 документа «Описание программы».

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

Таблица 3.1.2 — Программные и объёмные характеристики.

Целевое развёртывание и границы позиции поставки приведены в таблице 3.1.3.

Таблица 3.1.3 — Характеристики целевого развёртывания.

Показатели назначения приведены в таблице 3.1.4.

Таблица 3.1.4 — Показатели назначения.

Минимальная конфигурация таблицы 3.1.1 обеспечивает одну вычислительную ноду. Для профиля не менее 6000 камер при опросе одного кадра раз в две минуты применяются четыре вычислительные ноды — суммарно 16 ускорителей класса NVIDIA T4. Ресурсы внешней LLM-ноды в показатели LPI-VAP-CORE не включаются.

Условия обеспечения показателей приведены в подразделе 2.3 описания программы.

3.2. Функциональные характеристики¶

Таблица 3.2.1 — Функциональные характеристики.

4. Комплектность¶

4.1. Программные компоненты¶

Таблица 4.1.1 — Программные компоненты изделия.

Состав пакета развёртывания фиксируется при выпуске поставки.

Таблица 4.1.2 — Ведомость пакета развёртывания (заполняется при выпуске поставки).

Перечень контейнерных образов с точными версиями и неизменяемыми дайджестами приводится в ведомости образов поставки и заполняется при выпуске. Для контрольной суммы предпочтительно указывать дайджест образа вида sha256:…, а не только изменяемый тег.

Таблица 4.1.3 — Ведомость контейнерных образов (заполняется при выпуске поставки).

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

Таблица 4.1.4 — Ведомость системного и инфраструктурного программного обеспечения (заполняется при выпуске поставки).

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

Таблица 4.1.5 — Параметры установленного экземпляра (заполняется при вводе в эксплуатацию).

4.2. Эксплуатационная документация¶

Таблица 4.2.1 — Эксплуатационная документация.

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

4.3. Носители данных¶

Таблица 4.3.1 — Носители данных.

5. Свидетельство о приёмке¶

Центральный модуль управления данными и распределёнными вычислениями (LPI-VAP-CORE) в составе, приведённом в разделе 4, соответствует требованиям, установленным для поставки, и признан годным к эксплуатации.

Таблица 5.1 — Свидетельство о приёмке (заполняется при передаче изделия).

Место печати предприятия-изготовителя.

6. Периодические испытания¶

Раздел заполняется при проведении периодических проверок изделия в порядке, установленном заказчиком. Состав контрольных проверок приведён в приложении В руководства администратора.

При проверке фиксируются как минимум: состояние Helm-релиза; готовность узлов и обязательных рабочих нагрузок Kubernetes; доступность постоянных томов, хранилищ и брокера сообщений; наличие ресурса nvidia.com/gpu на вычислительных нодах; вход через СУДИР; поступление медиаданных и событий; результат формирования отчёта; дата последней успешной проверки восстановления из резервной копии. Отключённые опциональные функции отмечаются как неприменимые.

Таблица 6.1 — Учёт периодических проверок.

7. Сведения об эксплуатации¶

7.1. Приём и передача изделия¶

Таблица 7.1.1 — Приём и передача изделия.

7.2. Учёт работы изделия¶

Таблица 7.2.1 — Учёт работы изделия.

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

8. Учёт неисправностей¶

Таблица 8.1 — Учёт неисправностей.

В записи указываются: версия и ревизия Helm-релиза, пространство имён, нода, рабочая нагрузка, под и контейнер (если применимо), наименование составной части, текст сообщения из журнала без секретных данных, влияние на работу изделия и порядок устранения. Типовые сообщения и действия приведены в разделе 6 руководства администратора.

9. Сведения о хранении и транспортировании¶

Таблица 9.1 — Условия хранения и транспортирования.

Таблица 9.2 — Учёт хранения и транспортирования.

10. Сведения о консервации и расконсервации¶

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

Таблица 10.1 — Учёт консервации и расконсервации (при применении машинных носителей).

11. Сведения об утилизации¶

Утилизация изделия выполняется прекращением его эксплуатации с контролируемым удалением Helm-релиза, ресурсов Kubernetes, контейнерных образов, постоянных томов и конфигурации развёртывания, а также данных с серверных узлов и резервных копий. Операция выполняется в порядке, принятом у заказчика, с учётом требований к защите информации, политик возврата постоянных томов и установленных сроков хранения данных.

Таблица 11.1 — Сведения об утилизации.

Лист регистрации изменений¶

Таблица — Лист регистрации изменений

Рабочая редакция 0.2 отражает актуализацию документа по целевой архитектуре Kubernetes и составу поставки Helm в формате docs-as-code и не является зарегистрированным изменением утверждённого оригинала. При выпуске утверждаемой редакции необходимо:

1. присвоить обозначение документа и формальный номер изменения;
2. сформировать DOCX или PDF и указать фактическое число и номера листов;
3. заполнить реквизиты титульного листа, листа утверждения и свидетельства о приёмке;
4. заполнить ведомости пакета развёртывания, контейнерных образов, системного и инфраструктурного программного обеспечения с версиями и контрольными суммами;
5. в последующих строках регистрировать только изменения утверждённого оригинала, а не отдельные технические коммиты Git.

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