Системная архитектура информационных систем налоговой администрации

Системная архитектура

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

В этом случае выбор решения часто осложнен и часто осуществляется путем анализа чужого опыта: на основе историй успеха и референс визитов к заказчикам потенциальных поставщиков.

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

Международный стандарт ISO/IEC/IEEE 42010:2011 дает следующее определение:

«Архитектура — это фундаментальные концепции или свойства системы в ее окружении, воплощенные в ее элементах, отношениях, а также в принципах ее проектирования и эволюции»

«Описание системной архитектуры помогает понять суть системы и ключевые свойства, относящиеся к ее поведению, составу и эволюции, которые, в свою очередь, влияют на такие вопросы, как реализуемость, полезность и обслуживаемость системы».[1]

Сначала необходимо рассказать о том, что мы не рекомендуем делать при проектировании архитектуры налогового администрирования:

• Нельзя принимать на слепую веру слова продавцов технологий, потому что их задача продать и получить деньги, а не обеспечить работу системы. Их премии зависят от выполнения плана продаж, а не от успеха налоговой администрации.
• Нельзя бездумно слушать своих разработчиков. У них свои мотивы выбирать те или иные технологии, начиная от защиты своего места работы и выбора того, что знают хорошо, до безумного любопытства, то есть желания попробовать что-то новое и интересное.
• Нельзя выбирать технологии, не имея на своей стороне сильных и профессиональных экспертов, которые будут заинтересованы в успехе проекта и сосредоточены, например в собственном центре экспертизы, поддерживающем разработку, внедрение и сопровождение системы.

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

Показатели назначения

Самое важное при проектирование системной архитектуры это сформулировать ее назначение и целевые показатели:

• определить пользователей (внутренних и внешних), их количество, профиль использования ресурсов информационных систем (количество запросов, типы запросов в единицу времени);
• распределение нагрузки на систему по числу запросов в течение суток (определение часа максимальной нагрузки, определение максимальной нагрузки), включая гарантированное время отклика;
• объемы данных и прирост объема данных в единицу времени; количество записей и прирост количества в единицу времени; данные параметры должны быть конвертированы в показатели TPS (transactions per second — число операций в секунду).

TPS, гарантированное время отклика системы и количество записей становятся главными показателями, которые влияют на системную архитектуру и выбор технологий.

Показатели доступности

Кроме показателей назначения необходимо в рамках соглашения об уровне сервиса (Service Level Agreement, SLA) определить показатели доступности системы: процент времени гарантированной доступности системы за период (например, 99,9%) и время максимального простоя системы за период (например, не более 9 часов в год).

Эти показатели необходимо различать в зависимости от групп пользователей. Для сотрудников налоговых органов, которые работают по жесткому графику и только в будние дни, есть возможность проведения технических работ в выходные и ночью. С другой стороны, налогоплательщики хотят работать с информационными системами налоговых органов в любое время суток 365 дней в году, т. е. показатели SLA для них должны быть максимально возможными.

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

Требования информационной безопасности

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

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

Влияние унаследованной архитектуры

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

Открытое или закрытое ПО

При выборе технологий для реализации системной архитектуры существует важное решение по выбору вида программного обеспечения. Использовать ли технологии на основе программного обеспечения с открытым кодом (open source software) или выбрать так называемое проприетарное (proprietary — в смысле «закрытое») программное обеспечение? Это должен быть осознанный выбор налоговой администрации в зависимости от размера бюджетов и наличия собственных специалистов или специалистов поставщиков для технической поддержки приложений и, что очень важно, поддержки разработчиков.

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

При прочих равных условиях рекомендуется обратить внимание на технологии с открытым исходным кодом с учетом их популярности и востребованности в мире.

Системное программное обеспечение

С точки зрения выбора системного и инфраструктурного программного обеспечения необходимо рассматривать следующие типы технологий:

• Серверные операционные системы.
• Системы управления базами данных (СУБД), как реляционными (SQL), так и нереляционными (NoSQL) для транзакционных и аналитических задач.
• Интернет-серверы.
• Серверы приложений.
• Системы очередей сообщений и гарантированной доставки сообщений.
• Системы авторизации, аутентификации и информационной безопасности, включая защиту работы с электронной подписью или ее аналогами.
• Системы виртуализации и контейнеризации.
• Системы мониторинга приложений.

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

Исходя из собственного опыта можно рекомендовать следующий проверенный набор программного обеспечения с открытым кодом, который использовался во множестве проектов с разным уровнем масштаба по количеству пользователей, объему хранения и запросов:

	Технология	Выбор
1	Серверные операционные системы	RedHat Linux
2	Реляционные СУБД	PostgreSQL
3	Нереляционные СУБД (NoSQL)	Apache Hadoop (HDFS, Yarn, HBase) Apache Hive ClickHouse
4	Системы очередей сообщений	Apache Kafka
5	Интернет-сервер	NGINX
6	Сервер приложений	Apache Tomcat
7	Управление контейнерами	Kubernetes
8	Мониторинг приложений	Prometheus Zabbix Grafana

Рекомендации по проектированию системной архитектуры

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

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

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

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

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

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

---

[1] ISO/IEC/IEEE 42010:2011(en). Systems and software engineering — Architecture description. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec-ieee:42010:ed-2:v1:en