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

Система межведомственного электронного взаимодействия (СМЭВ), построение которой идет в России напротяжениипоследних нескольких лет, должна помогать органам власти исполнять федеральный закон 210. Согласно одному из пунктов этого документа, с 1 июля 2012 г. чиновники не имеют права требовать с обратившихся к ним за госуслугами граждан дополнительные справки, которые и так есть в распоряжении других чиновников.

Стоит отметить, что идеологически придумана системабыладостаточно давно. Первое упоминание необходимости «автоматизации процессов обмена данными между отдельными ведомственными информационными системами» можно найти еще в концепции формирования в России электронного правительства до 2010 г. Ее в 2007-2008 гг. подготовило Мининформсвязи под руководствомЛеонида Реймана.

С 2008 по май 2012 гг. за создание системы отвечало Минкомсвязи под руководствомИгоря Щеголева. После последней сменыправительствапроект курирует новая команда Минкомсвязи во главе сНиколаем Никифоровым.

«По сути на 1 июля 2012 года, когда вступила в силу статья 210 ФЗ о запрете требования документов у граждан, система не работала, - говорит CNewsАлексей Козырев,с ноября 2012 г.- директор департамента электронного правительства Минкомсвязи и руководитель проектного офиса СМЭВ. -Инфраструктурабыла сформирована, но как ей пользоваться, никто не понимал. Это все равно, что купить машину и не получить права». Чтобы «научиться ездить и получить права», т.е. запустить обмен и начать реальную работу, и был сформирован проектный офис.

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

Алексей Козырев руководит в Минкомсвязи проектным офисом СМЭВ

В России более 24 тыс. органов местного самоуправления, которые участвуют в межведомственном взаимодействии, плюс федеральные органы. Это огромная система, включающая в себя тысячи пользователей, - объясняет он. - При этом нельзя сказать, что это система класса enterprise. Наша система отличается от тех, которые создаются в крупных коммерческих организациях, живущих по вертикально стандартизованным процессам. В регионах и в федеральных ведомствах значительно отличаются и нормативная база, и бизнес-процессы».

Как устроено межведомственное взаимодействие

Физически СМЭВ представляет собой набор из 84 шин Oracle (узлов), расположенных на 7 ЦОДах «Ростелекома» в разных частях России. Один узел СМЭВ используется федеральными органами власти, и по одному - 83 регионами. К каждому региональному узлу подключены местные информационные системы (финансовые, медицинские, статистические и др.), порталы госуслуг, единая система идентификации и аутентификации, удостоверяющий центр, система нормативно-справочной информации и другие компоненты (подробная архитектура СМЭВ будет приведена в статье в ближайшем номережурнала CNews).

Таким образом, посредством СМЭВ интегрируются между собой многочисленные федеральные и региональные информационные системы. При этом каждая точка интеграции является отдельным мини-проектом. «Для того чтобы вся система работала стабильно, нужно, чтобы все эти системы не противоречили друг другу и правильно взаимодействовали между собой», - рассказывает Козырев.

Сервис-ориентированная архитектура СМЭВ предполагает, что поставщик сведений (им может выступать как федеральный орган власти, так и регион) выводит через свою систему в эту шину некий электронный сервис, который при правильном запросе сведений правильно выдает их. А потребитель сведений (также, регион или федеральный орган) через свою систему в шину интегрирует адаптер, который умеет правильно запрашивать сведения и получать ответ.

«Сама по себе СМЭВ, по сути, не является системой. Это такая государственная закрытая сеть, своего рода государственный интернет, к которому подключаются разные ресурсы, - объясняет Козырев. - Чем больше таких ресурсов будет подключено и чем большей функциональностью они будут обладать, тем более функциональна будет система государственного бэк-офиса».

Бесконечные тесты

