SaaS хмарна платформа та розгортання

МСП і швидкі запуски: спільний SaaS. Підприємства із суворими політиками безпеки або глибокою інтеграцією з ПЛК/VPN: виділений single-tenant або on-premise. Ми надаємо рекомендації на етапі PoC.

На європейській хмарній інфраструктурі, з можливістю вибору виділеного середовища та регіону за запитом.

Так. Почніть зі спільної моделі заради швидкості та переходьте на виділену чи on-premise у міру масштабування. Платформа ідентична.

У хмарному розгортанні локальний колектор на заводі продовжує опитувати обладнання і буферизує лічильники та записи простоїв у себе, а після відновлення каналу довантажує їх у платформу; на скільки вистачить буфера, залежить від конкретного розгортання і визначається на етапі PoC. Усе, що віддає сама платформа, зупиняється одразу: дашборди, запуск нових нарядів, звітні екрани. Усе, що оператор вводить руками, іде на папір до відновлення зв'язку, тож узгодьте запасний варіант для причин простоїв і браку ще до запуску в експлуатацію. На PoC просто висмикніть кабель і подивіться, що вийде.

Ні. Колектор усередині заводської мережі опитує контролери і сам ініціює вихідне з'єднання по TLS або через site-to-site VPN, тож жодного порту у бік цеху на фаєрволі відкривати не треба. Але чітко визначте, що цьому колектору дозволено: це довірений міст, і все, що платформа може попросити його записати назад у контролер, іде тим самим вхідним шляхом, лише під іншою назвою. Сегментацію рівня керування визначає ваш власний мережевий дизайн, тож нехай ваші мережевики й ОТ-фахівці перевірять адреси призначення, порти та права на запис до старту PoC.

На вас сервери, операційні системи, контейнерна платформа, база даних, резервні копії та регулярні тести відновлення з них, сертифікати та їх продовження, моніторинг і вікна оновлень. Це означає одну конкретну людину з досвідом Linux і контейнерів, без розподілу відповідальності по завантаженому відділу. Цього ресурсу зазвичай закладають у бюджет менше, ніж реально потрібно, і якщо в компанії немає нікого під цей опис, on-premise вам не підходить.

Це означає лише те, що платформу не зупиняють заради релізу. Гарантії, що нікого й ніщо не перерве, це не дає. Під час послідовного оновлення екран може перезавантажитися і, залежно від того, як термінал авторизований, попросити увійти знову, а незбережені дані у відкритій формі можуть загубитися. Міграція схеми БД або версія, що змінює методику розрахунку показників, усе одно може потребувати запланованого вікна. Домовтеся, кого попереджають перед релізом і як ви відкочуєтеся назад.

Спершу залізо і мережа: сервери під ті модулі, які ви купуєте, GPU-потужності, якщо берете машинний зір або ШІ, окремий VLAN для рівня керування, правила фаєрвола між ним і застосунком, записи DNS, сертифікати та місце для резервних копій із відповідальним за тести відновлення. Додайте іменні адмінські облікові записи й узгоджене вікно обслуговування. Дату запуску найчастіше зсувають саме ці пункти; софт тут винен рідше.

Платформу, яку ми експлуатуємо, і лише хмарні розгортання; за доступність on-premise відповідаєте ви. Ваш канал зв'язку, ваш фаєрвол, локальний колектор і саме обладнання в цю цифру не входять, а на практиці саме вони спричиняють більшість того, що завод сприймає як простій системи. Питайте, як саме вимірюється доступність, що вважається плановим обслуговуванням, за який період рахується показник і що ви отримуєте, коли його не витримали, і вносьте ці визначення в договір.

Так. Цехові системи фіксують, хто ввійшов на якому робочому місці і скільки тривала операція, тож платформу можна експлуатувати законно, але саме ваше розгортання відповідним автоматично не стає. Потрібен договір про обробку даних, визначений строк зберігання і рішення, хто має право бачити показники по конкретній людині, крім агрегованих. Спитайте, чи можна обмежити звітність по окремих працівниках за ролями або вимкнути її взагалі, і залучайте юристів і HR заздалегідь, бо з представниками трудового колективу це зазвичай узгоджують до запуску.