Поделиться
Как переделывают СМЭВ: ошибки прошлого и новые задачи
В Минкомсвязи заявили о существенных изменениях в системе межведомственного электронного взаимодействия, и рассказали о том, какие преобразования ждут ее в перспективе. Полная версия статьи, посвященной СМЭВ, включая подробную архитектуру системы и мнения пользователей, будет опубликована в ближайшем номере журнала CNews.
Бесконечные тесты
Рассказывать о проблемных местах проекта Алексей Козырев начинает с тестирования сервисов: «У каждого федерального органа есть своя уникальная база данных со своей уникальной архитектурой. По методическим рекомендациям они создавали сервисы, которые затем выводили в продуктивный контур СМЭВ. Эти сервисы должны были раздавать сведения, находящиеся в их базах. Чтобы потребитель мог приступить к взаимодействию, он должен был реализовать для себя адаптер и с его помощью попробовать обратиться к сервису. По такой логике возникала необходимость при разработке каждого адаптера проводить тестирование каждого сервиса. При этом в тестировании должен принимать участие и федеральный орган, который вывел сервис, и регион, который через адаптер хочет к этому сервису обратиться. Только в случае если тест проходит успешно, можно считать, что две конкретные системы - федерального органа и региона - интегрированы и могут обмениваться сведениями».
Если посчитать все тесты, которые федералы и регионы должны были провести, получится около 10 тыс., говорит чиновник. При этом если федеральный орган произвел доработку своей информационной системы и внес изменение в сервис, это автоматически приводит к необходимости тестировать заново все адаптеры. Кроме того, нет никакой гарантии, что тест будет успешно пройден с первого раза. В результате, «бутылочным горлышком» в этом процессе становится федеральный орган, который не может обеспечить постоянное тестирование с каждым регионом. Аналогичная проблема возникает и в ситуации, когда регионы являются поставщиками сведений.
Временное решение
«Тестировать точка в точку мы не могли, таких ресурсов у нас не было. Поэтому мы взяли за основу типовое решение, которое позволяет запрашивать для регионов федеральные сведения и отдавать региональные сведения федералам, - говорит Козырев. - Такое решение тестировалось с каждым федеральным органом один раз, а затем раздавалось регионам как составная часть региональной инфраструктуры электронного правительства в готовом виде. С использованием этого решения неоптимальная практика тестирования региональных разработок перестала быть критичной».
Сейчас типовое решение, по словам главы проектного офиса СМЭВ, раскатано на все регионы. К нему подключены все адаптеры, и регионы имеют возможность запрашивать федеральные сведения. «Задача по настройке и использованию типового решения технически не является сложной, - считает Козырев. - В типовом решении есть три рабочих места - администратора, руководителя и сотрудника, который готовит ответы. Решение является облачным. Настроить его администратор может за один день».
Типовое решение является временным и запасным, уверяют в Минкомсвязи: «Оно не является обязательным. Задачи подменить региональные системы этим решением не стоит. С его помощью необходимо было обеспечить техническую возможность межведомственного взаимодействия для исполнения закона там, где до сих пор не завершена разработка и тестирование собственных систем».
Постоянным решением проблемы многократного тестирования точек интеграции должен стать автоматизированный подход. «Для того чтобы убедиться, что адаптер работает правильно, нужно в сервис направить запрос и получить ответ, а затем посмотреть, насколько он корректен, - объясняет Алексей Козырев. - Сделав эмулятор сервиса, который использует федеральный орган, и заложив в него протоколы ответов (включая протокол ответа на ошибочные запросы), мы можем исключить сам федеральный орган из тестирования вообще».
Если федеральный орган решает модернизировать свою ИТ-систему и внести изменение в сервис, он сможет это сделать только после того, как внесет изменение в эмулятор. «Мы, как оператор системы, таким образом, можем гарантировано контролировать версионность сервисов, - говорит Козырев. - Это очень важно, т.к. неконтролируемое внесение изменений в сервисы приводит к дестабилизации системы в целом».
Система автоматизированного тестирования, по словам руководителя проектного офиса, во-первых, снимает с федерального органа необходимость участия в тестировании, а, во-вторых, регламент взаимодействия участников СМЭВ по поводу вывода в продуктивный контур их систем – сервисов и адаптеров - сводится к результатам автотестов: «Сейчас процесс тестирования очень сложный и неэффективный, в некоторых случаях он может длиться месяцами. Мы хотим, чтобы это происходило безболезненно для разработчиков сервисов и адаптеров». Козырев рассчитывает, что принцип автоматизированного тестирования заработает в первом полугодии 2013 года.
«Кроме этого мы планируем создать библиотеку адаптеров и стандартных сервисов, которые нужны для ведомственного взаимодействия, так чтобы их могли использовать разработчики в своих системах, - добавляет он. - Фактически это означает, что от текстовых методических рекомендаций мы переходим к техническим стандартам».
Мониторинг работоспособности
Еще одна проблема, по словам чиновника, заключалась в том, что система мониторинга СМЭВ даже оператору системы не позволяла определять, на чьей стороне возникала проблема: «Если сервис был недоступен, мы не знали - не работает ли СМЭВ как транспорт, не работает ли сам сервис или адаптер на стороне потребителя сведений. В результате все участники взаимодействия отрицали, что проблема на их стороне».
Для того чтобы понять, работают ли федеральные сервисы, Минкомсвязи решило использовать то же типовое решение, которое было предложено регионам: «С его помощью мы отправляли контрольный запрос и получали контрольный ответ. Если запрос корректно уходил и на него приходил корректный ответ, мы ставили галочку, что сервис работает. Таким образом, мы протестировали все сведения, которые регионы хотят запрашивать, и убедились, что самые востребованные федеральные сервисы сведения отдают, а при помощи типового решения можно эти сведения запрашивать и получать ответы».
Проблемы с адресацией
«В России 83 региона, от каждого из которых федеральные органы власти должны получать сведения, - вновь напоминает Козырев. - Если на региональном уровне все сервисы одинаковые, то федералу достаточно разработать свой адаптер и забирать с этих стандартных сервисов необходимые сведения. Но система была спроектирована так, что федеральный орган не знал, в каком именно органе местного самоуправления хранится информация, которая ему нужна. Например, если гражданину для получения услуги требуется выписка из домовой книги, федеральному органу неизвестно, в каком органе местного самоуправления ведется эта домовая книга».
Для решения этой проблемы Минкомсвязи приняло решение внедрить в систему маршрутизацию по коду ОКТМО. Этот код привязан к адресу. Зная адрес гражданина, можно определить, в какой орган местного самоуправления отправлять запрос.
Юридическая обоснованность
Организационная сложность, выявленная проектным офисом, заключалась в том, что федеральные органы власти не могли начать выдавать сведения по запросам из регионов до тех пор, пока они не проведут юридическую экспертизу обоснованности запроса. «Если регион своими нормативно-правовыми актами устанавливает определенный порядок оказания госуслуги, который подразумевает межведомственное взаимодействие, федеральный орган для того что бы отдать сведения должен был проверить, все ли правильно оформлено в нормативных актах региона, - объясняет Алексей Козырев. - Т.е. получить доступ к сведениям становилось отдельной проблемой. У нас есть более 24 тыс. органов местного самоуправления, со своей региональной спецификой. Федеральные органы просто не справлялись с этим».
Было принято решение, что юридическую обоснованность будут проверять сами регионы - на уровне губернатора, под его ответственность. Таким образом, если запрос совершается в соответствии с нормативными актами и авторизован с ЭЦП, федеральные сведения предоставляют сведения. «Это решило проблему огромной очереди на получение доступа к федеральным сведениям», - считают в Минкомсвязи.
Избыточная инфраструктура
Инфраструктура СМЭВ, представляющая собой 7 физических ЦОДов, по мнению Алексея Козырева, является избыточной: «Когда у нас есть 7 дата-центров, к которым подключено 83 региона, федеральный сервис нужно проксировать на каждый из 83 региональных узлов. Эта процедура повторяется каждый раз, когда в сервис вносятся какие-то изменения. Это огромный объем работы, и это значительно увеличивает трудоемкость поддержки системы».
Выход, по словам Козырева, заключается в упрощении и переходе от фрагментированной инфраструктуры к укрупненной. «Мы смотрим на разные варианты оптимизации», - говорит он.
Мнение потребителя
«Новая политика Минкомсвязи помогла нам сильно снизить ненужные затраты, - говорил CNews Сергей Сапельников, заместитель руководителя Росреестра. - Теперь мы не тестируем все десятки тысяч сервисов регионов, а работаем только с 8 «адаптерами», а органы, оказывающие услугу, сами подключают и тестируют свой сервис. Прежний порядок определял лишь форматы запроса и ответа по услугам, которые оказывают ОМСУ и РОИВ. Далее в зависимости от схемы организации оказания услуг в регионе сервисы ОМСУ или централизованные РОИВом сервисы публиковались в СМЭВ и потребитель (Росреестр) должен был оттестировать все, сделать таблицу маршрутизации, и все время держать ее в актуальном состоянии, чтобы знать, куда отправлять запрос. Теперь все РОИВы и/или ОМСУ должны самостоятельно присоединить готовые сервисы к общим для всех адаптерам в СМЭВ и обеспечить маршрутизацию запроса и ответов к ОМСУ и обратно. Для этого используется классификатор ОКТМО».
Мнения других пользователей СМЭВ будут представлены в полной версии статьи, которая выйдет в ближайшем номере журнала CNews.
Короткая ссылка
