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