Описание процессов поддержания жизненного цикла программного обеспечения CShark

Идентификация предоставляемого экземпляра

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

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

1.1. Организационные сведения

Функции разработки, тестирования, DevOps и системного администрирования, а также технической поддержки выполняют специалисты ООО «КОМПЕТЕНЦИЯ». Совмещение функций учитывается при планировании работ и разделении операций разработки, проверки и выпуска во времени.

2. Стадии жизненного цикла

Жизненный цикл включает:

1. сбор и анализ требований;
2. проектирование изменения;
3. разработку и проверку кода;
4. формирование версии;
5. сборку и контроль комплекта поставки;
6. установку или обновление;
7. эксплуатационный мониторинг;
8. обработку обращений и дефектов;
9. выпуск исправлений и улучшений;
10. прекращение поддержки версии и миграцию.

Каждое изменение должно иметь идентификатор, описание назначения, критерии приемки и связь с версией поставки.

3. Управление требованиями и изменениями

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

Перед реализацией изменение:

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

4. Разработка

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

Для изменений используются:

• статический анализ и форматирование;
• модульные тесты;
• интеграционные тесты с реальными PostgreSQL и NATS;
• контрактные тесты API и событий;
• проверка миграций базы данных;
• тесты интерфейса;
• сценарии резервного копирования и восстановления;
• проверка установочного комплекта.

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

5. Контроль качества

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

1. проверка полного набора автоматизированных тестов;
2. проверка сборки контейнерных образов;
3. проверка OpenAPI и сгенерированного клиента;
4. сканирование на утечку секретов;
5. проверка миграций на чистой и существующей базе;
6. Быстрое тестирование развернутого экземпляра;
7. визуальная проверка измененных пользовательских сценариев;
8. проверка архива поставки и контрольных сумм;
9. актуализация документации.

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

6. Версионирование и комплект поставки

Версия связывает:

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

Для закрытого контура формируется offline-комплект с локальными Docker-образами и APT-зависимостями. Комплект проверяется на чистой Ubuntu Server 24.04 LTS AMD64 без доступа к внешним репозиториям.

7. Поставка и установка

Поставка выполняется через защищенный сервер либо переносом offline-архива. Перед распаковкой проверяется SHA-256. Установщик повторно проверяет внутренний манифест, устанавливает зависимости, применяет миграции и выполняет быстрое тестирование.

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

8. Обновление системы

Текущий процесс обновления является управляемой административной операцией:

1. зафиксировать установленную версию;
2. проверить свободное место и состояние системы;
3. создать и проверить резервную копию;
4. получить идентифицированный комплект новой версии;
5. проверить контрольные суммы и примечания к выпуску;
6. проверить совместимость схемы данных;
7. применить миграции отдельным шагом;
8. переключить контейнеры на новую версию;
9. выполнить health-check и smoke-test;
10. зафиксировать результат обновления.

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

9. Управление миграциями и откатом

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

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

10. Мониторинг эксплуатации

Состояние системы контролируется по:

• /api/health;
• статусам контейнеров;
• метрикам публикации и обработки событий;
• глубине очереди Gateway;
• состоянию NATS;
• доступности PostgreSQL и S3;
• журналам Core, Gateway и инфраструктуры;
• свободному дисковому пространству;
• состоянию устройств.

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

11. Регистрация и классификация обращений

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

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

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

Процесс устранения включает:

1. регистрацию обращения;
2. сохранение исходного состояния и журналов;
3. классификацию влияния;
4. воспроизведение на безопасном стенде;
5. локализацию причины;
6. подготовку исправления;
7. регрессионные проверки;
8. выпуск исправленной версии;
9. установку по согласованному окну;
10. подтверждение результата пользователем;
11. актуализацию базы знаний.

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

13. Резервное копирование и восстановление

Бизнес-данные включают базу PostgreSQL и медиа в S3-совместимом хранилище.

Рекомендуемый базовый график:

• база данных - ежедневно;
• полная копия медиа - еженедельно;
• тестовое восстановление - после изменения процедуры и периодически по эксплуатационному регламенту.

Копия считается проверенной только после восстановления во временную среду и сверки контрольных счетчиков. Медиа сверяются по SHA-256 и итоговому digest манифеста.

14. Управление безопасностью

В процесс сопровождения входят:

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

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

15. Совершенствование программного обеспечения

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

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

16. Документация

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

• инструкция по установке;
• описание функциональных характеристик;
• руководство по эксплуатации;
• runbook для администраторов;
• OpenAPI и событийные контракты;
• примечания к выпуску;
• инструкции резервного копирования и восстановления.

Документация хранит дату актуальности и идентификатор версии, к которой она относится.

17. Персонал, необходимый для сопровождения

В небольшой команде один специалист может совмещать роли при наличии необходимых компетенций. Для штатной эксплуатации объекта минимально необходимы системный администратор и администратор CShark; разработчики и инженер по качеству привлекаются для исправлений и выпуска новых версий.

18. Прекращение поддержки версии

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