Опубликовано: 14.09.2026 | Источник: CNews (новости)

«Госуслуги» как кейс для ВКР: интеграция реестров, REST API и метрики SLA

Поддомен статьи: Backend/Frontend (интеграция государственных информационных систем)
Роль эксперта: Архитектор ПО
Выбранная схема структуры: B

Введение

Минцифры отчиталось: в 2025 году через «Госуслуги» зарегистрировали рождение 434 тыс. детей — почти каждый третий новорождённый в стране получил документы без визита в ЗАГС. За этой цифрой стоит не «красивый портал», а тяжёлая инженерная работа: онлайн-обмен данными между медицинскими организациями, ЗАГС, СФР и ФНС, защита персональных данных, отказоустойчивость и предсказуемое время отклика. Для выпускника ИТ-специальности это готовая модель защищаемой ВКР: тут есть и предметная область, и метрики, и архитектура. Ниже — как превратить новость в дипломную работу, которую не стыдно защитить и легко защитить по существу.

Основная часть: от реестров до SLA

Три темы ВКР, которые вырастают из кейса «Госуслуг»

Кейс универсален: он подходит и для чистой разработки, и для аналитики, и для тестирования. Выберите то, что ближе к вашей кафедре.

Глава 1 — анализ: где искать данные и стандарты

Первая глава — не «вода про актуальность», а рабочий раздел. Здесь вы обосновываете, что «Госуслуги» — не единый монолит, а ландшафт взаимосвязанных систем: ЕСИА (аутентификация), СМЭВ (межведомственное взаимодействие), ведомственные реестры ЗАГС и медорганизаций. Именно этот ландшафт рисуется в первой главе. Обязательные пункты:

• Обзор предметной области: жизненный цикл заявления от подачи до выдачи свидетельства.
• Нормативная база: ГОСТ 34.601-90 (стадии создания автоматизированных систем), ГОСТ 19.701 (схемы алгоритмов и программ), ФЗ-152 о персональных данных.
• Обзор аналогов и стандартов качества: ISO/IEC 25010 — по каким характеристикам вы будете оценивать своё решение (функциональная полнота, производительность, защищённость).
• Статистика из статьи как input для постановки задачи: 434 тыс. операций в год ≈ 1–2 тыс. в сутки, с пиками в конце месяца.

Глава 2 — проектирование: C4, OpenAPI, интеграция с ЕСИА и СМЭВ

Вторая глава — где студенты чаще всего «сыпятся». Не рисуйте один абстрактный прямоугольник «Сервис». Постройте диаграммы уровней C4: Context (кто пользователи, какие внешние системы), Container (какие компоненты: API Gateway, сервис заявлений, БД, очередь), Component (внутри сервиса), Code (только при необходимости). Для взаимодействия с внешними реестрами приложите диаграмму последовательности (UML Sequence) — там видно и асинхронность, и повторные попытки.

Контракт API описывайте в OpenAPI — это снимает половину вопросов комиссии о «полноте проектирования»:

# openapi-fragment.yaml — упрощённый контракт сервиса подачи заявления
openapi: 3.1.0
info:
  title: Birth Registration Service
  version: 1.0.0
paths:
  /v1/birth-applications:
    post:
      summary: Принять заявление на регистрацию рождения
      security:
        - esiaOAuth2: [birth.write]
      parameters:
        - name: Idempotency-Key
          in: header
          required: true
          schema: { type: string, format: uuid }
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/BirthApplication'
      responses:
        '202': { description: Принято в асинхронную обработку }
        '409': { description: Дубликат (совпал Idempotency-Key) }
        '422': { description: Ошибка валидации полей }

Обратите внимание на Idempotency-Key и код 202: заявление уходит в очередь (Kafka или RabbitMQ) и обрабатывается асинхронно. Именно так работают реальные сервисы такого масштаба — синхронное ожидание от ЗАГС было бы узким горлышком.

Глава 3 — реализация, нагрузка и метрики SLA

Третья глава без цифр — не третья глава. Возьмите за основу формулу SLI/SLO из SRE-подхода: доступность ≥ 99,9%, p95 времени ответа ≤ 800 мс на POST, доля успешно принятых заявлений ≥ 99,5%. Метрики собирайте через OpenTelemetry и считайте в Prometheus, визуализируйте в Grafana. Пример запроса для контроля SLA:

# PromQL — p95-задержка эндпоинта подачи заявления
histogram_quantile(
  0.95,
  sum(rate(http_request_duration_seconds_bucket{route="/v1/birth-applications", method="POST"}[5m])) by (le)
)

# Доля успешных заявлений (SLI «приёмоспособность»)
sum(rate(birth_applications_total{status="accepted"}[1h]))
/
sum(rate(birth_applications_total[1h]))

Нагрузочный тест проведите в JMeter или k6: смоделируйте 50 виртуальных пользователей, идемпотентные повторы и обрыв соединения. Зафиксируйте, как ведёт себя система при отказе внешнего реестра — не падает, а возвращает 202 и ставит в очередь. Это отдельный плюс на защите: вы показали не «happy path», а отказоустойчивость.

Чему вы научитесь

• Проектировать интеграцию разнородных реестров через асинхронные очереди и идемпотентные API.
• Описывать контракты по OpenAPI 3.1 и строить диаграммы C4/UML, понятные комиссии.
• Определять SLI/SLO и подтверждать их нагрузочными тестами, а не словами «система быстрая».
• Оформлять разделы ВКР по ГОСТ 34.601 и оценивать качество ПО по ISO/IEC 25010.
• Считать стоимость эксплуатации и обосновывать выбор облака или on-premise для госсектора.

FAQ

Мне обязательно писать свой сервис с нуля?

Нет. Достаточно прототипа, покрывающего 2–3 ключевых сценария: подача заявления, ответ внешней системы, повторная попытка. Всё остальное можно описать в архитектурной части и подтвердить диаграммами. Комиссия оценивает проектные решения, а не количество написанных строк.

Где взять данные про 434 тыс. заявлений, если нет доступа к «Госуслугам»?

Используйте открытые публикации Минцифры, материалы Росстата и данные аналитических агентств. Если нужен «объёмный» датасет для тестов — сгенерируйте синтетические заявки по статистическому распределению: пуассоновский поток с пиками в конце месяца. Такой подход корректен и часто встречается в промышленной практике.

Как оформлять схемы по ГОСТ, если у меня C4?

C4 — нотация архитектурная, ГОСТ 34 её не отменяет. В основной части показывайте C4 (она читаемая), а в приложениях разместите функциональную схему и схему алгоритма по ГОСТ 19.701. Не путайте уровни и подпишите каждую стрелку — за неподписанные интерфейсы снимают баллы.

Что важнее на защите: код или метрики?

Метрики. Код у вас посмотрят в лучшем случае мельком, а на вопрос «стало ли лучше после вашего решения?» ответ нужен цифрой. Поэтому заранее подготовьте таблицу «до/после» по p95, throughput и доле успешных операций.

Что проверить перед сдачей

Типичные ошибки студентов

Источник: Рождение каждого третьего ребёнка регистрируют на «Госуслугах» (опубликовано 2026-03-24)