Автоматизована система оплати проїзду знаходиться на фінальній стадії технічного впровадження та являє собою складну багатофункційну систему, яка повинна задовольняти сучасним вимогам щодо безпеки та цілісності даних, та розташовуватись у стабільному хмарному середовищі. Для реалізації проекту було проведено закупівлю за номером UA-2021-03-03-001794-a та укладено договір № КЛД-300421 від 30.04.2021р. на отримання ресурсів в ХЦОД, переможцем якого стала компанія Gigacloud. Після отримання необхідних ресурсів виникла необхідність залучення надавача послуг, що спеціалізується на послугах з конфігурації та адміністрування інфраструктур, розгорнутих у ХЦОД. За результатом закупівлі за номером UA-2021-03-17-015907-c був укладений договір від 14.06.2021 р. № 14/06/2021, згідно якого ТОВ «АСТВЕЛЛ СОФТ» надає послуги з конфігурації та адміністрування інфраструктури проекту в хмарних центрах обробки даних ЛКП «Львівавтодор». Процес впровадження відбувся на протязі приблизно півроку і було виконано великий обсяг роботи згідно договору . Але зважаючи на складність задачі, яка обумовлена великою кількістю підсистем, між якими необхідно налагодити взаємозв’язок і багато інших параметрів, а також у зв’язку з унікальністю технічного рішення проекту, в обумовлений договором термін виконати задачі, які виникли в процесі впровадження системи, в повному обсязі виявилось неможливим. На даний час існує необхідність завершити впровадження системи. Більшу частину роботи з впровадження було виконано за участю ТОВ « Аствелл Софт » згідно договору від 14.06.2021р. №14/06/2021, внаслідок чого ця компанія єдина на даний момент володіє повною інформацією про створену в ХЦОД інфраструктури проекту. Залучення іншого постачальника послуг до закінчення процесу впровадження системи призведе до значних витрат часу на вивчення технічного завдання, документації систем, що вже впроваджені, методів взаємодії підсистем та всіх налаштувань, також існує велика ймовірність порушення роботи вже впроваджених підсистем внаслідок вибору інших методів налагоджування, що в свою чергу призведе до ще більших витрат часу і, як результат, термін остаточного впровадження системи в експлуатацію може бути значно пізнішим запланованого.
Враховуючи, що в процесі впровадження системи при розгортанні сервісів ряд налаштувань Консорціум «Мікроелектроніка-СофтСерв» та ТОВ «АСТВЕЛЛ СОФТ» були вимушені робити інакше, ніж в архітектурній документації. Наприклад mirroring бази MS SGL із використанням witness в третьому DC. Налаштування відбувались в ручному режимі і багато рішень, які приймались на нарадах ТОВ «АСТВЕЛЛ СОФТ» спільно з Консорціумом «Мікроелектроніка-СофтСерв» та Замовником не були задокументовані.
Однак найбільшою складністю у залучені іншого надавача послуг є побудова системи на нестандартних рішеннях. Для прикладу:
● cloud інфраструктура мала б налаштовуватись централізовано, без вказання в якому DC (Київ, Львів) вибирати ресурси при deployment, а по факту у ручному режимі відбуваються:
- налаштування загальної мережі QA/PROD/LIVE кластерів на OpenStack;
- налаштування traffic routing на базі LoadBalancers, Mikrotik routers в OpenStack
- налаштування мережі в Kubernets для nodes і podes для потреб VPN for Monet+;
- вибір таких ресурсів як storages при CI/CD через GitLab при deployment процесі на Kubernets;
- моніторинги при збоях RabbitQM, Kibana, etc;
Це дуже складна сукупність систем, для якої неможливо застосувати класичний алгоритм впровадження, як для типових хмарних середовищ, такі як для AWS/Azure, що допомагають будувати, балансувати та виконувати моніторинг ресурсів k8s в автоматному і зручному режимі із можливістю все робити шаблонно згідно стандартів DevOps.
Наприклад - Windows кластер при створені має автоматично отримати ІР адресу, однак по факту - ІР адреса видається LoadBalancer в OpenStack, при чому з використанням не нативного для Windows середовища на базі Windows Servers або Azure.
Відповідно новий надавач послуг не зможе самостійно розібратись, як працює інфраструктура, через велику кількість кастомних підходів які були використані при розгортанні та налаштуванні інфраструктури проекту.

