1. Общие сведения

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

Документ описывает процессы, обеспечивающие поддержание жизненного цикла программного комплекса «Айтечество» (далее — программный комплекс): устранение неисправностей, выявленных в ходе эксплуатации, совершенствование программного комплекса, выпуск и поставку новых версий, техническую поддержку пользователей, а также сведения о персонале, необходимом для такой поддержки. Документ входит в состав документации, прилагаемой к заявлению о включении сведений о программном обеспечении в единый реестр российских программ для электронных вычислительных машин и баз данных. Документ предусмотрен подпунктом «е» пункта 11 Правил формирования и ведения единого реестра российских программ для электронных вычислительных машин и баз данных и единого реестра программ для электронных вычислительных машин и баз данных из государств — членов Евразийского экономического союза, за исключением Российской Федерации, утверждённых постановлением Правительства Российской Федерации от 16.11.2015 № 1236 (в редакции от 13.08.2026) (далее — Правила).

1.2. Сведения о правообладателе

Параметр	Значение
Правообладатель	Индивидуальный предприниматель Орлова Юлия Витальевна
ОГРНИП	318784700117489
ИНН	781438442029
Адрес места осуществления деятельности	[ЗАПОЛНИТЬ: адрес на территории Российской Федерации]
Адрес электронной почты технической поддержки	[ЗАПОЛНИТЬ]
Телефон технической поддержки	[ЗАПОЛНИТЬ]
Сайт программного комплекса	https://айтечество.рф

1.3. Этапы жизненного цикла

Жизненный цикл программного комплекса включает разработку, проверку качества, выпуск версии, поставку и установку у заказчика или в инсталляции правообладателя, эксплуатацию и сопровождение (устранение неисправностей, обновление, техническая поддержка), а также вывод из эксплуатации. Работы выполняют правообладатель и исполнитель по договору на доработку и сопровождение (раздел 6); средства хранения исходного текста и сборки описаны в документе «Описание технических средств хранения исходного текста и объектного кода и средств компиляции».

2. Устранение неисправностей

2.1. Источники сведений о неисправностях

• обращения пользователей в техническую поддержку (раздел 5);
• автоматический мониторинг: метрики сервисов и правила оповещений (ошибки и задержки шлюза, недоступность сервисов, очередь событий, биллинг, целевые показатели доступности), внешняя проверка доступности и срока действия сертификатов, ежедневная проверка резервных копий;
• автоматические проверки при каждом изменении исходного текста и ночные сквозные тесты (раздел 3.3);
• еженедельная проверка закреплённых сторонних образов на известные уязвимости.

2.2. Регистрация и классификация

Каждая неисправность регистрируется в системе учёта задач правообладателя — модуле учёта задач системы хранения исходного текста (документ «Описание технических средств хранения исходного текста и объектного кода и средств компиляции», раздел 2.1) — с описанием, условиями воспроизведения, версией и оценкой критичности. Содержимое запросов пользователей, персональные данные и секреты в системе учёта задач не размещаются. [ПРОВЕРИТЬ ДО ПОДАЧИ: система учёта задач сервиса хранения исходного текста правообладателя введена в работу]

Критичность	Признаки	Реакция	Устранение
Критическая	Возможная передача немаскированных данных провайдеру модели или третьим лицам; недоступность шлюза; потеря данных	2 часа, круглосуточно	24 часа
Высокая	Отказ одной из функций без обходного пути (консоль, оплата, отдельный провайдер)	4 рабочих часа	3 рабочих дня
Средняя	Отказ функции при наличии обходного пути; пропуск значения отдельной категории без передачи за пределы организации	1 рабочий день	В ближайшей версии, не позднее 30 дней
Низкая	Недочёты интерфейса и документации	3 рабочих дня	По плану выпусков

Реакция — подтверждение регистрации обращения и начало работ по нему; устранение — выпуск исправления или предоставление обходного решения. Сроки отсчитываются от регистрации обращения или срабатывания мониторинга; рабочие часы и дни определяются режимом работы технической поддержки (раздел 5.1).

2.3. Порядок устранения

