Работоспособность ПО
Документ: Описание процессов, обеспечивающих поддержание жизненного цикла программного обеспечения (устранение неисправностей и совершенствование), и сведения о персонале поддержки.
Продукт: Vessa — суверенная платформа голосового и чат-AI для банков и регулируемых организаций.
Версия: V2 от 20.06.2026. (V2: добавлены каналы поддержки/контакты, эскалация, уведомление об обновлениях — для аккредитации.)
Юридическое лицо: Общество с Ограниченной Ответственностью «Суверенные Голосовые Технологии», 142500, Московская обл., Павлово-Посадский г. о., г. Павловский Посад, ул. Автомобилистов, д. 5.
Сайт: www.vessa.tech. Ответственный за ИБ: Прудников Владимир Павлович, security@vessa.tech.
Секреты: документ не содержит ключей, токенов, паролей, реальных адресов хостов.
1. Назначение и область
Документ описывает процессы поддержания жизненного цикла платформы Vessa: устранение неисправностей, выявленных в ходе эксплуатации, совершенствование ПО, выпуск обновлений и сведения о персонале, необходимом для поддержки. Установка и эксплуатация описаны в «Руководстве по установке и эксплуатации».
Граница с ИБ. Настоящий документ описывает программные дефекты и сопровождение. Инциденты информационной безопасности (взлом, эксфильтрация, нарушение целостности) — отдельный, более строгий процесс: «Регламент обработки инцидентов информационной безопасности».
2. Сведения о ПО
Платформа Vessa — суверенное (on-prem) AI-решение голосового и чат-обслуживания клиентов (см. «Паспорт программного продукта», «Описание продукта»). Полный цикл — от исследований и адаптации моделей до поставки, сопровождения и обновлений (см. «Описание ИТ-деятельности компании»).
3. Модель жизненного цикла
Итеративная модель сопровождения с разделением сред:
- Среда разработки (dev) — разработка и отладка изменений.
- Среда предпроверки (staging / dev-зеркало) — валидация изменений и миграций БД до боевого контура.
- Боевая среда (prod) — в периметре заказчика; изменения вносятся только через управляемую процедуру выпуска с возможностью отката.
Клиентские данные не покидают боевой периметр; разработка и предпроверка ведутся на непродуктивных данных.
4. Управление версиями и выпуск обновлений
- Версионирование. Каждая сборка имеет инкрементируемую версию; изменения фиксируются в истории.
- Контроль изменений. Изменения проходят внутренний контроль качества и сборочную валидацию перед выпуском; для конфигурации ИИ — governance (версии, сравнение «было/стало», согласование, откат), см. «Обзор архитектуры безопасности», §7.
- Выпуск в боевой контур. Обновление разворачивается в согласованное окно, с предварительной проверкой на предпроверочной среде и возможностью отката на предыдущую версию.
- Порядок выкатки. Изменения БД (миграции) → серверные компоненты → каналы → конфигурация — с проверкой на каждом шаге.
- Уведомление и регистрация. Об обновлениях заказчик уведомляется заранее (описание изменений / release notes); факт выпуска фиксируется в истории версий и аудите. Внеплановые обновления безопасности выпускаются по приоритету критичности с уведомлением.
5. Устранение неисправностей (кто и как чинит баги)
Неисправность — отклонение работы ПО от ожидаемого (ошибка, сбой функции). Порядок:
- Приём обращения. Заказчик сообщает о неисправности через выделенный канал поддержки (электронная почта поддержки / портал заявок — реквизиты в договоре и SLA). Часть дефектов выявляется самой платформой (наблюдаемость моделей, журналы событий) и фиксируется проактивно.
- Регистрация и классификация. Обращение регистрируется; присваивается уровень критичности (см. матрицу). Целевые сроки реакции и устранения — по SLA договора.
- Диагностика. Воспроизведение и анализ по журналам и наблюдаемости. При необходимости доступа к боевому контуру — через контролируемую сессию, предоставляемую заказчиком (постоянного доступа поставщика к боевым данным нет; см. «Паспорт…», §10).
- Исправление. Разработка исправления в среде разработки.
- Тестирование. Проверка фикса; регрессия эталонными сценариями (golden) и, при необходимости, массовая симуляция (Digital Twin); валидация миграций на предпроверочной среде (dev-зеркало).
- Выпуск и проверка. Выкатка по процедуре §4 с откатом наготове; подтверждение устранения совместно с заказчиком; запись в историю изменений и аудит.
- Гарантийное устранение. Дефекты в рамках гарантийных обязательств устраняются по договору ([УСЛОВИЯ ПОДДЕРЖКИ]).
Матрица критичности дефектов
| Уровень | Определение | Целевая реакция / устранение |
|---|---|---|
| S1 — критический | Полная неработоспособность сервиса либо потеря/искажение данных; обход невозможен | [СРОК РЕАКЦИИ S1] / [СРОК УСТРАНЕНИЯ S1] |
| S2 — высокий | Существенная функция недоступна; обхода нет или он трудоёмок | [СРОК РЕАКЦИИ S2] / [СРОК УСТРАНЕНИЯ S2] |
| S3 — средний | Частичное нарушение функции; есть обходной путь | [СРОК РЕАКЦИИ S3] / [СРОК УСТРАНЕНИЯ S3] |
| S4 — низкий | Незначительное отклонение, косметика, мелкое улучшение | [СРОК РЕАКЦИИ S4] / в плановом порядке |
Конкретные сроки фиксируются в SLA договора.
5.1. Каналы поддержки, контакты и эскалация
Куда обращаться. Обращения принимаются через выделенный канал технической поддержки:
- Электронная почта поддержки: [E-MAIL ПОДДЕРЖКИ] (по вопросам ИБ —
security@vessa.tech). - Портал заявок / трекер: [ПОРТАЛ ЗАЯВОК] (если предусмотрен договором).
- Дежурная линия (телефон/мессенджер) для критичных обращений S1: [ДЕЖУРНАЯ ЛИНИЯ].
Реквизиты каналов и режим работы (часы поддержки, дежурство для S1) фиксируются в договоре и SLA.
Что указать в обращении. Описание проблемы и ожидаемого поведения; время возникновения; затронутый компонент/раздел; шаги воспроизведения; предварительный уровень критичности; контакт заявителя. Для ускорения — выдержки из журналов/наблюдаемости (без выгрузки клиентских данных).
Эскалация.
| Линия | Кто | Когда подключается |
|---|---|---|
| 1-я линия (приём, регистрация, первичная диагностика) | Поддержка заказчика | Все обращения |
| 2-я линия (исправление) | Инженер разработки / эксплуатации | По результату диагностики |
| 3-я линия (архитектура, сложные дефекты) | Ведущий инженер / архитектор | S1/S2 либо эскалация со 2-й линии |
| Координация инцидента ИБ | Ответственный за ИБ (Прудников В. П., security@vessa.tech) | Признаки инцидента ИБ |
Для S1 (полная неработоспособность либо потеря/искажение данных) — немедленная эскалация на 2-ю и 3-ю линии и уведомление ответственного лица заказчика. Инциденты информационной безопасности ведутся параллельно по «Регламенту обработки инцидентов ИБ».
6. Совершенствование ПО
- Запросы на развитие. Предложения заказчика по новым функциям и улучшениям регистрируются и приоритизируются совместно.
- Планирование. Развитие ведётся в рамках дорожной карты продукта (включая импортонезависимость — см. «Roadmap импортонезависимости» — и языковое расширение).
- Изменения ИИ как управляемый актив. Развитие диалогового поведения (промпты, сценарии, маршрутизация, политики) вносится через governance с версионированием, согласованием и откатом — без неконтролируемого изменения «чёрного ящика».
7. Управление модельным риском в жизненном цикле
Модели (языковая, распознавание, синтез) ведутся как версионируемый актив: реестр моделей со статусом и уровнем риска, непрерывная наблюдаемость качества и задержек, контроль деградации (drift) относительно порога приёмки, промоут и откат версии с записью в аудит, регрессия golden перед изменением. Подробно — «Обзор архитектуры безопасности», §7.
8. Тестирование и контроль качества
- Регрессия эталонными сценариями (golden) на боевой модели — перед изменениями диалогового контура.
- Массовая симуляция (Digital Twin) — проверка поведения на объёме сценариев.
- Предпроверка миграций БД на dev-зеркале до боевого контура.
- Сборочная валидация артефактов перед выпуском.
9. Управление уязвимостями и обновления безопасности
- Отслеживание уязвимостей в используемых компонентах с открытым исходным кодом; обновление по мере необходимости.
- Обновления безопасности выпускаются по процедуре §4 с приоритетом по критичности.
- Эксплуатационная гигиена (ротация секретов, шифрование резервных копий, минимизация периметра, патчинг ОС) — см. «Обзор архитектуры безопасности», §8.
- Инциденты ИБ — «Регламент обработки инцидентов информационной безопасности».
10. Резервное копирование, восстановление, непрерывность
- Регулярные шифрованные резервные копии БД; off-box-реплика аудита (сохраняется при компрометации основного узла).
- Восстановление из резервной копии — по процедуре поставщика; проверка целостности аудита после восстановления.
- Непрерывность обслуживания при сбое ИИ — резервный отказ на операторов/IVR (см. «Руководство по установке и эксплуатации», §7).
- Сроки хранения и удаление — «Регламент хранения и удаления данных».
11. Персонал, обеспечивающий поддержку
Поддержку обеспечивает команда разработчика с компетенциями (см. «Описание ИТ-деятельности», §6): машинное обучение и речевые технологии; разработка распределённых backend-систем; эксплуатация GPU-инфраструктуры; информационная безопасность. Роли в сопровождении:
| Роль | Зона ответственности |
|---|---|
| Ведущий инженер / архитектор | Архитектура, ключевые исправления и изменения, контроль качества |
| Инженер разработки | Реализация исправлений и улучшений |
| Инженер эксплуатации (DevOps) | Выпуск обновлений, развёртывание, мониторинг |
| Ответственный за ИБ | Безопасность, реагирование на инциденты (Прудников В. П., security@vessa.tech) |
| Поддержка заказчика | Приём и сопровождение обращений |
Процессы и технические контроли (неизменяемый аудит, off-box-журнал, правило двух лиц, согласование изменений) выстроены так, что не зависят от численности команды; в компактной команде роли могут совмещаться при сохранении этих контролей.
12. Вывод версий и завершение эксплуатации
- Снятие версий ПО/моделей — управляемо, с фиксацией в реестре и аудите; предыдущая версия доступна для отката в течение согласованного периода.
- Завершение договора — выгрузка/передача данных заказчику и удаление по «Регламенту хранения и удаления данных», §6; отзыв ключа заказчиком (HYOK) делает данные недоступными для расшифровки.
13. Связанные документы
«Руководство по установке и эксплуатации», «Паспорт программного продукта», «Описание ИТ-деятельности компании», «Обзор архитектуры безопасности», «Регламент обработки инцидентов информационной безопасности», «Регламент хранения и удаления данных», «Roadmap импортонезависимости», «Описание архитектуры платформы».