GovTech в Узбекистане: как разрабатывают системы для госсектора

Государственный сектор Узбекистана за последние годы прошёл серьёзную цифровизацию: единый портал интерактивных госуслуг, межведомственный обмен данными, электронный документооборот, отраслевые информационные системы. За каждым таким проектом стоит подрядчик, который должен соответствовать целому набору требований, которых нет в обычной коммерческой разработке. GovTech — это не просто «сайт для министерства», а система, к которой предъявляются требования по безопасности, доступности, хранению данных и юридической чистоте процесса закупки.

В этой статье разбираем, чем GovTech-проекты отличаются от частного бизнеса и на что реально обращать внимание команде, которая хочет работать с госсектором в Узбекистане.

Чем требования госсектора отличаются от коммерческих

Главное отличие — приоритеты. В коммерческом проекте на первом месте обычно скорость вывода на рынок и стоимость. В госсsекторе впереди идут предсказуемость, прослеживаемость и соответствие нормативке. Заказчик не может «передоговориться на ходу»: объём работ зафиксирован в техническом задании и договоре, а любое отклонение требует формального изменения документов.

На практике это означает несколько вещей:

• детальное ТЗ становится не формальностью, а юридическим документом, по которому потом принимают работу;
• приёмка идёт поэтапно, с актами и протоколами испытаний;
• повышенные требования к документации — нужны не только пользовательские инструкции, но и эксплуатационная, и проектная документация;
• данные граждан и ведомственная информация попадают под требования по защите и локализации хранения внутри страны;
• интеграция с государственными платформами идёт через утверждённые шлюзы межведомственного обмена, а не через произвольные API.

Как устроены тендеры и закупки

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

Что важно понимать команде, выходящей на тендеры:

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

Импортонезависимость и локализация

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

На практике для GovTech в Узбекистане разумная база — это связка из открытых и проверенных технологий: PostgreSQL вместо проприетарных СУБД, Linux-серверы, контейнеризация (Docker/Kubernetes) для переносимости, размещение в дата-центрах на территории страны. Такой стек снимает санкционные и лицензионные риски и при этом остаётся в рамках мирового мейнстрима — найти специалистов и поддерживать систему годами реально.

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

Отказоустойчивость и эксплуатация

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

Базовый инженерный набор, который мы закладываем в такие проекты:

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

Безопасность и работа с данными

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