Привет, Хабр! Меня зовут Дима. Я работаю в отделе разработки систем межведомственного взаимодействия РЕД СОФТ. Представляю вам вторую статью про импортозамещение в АИС ФССП России, в которой я расскажу о проектировании сложных территориально распределённых информационных систем.
В прошлом материале "Распределённые системы на службе ФССП России. Часть 1. МВВ" мы писали об общей архитектуре АИС ФССП России и подсистемах, которые она включает. В этой статье подробнее остановимся на важном проекте, которым мы занимались при работе над АИС — суперсервис «Цифровое исполнительное производство».
Для тех, кто впервые слышит про суперсервисы, поясним подробнее что это такое.
Суперсервисы — это комплексы государственных услуг, сгруппированные по типичным жизненным ситуациям. На Едином портале государственных услуг вы можете получить эти услуги онлайн в сокращённые сроки. В зависимости от жизненной ситуации, сервис предоставляет услуги, напоминает о положенных выплатах и присылает уведомление, сообщая о готовности документов. Без бумажных документов и очередей.
На Хабре есть обзорная статья про этот проект: "Пять первых государственных суперсервисов открылись для публичного тестирования".
Суперсервис Цифровое исполнительное производство (ЦИП)
Суперсервис «Цифровое исполнительное производство» (далее по тексту - ЦИП), развиваемый Федеральной службой судебных приставов, позволяет пользователям портала госуслуг — гражданам и предпринимателям — получать в электронном виде исчерпывающие сведения о ходе исполнительного производства, о ходе снятия ограничения выезда, позволяет пользователям подавать заявления приставам. Информация выдаётся автоматически, без необходимости личного взаимодействия с судебным приставом-исполнителем. При этом повысилась её точность и оперативность предоставления. В сервис поступают все процессуальные документы АИС ФССП России, в том числе, вынесенные в формате принудительное исполнение в электронном виде (далее по тексту - ПИЭВ).
Сама концепция суперсервиса ЦИП преследовала следующие цели:
упростить взаимодействие граждан с приставами, исключив личные встречи (это было особенно важно в период пандемии);
ускорить информирование и документооборот, повышение осведомленности всех сторон исполнительного производства, включая физических и юридических лиц, взыскателей и должников;
помочь упростить процесс подачи заявлений, жалоб, ходатайств в ФССП России;
повысить прозрачность работы судебного пристава-исполнителя;
снизить нагрузку на судебного пристава-исполнителя;
сократить издержки для организаций на взаимодействие с ФССП России;
сократить издержки для государства.
В нелёгкий для всех 2020 год, в условиях удалёнки, нашей команде представилась возможность реализовать этот важный для общества проект.
Исходя из целей, мы сформировали следующие требования к системе:
высокая скорость автоматического предоставления расширенных сведений, которые на тот момент хранились и собирались в разных местах системы;
обширный перечень документов и данных для формирования ответов;
повышенная актуальность предоставляемых сведений (по некоторым услугам до нескольких минут);
высокая доступность услуг (порядка 99.9%);
значительные объёмы данных, как хранимых, так и передаваемых пользователю. Например, запрос списка исполнительных производств для некоторых банков, где банк является взыскателем, исчисляется сотнями тысяч;
быстрая и гарантированная доставка заявлений, уведомлений, ответов и платежей. Особенно актуально в случае, если гражданин оплатил долг в аэропорту при выезде за границу и отслеживает ход этого процесса.
Однако с технической точки зрения, чтобы реализовать все эти требования, включая показатели назначения, кроме реализации самих сервисов, нам пришлось существенно переработать часть подсистемы межведомственного взаимодействия АИС ФССП России (далее по тексту - МВВ) и ИТ-инфраструктуру службы ФССП России, в том числе состав и модель многих реестров банка данных, добавить новые реестры и документы, перепродумать архитектуру построения и работы самого банка данных. При проектировании и реализации суперсервиса в наш техностек и инфраструктуру ФССП России в достаточно короткие сроки пришлось включить абсолютно новые для компании и достаточно смелые решения, такие как основное распределённое хранилище данных и транспорт гарантированной доставки сообщений. И немаловажно, что все они являются продуктами с открытым исходным кодом.
Госуслуги, предоставляемые в рамках суперсервиса ЦИП, можно разделить на две категории: интерактивные и неинтерактивные. К первой категории относятся услуги, ответ на которые должен быть предоставлен пользователю немедленно. И это означает, что услуги имеют строгие ограничения по времени и доступности. Например, предоставление информации о ходе и наличии исполнительного производства или информации о ходе снятия ограничения выезда. К неинтерактиным относится подача заявлений и ходатайств. Ответ на них не всегда автоматический, требования к времени ответа не такие жесткие, как у интерактивных услуг, но их требуется гарантированно доставить до ответственного лица — судебного пристава- исполнителя.
Услуги суперсервиса ЦИП
Госуслуга «Ход исполнительного производства»
Примером того, насколько мы достигли поставленные цели, может продемонстрировать госуслуга по предоставлению информации о ходе исполнительного производства. Это первая услуга из перечня суперсервисов, которую мы вывели в бой, и её работу уже оценили в Минцифры Роcсии как самую быструю на портале госуслуг и одну из самых популярных.
Суть услуги в предоставлении стороне исполнительного производства (должнику или взыскателю) исчерпывающей информации о ходе его производства за предельно короткое время через портал госуслуг. В рамках услуги предоставляются все необходимые документы, расчёты и прочие сведения.
Стоит отметить, что ранее для Системы межведомственного электронного взаимодействия (далее по тексту - СМЭВ) второй версии была доступна предыдущая версия государственной услуги. Она отличалась от нынешней составом предоставляемых сведений, который ранее был значительно более скудным. О ней я рассказывал в 2019 году: "Высоконагруженные сервисы электронного правительства / Дмитрий Горчаков, Кристина Моргаева".
Интерактивные услуги для суперсервиса включают ещё две услуги:
Госуслуга «Информация о наличии ИП из банка данных»
Должник или взыскатель, введя свои данные, может получить список актуальных исполнительных производств. Как и предыдущей, пользоваться данной услугой могут как граждане так и организации.
Госуслуга «Информация о ходе снятия ограничения выезда»
Граждане, имеющие задолженности, могут отслеживать процесс снятия ограничения на выезд через госуслуги сразу после оплаты долга.
По данным из открытых источников, с января по декабрь 2022 года более 15 млн должников были включены в списки невыездных из-за задолженностей. Для того, чтобы ограничение на выезд было снято, необходимо погасить долг. Но после оплаты долга пройдет еще какое-то время, прежде чем пограничники смогут пропустить человека. Все дело в юридической процедуре: сначала пристав должен увидеть, что долг погашен. Затем ему необходимо вынести соответствующее постановление и направить его в Пограничную службу ФСБ России. На все процедуры суммарно могло уходить от нескольких дней до нескольких недель.
Должник сам мог поспособствовать ускорению процесса. Например, при оплате долга банковским переводом мог направить приставу по электронной почте скан квитанции об уплате. Однако после этого проблема оставалась – информация от приставов до пограничников доходила не моментально и даже не за несколько часов.
В рамках суперсервиса, мы оптимизировали процессы по выставлению начислений и получения платежей из Казначейства России. На нашей стороне и стороне Пограничной службы существенно переработан обмен по доставке постановлений об ограничении и снятии ограничения на выезд. Теперь данные о ходе снятия обновляются в течение нескольких минут.
От интерактивной услуги по предоставлению информации о ходе снятия ограничения выезда также требовалось высокая доступность и скорость предоставления актуальных сведений. А для анализа данных использовалось множество различных сведений - от информации об исполнительном производстве должника до состояния маршрута доставки платежа и постановлений о снятии ограничения на выезд.
Это не полный перечень доступных обменов в суперсервисе ЦИП. Кроме того, он включает доставку заявлений и ходатайств судебным приставам-исполнителям, а также сервисы по выставлению начислений и приёму платежей. Серьёзным изменениям подверглись существующие системы, например, программный комплекс отдела судебных приставов (далее по тексту - ПК ОСП), в котором непосредственно ведутся исполнительные производства.
Архитектура
В архитектуре суперсервиса ЦИП активно применялись технологии построения распределённых систем с высокими показателями отказоустойчивости и надёжности, а также скорости вычислений. Все компоненты суперсервиса резервируются и могут горизонтального масштабироваться. Это необходимо для обеспечения показателей отказоустойчивости и доступности сервиса и времени предоставления ответа независимо от сбоев.
Архитектура сервиса интерактивных запросов
Описывать архитектуру всех реализованных обменов в суперсервисе излишне, остановимся на архитектуре сервисов предоставления интерактивных услуг. В их состав входят:
услуга информации о ходе исполнительного производства: отвечает за отслеживание хода исполнительного производства;
услуга информации о наличии исполнительного производства: предоставляет информацию о наличии исполнительного производства и его статусе;
услуга хода снятия ограничения на выезд: позволяет проверить наличие ограничений на выезд и получить информацию о процедуре снятия ограничений.
Подробнее как работает обмен по интерактивным запросам и какие присутствуют информационные потоки.
Начнём с фронтальных модулей СМЭВ3 адаптеров. Их главное предназначение — работа с веб-сервисом очередей СМЭВ3.
Кратко о СМЭВ3 и его сервисе работы с очередями вы можете почитать в статье на Хабре: "Под капотом Госуслуг: про СМЭВ3 от первого лица".
Запросы из портала госуслуг поступают во входящую очередь СМЭВ3 для вида сведений (далее по тексту - ВС).
Пример SOAP сообщения с запросом из входящей очереди выглядит так:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<ns2:GetRequestResponse xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1">
<ns2:RequestMessage>
<ns2:Request xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" Id="SIGNED_BY_SMEV">
<ns2:SenderProvidedRequestData xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1" Id="SIGNED_BY_CALLER">
<ns2:MessageID>b757d995-044b-11ee-a0b6-42d188083b2c</ns2:MessageID>
<MessagePrimaryContent>
<fssp:EPGURequest xmlns:fssp="urn://x-artifacts-fssp-ru/mvv/smev3/epgu/1.0.0" Env="DEV">
<fssp:OrderId>2161260451989514</fssp:OrderId>
<fssp:Date>2023-06-06T12:22:53.644757</fssp:Date>
<fssp:Department>ФССП России</fssp:Department>
<fssp:DepartmentCode>00000</fssp:DepartmentCode>
<fssp:ReceiverID>FSSP11</fssp:ReceiverID>
<fssp:ServiceCode>10001449665</fssp:ServiceCode>
<fssp:TargetCode>389825677</fssp:TargetCode>
<fssp:StatementDate>2023-06-06</fssp:StatementDate>
</fssp:EPGURequest>
</MessagePrimaryContent>
<AttachmentHeaderList>
<AttachmentHeader>
<contentId>piev_epgu.zip</contentId>
<MimeType>application/zip</MimeType>
<SignaturePKCS7>MIIMJwYJKoZI...vuYKg==</SignaturePKCS7>
</AttachmentHeader>
</AttachmentHeaderList>
<ns2:BusinessProcessMetadata/>
</ns2:SenderProvidedRequestData>
<ns2:MessageMetadata xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1">
<ns2:MessageId>b757d995-044b-11ee-a0b6-42d188083b2c</ns2:MessageId>
<ns2:MessageType>REQUEST</ns2:MessageType>
<ns2:Sender>
<ns2:Mnemonic>MNSV49</ns2:Mnemonic>
<ns2:HumanReadableName>DEV2_ЕПГУ</ns2:HumanReadableName>
</ns2:Sender>
<ns2:SendingTimestamp>2023-06-06T12:22:54.450+03:00</ns2:SendingTimestamp>
<ns2:DestinationName>unknown</ns2:DestinationName>
<ns2:Recipient>
<ns2:Mnemonic>FSSP11</ns2:Mnemonic>
<ns2:HumanReadableName>Подсистема МВВ АИС ФССП России.ЕПГУ.Информация о ходе снятия ограничения выезда</ns2:HumanReadableName>
</ns2:Recipient>
<ns2:SupplementaryData>
<ns2:DetectedContentTypeName>not detected</ns2:DetectedContentTypeName>
<ns2:InteractionType>NotDetected</ns2:InteractionType>
</ns2:SupplementaryData>
<ns2:DeliveryTimestamp>2023-06-06T12:23:11.515+03:00</ns2:DeliveryTimestamp>
<ns2:Status>responseIsDelivered</ns2:Status>
</ns2:MessageMetadata>
<ns2:ReplyTo>eyJzaWQiOjE2OTQzOSwibWlkIjoiYjc1N2Q5OTUtMDQ0Yi0xMWVlLWEwYjYtNDJkMTg4MDgzYjJjIiwiZW9sIjowLCJydHRsIjowLCJydGkiOmZhbHNlLCJzbGMiOiJ4LWFydGlmYWN0cy1mc3NwLXJ1X212dl9zbWV2M19lcGd1XzEuMC4wX0VQR1VSZXF1ZXN0IiwibW5tIjoiTU5TVjQ5IiwibnMiOiJ1cm46Ly94LWFydGlmYWN0cy1mc3NwLXJ1L212di9zbWV2My9lcGd1LzEuMC4wIiwicmVvbCI6MCwib3JpZCI6bnVsbH0=</ns2:ReplyTo>
</ns2:Request>
<AttachmentContentList xmlns="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/basic/1.1" xmlns:ns2="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/1.1" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns3="urn://x-artefacts-smev-gov-ru/services/message-exchange/types/faults/1.1">
<AttachmentContent>
<Id>piev_epgu.zip</Id>
<Content>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:piev_epgu.zip"/>
</Content>
</AttachmentContent>
</AttachmentContentList>
<ns2:SMEVSignature>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34102012-gostr34112012-256"/>
<ds:Reference URI="#SIGNED_BY_SMEV">
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:Transform Algorithm="urn://smev-gov-ru/xmldsig/transform"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="urn:ietf:params:xml:ns:cpxmlsec:algorithms:gostr34112012-256"/>
<ds:DigestValue>JDkkHS3VRm2Rhj9j0dpjxqRB5tN3hJsSx4g1Jj7eEy4=</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>mN4FK92XyqLGhJqgBNe85owwlhX3/XPuK68TIf9T6jWowRlg0X5LSXUZxi5DOeqLSQ9+ycKjA/0KDyw2CuR4mw==</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>MIIJFDCCCM...fq+</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</ns2:SMEVSignature>
</ns2:RequestMessage>
</ns2:GetRequestResponse>
</soap:Body>
</soap:Envelope>Сами данные запросы передаются как MTOM в архиве piev_epgu.zip отдельными HTTP пакетами.
Каждый СМЭВ3-модуль использует специально разработанные адаптеры для получения SOAP-запросов из входящей очереди. Затем по коду услуги он определяет целевой топик в кластере очередей сообщений. СМЭВ3-модуль помещает сообщение в этот топик и передаёт подтверждение в СМЭВ3. Важный момент, запросы в СМЭВ3 очереди имеют ограниченное время жизни, и объём очереди ограничен. Чтобы избежать переполнения и потери сообщений, работа по получению сообщений не должна прерываться, даже во время обновлений или сбоев. Для этих целей отказоустойчивости в кластере развёрнуто несколько узлов СМЭВ3 модуля. В случае сбоя, падения или иного отказа, процесс получения запросов продолжается за счёт оставшихся доступных узлов. Модуль также содержит БД для хранения фактов отправки сообщений, статистики и механизма переотправок.
Подпись сообщений и проверка подписи с валидацией сертификатов происходит на специально выделенном сервисе, который представляет собой кластер крипто-модулей. Крипто-модуль принимает синхронные HTTP-запросы на подпись или проверку подписи сообщения и, имея доступ к физическому токену подписывает сообщение или валидирует подпись. Каждый крипто-модуль содержит небольшую по объему БД для хранения настроек, списка сертификатов и их отзывов. Можно их считать как stateless-сервисы. Для балансировки нагрузки между узлами кластера используется Nginx.
Кластер очередей сообщений на базе Apache Kafka разделён на множество топиков каждый из которых соответствует определённой госуслуге и определялся её кодом. Такое разделение на топики позволяет максимально изолировать обработку каждой услуги и избежать проблем с очередями или всплесков обмена для одной услуги, которые могут повлиять на другие.
Пример сообщения-запроса для услуги хода исполнительного производства:
{
"senderId":861837413621,
"requestId": null,
"sender": {
"organization": "ЕПГУ",
"department": null,
"protocol": "SS_GU_INT_IPSIDE_FL"
},
"receiver": {
"organization": "ФССП",
"department": "00000",
"protocol": "SS_GU_INT_IPSIDE_FL"
},
"content": "PGZzc3A6RV...ZXN0Pg==",
"sig": null,
"smevMessageId": "4a7df0d4-e818-11ed-8f54-1ef3d80c451e",
"smev3Type": "REQUEST",
"replyTo": "eyJtaWQiOiI0YTdkZjBkNC1lODE4LTExZWQtOGY1NC0xZWYzZDgwYzQ1MWUiLCJydGkiOmZhbHNlLCJzbGMiOiJ4LWFydGlmYWN0cy1mc3NwLXJ1X212dl9zbWV2M19lcGd1XzEuMC4wX0VQR1VSZXF1ZXN0IiwibW5tIjoiTU5TVjAzIiwiY3J0IjoiMjAyMy0wNS0wMVQxNTowNDoxNC42NjkrMDM6MDAiLCJjaWQiOiI0YTdkZjBkNC1lODE4LTExZWQtOGY1NC0xZWYzZDgwYzQ1MWUiLCJucyI6InVybjovL3gtYXJ0aWZhY3RzLWZzc3AtcnUvbXZ2L3NtZXYzL2VwZ3UvMS4wLjAiLCJzaWQiOjM0NTA3LCJydHRsIjowLCJyZW9sIjowLCJvcmlkIjpudWxsLCJlb2wiOjB9",
"messageDate": 1682942654803,
"attachments": [
{
"data": "UEsDBBQACAAIAId4oVYAAAAAAAAAAAAAAAANA...A7AAAAdgIAAAAA",
"sig": "MIIMbgYJKoZIhvc...RvGPNW8nYl",
"filename": "piev_epgu.zip",
"contentType": "application/zip",
"dataLength": null,
"remoteDataDirName": null,
"indexServerBlob": null
}
],
"records": [],
"properties": {
"mqClientName": "SMEV3-GU-FSSP07-10003818851",
"ReceiverID": "FSSP07",
"deliveryTime": "01.05.2023, 15:04:14.771",
"TargetCode": "10003818851",
"messageId": "4a7df0d4-e818-11ed-8f54-1ef3d80c451e",
"OrderId": 1682942654384,
"sendingTime": "01.05.2023, 15:04:14.669"
},
"directive": false
}Где, поле content содержит СМЭВ заголовок, например такой:
<fssp:EPGURequest xmlns:fssp="urn://x-artifacts-fssp-ru/mvv/smev3/epgu/1.0.0" Env="PROD">
<fssp:OrderId>1682942654384</fssp:OrderId>
<fssp:Date>2023-05-01T15:04:14.384603</fssp:Date>
<fssp:Department>ФССП</fssp:Department>
<fssp:DepartmentCode>00000</fssp:DepartmentCode>
<fssp:ReceiverID>FSSP07</fssp:ReceiverID>
<fssp:ServiceCode>10001449665</fssp:ServiceCode>
<fssp:TargetCode>10003818851</fssp:TargetCode>
<fssp:StatementDate>2023-05-01</fssp:StatementDate>
</fssp:EPGURequest>Сами данные передаются в поле attachments/data в виде закодированного в base64 zip архива. Однако, если данные занимают значительный объём, то вместо передачи самого архива передается ссылка на его общий доступ.
Топики в Kafka кластере разделены на реплицируемые партиции с отказоустойчивым распределением мастер-партиций и реплик на разных физических серверах.
Для каждого топика очереди сообщений назначена группа потребителей-обработчиков, которые соответствуют конкретной услуге. Например, группа обработчиков для услуги «Информация о ходе исполнительного производства из банка данных для физических лиц». Количество обработчиков определятся нагрузкой, и остановка или сбой потребителя не должны влиять на работоспособность сервиса. В этом случае потребителями назначаются другие доступные запущенные обработчики из группы. В обработчиках используется БД для хранения полученных запросов и сформированных ответов.
Теперь подробнее о формате запросов и ответов. Они формируются в специально утверждённых прикладных форматах ПИЭВ.
Пример XML интерактивного запроса в формате ПИЭВ:
<fssp:IRequest xmlns:fssp="http://www.fssprus.ru/namespace/incoming/2019/1">
<fssp:ExternalKey>1682942654384</fssp:ExternalKey>
<fssp:DocType>I_IPSIDE_FSSP_INTERACTIVE</fssp:DocType>
<fssp:DocName>Заявление о предоставлении информации о ходе исполнительного производства из банка данных</fssp:DocName>
<fssp:DocDate>2023-05-01</fssp:DocDate>
<fssp:DeloNum>XXX/XX/XXX83-ИП</fssp:DeloNum>
<fssp:ComplainerType>2</fssp:ComplainerType>
<fssp:AuthorName>Тестовый Иван Тестович</fssp:AuthorName>
<fssp:ComplainerGender>1</fssp:ComplainerGender>
<fssp:AuthorBorn>1991-01-01</fssp:AuthorBorn>
<fssp:AuthorSnils>105XXXXXXX1</fssp:AuthorSnils>
<fssp:AuthorBackAddrType>ЕПГУ</fssp:AuthorBackAddrType>
<fssp:AuthorBackAddr>105XXXXXXX1</fssp:AuthorBackAddr>
<fssp:SimpleDigSignature>105XXXXXXX1</fssp:SimpleDigSignature>
<fssp:Sendlist>
<fssp:Receiver>ФССП</fssp:Receiver>
<fssp:ReceiverDivisionCode>00000</fssp:ReceiverDivisionCode>
<fssp:ReceiverAddrType>ВЕБ-СЕРВИС</fssp:ReceiverAddrType>
<fssp:ReceiverAddr>00000</fssp:ReceiverAddr>
</fssp:Sendlist>
</fssp:IRequest>И ответа с данными:
<IRequest xmlns="http://www.fssprus.ru/namespace/incoming/2019/1">
<ExternalKey>811050038666</ExternalKey>
<Barcode>500XXXX/0000</Barcode>
<DocType>O_IPSIDE_OSP_COURSEIP_INT</DocType>
<DocName>Уведомление о ходе исполнительного производства из банка данных</DocName>
<DocDate>2023-05-01</DocDate>
<Text>Сведения об исполнительном производстве № XXXXX/23/XXXXX-ИП предоставлены по состоянию на 01.05.2023 15:03 в ответ на заявление о предоставлении информации о ходе исполнительного производства от 01.05.2023.
Настоящее уведомление сформировано автоматически в ФГИС №0133 «Автоматизированная информационная система Федеральной службы судебных приставов».</Text>
<AuthorName>Центральный аппарат Федеральной службы судебных приставов</AuthorName>
<AuthorAddress>107996, Россия, г. Москва, , , , ул. Кузнецкий Мост, 16/5, 1, </AuthorAddress>
<AuthorEmail>ca@fssprus.ru</AuthorEmail>
<AuthorOkogu>13176</AuthorOkogu>
<AuthorShortName>Центральный аппарат</AuthorShortName>
<MinistryName>МИНИСТЕРСТВО ЮСТИЦИИ РОССИЙСКОЙ ФЕДЕРАЦИИ</MinistryName>
<AuthorDivisionCode>00000</AuthorDivisionCode>
<QueryKey>1682942609984</QueryKey>
<QueryDate>2023-05-01</QueryDate>
<Sendlist>
<Receiver>Тестовый Иван Тесторович</Receiver>
<ReceiverAddrType>ЕПГУ</ReceiverAddrType>
<ReceiverAddr>10XXXXXXX27</ReceiverAddr>
</Sendlist>
<IPAcctRecords>
<AccDate>2023-02-22</AccDate>
<RegType>201</RegType>
<DestType>01</DestType>
<Amount>18.86</Amount>
</IPAcctRecords>
<IPAcctRecords>
<AccDate>2023-03-29</AccDate>
<RegType>101</RegType>
<DestType>00</DestType>
<Amount>398.12</Amount>
<RecipTransmitName>ООО "Рога и Копыта"</RecipTransmitName>
</IPAcctRecords>
<IPDocsInfo>
<OIpId>45351535876231</OIpId>
<IpId>45351535794343</IpId>
<DocNumber>XXXXX/23/XXXXX</DocNumber>
<DocDate>2023-02-22</DocDate>
<DocType>I_ANSWER</DocType>
<DocTypeName>Ответ на запрос информации о должнике или его имуществе</DocTypeName>
<Correspondents>
<CorrespondentName>АО «БАНК»</CorrespondentName>
</Correspondents>
</IPDocsInfo>
<IPDocsInfo>
<OIpId>45351535848206</OIpId>
<IpId>45351535794343</IpId>
<DocNumber>XXXXX/23/XXXXXX</DocNumber>
<DocDate>2023-02-22</DocDate>
<SpiFio>Иванов Иван Иванович</SpiFio>
<DocType>O_IP_RES_REOPEN</DocType>
<DocTypeName>Постановление о возбуждении исполнительного производства</DocTypeName>
</IPDocsInfo>
<AdvancedIPInformation>
<IpId>45351535794343</IpId>
<IDTypeCode>1</IDTypeCode>
<IDOrgCode>-21214</IDOrgCode>
<IDOrganName>ПЕРВОМАЙСКИЙ РАЙОННЫЙ СУД Г. КРАСНОДАРА</IDOrganName>
<IDNum>ФС 0321XXXXX</IDNum>
<IDDate>2022-09-30</IDDate>
<number>XXXXX/23/XXXXX-ИП</number>
<riseDate>2023-02-22</riseDate>
<numberComposite>Значение не указано</numberComposite>
<debtText>Иные взыскания имущественного характера в пользу физических и юридических лиц</debtText>
<debtorName>ООО "КОЛЛЕКТИВ"</debtorName>
<debtorINN>230824XXXX</debtorINN>
<debtorAddress>РОССИЯ,125167,Г. МОСКВА , , , ,...</debtorAddress>
<crdrName>Тестов Тестер Тестович</crdrName>
<crdrBirthDate>1988-01-01</crdrBirthDate>
<debtSum>120.86</debtSum>
<debtRestTotal>69.12</debtRestTotal>
<debtRestIP>69.12</debtRestIP>
<debtRestDuty>0.00</debtRestDuty>
<debtRestOther>0.00</debtRestOther>
<ospCode>77035</ospCode>
<divName>Савеловский отдел судебных приставов ГУФССП России по г. Москве</divName>
<divAdr>127083, Россия, , , г. Москва, ,... </divAdr>
<SPIShortName>Иванов И. И.</SPIShortName>
<SPITelephone>+7(499)XXX-XX-XX</SPITelephone>
<actualityDate>2023-04-30T02:05:19</actualityDate>
<unifoChargeFssp>322770352300XXXXXXXX</unifoChargeFssp>
</AdvancedIPInformation>
<ArrestInfo>
<OIpId>45351535895750</OIpId>
<DocDate>2023-02-27</DocDate>
<DocType>O_IP_ACT_BAN_GIBDD</DocType>
<DocName>Постановление о запрете регистрационных действий и действий по распоряжению в отношении транспортных средств</DocName>
<Description>***</Description>
<Type>04</Type>
</ArrestInfo>
<ArrestInfo>
<OIpId>45351536158122</OIpId>
<DocDate>2023-02-27</DocDate>
<DocType>O_IP_ACT_BAN_EGRUL</DocType>
<DocName>Постановление о запрете по внесению изменений в Единый государственный реестр юридических лиц</DocName>
</ArrestInfo>
<ArrestInfo>
<OIpId>45351539303957</OIpId>
<DocDate>2023-03-28</DocDate>
<DocType>O_IP_ACT_GACCOUNT_MONEY</DocType>
<DocName>Постановление об обращении взыскания на денежные средства должника, находящиеся в банке или иной кредитной организации</DocName>
<Description>***</Description>
<Type>09</Type>
</ArrestInfo>
</IRequest>Обработчики интерактивных запросов формируют ответ на основе мастер данных, хранящихся в виде реестров в распределённом хранилище банка данных. К ним можно получить доступ через SQL по протоколу JDBC. Подробнее про само хранилище чуть позже. Стоит отметить, что формирование ответ не сводится к простому единичному select-запросу. Состав данных и их условия выборки формируются динамически в зависимости от статуса и состояния документов и самого исполнительного производства.
После формирования, ответы с данными отправляются в соответствующий исходящий топик в кластере очередей сообщений. Узел СМЭВ3 модуля забирает сообщения из топиков ответов и отправляет их исходящую очередь СМЭВ3.
За работой каждого компонента и модуля осуществляется постоянный мониторинг. Для обеспечения мониторинга и анализа хода автоматизируемого процесса, со всех компонентов обеспечен сбор метрик. В основном в pull режиме через специальные сервлеты Prometheus забирает метрики и с помощью Grafana представляет их в виде дашбордов. Настроенные уведомления о нештатных ситуациях позволяют своевременно реагировать на сбои.
Важным компонентом архитектуры здесь является так называемая система управления банком данных и на ней мы остановимся подробнее.
Кластер мастер-данных как ключевой компонент архитектуры
В банке данных в текущем состоянии более 85Тб и они распределены в кластере по 24 узлам на 6 физ серверах. При этом в оперативной памяти находится 13Тб горячих данных, а объём WAL-журналов примерно равен 3Тб.
Кластер мастер данных обеспечивает быстрый, отказоустойчивый, транзакционный доступ к банку данных через SQL. Благодаря распределённому хранению данных на нескольких узлах, появляется возможностью горизонтального масштабирования при добавлении новых узлов.
Конфигурация кластера нацелена на обеспечение бесперебойной работы сервисов даже в случае отказа одного физического сервера. Такая отказоустойчивость достигается за счёт распределения мастер и бэкап партиций строго по разным физическим серверам. Сами данные разделены на патриции, каждая из которых имеет синхронный бэкап, то есть имеем двойную избыточность данных. Отказ целого физического сервера неоднократно происходило в промышленной среде. Факт никак не сказался на надежности сервиса и времени предоставления ответа, что подтвердило правильность выбранного подхода.
Кластер мастер данных предоставляет возможность индексного поиска по данным, хранение «горячих» данных в памяти, использования языка SQL для манипуляции и выборки данных из хранилища. В самом хранилище около 15 таблиц не считая системных. Всё это построено на базе Apache Ignite. Про Ignite gодробнее можно почитать:
Кластер мастер данных наполняется из нескольких источников.
Первый источник — реестры формируемые в отделах. По системе гарантированной доставки реестры в бинарном или CSV виде периодически поступают на сегменты подсистемы МВВ. Cегменты банка данных транзакционно сливают их с уже имеющимися по данному отделу данными в кластере. Изменения публикуются в кластер. Отказоустойчивость сегмента обеспечивается master-slave репликацией БД и переключением в случае сбоя мастер узла базы данных.
Но не все данные приходят из отделов, есть другие источники для кластер данных.
Отличие их в том, что приходят они не массово, эти данные обновляются по одной записи. Это необходимо для обеспечения максимальной актуальности данных, где каждая секунда на счету, например, для услуги хода снятия ограничения выезда. Это платежи из федерального казначейства и состояния документов, например, постановлений. Узлы их приёма и обработки синхронно записывают в брокер каждое изменение, и затем из брокера данные асинхронно заливаются в кластер. При штатной работе, обновление данных происходит с задержкой всего в несколько миллисекунд.
Потребители мастер-данных в подсистеме МВВ: это не только суперсервис, кластер банка данных интегрирован в инфраструктуру АИС МВВ ФССП России. Кластер мастер данных предоставляет данные для многих других сервисов: запросов и обращений от банков, прочих крупных взыскателей, БКИ, сервисов оповещений пользователей, ограничения выезда, прочих сервисов портала госуслуг, предоставления сведений отделам ФССП России по экстерриториальности, сервисов центра телефонного информирования, даже клиентские обмены, где ФССП России являются потребителями сведений, используют кластер.
Для подобная интеграции требуются соответствующие показатели назначения. В спокойном режиме кластер Ignite выдерживает до 500-1000 qps (при этом, времени ответа порядка 1 ms). Это SQL запросы с IN, JOIN, сложными фильтрами, даже с группировками.
В пиковых нагрузках или «благодаря» ошибкам которые случались и исправлялись, чтение данных доходила до 8K-10K qps.
Хранилище мастер данных, как и прикладные модули, включено в мониторинг. Prometheus в pull-режиме собирает метрики производительности с Ignite кластера. Для него есть отдельные витрины.
Схема работы для заявлений в отдел. Здесь, в отличие от схемы работы интерактивного обмена, сделан акцент на маршрутизацию.
Архитектура обмена заявлениями и ходатайствами для суперсервиса выглядит несколько проще и ориентирована больше на пропускную способность и маршрутизацию чем на скорость предоставления ответа и доступность. Здесь не предъявляются строгие требования к времени ответа, а избыточность в развёртывании некоторых прикладных компонентов отсутствует. На схеме нет хранилища мастер данных и дублирующих узлов обработки, но добавлен важный компонент очередей в отделы.
Для суперсервиса ЦИП были разработаны новые механизмы обмена для массовой доставки почтовых уведомлений через СМЭВ3 на портал госуслуг и перепроектировался механизм выставления начислений и доставки платежей из Федерального казначейства. В текущей статье мы подробно не будем на них останавливаться.
Обратим внимание на такое важное мероприятию, как нагрузочное тестирование (далее по тексту - НТ). Мы проводили их несколько раз, в том числе перед самым запуском обменов по интерактивным госуслугам и передачи заявлений, а также обмена почтовыми уведомлениями.
Для НТ был разработан эмулятор работы сервиса СМЭВ3 со настраиваемыми задержками операций, криптографией и прочими моментами влияющими на производительность. В промышленной среде НТ происходило на реальных данных. Т.е. эмулятор выполнял SQL запрос к хранилищу реальных данных, выбирал случайным образом необходимы записи и формировал запросы к системе. Таким образом, система работала с профилем нагрузки неотличимой от реальной.
В результате, в текущих конфигурациях модулей, пиковые показатели по пропускной способности при сохранении допустимых временных интервалов формирования ответа достигали 55 запросов в секунду для каждой услуги. Полученные в ходе НТ максимальные показатели в среднем в 25 раз превышает обмен по интерактивным запросам в спокойном режиме. Увеличение даже этих пиковых показателей достигается добавлением экземпляров прикладных модулей и узлов СМЭВ3-адаптеров.
Эффект от внедрения
Наверное, одни из главных достижений для нашей команды стало получения опыты и экспертизы в проектировании и разработке подобных проектов, а также доказательство того, что наработки и решения, созданные нашей командой на базе отечественных продуктов и продуктов с открытым исходным кодом, позволяют реализовывать сложные проекты, создавать высокопроизводительные и высокодоступные системы, в том числе системы межведомственного электронного взаимодействия. Суперсервис ЦИП — это пример архитектуры, построенной полностью на Open Source продуктах и отечественном ПО. Это позволяет создавать высоконадежные и безопасные системы, которые могут работать в любых условиях и не зависят от импортных продуктов и технологий.
Внедрение суперсервиса позволило:
повысить точность и оперативность предоставляемой информации;
сократить нагрузку ФССП России, банков и других органов, которые гражданам приходилось посещать лично;
сократить операционные издержки для юридических и физических лиц;
сэкономить средства на почтовые отправления и личные приемы;
снизить нагрузки на судебного пристава-исполнения за счет автоинформирования заявителя о наличии и ходе исполнительного производства.
Социальный эффект от внедрения
Для граждан и юридических лиц:
повышение осведомленности сторон исполнительного производства: физических и юридических лиц, взыскателей и должников;
повышение прозрачности работы судебного пристава по исполнительному производству для сторон исполнительного производства;
упрощение процесса подачи заявлений, жалоб, ходатайств в ФССП России;
сокращение количества личных контактов сторон исполнительного производства с ФССП России;
сокращение операционных издержек для юридических лиц на взаимодействие с ФССП России.
Для государства:
повышение эффективности принудительного исполнения;
сокращение нагрузки на судебных приставов-исполнителей;
сокращение операционных издержек на исполнительное производство;
исполнение требований законодательства по уведомлению сторон исполнительного производства;
повышение лояльности и доверия граждан и бизнеса к государству;
повышение уровня удовлетворенности граждан качеством государственных сервисов.
Оценка работы ФССП России в части ИТ:
ФССП России уже который год находится среди лидеров по автоматизации и цифровизации (https://d-russia.ru/na-cipr-nazvany-foiv-i-regiony-lidirujushhie-v-rejtinge-cifrovoj-transformacii.html)
В Минцифре России отметили: «По нашей оценке, ФССП России сделала качественный рывок в цифровизации своего направления. Приставами созданы прецеденты, которые будут являться образцом для остальных ведомств».
Суперсервис «Цифровое исполнительное производство» получил ряд наград:
Премия «Цифровые вершины 2021». В номинации «Лучший государственный сервис» победителем стал Суперсервис «Цифровое исполнительное производство», разработанный компанией РЕД СОФТ (https://arppsoft.ru/news/arpp/11080/);
Лауреат премии в области передовых технологий «Приоритет-2021» в номинации «Информационные технологии. Программное обеспечение» за автоматизированную информационную систему Федеральной службы судебных приставов (https://prioritetaward.ru/participants/participant_400.html);
Номинация «Большие данные» (ПРОФ ИТ). 1 место – «Суперсервис «Цифровое исполнительное производство» (ООО «Ред Софт», Москва) (https://d-russia.ru/objavleny-prizery-i-pobediteli-ii-nacionalnogo-konkursa-it-reshenij-prof-it-innovacija.html).
Видео моего выступления на тему реализации АИС ФССП России и Суперсервисов:
Распределённые системы «суперсервисов» на службе ФССП / Дмитрий Горчаков
Подробнее о продуктах и технологиях расскажем в следующей (заключительной) 3-ей части цикла статей.
Комментарии (2)
PESADRUS
09.01.2024 14:17Вот было бы классно если бы было настроено электронное взаимодействие сторон исполнительного производства с нотариатом для оформления эл. доверенностей на представителей. Для указанных целей приходится физически бегать за доверкой для того, чтобы потом использовать её на госуслугах. Да, и API сейчас закрыта, как сказал aborouhin.
aborouhin
Готовые "суперсервисы" для конечных пользователей - это, конечно, прекрасно. Но в это же самое время существовавший ранее открытый API ФССП закрыла. Так что интегрировать не то, что все Ваши прекрасные сервисы, но даже элементарную проверку наличия/статус исп. производств в свою систему работы с дебиторкой или проверки контрагентов простому смертному (не удостоившемуся доступа к СМЭВ) стало на порядок сложнее...