1. Неисправность воспроизводится на тестовой инсталляции; для дефектов маскирования используется обезличенный пример, а не исходный текст пользователя.
2. Исправление вносится в отдельной ветке и сопровождается тестом, воспроизводящим неисправность: для пропуска значения — новым случаем эталонного набора маскирования, для ошибок восстановления — проверкой восстановления.
3. Исправление проходит рецензирование и все автоматические проверки (раздел 3.3) и сливается в основную ветку.
4. Исправление выпускается в составе ближайшей версии; критические исправления выпускаются отдельной корректирующей версией (раздел 4.1).
5. После установки выполняется проверочный сценарий и проверяются признаки неисправности; обращение закрывается с уведомлением пользователя.

Если неисправность вызвана новой версией, инсталляция возвращается к предыдущей версии повторным развёртыванием её образов: миграции схемы базы данных обратно совместимы, поэтому откат схемы не требуется.

2.4. Инциденты с персональными данными

При подозрении на неправомерную передачу персональных данных (в том числе из-за дефекта маскирования) применяется отдельная процедура:

1. Регистрация инцидента с фиксацией времени обнаружения — не позднее 30 минут.
2. Сдерживание: сохранение сведений для расследования, затем остановка передачи (для дефекта маскирования — возврат шлюза к последней исправной версии).
3. Оценка состава затронутых данных, организаций и провайдеров — в течение 10 часов.
4. Уведомление затронутых заказчиков — не позднее 12 часов с момента обнаружения; уведомление Роскомнадзора в сроки, установленные законодательством о персональных данных (24 часа — об инциденте, 72 часа — о результатах расследования), и взаимодействие с ГосСОПКА в случаях, предусмотренных законодательством. [ПРОВЕРИТЬ: распределение обязанностей по уведомлению между правообладателем и заказчиком как операторами персональных данных]
5. Устранение причины, тест на неисправность, проверка после установки и разбор инцидента в течение 5 рабочих дней.

2.5. Уязвимости

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

2.6. Восстановление после сбоев

База данных ежедневно копируется в зашифрованном виде в объектное хранилище вне сервера данных (срок хранения — 14 дней, в Kubernetes дополнительно непрерывное архивирование журнала транзакций). Ежемесячно выполняется проверочное восстановление во временную базу данных со сверкой числа строк; неуспешная проверка рассматривается как инцидент. Порядок восстановления приведён в документе «Информация, необходимая для установки и эксплуатации».

3. Совершенствование программного комплекса

3.1. Источники требований

• предложения пользователей и заказчиков, поступающие в техническую поддержку и через форму на сайте;
• обезличенная статистика использования (журнал запросов содержит только метаданные);
• результаты измерения качества маскирования на эталонном наборе текстов;
• изменения законодательства Российской Федерации о персональных данных и информации;
• изменения API провайдеров языковых моделей (YandexGPT, GigaChat) и появление новых моделей.

3.2. Планирование

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

3.3. Разработка и контроль качества

Изменения вносятся в отдельных ветках и попадают в основную ветку только через запрос на слияние после рецензирования и успешного прохождения автоматических проверок:

• согласованность общих контрактов (схема базы данных, JSON-схемы, типы API, перечень категорий) и их копий в компонентах;
• статический анализ и проверка форматирования (Go, Python, TypeScript, сценарии оболочки, файлы сборочной системы), строгая проверка типов API управления;
• модульные и интеграционные тесты всех компонентов с реальными PostgreSQL и Valkey, тесты шлюза с проверкой гонок;
• эталонный набор текстов маскирования с нижними границами точности и полноты по каждой категории: изменение, ухудшающее показатели, не может быть принято;
• архитектурная проверка того, что исходящие соединения шлюза выполняются только через единую точку с проверкой адресов;
• поиск известных уязвимостей в зависимостях;
• проверка чартов Helm и шаблона стека Docker Swarm, правил мониторинга;
• сборка всех образов, полный набор тестов сервиса извлечения текста внутри его образа, проверка образов сканером уязвимостей;
• совместимость с предыдущим выпуском: интеграционные тесты предыдущей версии выполняются на схеме базы данных новой версии;
• сравнение производительности шлюза с основной веткой (отчёт).

