Програмне забезпечення Системи  повинне складатися із:

• загальносистемного програмного забезпечення;
• прикладного програмного забезпечення.

  Програмне забезпечення Системи повинно забезпечувати:

• підтримку функціонування в різнорідному апаратному і програмному середовищах;
• захист від помилок і підтримку цілісності даних;
• мінімальні витрати на закупівлю та експлуатацію.

  До Загальносистемного  програмного забезпечення відносяться:

• Операційні системи (Ubuntu);
• Система забезпечення версійності та інтеграції проекту Jenkins або аналоги;
• Система моніторингу Zabbix.

Загальносистемне програмне забезпечення не є предметом закупівлі або розробки в межах цього Технічного завдання. При розробці прикладного програмного забезпечення повинні використовуватися принципи модульності та типовості, які забезпечать послідовне нарощування функціональних можливостей Системи за рахунок впровадження та тиражування функціонально завершених програмних модулів. Для розміщення Системи в період, коли кількість користувачів, що одночасно знаходяться на Сайті, не перевищує 2000, необхідна наступна конфігурація серверів:

• 4 ядра, 4 Gb RAM, 30 Gb HDD – 6 шт.;
• 2 ядра, 2 Gb RAM, 30 Gb HDD – 2 шт.;
• 2 ядра, 1 Gb RAM, 30 Gb HDD – 4 шт.;
• 8 ядра, 4 Gb RAM, 30 Gb HDD – 1 шт.;
• 2 ядра, 1 Gb RAM, 200 Gb HDD – 1 шт.

Конфігурація: 1 балансувальник, 6 додатків, 1 обробник черг, 2 mysql-server (основна та резервна база даних), 1 redis-server (redis-server: кеш сесій), 1 elasticsearch, 1 об'єктне файлове сховище, 1 сервер геокодингу. Для розміщення Системи у період, коли кількість користувачів, що одночасно знаходяться на Сайті, від  2000 до 10 000, необхідна наступна конфігурація серверів:

• 8 ядер, 4 Gb RAM, 60 Gb HDD –  1шт. (балансувальник);
• 4 ядра, 4 Gb RAM, 30 Gb HDD –  24шт. (додатки);
• 8 ядер, 24 Gb RAM, 60 Gb HDD –  1шт. (redis-server: кеш сесій);
• 4 ядра, 8 Gb RAM 1000 Gb HDD –  1шт. (об'єктне файлове сховище);
• 4 ядра, 2 Gb RAM, 30 Gb HDD –  1шт. (обробник черг);
• 32 ядра, 16 Gb RAM, 60 Gb HDD –  1 шт. (основна база даних);
• 4 ядра, 8 Gb RAM, 60 Gb HDD –  1шт. (резервна база даних);
• 4 ядра, 4 Gb RAM, 60 Gb HDD –  1шт. (elasticsearch);
• 4 ядра, 4 Gb RAM, 30 Gb HDD –  1шт. (сервер геокодингу);

На всіх серверах повинні бути ОС Ubuntu 16.04×64 LTS, root з доступом по паролю (тимчасово, в процесі автоматичної інсталяції доступ до ssh по паролю буде закритий). При збільшенні навантаження на різні компоненти, споживання системних ресурсів може зростати нелінійно, і тоді необхідна принципово інша схеми розміщення. Розробка даної схеми виходить за межі даного Технічного завдання. Система має бути налаштована під такі веб-браузери: Google Chome, IE11+, Edge, Firefox 42+, Chrome 47+, Safari 9+, Opera 35+. На прикладному рівні Системи використовуватимуться HTML5, CSS3, Js. Для розробки адміністративної панелі Системи використовуються системи php7 (OpenSSL PHP Extension, PDO PHP Extension, Mbstring PHP Extension, Tokenizer PHP Extension), MariaDB, Redis, BeanstalkD, NodeJS та фреймворк – Laravel 5.2 javascript стандарту ES6, який транслюється в ES5 за допомогою babel. Верстка адаптивна та оптимізована під усі сучасні розширення екранів моніторів, включаючи Full HD (1920*1080), екрани планшетів від 6 дюймів та смартфонів від 3,5 дюймів.

Загальна архітектурна схема рішення представлена на Рисунок 41. Загальна архітектурна схема рішення.

Рисунок 41. Загальна архітектурна схема рішення Підключення зовнішніх клієнтів до служб відбувається через балансувальник навантаження на базі nginx / openresty (в разі критичних навантажень їх може бути кілька, які розподіляються через round-robin dns). Кожен балансувальник розподіляє запити між N серверами додатків, кожен з яких взаємодіє із зображеними сервісами по ізольованій внутрішній мережі (крім зовнішніх сервісів, виділених на схемі, взаємодія з якими відбувається по зовнішній мережі). Фонові завдання обробляються окремим сервісом (Додаток та Сервіс черг), який недоступний ззовні. СКБД і файлове сховище в реальному часі синхронізується з відповідними сервісами в резервному оточенні (дзеркало) за допомогою master-slave реплікації. Детальна схема архітектури інфраструктури Системи представлена на Рисунок 42. Схема архітектури інфраструктури Системи:     Рисунок 42. Схема архітектури інфраструктури Системи Резервний MySQL сервер  є slave-реплікою основого. Усі конфігурації ПЗ серверів, а також процеси розгортання системи, контролюються за допомогою Ansible. Тестове середовище доступне за окремим посиланням і є стиснутою до одного сервера копією продуктового середовища