Окрім нестандартних рішень самої інфраструктури, також система АСОП побудована з не стандартними налаштуваннями для інших учасників впровадження АСОП. Для прикладу:
● Архітектура роботи із зовнішніми провайдерами, а саме організація VPN для Monet+ з організацією закритого каналу з обмеженою кількістю ІР адрес.
● Для Київстару - організація по ІР адресах з налаштуванням ряду VPN серверів центрів обслуговування пасажирів.
● Нюанси налаштування LoadBalancer в OpenStack та Windows-кластеру для роботи з ПЗ FareON.
● Налаштування та архітектура мереж для доступу до зовнішніх провайдерів (для VPN створення додаткових мереж, що не поміщались в основну мережу).
● Центр обслуговування пасажирів ЛКП «Львівавтодор» здійснює обмін даними через VPN на базі Microtik. Через нюанси налаштування необхідно працювати по схемі VPN через proxy server, хоча б мали іти напряму на LoadBalancer в OpenStack без proxy server, якби не нюанси Microtik.

Також варто зазначити, що особливо важливим є також пункт договору від 14.06.2021р. № 14/06/2021. ТОВ «АСТВЕЛЛ СОФТ» не лише здійснює конфігурацію інфраструктури, але і надає послуги в режимі 24/7 з підтримки існуючої інфраструктури шляхом постійного про-активного моніторингу великої кількості усіх елементів складної та високотехнологічної системи, а саме: Kubernetes Cluster, взаємодія сервісів між ХЦОД, Windows Failover Cluster, Bastion Host, E-mail server, VPH, SSH, RDP, Load Balancer, HAProxy, бази даних MSSQL та інші.
Беручи до уваги всю складність системи, можна стверджувати, що ця підтримка є вкрай необхідною на постійній основі 24/7 тому, що без неї вчасне розгортання проекту є неможливим, а вже зроблена робота може бути повністю заблокована збоєм у роботі хоч однієї із систем. Новий надавач послуг не зможе оперативно виправити дані несправності, оскільки лише на ознайомлення з архітектурним рішенням системи і всіма налаштуваннями системи та передачею всіх необхідних прав доступу буде необхідний тривалий час, який може сягати декількох місяців, протягом яких роботу всього проекту та всіх його учасників буде заблокованою, що призведе як до фінансових, так і репутаційних втрат для ЛКП «Львівавтодор». ТОВ «АСТВЕЛЛ СОФТ», що володіє актуальною інформацією стосовно впровадження системи АСОП та розуміє тонкощі її будови і взаємодії всіх елементів, в разі будь-якого збою може виправити його оперативно, що на даний момент є надзвичайно критичною потребою. Таким чином, в даному випадку можна вважати, що обрання переговорної процедури закупівлі послуг на впровадження та технічний супровід системи у ТОВ «АСТВЕЛЛ СОФТ» надасть можливість закінчити впровадження системи у запланований термін та дозволить уникнути інших негативних наслідків.
Отже, зміна обслуговуючої організації може призвести до тривалого відтермінування проекту, та завдати додаткових витрат фінансових та часових, адже у період відсутності обслуговуючої організації будуть призупинені роботи по впровадженню проекта, налаштуванню його нових сервісів та підтримці діючих. Водночас буде відбуватись частковий простій інфраструктури, за яку буде вноситись плата провайдеру. На даному етапі заміщення обслуговуючої організації є недоцільною та може завдати негативного впливу на проект.
Враховуючи вищезазначене, в замовника ЛКП «Львівавтодор» існують законні підстави щодо проведення закупівлі: «Надання послуги з конфігурації та адміністрування інфраструктури в хмарних центрах обробки даних» (код ДК 021:2015:72250000-2 Послуги, пов’язані із системами та підтримкою) за переговорною процедурою закупівлі на підставі абз. 4 п. 2 ч. 2 ст. 40 Закону (якщо роботи, товари чи послуги можуть бути виконані, поставлені чи надані виключно певним суб’єктом господарювання за відсутності конкуренції з технічних причин, яка має бути документально підтверджена замовником). Це також підтверджує Експертний висновок від 31.12.2021 № 01-575, наданий ДП «Одеський науково- дослідний інститут зв’язку ».