Ежесуточно выполняются сквозные тесты веб-консоли и API на полной локальной инсталляции, еженедельно — нагрузочный тест. Сравнение с результатами предыдущих запусков и отклонение изменений, ухудшающих производительность более чем на 20 %, выполняются на выделенном сборочном сервере правообладателя (документ «Описание технических средств хранения исходного текста и объектного кода и средств компиляции», раздел 4.1); на других серверах тест только формирует отчёт. [ПРОВЕРИТЬ ДО ПОДАЧИ: сборочный сервер на территории Российской Федерации назначен для нагрузочного теста]

3.4. Совместимость

Миграции схемы базы данных выполняются по схеме «расширение — сжатие»: новая версия совместима со схемой предыдущей, удаление и переименование полей выполняются на следующем выпуске. OpenAI-совместимый API шлюза и API маскирования сохраняют обратную совместимость в пределах основной версии.

4. Выпуск версий

4.1. Нумерация версий

Версия программного комплекса обозначается номером X.Y.Z, где X — основная версия (несовместимые изменения API), Y — дополнительная (новые функции), Z — корректирующая (исправления). Выпуск отмечается тегом vX.Y.Z в системе контроля версий. Текущая версия — 0.2.0 (редакция RU). Номера версий отдельных пакетов компонентов являются внутренними и с номером версии программного комплекса не совпадают. [ПРОВЕРИТЬ ДО ПОДАЧИ: тег v0.2.0 установлен на коммит, указанный на титульном листе документа «Текст программы»]

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

4.2. Сборка и публикация

Образы контейнеров каждого компонента собираются один раз из коммита, публикуются в реестр образов правообладателя и после проверки сканером уязвимостей получают теги sha-<первые 12 символов коммита> и, для выпуска, vX.Y.Z. Состав образа фиксируется перечнем компонентов (SBOM). Состав выпуска: образы gateway, api, nlp, extractor, web, backup; чарты Helm; шаблон стека Docker Swarm и сценарии установки; файл закрепления сторонних образов; эксплуатационная документация.

Перечень изменений каждой версии (журнал изменений) ведётся в репозитории исходного текста, публикуется на сайте правообладателя в разделе документации «Изменения» одновременно с выпуском и направляется по электронной почте заказчикам, установившим программный комплекс в своей инфраструктуре. [ПРОВЕРИТЬ ДО ПОДАЧИ: журнал изменений введён и опубликован на сайте правообладателя]

4.3. Поставка и установка обновлений

Заказчики, использующие инсталляцию правообладателя, получают обновления автоматически: правообладатель устанавливает новую версию с предварительным уведомлением о плановых работах. Заказчики, установившие программный комплекс в своей инфраструктуре, получают уведомление о выпуске и устанавливают обновление сами по документу «Информация, необходимая для установки и эксплуатации». Обновление выполняется без остановки обслуживания: экземпляры сервисов заменяются поочерёдно, а шлюз завершает начатые потоковые ответы перед остановкой. Обновления поступают в инсталляции только из сборочной системы и реестра образов правообладателя (документ «Описание технических средств хранения исходного текста и объектного кода и средств компиляции», разделы 3 и 4.4); принудительное обновление инсталляций заказчиков и управление ими со стороны правообладателя отсутствуют.

Срок поддержки версий: исправления критических неисправностей и уязвимостей выпускаются для текущей и предыдущей дополнительной версии; остальные исправления включаются в очередную версию.

5. Техническая поддержка

5.1. Каналы

Канал	Значение
Электронная почта	[ЗАПОЛНИТЬ: адрес технической поддержки]
Телефон	[ЗАПОЛНИТЬ]
Форма на сайте	Раздел «Контакты» сайта программного комплекса https://айтечество.рф (темы: демонстрация, корпоративная лицензия, партнёрство, другое) [ПРОВЕРИТЬ ДО ПОДАЧИ: форма заявок включена на сайте правообладателя]
Режим работы	Понедельник — пятница, с 10:00 до 19:00 по московскому времени, кроме нерабочих праздничных дней; сообщения о критических неисправностях инсталляции правообладателя принимаются круглосуточно по электронной почте и через автоматический мониторинг
Язык	Русский

5.2. Состав услуг

• консультации по установке, настройке и эксплуатации программного комплекса;
• консультации по настройке политик, подключений к провайдерам моделей и интеграции приложений через API;
• приём и устранение неисправностей (раздел 2);
• предоставление обновлений и документации;
• восстановление работоспособности инсталляции правообладателя после сбоев.