Рассказывать опроблемныхместах проекта Алексей Козырев начинает с тестирования сервисов: «У каждого федерального органа есть своя уникальная база данных со своей уникальной архитектурой. По методическим рекомендациям они создавали сервисы, которые затем выводили в продуктивный контур СМЭВ. Эти сервисы должны были раздавать сведения, находящиеся в их базах. Чтобы потребитель мог приступить к взаимодействию, он должен был реализовать для себя адаптер и с его помощью попробовать обратиться к сервису. По такой логике возникала необходимость при разработке каждого адаптера проводить тестирование каждого сервиса. При этом в тестировании должен принимать участие и федеральный орган, который вывел сервис, и регион, который через адаптер хочет к этому сервису обратиться. Только в случае если тест проходит успешно, можно считать, что две конкретные системы - федерального органа и региона - интегрированы и могут обмениваться сведениями».

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

Временноерешение

«Тестировать точка в точку мы не могли, таких ресурсов у нас не было. Поэтому мы взяли за основу типовое решение, которое позволяет запрашивать для регионов федеральные сведения и отдавать региональные сведения федералам, - говорит Козырев. - Такое решение тестировалось с каждым федеральным органом один раз, а затем раздавалось регионам как составная часть региональнойинфраструктурыэлектронного правительства в готовом виде. С использованием этого решения неоптимальная практика тестирования региональных разработок перестала быть критичной».

Сейчас типовое решение, по словам главы проектного офиса СМЭВ, раскатано на все регионы. К нему подключены все адаптеры, и регионы имеют возможность запрашивать федеральные сведения. «Задача по настройке и использованию типового решения технически не является сложной, - считает Козырев. - В типовом решении есть три рабочих места - администратора, руководителя и сотрудника, который готовит ответы. Решение является облачным. Настроить его администратор может за один день».

Типовое решение является временным и запасным, уверяют в Минкомсвязи: «Оно не является обязательным. Задачи подменить региональные системы этим решением не стоит. С его помощью необходимо было обеспечить техническую возможность межведомственного взаимодействия для исполнения закона там, где до сих пор не завершена разработка и тестирование собственных систем».

Автоматизация

Постоянным решением проблемы многократного тестирования точек интеграции должен стать автоматизированный подход. «Для того чтобы убедиться, что адаптер работает правильно, нужно в сервис направить запрос и получить ответ, а затем посмотреть, насколько он корректен, - объясняет Алексей Козырев. - Сделав эмулятор сервиса, который использует федеральный орган, и заложив в него протоколы ответов (включая протокол ответа на ошибочные запросы), мы можем исключить сам федеральный орган из тестирования вообще».

Если федеральный орган решает модернизировать свою ИТ-систему и внести изменение в сервис, он сможет это сделать только после того, как внесет изменение в эмулятор. «Мы, как оператор системы, таким образом, можем гарантировано контролировать версионность сервисов, - говорит Козырев. - Это очень важно, т.к. неконтролируемое внесение изменений в сервисы приводит к дестабилизации системы в целом».

Система автоматизированного тестирования, по словам руководителя проектного офиса, во-первых, снимает с федерального органа необходимость участия в тестировании, а, во-вторых, регламент взаимодействия участников СМЭВ по поводу вывода в продуктивный контур их систем – сервисов и адаптеров - сводится к результатам автотестов: «Сейчас процесс тестирования очень сложный и неэффективный, в некоторых случаях он может длиться месяцами. Мы хотим, чтобы это происходило безболезненно для разработчиков сервисов и адаптеров». Козырев рассчитывает, что принцип автоматизированного тестирования заработает в первом полугодии 2013 года.

«Кроме этого мы планируем создать библиотеку адаптеров и стандартных сервисов, которые нужны для ведомственного взаимодействия, так чтобы их могли использовать разработчики в своих системах, - добавляет он. - Фактически это означает, что от текстовых методических рекомендаций мы переходим к техническим стандартам».

Мониторинг работоспособности

Еще одна проблема, по словам чиновника, заключалась в том, что система мониторинга СМЭВ даже оператору системы не позволяла определять, на чьей стороне возникала проблема: «Если сервис был недоступен, мы не знали - не работает ли СМЭВ как транспорт, не работает ли сам сервис или адаптер на стороне потребителя сведений. В результате все участники взаимодействия отрицали, что проблема на их стороне».

