Как мы построили государственный реестр участников СВО: госпроект изнутри

К нам пришла задача, от которой не отказываются: нужна информационная система для государственного заказчика — реестр данных об участниках СВО, местах захоронений, родственниках и памятных объектах. Сроки сжатые, требования высокие, второго шанса не будет. Рассказываем, как команда NextCore строила эту систему — без магии и без прикрас.

Проблема, о которой не говорят вслух

Когда речь заходит об IT в госучреждениях, в голову сразу лезут стереотипы: всё на Excel, всё медленно, всё через одно место. В этот раз стереотип попал в точку. Задачу на первый взгляд сформулировали просто — «надо вести учёт». А за этими двумя словами скрывался настоящий хаос.

Десятки муниципалитетов, и каждый ведёт собственный реестр: кто-то в Excel, кто-то в текстовом файле, кто-то вообще на бумаге. У каждого своя структура таблиц, свой набор колонок, своё понимание того, что важно. Один записывает дату как «12.03.2024», другой — как «12 марта 2024 г.», третий не указывает её вообще. А когда нужно собрать сводную картину — хотя бы посчитать записи и их статусы, — люди вручную пересчитывают строки в разрозненных файлах.

А теперь главное: это не абстрактная статистика, а сведения о людях. Цена ошибки здесь совсем другая. Мы сразу поняли: это не «надо запилить CRM». Это система, которая либо работает как часы, либо не работает вообще.

Сначала — проектирование, потом код

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

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

Технологический выбор: никакой магии

Когда речь заходит о стеке, многие удивляются: «А где 1С? А где тяжёлая энтерпрайз-платформа за миллионы рублей?» Нам нужны были скорость, гибкость и прозрачность. Поэтому:

• Бэкенд — Python и FastAPI: один из самых быстрых веб-фреймворков, асинхронность из коробки, автогенерация документации, сильная валидация данных. Под капотом — PostgreSQL. Надёжная связка.
• Фронтенд — Next.js и React: современный, отзывчивый веб-интерфейс, а не «консольный ввод».
• Доступ — JWT-аутентификация и ролевая модель RBAC.
• Деплой — Docker: система поднимается одной командой на тестовом стенде, на проде и на машине разработчика. Никаких «у меня на компьютере всё работает».
• Тесты — с самого начала, прямо во время разработки.

Архитектура: многослойная, без магии

Мы построили бэкенд по принципу многослойной архитектуры: HTTP-запрос не лезет напрямую в базу данных, а проходит через несколько слоёв. Как в хорошем ресторане — официант не бежит сам жарить стейк.

• Слой маршрутов принимает запрос и проверяет корректность данных и права доступа.
• Слой бизнес-логики решает, что именно нужно сделать, и управляет транзакциями.
• Слой доступа к данным общается с базой — и больше ничем не занимается.

Зачем это нужно. Первое — заменяемость: хотите поменять базу данных — меняете только слой доступа к данным. Второе — тестируемость: бизнес-логика тестируется отдельно от базы и маршрутов. Третье — понятность: новый разработчик не тонет в тысяче строк, а открывает конкретный сервис и видит конкретную задачу. Когда проект разросся, это сэкономило нам массу времени.

Вызов первый: миграция из Excel

Исторические данные лежали в разрозненных файлах из муниципалитетов: десятки файлов, у каждого своя структура и свои «творческие решения» на местах. Кто-то вставлял пробелы перед фамилиями, кто-то писал даты текстом, кто-то оставлял пустые строки в середине таблицы «для красоты», а кто-то умещал в одной ячейке фамилию, имя, отчество и год рождения.

Решение: импорт вынесли в фоновый режим. Пользователь загружает файл и занимается своими делами, а система в фоне разбирает таблицу и валидирует каждую строку. Если в файле тысяча строк и двадцать битых — система не падает. Она импортирует 980 корректных, а по оставшимся 20 формирует отчёт об ошибках: в этой строке, в этой колонке такая-то проблема. Пользователь получает обратно файл с ошибками, сгруппированными по муниципалитетам, и исправляет их точечно — не перезагружая весь массив. Это сэкономило заказчику недели ручной работы.

Вызов второй: безопасность без компромиссов

Госпроект, персональные данные — и ты отвечаешь за то, чтобы они не утекли. Мы выстроили защиту в несколько эшелонов: хеширование паролей без хранения открытого текста, аутентификация без серверных сессий (меньше точек отказа), валидация всех входящих данных — любой «мусор» обрубается на входе.

Самое интересное — ролевая модель, привязанная к территории. Модератор района имеет полный доступ к данным своего района, но не видит данные соседнего — даже если вручную подставит чужой идентификатор в запрос. Система на уровне бизнес-логики проверяет: кто ты, к какому муниципалитету привязан, откуда запрашиваешь данные. Администратор видит всё, модератор — только своё, гость — только одобренное и опубликованное.

Вызов третий: 73 теста, которые держат репутацию

Самое грустное в госразработке — системы, которые «вроде работают»: заказчик принимает проект, а через месяц начинается — тут вылетело, там не сохранилось, права доступа сломались. Мы решили эту проблему просто и надёжно: написали 73 интеграционных теста. Они покрывают и позитивные сценарии (всё работает как надо), и негативные (что будет, если передать неверные данные или пользователь без прав попытается сделать то, что ему нельзя).

Техническая деталь: каждый тест работает в собственной изолированной транзакции. Отработал — база откатилась в исходное состояние. Никаких «тест номер 42 сломал данные для теста 43». База всегда чистая, результаты всегда воспроизводимы.

Почему госзаказ — это не страшно

• Документация — это не наказание. В коммерческом проекте можно договориться на словах, в госпроекте всё должно быть на бумаге. И это, как ни странно, дисциплинирует: лучше понимаешь, что именно строишь.
• Безопасность — это фундамент, а не фича. Здесь нельзя «сначала запуститься, потом прикрутить защиту». И это правильно, потому что система работает с данными людей.
• Воспроизводимость. Тестовый стенд, боевой сервер и машина разработчика — три разных мира. Если система не разворачивается одной командой одинаково на всех трёх — ты не готов к госзаказу.

Что получилось в итоге

• Централизованный учёт по единому стандарту — без «своих форматов» и дублей.
• Разграничение доступа по ролям и территориям.
• Импорт исторических данных из Excel с умной обработкой ошибок.
• Аналитика в реальном времени.
• Полная история изменений с аудитом.
• Стабильная работа под нагрузкой.
• 73 теста, 30 сущностей, многослойная архитектура, документация API, деплой одной командой.

Система принята ведомством и отмечена благодарностью Администрации губернатора Пермского края. Для нас это главное подтверждение: сделали не «для галочки», а в эксплуатацию.

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

В России огромный запрос на качественную IT-разработку в госсекторе — на реальные работающие системы, а не на «освоение средств». Такие задачи по силам небольшим командам, которые умеют проектировать, программировать и доводить до результата. Если вы представляете госструктуру и вам нужна информационная система — пишите нам.