Объём поддержки определяется тарифом или договором с заказчиком. Сроки реакции и устранения по уровням критичности приведены в разделе 2.2 и применяются, если договором с заказчиком не установлены иные сроки.

6. Персонал

6.1. Состав персонала

Поддержание жизненного цикла программного комплекса обеспечивают два лица: правообладатель — индивидуальный предприниматель, гражданин Российской Федерации, — и исполнитель по договору на доработку и сопровождение программы для ЭВМ «Айтечество», заключённому с правообладателем. По этому договору исполнитель выполняет доработку, сопровождение и эксплуатацию программного комплекса, а исключительное право на результаты доработки принадлежит правообладателю с момента их создания. Роли совмещаются:

Роль	Обязанности	Исполняет
Руководство	Планирование работ и выпусков, утверждение выпуска версий, взаимодействие с заказчиками и регуляторами	Правообладатель
Приём обращений	Приём и регистрация обращений пользователей, первичные консультации, передача неисправностей в разработку	Правообладатель
Разработка	Шлюз, маскирование, API управления, фоновые задачи (Go, Python); веб-консоль, чат, сайт (TypeScript, React); рецензирование изменений	Исполнитель
Качество маскирования и тестирование	Эталонный набор текстов, тесты, проверка выпусков	Исполнитель
Эксплуатация	Сборочная система, реестр образов, инсталляция правообладателя, мониторинг, резервное копирование	Исполнитель
Информационная безопасность	Уязвимости, ротация ключей, разбор инцидентов	Исполнитель
Техническая поддержка	Устранение неисправностей, консультации по установке, настройке и интеграции	Исполнитель

Общее число лиц, обеспечивающих поддержку, — 2. [ПРОВЕРИТЬ ДО ПОДАЧИ: договор на доработку и сопровождение подписан; исполнитель — гражданин Российской Федерации (подпункты «з» и «в» пункта 5 Правил: выплаты по договору на доработку иностранному физическому лицу учитываются в ограничении 30 % выручки); состав лиц соответствует таблице]

6.2. Место работы персонала

Правообладатель и исполнитель выполняют работы на территории Российской Федерации; фактический адрес, по которому осуществляется поддержка: [ЗАПОЛНИТЬ: адрес на территории Российской Федерации]. Договор на доработку и сопровождение обязывает исполнителя передавать изменения в инсталляции только через сборочную систему и реестр образов правообладателя на территории Российской Федерации, которые находятся под контролем правообладателя. Административный доступ к средствам хранения исходного текста, сборки и инсталляции правообладателя имеют только правообладатель и исполнитель; управление программным комплексом и его обновление из-за пределов Российской Федерации не осуществляются. [ПРОВЕРИТЬ ДО ПОДАЧИ: оба лица находятся на территории Российской Федерации; средства хранения и сборки перенесены на территорию Российской Федерации (условия документа «Описание технических средств хранения исходного текста и объектного кода и средств компиляции»)]

6.3. Требования к квалификации

Роль	Требования
Руководство, приём обращений	Опыт управления разработкой программного обеспечения или ИТ-проектами; знание законодательства Российской Федерации о персональных данных и об информации; навыки работы с веб-консолью программного комплекса и системой учёта задач
Разработка, тестирование, эксплуатация, информационная безопасность, техническая поддержка	Знание языков программирования Go, Python и TypeScript; PostgreSQL; контейнерной виртуализации (Docker, Docker Swarm, Kubernetes, Helm); протоколов HTTP, TLS и Server-Sent Events; методов обработки естественного языка для русского языка; управления уязвимостями, ключами шифрования и реагирования на инциденты; законодательства Российской Федерации о персональных данных

7. Вывод из эксплуатации

При прекращении использования инсталляции заказчиком данные организаций удаляются средствами веб-консоли (удаление организации: данные удаляются через 30 дней, платёжные документы хранятся 5 лет) или удалением базы данных, объектного хранилища и резервных копий инсталляции. Резервные копии удаляются по истечении срока хранения (14 дней). Ключи шифрования уничтожаются после удаления всех копий данных.