Для того чтобы понять, работают ли федеральные сервисы, Минкомсвязи решило использовать то же типовое решение, которое было предложено регионам: «С его помощью мы отправляли контрольный запрос и получали контрольный ответ. Если запрос корректно уходил и на него приходил корректный ответ, мы ставили галочку, что сервис работает. Таким образом, мы протестировали все сведения, которые регионы хотят запрашивать, и убедились, что самые востребованные федеральные сервисы сведения отдают, а при помощи типового решения можно эти сведения запрашивать и получать ответы».

Проблемы с адресацией

«В России 83 региона, от каждого из которых федеральные органы власти должны получать сведения, - вновь напоминает Козырев. - Если на региональном уровне все сервисы одинаковые, то федералу достаточно разработать свой адаптер и забирать с этих стандартных сервисов необходимые сведения. Но система была спроектирована так, что федеральный орган не знал, в каком именно органе местного самоуправления хранится информация, которая ему нужна. Например, если гражданину для получения услуги требуется выписка из домовой книги, федеральному органу неизвестно, в каком органе местного самоуправления ведется эта домовая книга».

Для решения этой проблемы Минкомсвязи приняло решение внедрить в систему маршрутизацию по коду ОКТМО. Этот код привязан к адресу. Зная адрес гражданина, можно определить, в какой орган местного самоуправления отправлять запрос.

Юридическая обоснованность

Организационная сложность, выявленная проектным офисом, заключалась в том, что федеральные органы власти не могли начать выдавать сведения по запросам из регионов до тех пор, пока они не проведут юридическую экспертизу обоснованности запроса. «Если регион своими нормативно-правовыми актами устанавливает определенный порядок оказания госуслуги, который подразумевает межведомственное взаимодействие, федеральный орган для того что бы отдать сведения должен был проверить, все ли правильно оформлено в нормативных актах региона, - объясняет Алексей Козырев. - Т.е. получить доступ к сведениям становилось отдельной проблемой. У нас есть более 24 тыс. органов местного самоуправления, со своей региональной спецификой. Федеральные органы просто не справлялись с этим».

Было принято решение, что юридическую обоснованность будут проверять сами регионы - на уровне губернатора, под его ответственность. Таким образом, если запрос совершается в соответствии с нормативными актами и авторизован с ЭЦП, федеральные сведения предоставляют сведения. «Это решило проблему огромной очереди на получение доступа к федеральным сведениям», - считают в Минкомсвязи.

Избыточнаяинфраструктура

Инфраструктура СМЭВ, представляющая собой 7 физических ЦОДов, по мнению Алексея Козырева, является избыточной: «Когда у нас есть 7 дата-центров, к которым подключено 83 региона, федеральный сервис нужно проксировать на каждый из 83 региональных узлов. Эта процедура повторяется каждый раз, когда в сервис вносятся какие-то изменения. Это огромный объем работы, и это значительно увеличивает трудоемкость поддержки системы».

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

Мнение потребителя

«Новая политика Минкомсвязи помогла нам сильно снизить ненужные затраты, - говорил CNewsСергей Сапельников, заместитель руководителя Росреестра. - Теперь мы не тестируем все десятки тысяч сервисов регионов, а работаем только с 8 «адаптерами», а органы, оказывающие услугу, сами подключают и тестируют свой сервис. Прежний порядок определял лишь форматы запроса и ответа по услугам, которые оказывают ОМСУ и РОИВ. Далее в зависимости от схемы организации оказания услуг в регионе сервисы ОМСУ или централизованные РОИВом сервисы публиковались в СМЭВ и потребитель (Росреестр) должен был оттестировать все, сделать таблицу маршрутизации, и все время держать ее в актуальном состоянии, чтобы знать, куда отправлять запрос. Теперь все РОИВы и/или ОМСУ должны самостоятельно присоединить готовые сервисы к общим для всех адаптерам в СМЭВ и обеспечить маршрутизацию запроса и ответов к ОМСУ и обратно. Для этого используется классификатор ОКТМО».

http://www.cnews.ru/news/top/index.shtml?2013/01/30/517201_2