Поделиться
Алексей Козырев: О планах развития ЕПГУ, СМЭВ и других систем электронного правительства
О борьбе с «пробками» в СМЭВ, новой версии портала госуслуг, приоритетах регионов в развитии электронного правительства и рейтингах их успеваемости, роли «Ростелекома», Почты России и НИИ «Восход» в интервью CNews рассказал заместитель министра связи Алексей Козырев.Доработка, которую мы сделали в 2013 году, решает проблему методических рекомендаций за счет реализации технического стандарта. То есть мы создали технологию, при которой подписание запроса и ответа электронной подписью, упаковка данных в конверт, порядок обработки этого конверта унифицированы на уровне единого адаптера СМЭВ. Достаточно один раз реализовать интеграцию со СМЭВом через этот адаптер, чтобы потом любые сведения, которые нужно запрашивать, можно было настроить через него. То есть мы просто указываем состав данных, которые через этот адаптер надо запрашивать и получать. И, таким образом, один раз проведя интеграцию, для доступа как к наиболее востребованным, так и к наименее востребованным сведениям не нужно делать новые проекты по интеграции. Достаточно просто поменять настройки.
Еще одна важная инновация – это очередь гарантированной доставки запросов и ответов, которая при создании СМЭВ не была реализована. В результате получалось так, что, например, у Федерального казначейства информационная система, которая выдает сведения ГИС ГМП, выполнена таким образом, что очередь запросов выстраивается на стороне информационной системы. СМЭВ, как через трубу, все запросы передает, а на стороне Казначейства производительности системы не хватает, запросы выстраиваются в очередь.
CNews: Пробка…
Алексей Козырев: Пробка, но пробка, из которой запросы не вылетают. То есть система их принимает, но обрабатывает не сразу, а с некоторой задержкой. Росреестр же сделал свою систему, например, без такой очереди, рассчитывая на то, что функциональность должна быть реализована на стороне СМЭВа. А в СМЭВе этой функциональности не было. В результате получается такая ситуация, что, когда для оказания услуги требуется сведения Росреестра, орган власти, который услугу оказывает, отправляет запрос в Росреестр, а сервис Росреестра имеет предельную мощность 20 одновременных запросов. Если орган власти пытается поставить на этот сервис 21 запрос, то он получает сообщение об ошибке: сервис недоступен. Хотя это просто пиковый час, сервис работает, но не может обработать 21-е обращение.
Алексей Козырев: 2013 год был направлен на развитие инфраструктуры электронного правительства и развитие функциональности каналов, которые видны гражданам
Поэтому в СМЭВ поставили очередь гарантированной доставки, в которую запрос будет принят гарантировано. Когда этого сервиса нет, фактически потребитель начинает усугублять ситуацию. Сейчас на свой запрос он может получить ответ «сервис недоступен», но услугу-то ему надо оказывать. Он вынужден отправлять еще один запрос, еще один, еще один. Получается такой снежный ком, который начинает расти. Сейчас мы сделали очередь, в которую запрос встает один раз. Тот, кто отправил запрос, получает билетик, что запрос принят системой. И когда сервис готов его обработать, он его обрабатывает, после чего возвращает ответ, который доставляется потребителю. Технология сейчас реализована и принята нами по госконтракту. В 2014 году мы начинаем ее внедрять, потому что внедрение этой технологии требует, чтобы и потребитель, и поставщики сведений свои сервисы переделали под работу с очередью гарантированной доставки и универсальным адаптером.
Наиболее крупные поставщики сведений – Казначейство и Росреестр – больше всего заинтересованы в этой технологии, и, соответственно, мы начинаем с них. За 2014 год мы рассчитываем эту технологию внедрить и таким образом обеспечить более надежную, стабильную работу всей инфраструктуры электронного правительства на базе СМЭВ.
CNews: Насколько трудоемкой и дорогой будет доработка сервисов под описанные требования?
Алексей Козырев: Если посмотреть на историю работы СМЭВ, то порядка 20% сервисов, которые работают, за год так или иначе меняются, потому что меняется нормативка, и под изменившуюся нормативку требуется переделка самих форматов сервисов. Мы специально активно не запускаем процесс перехода на новую технологию. Но тогда, когда меняется нормативка и требуется переделывать сервис, он должен быть сделан уже по новой технологии.
Например, недавно были внесены изменения в законодательство о порядке регистрации недвижимости и сделок с ней, под которые Росреестр будет менять свой сервис. Соответственно, запуск этой новой технологии мы приурочиваем к естественным изменениям нормативки. Росреестр будет делать новый сервис под новые методические рекомендации, ориентированные на очередь гарантированной доставки. Естественно, что при этом старый сервис будет продолжать работать для того, чтобы процессы не останавливались. Здесь нам потребовалось принимать отдельное решение на уровне подкомиссии, потому что сейчас при изменении нормативки изменения предполагается делать планомерно. Если с первого числа нормативка меняется, значит с первого же числа все информационные системы должны работать по-новому. К сожалению, так не получается сделать. Поэтому мы ввели такой период плавной миграции, когда в течение 2014 года сначала Росреестр сделает новые сервисы, потом параллельно будут работать два сервиса, и потребители сервисов постепенно смогут переключиться со старого на новый так, чтобы их процессы не пострадали.
Поскольку на долю Росреестра и Казначейства сейчас приходится порядка 70-80% от общего количества запросов, перевод только двух этих сервисов на новые технологии позволит большую часть трафика, которая проходит через СМЭВ, уже сделать с гарантированной доставкой и с поддержкой такого оптимального процесса.
CNews: Для этого нужно, чтобы каждый регион произвел доработку сервисов?
Алексей Козырев: Да, безусловно. Но регионы и так должны будут это сделать в силу того, что нормативка изменилась, т.е. заодно. Даже если бы не было этой технологии, Росреестр все равно бы менял сервис, потому что закон изменился, и регионы все равно бы переподключались. Но здесь мы им даем возможность при этом переподключении сделать универсальный адаптер и ко всем остальным сервисам подцепляться уже без этих интеграционных сложностей.
CNews: Каковы планы по развитию других систем электронного правительства, помимо СМЭВ?
Алексей Козырев: Важно выделить проект по развитию Единой системы нормативно-справочной информации. Ведомства, которые предоставляют сведения, ведут на своей стороне реестр сведений – базы данных, в которых хранятся массы интересных сведений. В этих базах используются справочники, которые ведомства сами определяют и сами ведут. И от актуальности этих справочников, от использования корректных значений полей зависит, насколько эффективно работает межвед. Если, например, в ведомственной системе пол гражданина закодирован как буква «М», буква «Ж» и, допустим, «Неизвестный» – три значения, а в системе, которая запрашивает сведения, мужской пол – единица, женский – ноль, и неизвестный – прочерк, тогда для того, чтобы обеспечить корректное взаимодействие, необходимо сделать перевод значений информационной системы, которая запрашивает, на значения, которые ведутся в ведомственном справочнике. А учитывая, что в ведомственный справочник ведомство вносит изменения, все системы, которые запрашивают сведения, должны получать этот апгрейд.
Единая система нормативно-справочной информации с учетом доработки позволяет ведомствам, которые эти справочники ведут (на этапе обследования мы идентифицировали более 800 таких справочников), выгружать в нее данные при помощи специального терминального решения. Это решение не требует интеграции с информационными системами. Это некий сервис, в который надо делать экспорт данных. А со стороны потребителя сведений такое же терминальное решение позволяет подписаться на обновление справочника, чтобы узнать своевременно о том, что какие-то изменения внесены, и делать маппинг значений из мастер-справочника, который ведомство ведет, на значения справочника, который ведется в своей системе.
Почему это важно? Потому что некоторые справочники в информационных системах зашиты на уровне кода. Например, когда разработчик считает, что, кроме мужского и женского пола, не может быть значений, то вместо того, чтобы делать настраиваемый справочник, он использует жесткие значения «М» и «Ж». Но когда, допустим, в МВД количество полов существенно выше, потому что у них есть, например, «Пол невозможно установить», «Пол сменен» или еще что-то, в системе, где на уровне хардкода этот справочник заведен, возникает необходимость в доработке для того, чтобы адаптироваться конкретно к сведениям МВД. И это опять деньги, проекты по разработке информационной системы.
Разработанная нами технология позволяет настраивать маппинг гибко для того, чтобы в случае изменения справочников, если необходимо начать получать новые сведения, можно было бы это делать тоже настройками, без необходимости что-то кодить. В 2014 мы начинаем ее внедрение.
Короткая ссылка
