Обзор типовых схем развёртывания при переходе с АИС «Скиф 3» на АИС «Скиф-БП»

Типовая схема развёртывания АИС «Скиф 3» в субъекте РФ представлена на рисунке:

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

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

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

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

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

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

•Отсутствует возможность хранения в системе нескольких копий одних и тех же данных, описанная выше1. Таким образом, например, замеченная субъектом ошибка в своде по Муниципальному образованию не может быть исправлена напрямую им самим. Придётся ожидать, когда данные будут исправлены по всей цепочке от Посёлка и выше с перевычислением свода по Муниципальному образованию. Это может потребовать изменения технологии сбора и подготовки данных.

•Необходимость администрировать на уровне субъекта всех пользователей всех подведомственных учреждений.

•Необходимость конструирования более сложных схем документооборота, которые бы позволили сотрудникам из учреждений более высоких уровней манипулировать состояниями данных учреждений с более низких уровнях бюджетной иерархии (например, чтобы Субъект мог закрыть для редактирования определённую форму не только на своём уровне, но и на уровне Муниципальных образований и на уровне Посёлков).

•И наконец, стандартные недостатки Web решений, такие как необходимость развёртывания дополнительного сервера (не обязательно, но желательно), наличия стабильного Интернет соединения на период работы у всех клиентов и т.д..

Выше была дана характеристика типовым вариантам схем развёртывания, если недостатки, какой либо схемы представляются для субъекта вескими, следует проанализировать все варианты схем развертывания.

Сбалансированный вариант, при котором нагрузка распределена по серверам промежуточных уровней (Муниципальных образований, в данном примере) и, одновременно, конечные участники бюджетной иерархии (Посёлки) по-прежнему избавлены от необходимости устанавливать какое-либо ПО и работают через Web клиенты:

Недостатком такой схемы является необходимость иметь в Муниципальных образованиях во-первых, собственно сервер (а лучше два сервера), а во-вторых, квалифицированный IT персонал, способный обеспечить развёртывание и функционирование связки SQL сервер + Web сервер. Однако самая распространённая на сегодняшний день схема развёртывания АИС «Скиф 3» очень похожа на данную схему, поэтому есть уверенность, что такая схема тоже может быть успешно освоена Муниципальными образованиями.

Безусловно, возможны смешанные схемы развёртывания, когда на каждой ветке иерархии участников бюджетного процесса решение об архитектуре принимается индивидуально. Целью данной статьи дать сравнительные характеристики архитектур, связанных с применением Web-технологий, поэтому на приведённых схемах никак не отражена возможность использования Терминала, поскольку его возможности остались на том же уровне, что и в рамках АИС «Скиф 3».

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

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

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

Установка Desktop-клиента со своей базы данных или Терминала выбирается при отсутствии на вышестоящем уровне Web сервера или при отсутствии устойчивого Интернет соединения. Кроме того, установка Desktop клиента будет предпочтительнее, если необходим дополнительный функционал на этом уровне (например, Аналитика). Но, для этого понадобится более полная лицензия. В остальных случаях работа через Web клиент, конечно удобнее.

При необходимости сводить данные нижележащих учреждений – уже строго необходим сервер БД:

Для реализации этой схемы необходима установка Internet Information Service версии 7.х или выше. При небольших нагрузках Web сервер может быть совмещён с сервером БД, но настоятельно рекомендуется установить два сервера: один для сервера базы данных, другой для Web сервера.

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

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