Варианты развертывания серверной части OMOBUS
Серверная часть OMOBUS (в дальнейшем — С.Ч.) является одной из двух основных частей SFA OMOBUS. Вариант развертывания С.Ч. не зависит от варианта поставки.
Возможны несколько вариантов развертывания С.Ч. В зависимости от решения заказчика, выбирается тот или иной вариант. Однако, все они отличаются друг от друга, в основном, местом расположения серверов (физических или виртуальных), разделением ответственности между заказчиком и исполнителем, и перечнем услуг по обеспечению работоспособности С.Ч. OMOBUS, оказываемых исполнителем заказчику.
В зависимости от нагрузки на систему и требований к надежности, серверов может быть один или два.
При некоторых условиях, вместо физических серверов могут использоваться виртуальные серверы.
Варианты развертывания С.Ч. OMOBUS приведены в списке:
D1. Физический или виртуальный сервер принадлежит заказчику, расположен на территории заказчика и/или находится под его физическим контролем и в его же зоне ответственности.
Ответственность за аппаратную часть: ЗАКАЗЧИК.
Ответственность за работоспособность С.Ч. OMOBUS: ИСПОЛНИТЕЛЬ.
Способ управления аппаратной частью сервера: ПРЯМОЙ ДОСТУП ЗАКАЗЧИКА.
Способ управления ОС сервера: УДАЛЕННЫЙ ДОСТУП ИСПОЛНИТЕЛЯ.
Способ управления С.Ч. OMOBUS: УДАЛЕННЫЙ ДОСТУП ИСПОЛНИТЕЛЯ.
Ремонт аппаратной части: ЗАКАЗЧИК.
D2. Физический сервер принадлежит заказчику, расположен на территории провайдера услуги ко-локейшн (по выбору исполнителя) и находится под физическим контролем и в зоне ответственности исполнителя. Допустимы разумные способы контроля заказчиком сохранности, исправности, физической целостности и использования по назначению принадлежащего ему имущества.
Ответственность за аппаратную часть: ИСПОЛНИТЕЛЬ.
Ответственность за работоспособность С.Ч. OMOBUS: ИСПОЛНИТЕЛЬ.
Способ управления аппаратной частью сервера: ДОСТУП ИСПОЛНИТЕЛЯ по согласованию с провайдером.
Способ управления ОС сервера: УДАЛЕННЫЙ ДОСТУП ИСПОЛНИТЕЛЯ.
Способ управления С.Ч. OMOBUS: УДАЛЕННЫЙ ДОСТУП ИСПОЛНИТЕЛЯ.
Ремонт аппаратной части: ИСПОЛНИТЕЛЬ, при условии 100% компенсации расходов заказчиком.
D3. Виртуальный сервер арендуется заказчиком у исполнителя, расположен на территории или в зоне ответственности исполнителя.
Ответственность за аппаратную часть: не актуально.
Ответственность за работоспособность С.Ч. OMOBUS: ИСПОЛНИТЕЛЬ.
Способ управления аппаратной частью сервера: не актуально.
Способ управления ОС сервера: УДАЛЕННЫЙ ДОСТУП ИСПОЛНИТЕЛЯ.
Способ управления С.Ч. OMOBUS: УДАЛЕННЫЙ ДОСТУП ИСПОЛНИТЕЛЯ.
Расходы на ремонт аппаратной части: не актуально.
Периодические расходы заказчика
Расходы заказчика, связанные с оплатой услуг исполнителя по поддержанию работоспособности сервера OMOBUS. Указанные услуги могут включать в себя:
Техническая поддержка OMOBUS. Включает в себя обеспечение работоспособности ОС сервера и С.Ч. OMOBUS, поддержание ПО С.Ч. в актуальном состоянии1, а так же обеспечение работоспособности клиентской части OMOBUS и поддержание ПО клиентской части OMOBUS в актуальном состоянии, добавление новых потоков данных, и несложные изменения в существующих потоках данных.
Аренда виртуального сервера.
Ремонт аппаратной части сервера (по необходимости).
Конкретный состав услуг определяется вариантом развертывания С.Ч. OMOBUS.
D1.
Техническая поддержка OMOBUS (не обязательно).
D2.
Техническая поддержка OMOBUS.
Ремонт аппаратной части сервера (по необходимости).
D3.
Аренда виртуального сервера.
Техническая поддержка OMOBUS.
1 Поддержание ПО OMOBUS в актуальном состоянии означает, что к установленному ПО будут применяться все выпускаемые разработчиком обновления, связанные с устранением выявленных ошибок, внесением концептуальных и технологических изменений. Последнее, в свою очередь, означает, что в ПО, находящееся в актуальном состоянии, в любой момент могут быть интегрированы новые функциональные модули, новые технологии обмена данными и другие новшества подобного вида.
ПО не актуализированное, с течением времени, приходит в рассогласование с основными ветвями (серверной или клиентской) проекта OMOBUS, и внесение в него изменений становится значительно более трудоемкой задачей. Например, новый функциональный модуль может использовать измененные интерфейсы, другие протоколы обмена, и интеграция его в не актуальное ПО может оказаться невозможной.
Так же играет роль и время, которое необходимо разработчикам для "вхождения в тему" при доработках не актуальных проектов.