Данная статья будет интересна узкому кругу читателей Хабра — разработчиков федеральных информационных систем и широкому — тех, кому с этими системами уже приходилось, приходится или придется взаимодействовать в будущем.
Повествование будет вестись на примере ФИС ГИА и приема (это название присвоено Д. Медведевым 31.08.2013 г., предыдущие полтора года система была известна под именем, данным В. Путиным — ФИС ЕГЭ и приема).
Что это вообще такое и кому оно нужно?
Федеральная информационная система обеспечения проведения государственной итоговой аттестации обучающихся и приема граждан в образовательные организации (полное название по ссылке) — система, созданная в интересах Рособрнадзора, в которую вузы и ссузы уже 3 года обязаны заносить сведения о ходе приёмной кампании, включая персональные данные всех абитуриентов. А именно, до начала приема туда в определенном формате передаются количество мест, перечни вступительных испытаний, разрешенные льготы, а во время — данные о заявлениях абитуриентов, включая ФИО и реквизиты паспорта, практически в режиме реального времени.
Теоретически надзорное ведомство таким образом проверяет, не нарушается ли где-нибудь утвержденный Министерством Порядок приема. На практике же наказания пока случались только за не-передачу данных в систему.
Взаимодействие образовательных учреждений с ФИС
Все учреждения высшего и среднего профессионального образования обязаны ежедневно передавать в ФИС сведения о ходе приема. Для этого предусмотрен как веб-интерфейс ввода и просмотра данных, так и сервис автоматизированного взаимодействия для пакетной передачи в XML-формате. Теоретически всё красиво, но есть толстые нюансы. Первый — это скорость взаимодействия: в ручном режиме на ввод одного заявления в часы пиковых нагрузок уходит до 20 минут, а в автоматизированном пакеты могут ждать обработки в очереди сутками. Второй — ошибки в работе программного обеспечения, порождающие противоречия в данных. Но обо всём по порядку.
Проектирование модели данных
В предметной области приемной кампании один абитуриент может подать до трех заявлений в вуз. В случае передачи данных в XML различные сущности представляются в виде элементов дерева. Как бы вы решили задачу представления заявлений в XML? Очевидно, заявления привязаны к абитуриенту и логично разместить сведения о личности абитуриента в элементе более высокого уровня, а о поданных им заявлениях — во вложенных элементах. Однако разработчики ФИС поступили наоборот: сведения об абитуриенте повторяются в каждом заявлении и даже могут противоречить друг другу, и тогда в веб-интерфейсе появляется несколько строчек с одинаковыми ФИО, но разными, например, паспортными данными. При этом ссылки из всех таких строк ведут в одну и ту же карточку, в которой отображается только один случайный паспорт из нескольких противоречивых.
Еще из замечательного. Понятно, что в XML производится только обмен данными, а внутреннее представление в системе является всё-таки реляционным и хранится в приличной СУБД. И тогда возникает очень хорошая идея — добавить в протокол обмена первичные ключи сущностей, используемые в системах вузов, являющихся источниками данных. Ведь это должно упростить выявление новых сущностей и обновление старых. Но следует ли исходить из того, что все клиентские системы имеют аналогичную модель данных и реляционная ли она в них вообще? Наверняка вузовским программистам клиентов обмена данными забавно будет столкнуться с необходимостью генерировать уникальный и неизменный идентификатор там, где его отродясь не было, или опытным путем наткнуться на ошибку, при которой идентификатор аттестата и, например, диплома олимпиады не могут совпадать (видимо, в ФИС все документы хранятся в одной таблице, но где это отражено в документации?)
Документация
Грамотная документация при публикации в продакшн системы, с которой должны стыковаться сотни и тысячи разношерстных систем поменьше — залог успеха. Грустно, что разработчики ФИС не смогли решить эту задачу даже за 3 года, хотя некоторый прогресс всё-таки имеется. Опубликованная структура XML в виде PDF-документа и XSD-схемы, безусловно, необходима. Но важно хотя бы проверить, чтобы XSD была, во-первых, валидной, а во-вторых — не конфликтовала с эталонным XML-документом. Иначе сотни сторонних разработчиков будут исправлять корявые regex-ы и досадные length=«50» вместо maxLength=«50» вместо тех, кому это положено.
Кроме того, формального описания протокола обмена категорически недостаточно, ведь в случае сложной структуры данных система будет принимать не любой валидный пакет, а только тот, который удовлетворяет ряду дополнительных проверок на адекватность. Один из примеров с внешними ключами приведен выше.
Ограничения и проверки при взаимодействии с внешними клиентами
Вообще, не перейти тонкую грань между необходимыми проверками и избыточными ограничениями, не пропускающими корректные данные — почти как удержаться на лезвии ножа. И главное здесь — доскональное понимание предметной области перед началом разработки. В частности, разработчики ФИСа в этом году начали резать вполне допустимый в ряде случаев прием заявлений на нулевые квоты. Когда стоит цель сбора информации, лучше разрешить загрузку некорректных на первый взгляд данных для последующего анализа, а отсекать только заведомо неполные.
Ошибки в системе и рекомендации разработчикам сопрягаемых систем
ФИС в частности и, подозреваю, государственные системы вообще — замечательный образец нестабильных «партнеров» для оттачивания навыков взаимодействия с удаленными системами, когда следует проверять абсолютно все. Например, отправлен XML в HTTP-запросе и в ответ ожидается другой XML, но:
1. Может просто оборваться сетевое соединение.
2. Может случиться таймаут и его, кстати, лучше заранее сделать разумным, так как иначе ожидание ответа может растянуться на часы.
3. В ответ может придти не XML вовсе, а что угодно.
4. Может придти XML, не соответствующий заявленной разработчиком схеме.
5. Придет XML, но данные в нем будут противоречивы. Пример — в запросе отправлено 100 объектов для импорта, в ответе ожидается количество успешно импортированных и перечень незагруженных из-за ошибок. На поверку же в ответе оказывается всего 83 объекта, а где искать остальные 17 и какие в итоге вообще загружены — остается загадкой.
Теоретически все описанные ситуации банальны, но далеко не в любой системе все они встречаются регулярно с высокой вероятностью.
Организация подключения к системе и защита ПДн
Для тех, кто дочитал до этого абзаца — самое интересное. ФИС ГИА и приема расположена в закрытой сети Федерального центра тестирования, к которой вузы подключаются через VPN-клиенты ViPNET. Кроме того, за приличные деньги навязывается некое уникальное решение малоизвестной фирмы-монополиста для фильтрации данных на стороне клиента, «чтобы не выкачать из системы с персональными данными миллионов граждан лишнего». Объяснение, почему эта фильтрация должна производиться у каждого клиента, а не единственный раз на серверной стороне, отсутствует. По косвенным признакам данное уникальное решение является всего лишь прокси-сервером, фильтрующим допустимые URL при работе с сервером ФИС.
Однако недавно пытливые умы заметили, что если в просмотре результатов импорта пакетов в веб-интерфейсе случайно (или намеренно) указать другой идентификатор пакета, то он откроется! И не только откроется, а еще и позволит скачать XML-файл со всеми данными всех абитуриентов, включая паспорта, данные о предыдущем образовании, сведения о льготах, в т.ч. медицинских, и т.д. Таким образом, любой пользователь, имеющий доступ к ФИС, имеет возможность получить простым перебором данные значительной части абитуриентов за последние 3 года.
Резюме
В заключение напрашиваются одни банальности, но, поскольку с этой ФИС и ей подобными предстоит столкнуться еще тысячам и тысячам айтишников, думаю, можно их написать.
Для тех, кому предстоит взаимодействовать с недостаточно продуманными, плохо документированными специфическими информационными системами, сделанными по госзаказу — будьте готовы ко всему и сразу закладывайте в алгоритм обмена все мыслимые и немыслимые ошибки, доверять нельзя ни в чем. Даже в условиях недостатка времени на разработку лучше заложить максимум проверок.
Удачи вам!
Автор:
