У цій статті Андрій Вайленко, Head of IT Infrastructure Telesens, і Євген Шевченко, System Administrator у Telesens, діляться практичним досвідом побудови інфраструктури віддаленого доступу: чому вони й інші інженери комбінують протоколи, як реалізувати Zero Trust на мінімалках і де насправді приховані підводні камені open-source рішень.

Еволюція болю: від «тунелю» до екосистеми

Колись VPN був просто трубою: ти підключився — і ти «всередині». Коли команда стає глобальною, виникають три проблеми:

1. Швидкість світла: Ганяти трафік з України через сервер у Нью-Йорку, щоб потрапити на ресурс у Франкфурті, це гарантовані гальма.
2. Безпека периметра: Якщо джуніор підключився до VPN, чи має він бачити базу даних Production? Спойлер: ні.
3. Зоопарк пристроїв: Mac, Windows, Linux, Android — і на кожному все має працювати стабільно.

Інженери зрозуміли, що універсального рішення не існує, і прийшли до гібридної схеми.

Священна війна протоколів: що і де використовується

Вибір протоколу — це не про смаки, а про інженерну задачу. Ось градація:

1. WireGuard: Швидкість vs Відсутність MFA

Це фаворит для зв’язку між серверами й офісами.

• Чому: 4000 рядків коду проти сотень тисяч у конкурентів. Він «літає», миттєво відновлює з’єднання після зміни мережі (наприклад, перехід із Wi-Fi на 4G).
• Де використовуємо: Для Site-to-Site тунелів (об'єднання кластерів) і підключення технічно підкованих юзерів (DevOps).
• Нюанс: «Голий» WireGuard жахливий в адмініструванні. Ротація ключів та менеджмент користувачів без додаткових обгорток (на кшталт Tailscale чи Netmaker) — це біль. Протокол спирається виключно на криптографію з публічним ключем (Curve25519) та архітектурно не підтримує MFA. Якщо приватний ключ скомпрометовано, зловмисник отримує доступ миттєво — без SMS чи TOTP кодів. Саме тому «голий» WireGuard ми залишаємо для Site-to-Site.

2. IPsec/IKEv2 (StrongSwan): Стабільна класика

• Де використовується: Для підключення мобільних пристроїв і корпоративних ноутбуків.
• Чому: Нативна підтримка в iOS/macOS/Windows. Користувачу не треба ставити сторонній софт — усе працює «з коробки».

3. OpenVPN: Старий кінь борозни не псує

• Де використовується: Там, де потрібна складна маршрутизація, або у мережах із жорсткими фаєрволами, які блокують UDP. OpenVPN по TCP на 443 порту пролазить майже всюди.

Архітектура: як це працює глобально

Інженери відходять від схеми «один центральний VPN-сервер». Натомість будують мережу PoP (Points of Presence).

1. Географія: Сервери розміщуються в ключових хабах (Франкфурт, Сингапур, Нью-Йорк, Київ).
2. Маршрутизація: Користувач підключається до найближчого PoP.
3. Split Tunneling (Розділення трафіку): Це палиця з двома кінцями.

• Як треба: Корпоративний трафік (Jira, GitLab, Prod DB) йде в тунель. YouTube і Netflix — напряму через провайдера. Це розвантажує наш шлюз.
• Ризик: Якщо домашній комп'ютер співробітника скомпрометовано, хакер може використати цей місток для атаки на корпоративну мережу. Тому Split Tunneling вмикаємо тільки за наявності антивірусу й EDR на хості.

Zero Trust і фізична ізоляція: Градація параної

Самого лише шифрування каналу замало. Інженери будують захист шарами, де рівень ізоляції залежить від критичності даних.

Рівень 1. Логічна сегментація (Бізнес та IT)

Для більшості задач працює принцип Zero Trust: доступ видається на основі ролі, а не факту підключення до мережі.

• Managers: Мають доступ лише до CRM і фінансових інструментів (наприклад, підмережа 10.1.10.x).
• DevOps: Бачать CI/CD, Git і тестові бази.
• QA: Мають доступ до Staging Environment.

Результат: Якщо хакер вкраде ноутбук менеджера, він не зможе покласти Production-базу, бо мережевий шлюз просто дропне ці пакети.

Рівень 2. «Червона зона»: Де закінчується VPN

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

Тут інженери переходять від Zero Trust до Air-gap (Повітряного проміжку).

• Суть: Фізичне відключення захищеного контуру від інтернету. Найкращий фаєрвол — це відсутність кабелю.
• Відмінність: Якщо в IT-компанії адмін може зайти на сервер із дому через VPN, то в контурі Air-gap віддалений доступ заборонений архітектурно.

Інженерний висновок: Не намагайтеся натягнути офісні VPN-рішення на об'єкти критичної інфраструктури. Там, де ціна злому, це техногенна катастрофа, безпеку забезпечує фізика, а не софт. Для всього іншого є VLAN і Zero Trust.

Чек-ліст безпеки (Must Have):

1. MFA (Multi-Factor Authentication): Без OTP токена VPN не підніметься. Це не обговорюється.
2. DNS over HTTPS (DoH): Закриваємо DNS Leaks. Немає сенсу шифрувати тунель, якщо запити летять відкритим текстом. Форсуємо DoH, щоб не світити внутрішні домени адміну кав'ярні.
3. Моніторинг: Prometheus + Grafana дивляться за навантаженням. ELK Stack збирає логи.
4. Аномалії: Якщо один юзер логіниться з Києва, а через 5 хвилин з Амстердама (Impossible Travel), акаунт блокується автоматично.

Open-Source vs Комерція: що обрати?

Це вічне питання: «Build or Buy?»

Open-Source (WireGuard, OpenVPN або StrongSwan):

• Плюси: Безкоштовно (ліцензії), повний контроль, немає прив'язки до вендора.
• Мінуси: TCO (Total Cost of Ownership) може бути вищим. Ви платите зарплату інженерам, які це налаштовують, патчать і підіймають, коли воно впало о 3-й ночі.
• Кому підходить: Стартапам, Tech-компаніям із сильною інженерною культурою.

Комерційні рішення (Cisco, Fortinet, Palo Alto):

• Плюси: Підтримка, SLA, готові інтеграції з Active Directory та перевірка «здоров'я» пристрою (Compliance Check).
• Мінуси: Дорого. Дуже дорого. Часто надлишковий функціонал.
• Кому підходить: Enterprise, банкам, компаніям із суворим комплаєнсом (SOC2, HIPAA).

Замість висновків

Побудова інфраструктури для віддалених команд — це баланс між підвищеними вимогами безпеки та комфортом розробника.

Якщо ви будуєте систему з нуля або рефакторите старий спадок, ось п’ять заповідей, написаних потом і кров’ю інженерів:

1. Ніяких самописів для WireGuard. Забудьте про скрипти для генерації ключів. Це працює для трьох друзів, але в компанії перетворюється на пекло. Беріть Netmaker, Firezone або Tailscale. Інструмент має працювати на вас, а не ви на нього.
2. MFA — це база. Паролі крадуть, сесії перехоплюють. Без другого фактора (OTP/YubiKey) VPN-доступ не видається. Це не обговорюється навіть із CEO.
3. Принцип мінімальних прав. Дефолтне правило для будь-якого нового юзера - deny all. Ніякого доступу до всієї підмережі /24. Відкривайте тільки конкретні IP і порти, які потрібні для роботи.
4. Фізика надійніша за софт. Якщо ви захищаєте щось справді критичне (від управління заводом до ключів шифрування), не сподівайтесь на VLAN. Будуйте Air-gap. Кабель, який не підключено, неможливо хакнути віддалено.
5. Бекап — це ілюзія. Поки ви не розгорнули інфраструктуру з бекапу на чистому сервері, у вас немає бекапу. Ви маєте лише файл, який займає місце на диску. Тестуйте restore, а не backup.

І пам'ятайте: інфраструктура не буває «готовою». Те архітектурне рішення, яким ви пишаєтесь сьогодні, завтра неминуче стане legacy, що гальмує бізнес. Не бійтеся рефакторити мережу. Бійтеся моменту, коли вона стане настільки складною, що ви побоїтеся її чіпати.

Будуєте складну інфраструктуру для свого продукту? Дізнайтеся більше про наші рішення в системній інтеграції та Smart Routing на сайті Telesens або сконтактуйте з нами у LinkedIn.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

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

Усе, про що ви прочитаєте далі, — це не просто теоретичні поради з підручників з менеджменту. Це результат багаторічного досвіду в ІТ-індустрії, сотень проведених співбесід та спостережень за злетами й падіннями фахівців різного рівня.

Саме про цю усвідомлену стратегію «тихого входу» — без зайвого тиску, але з чітким розумінням контексту, ролей і моменту для дій — розповість Олеся Ульянова, Ph.D, MBA, CEO Telesens, Founder ITGC, ex-ментор USAID.

1. Я б не намагалась одразу показати максимум експертизи

Найпоширеніший внутрішній імпульс на старті — бажання якомога швидше підтвердити свою цінність для команди й компанії. Всередині це часто звучить так: «Треба швидко показати, що я сильний фахівець».

Під тиском цього імпульсу людина починає діяти не з позиції розуміння, а з позиції самодоказу. З’являється потреба бути помітним, корисним тут і зараз, навіть якщо для цього ще бракує контексту. У результаті люди:

• активно коментують рішення, не знаючи передумов і обмежень;
• пропонують «очевидні покращення», не розуміючи, чому процеси виглядають саме так;
• демонструють знання й досвід, які поки що не вбудовані в реальність конкретної компанії.

Проблема не в експертизі. Проблема — у відсутності розуміння системи, у якій ця експертиза має працювати. У перший місяць будь-яка «розумна порада» без контексту легко зчитується як критика, тиск або зверхність, навіть якщо наміри були конструктивними.

Куди ефективніша стратегія на цьому етапі:

• слухати більше, ніж говорити;
• накопичувати спостереження, а не рішення;
• фіксувати питання, а не поспішні висновки.

2. Я б не робила вигляд, що мені все зрозуміло

Кивати на мітингах, боятись поставити питання, не уточнювати терміни чи рішення — дуже дорога стратегія. В ІТ незрозуміле не «проясниться само собою».  Воно накопичується — і вибухає пізніше у вигляді:

• помилок;
• переробок;
• відчуття, що «я щось пропустив».

Парадоксально, але людина, яка питає, виглядає професійніше за ту, яка мовчки плутається. Сильна позиція фахівця звучить так: «Я хочу переконатися, що правильно розумію логіку».

3. Я б не порівнювала нову компанію з попередньою

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

Фрази (навіть внутрішні) «А от у нас раніше…» чи «У минулій команді це робили інакше» — запускають механізм протиставлення «там» і «тут» і заважають по-справжньому прийняти нову реальність. Замість занурення виникає оцінювання, замість розуміння — порівняльна шкала, де нова компанія завжди програє або потребує «виправлення».

Варто пам’ятати: кожна ІТ-компанія — це не набір випадкових рішень, а результат конкретної історії, контексту й обмежень. У неї завжди є:

• власний темп ухвалення рішень;
• свої компроміси між якістю, швидкістю та ресурсами;
• свої болі, які не завжди очевидні з першого погляду.

Порівняння не допомагає адаптації. Воно лише підсилює внутрішній опір і неприйняття того, що вже існує. Значно продуктивніше змістити фокус із «як було» на «чому тут саме так» і почати ставити інші запитання:

• чому в цій команді обрали саме такий підхід;
• що саме це рішення захищає або оптимізує;
• яку проблему воно реально вирішує в поточних умовах.

4. Я б не поспішала «вписатися» будь-якою ціною

Я б не радила поспішати «вписатися» в нову команду будь-якою ціною. На старті це виглядає як безпечна стратегія: бути прийнятим, не створювати напруги, швидко стати частиною колективу. Бути «своїм» — цілком природне бажання, особливо в новому середовищі, де ще немає опори, репутації й довіри.

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

• надмірна згода з будь-якими рішеннями;
• уникання незручних, але важливих питань;
• спроба підлаштуватися під команду замість того, щоб спочатку її зрозуміти.

У результаті ви швидше стаєте зручними, ніж корисними. А зручність рідко трансформується в довіру чи реальний вплив у довгостроковій перспективі. Це слабка стратегія для фахівця, який хоче не просто «залишитися», а бути цінним елементом системи.

Набагато ефективніше на цьому етапі зайняти іншу позицію:

• спокійної нейтральності без демонстративної лояльності;
• уважного спостерігача, а не активного погоджувача;
• людини, яка ще збирає повну картину, перш ніж робити висновки й пропонувати рішення.

5. Я б не очікувала від себе миттєвої продуктивності

Я б не очікувала від себе миттєвої продуктивності на новому етапі. Навіть якщо технічно ви сильні, з досвідом і хорошим бекграундом, організм і мислення все одно проходять фазу адаптації.

Перший місяць — це не про результати, а про вбудовування в контекст:

• нові домени;
• нові люди;
• нові залежності;
• нові правила гри.

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

6. Я б не брала на себе більше, ніж реально можу винести

Я б не брала на себе більше, ніж реально можу винести — особливо на старті. Перший місяць часто створює ілюзію, що потрібно довести свою цінність якомога швидше: бути зручною, максимально корисною, завжди «так». У цей момент легко переплутати відповідальність із перевантаженням.

У перший місяць особливо легко переоцінити власні ресурси: погоджуватись на все, брати зайві задачі і не ставити меж.

З боку це виглядає як мотивація. На практиці — як шлях до швидкого вигорання або помилок. Краще одразу формувати репутацію людини, яка:

• чесно оцінює навантаження;
• не обіцяє зайвого;
• вміє сказати «мені потрібно уточнити».

7. Я б не робила ранніх висновків про людей і команду

Я б не робила ранніх висновків про людей і команду — і свідомо залишала собі паузу на спостереження. Перший місяць спотворює оптику: ми дивимось на нове середовище крізь власний стрес, очікування й бажання швидко зрозуміти, «хто тут хто». Але команда в цей момент ще не є собою, а ми — ще не в ній.

У перший місяць:

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

Те, що здається байдужістю, слабкістю чи незацікавленістю часто виявляється адаптацією, втомою або обережністю. Ранні ярлики — найгірший інструмент орієнтації.

Перший місяць в ІТ — це не час бути ідеальним.  Це час бути точним, уважним і чесним із собою. Найкраща стратегія фахівця на старті — не блищати, не змагатися і не доводити. А вбудовуватись у систему так, щоб через кілька місяців ваша цінність стала очевидною без слів.

Пам’ятайте: сильний старт — це не швидкість. Це відсутність зайвих помилок.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Доходи приходять із різних джерел, часто міжнародних, з’являються нові моделі монетизації, гранти для стартапів, а податкове законодавство постійно адаптується. Фінансове планування на 2026 рік має бути гнучким, стратегічним, враховувати нові податкові режими, міжнародні платежі, грантові надходження та нестандартні джерела доходів.

Податкове середовище у 2026 році

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

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

Спеціальну систему оподаткуванню і надалі матимуть резиденти Дія.City. Податок на виведений капітал (ПнВК) 9% сплачують тільки при виведенні коштів із бізнесу, тож компанія може реінвестувати прибуток у розвиток без податку.

Ще одна особливість — гнучкі правила оплати праці. Для працівників і гіг-спеціалістів ПДФО становить 5% замість стандартних 18%, плюс мінімальні ЄСВ. Це зменшує податкове навантаження на зарплати й робить бюджет більш передбачуваним.

Валютні коливання та ризики

ІТ-компанії часто отримують гроші у валюті, але витрачають їх у гривнях. Курс валют постійно змінюється, і це може впливати на ваш дохід. Тому під час планування варто:

1. Закладати «страховку» на випадок падіння або стрибка курсу.
2. Вести облік доходів у валюті та витрат у гривнях, щоб бачити реальний ефект коливань.
3. Розглядати прості способи захисту, наприклад, фіксований курс у договорах або часткове конвертування відразу.

Гранти та стартап-фінансування

Лише за перший квартал 2025 року українські ІТ-стартапи залучили рекордні $450 мільйонів інвестицій. У 2026 році ця тенденція зростатиме. Важливо пам’ятати: гранти — це не класичний дохід, а цільове фінансування. Тобто гроші видаються під конкретні завдання або проєкти. Якщо їх не відокремлювати від комерційних надходжень, легко втратити контроль над бюджетом.

Що планувати, щоб не заплутатися?

1. Бюджет гранту: розбийте на категорії (зарплати, маркетинг, розробка, обладнання) і прив’язуйте витрати до конкретних цілей гранту.
2. Терміни та звітність: усі гранти вимагають регулярних звітів, тому закладайте час та ресурси на підготовку документів.
3. Додаткові інвестиції: інвестори часто хочуть бачити, як стартап буде масштабуватися після гранту, тому плануйте фінансову «дорожню карту» на 6–12 місяців.
4. Комбінування джерел: поєднувати гранти та венчурне фінансування можна, але треба чітко розмежовувати, які витрати покриває кожне джерело.

У 2026 році фінансова стратегія ІТ-компаній має бути такою ж гнучкою, як і технології, що вони створюють. Для цього потрібно зібрати всі доходи, податки й валютні ризики в єдину систему. Це дасть вам можливість займатися розвитком бізнесу, не відволікаючись на екстрене гасіння бухгалтерських проблем.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Ми безпосередньо стикнулися з цим бар’єром під час місії World Central Kitchen (WCK) у Туреччині — організації, що надає продовольчу допомогу постраждалим. Після серії потужних землетрусів команда працювала в постраждалих районах, організовуючи харчування для місцевих жителів. Щоб налагодити комунікацію з людьми, зорієнтувати їх, підказати, де можна отримати медичну допомогу чи підтримку від інших служб, був необхідний доступ до інтернету —  щонайменше, до Google Перекладача. Проте мобільні мережі залишалися перевантаженими. Ми ухвалили рішення задіяти Starlink на власний ризик, розуміючи, що його можуть конфіскувати.

Поки ми на зв’язку — розуміємо, що відбувається, і можемо діяти. Коли ж зв’язок зникає, з’являється інформаційний вакуум, який породжує паніку, дезорієнтацію і стає ґрунтом для дезінформації.

Становлення супутникового інтернету: від Tooway до Starlink

Ще недавно супутниковий інтернет був маловідомою технологією, про яку ми знали хіба що з голлівудських політичних трилерів. Сьогодні це один із ключових засобів підтримки зв’язку в Україні — і один із факторів, що буквально впливає на виживання та ефективність оборони.

Перші партії Starlink, флагмана серед провайдерів супутникового зв’язку, з’явилися в Україні навесні 2022 року. Станом на 2025 рік країна отримала понад 50 тисяч терміналів. За оцінками Adaptis, у приватному користуванні українців ще близько 100 тисяч терміналів.

Ветерани АТО, згадуючи бойові дії у 2014-2015 роках, називають проблеми зі зв’язком істотною проблемою на той момент. За свідченнями ветеранів, проблеми зі зв’язком були одним з чинників, що призвели до оточення в Іловайську. Наземна інфраструктура не витримувала навантаження або просто знищувалася обстрілами. Мобільний зв’язок працював із перебоями, частоти глушилися, а підрозділи часто залишалися без координації. Єдиним резервом були військові радіостанції — але радіо не забезпечувало передачу даних, координат чи зображень, а канали часто перехоплювалися противником.

Спроби вирішити проблему супутниковими рішеннями тоді існували, але були обмеженими. Використовувалися системи на кшталт Tooway — великі круглі супутникові “тарілки” (діаметром близько 80 см), що працювали через геостаціонарні супутники та вимагали фіксованого розміщення. Такі комплекси забезпечували базовий інтернет-канал, але мали критичні недоліки для фронтових умов: велику затримку сигналу (пів секунди і більше), складність налаштування, потребу у фіксованому розміщенні антени. Це означало, що супутниковий інтернет можна було встановити на командному пункті чи в тилу, але не «в полі». Для мобільних підрозділів, евакуаційних груп, розвідників або артилерійських розрахунків такі рішення були практично непридатні.

На відміну від 2014 року, коли супутникові рішення залишалися малопридатними для бойових умов, у 2022-му, з початком повномасштабного вторгнення Росії, ситуація змінилася докорінно. До цього часу супутникові технології вже пройшли суттєву еволюцію, і поява Starlink як флагмана нового покоління зробила можливим стабільний інтернет навіть на лінії фронту.

Мережа Starlink складається з сотень малих супутників на низькій орбіті (LEO), що забезпечує мінімальну затримку сигналу й усуває потребу в точному наведені терміналів. Завдяки цьому зв’язок можна розгорнути буквально за кілька хвилин і використовувати навіть у польових умовах: на передовій, у бронетехніці, мобільних штабах чи на безпілотниках.

Що далі? Пошук альтернатив і диверсифікація ризиків

Збої в роботі Starlink, а також раптові обмеження доступу під час бойових дій підкреслили потребу в резервних рішеннях і локальних інженерних розробках. Стала очевидною і головна вразливість: залежність від єдиного провайдера.

Найактивніше у цьому напрямку працюють кілька міжнародних гравців. Amazon розгортає свій проєкт Project Kuiper — мережу з понад 3 000 супутників на низькій орбіті. Kuiper робить ставку на інтеграцію з AWS-хмарами, тобто поєднання супутникового доступу з аналітикою й зберіганням даних у реальному часі. Перші тестові запуски відбулися у 2025 році, а комерційний старт очікується найближчим часом.

У Європі створюється IRIS² — ініціатива Єврокомісії, що має на меті забезпечити цифровий суверенітет ЄС і надати безпечний канал зв’язку для урядів, оборонних структур і критичної інфраструктури. Свої проєкти активно розвивають і європейсько-британська компанія Eutelsat OneWeb (флот із понад 600 LEO-супутників) та Telesat Lightspeed у Канаді.

У ближчій перспективі Starlink навряд чи втратить лідерство — він має перевагу у масштабі, темпі запусків і польовому досвіді. Але конкуренція посилюється: у 2026-2027 роках очікується розгортання ще кількох LEO-мереж, які можуть створити реальну політику «стримування та противаг». Для України це означає не лише технологічну незалежність, а й можливість диверсифікувати ризики, мати резервні канали зв’язку й будувати власні рішення поверх глобальної інфраструктури.

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

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Коли команди стають мультикультурними, децентралізованими й самостійними, керівник уже не може просто «менеджити». Він має вести за собою, розуміти людей і трансформувати себе разом із ними.

Саме з цієї ідеї виросла книга «Антименеджер. Я і тільки Я» від авторки, тренерки з розвитку soft skills і лідерства Олесі Ульянової. Вона пропонує не ще один посібник із менеджменту, а цілком нову концепцію — антименеджмент, де «анти» означає не заперечення, а переосмислення ролі лідера.

Не ще одна книга про лідерство

Uli пояснює: класичний менеджмент вичерпав себе там, де команди потребують не контролю, а довіри.

«Антименеджер — це не про жорсткі процеси. Це про людину, яка розвиває себе настільки, що може вести інших без тиску. Не через KPI, а через усвідомленість і взаємодію».

Її підхід побудований у форматі трилогії, де кожна частина — окремий рівень розвитку лідера:

● «Я і тільки Я» — персональна ефективність, самодисципліна, управління ресурсом.

● «Я та ми» — комунікація, взаємодія в команді, робота з конфліктами.

● «Я та вони» — управління змінами, синергія між командами, системне лідерство.

Це не просто три книги — це шлях трансформації: від себе до команди, від команди до організації.

Soft skills без пафосу

Для ІТ-сфери, де часто фокус робиться на hard skills, цей підхід звучить несподівано. Але саме в технологічних командах сьогодні найчастіше виникають кризи довіри, вигорання і брак емоційної зрілості лідерів.

Авторка не романтизує soft skills. Вона показує, що самодисципліна, продуктивність і робота зі станом — це не «мотивація», а технологія, яку можна відтренувати.

«Жодна навичка не є магією. Те, що називають «харизмою» або «енергією лідера», — це системна робота над собою».

Але головний виклик — у тому, що зміни потребують не лише знань, а й внутрішньої трансформації. Soft skills неможливо просто вивчити — їх потрібно прожити. І цей процес не завжди комфортний.

Як народився «Антименеджер»

Ідея книги з’явилася у 2020 році, коли через пандемію тренінги перейшли в онлайн, а слухачі почали просити систематизований матеріал. Спочатку замислювалася велика енциклопедія soft skills на 900 сторінок, але війна та переосмислення власного досвіду змінили підхід.

Так народилася трилогія, яка виросла з реальної практики — тренінгів, кейсів і робочих історій із командами різних рівнів.

«Мені хотілося створити не теорію, а інструмент. Кожна порада має алгоритм, який можна застосувати в реальній роботі вже завтра», — пояснила авторка.

Хто такий антименеджер у сучасному ІТ

Антименеджер — це не опозиція до менеджменту. Це його еволюція. У світі, де лідери змагаються не в контролі, а в довірі, антименеджер:

● працює над собою більше, ніж над іншими;

● створює команду однодумців, а не просто виконавців;

● уміє відновлювати свій ресурс і не згорати разом із командою;

● не боїться експериментів і помилок.

Для ІТ-компаній це підхід, який допомагає будувати автономні команди, де відповідальність розподілена, а розвиток — спільна справа.

Що далі

Наступна книга планується у форматі метафоричної «кухні» — не про страви, а про рецепти поведінки лідера. Як у The Phoenix Project, де професійні виклики подано у формі художньої історії, ти читаєш і впізнаєш своє життя в команді.

І ще одна ідея — книга про фідбек, адже це одна з найболючіших тем для менеджерів. Вона вже буде коротшою — не 900 сторінок, але не менш змістовною.

Підсумки

Антименеджмент — це не про заперечення системи, а про усвідомлення себе в ній. В ІТ, де зміни відбуваються щодня, саме такі лідери — не адміністратори, а аналітичні, емпатійні й саморефлексивні — формують культуру команд, здатних зростати без мікроменеджменту.

Перша книга трилогії — «Антименеджер. Я і тільки Я» — вже у продажу. І, можливо, саме з неї почнеться ваш шлях від керівника до справжнього лідера.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Як не втратити гроші під час роботи з іноземними замовниками?

IT-бізнес рідко обмежується однією країною. Часто айтівці працюють із клієнтами зі США, Європи або Азії. Це передбачає врахування кількох важливих нюансів:

• Валютний контроль. Коли на ваш рахунок заходить валюта, банк не пропустить її далі без підтвердження. Потрібні інвойси, договори й опис послуг. Якщо чогось не вистачає, гроші просто «зависають» на транзиті, і ви не можете ними користуватися.
• Контракти англійською. Замовники не розуміють, чому вам потрібен документ на п’ять сторінок із мокрою печаткою, у них інвойс на один абзац вважається достатнім. Але для українського банку й податкової такий документ може мати сумнівний вигляд.
• Подвійне оподаткування. Якщо замовник зі США чи Німеччини, потрібно враховувати міжнародні угоди. Інакше можна опинитися в ситуації, коли частину податку візьме Україна, а частину — країна клієнта.

Завдання бухгалтера — подавати українські дані у форматі, зрозумілому фінансовим контролерам за кордоном. Це не просто переклад цифр, а перебудова структури звітності під конкретні вимоги замовника. Такий підхід вимагає знання міжнародних стандартів фінансової звітності (IFRS), мовних особливостей і специфіки податкових юрисдикцій.

Фриланс-платформи: блокування, адаптація інвойсів і відповідність українському законодавству

Upwork, Fiverr, Toptal, Payoneer чи PayPal — стандартні канали отримання доходів для ІТ-фахівців, але їх використання дещо ускладнює бухгалтерський облік. Наприклад, платформи знімають комісії. Ви бачите у контракті суму в тисячу доларів, але на рахунок приходить менше. Для податкової ж важливо чітко розмежувати: що є доходом, а що витратами. Якщо цього не зробити, у звітах виникає розрив, і податкова може трактувати зменшену суму як заниження доходу.

Інвойси з Upwork чи виписки з PayPal часто не відповідають стандартам української податкової. Вони англійською, без правильних реквізитів, іноді взагалі виглядають як коротка квитанція. Банки через це часто ставлять платежі на паузу й вимагають додаткових пояснень про реальність доходу від ІТ-послуг, а не як приватний переказ.

Саме тому потрібно або оформлювати доходи через ФОП/ТОВ, або адаптувати інвойси та виписки через бухгалтерію. Адже якщо поставитись до роботи з платформами невідповідально, є ризики залишитися без доступу до власних коштів.

Особливості роботи з інтелектуальною власністю та ліцензіями

В ІТ часто йдеться не про послугу, а про продукт: мобільні ігри, SaaS із підпискою, ліцензії на софт чи продаж коду. Якщо йдеться про послугу з розроблення під конкретного замовника, усе більш-менш зрозуміло. Але якщо про продаж ліцензії чи прав на продукт, виникає питання: це роялті, послуга чи продаж нематеріального активу? Від відповіді залежить, яку ставку податку потрібно сплатити, чи взагалі можна залишатися на спрощеній системі, і чи не поставить податкова під сумнів законність такої моделі роботи.

Щоб уникнути проблем із банком і податковою, варто:

• Правильно визначити природу доходу (послуга, роялті, продаж активу).
• Обрати доречну систему оподаткування.
• Підготувати коректні договори й інвойси так, щоб банк і податкова не мали підстав ставити операції під сумнів.
• Залучити фахівців (бухгалтерів чи юристів) для мінімізації ризиків.

Дія.City: податковий оазис для айтівців

Дія.City — це спеціальний правовий режим, створений для підтримки та розвитку української IT-індустрії. Компанії-резиденти можуть обирати між 18% податку на прибуток і 9% податку на виведений капітал. Дивіденди для фізичних осіб обкладаються 0%, якщо виплачуються раз на два роки, а також якщо компанії отримують дивіденди від резидента Дія.City, що обере ПнВК. Така гнучкість дає можливість зберігати більше коштів у бізнесі й ефективно планувати розвиток.

Ще однією перевагою є гнучкі форми співпраці. Гіг-контракти стали золотою серединою між ФОПом і класичним працевлаштуванням: вони дають компанії легальні механізми для гнучкого залучення спеціалістів, зокрема й іноземних, а працівникам — соціальні гарантії та захист.

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

Статус резидента Дія.City означає прозорість і зрозумілі правила для іноземних партнерів. Інвестори охочіше співпрацюють із компаніями, які ведуть звітність за міжнародними стандартами, а цей режим саме це і передбачає.

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

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Про vibe coding уперше заговорив Андрій Карпати у лютому майже жартома. Іронічну фразу про «лови вайб, забудь про код» швидко підхопили в твіттері, а потім і в командах, де експериментують із GitHub Copilot, ChatGPT, Cursor, Claude та іншими ШІ-асистентами. Згодом виявилося, що ця фраза не лише мем. Вона точно описує те, що вже робить чимало людей: пояснює комп’ютеру, що потрібно, не занурюючись у реалізацію.

Я вирішила зібрати коментарі розробників, які реально працюють із ШІ і розібратись у тому, чим є vibe coding на практиці, чим він відрізняється від low-code і класичного девелопменту, які інструменти його підтримують і яке майбутнє чекає нас з vibe coding.

Кодити без написання коду: звучить сумнівно, але працює

Vibe coding — це новий підхід до програмування, де вихідною точкою є не код, а розмова. Вищезгаданий Андрій Карпати вперше вжив фразу vibe coding у відповідь на запитання про те, як девелоперам працювати з LLM.

«Ти просто ніби вайбиш із моделлю»,— написав він і під «вайбиш» мав на увазі інтуїтивний процес роботи з кодом, коли ви пишете промпти, пояснюєте ШІ, що вам потрібно і потім коригуєте код, який згенерував штучний інтелект.

Вже за кілька тижнів цей вираз почали використовувати IT-спеціалісти, продакт-менеджери і навіть венчурні інвестори, які без вагань включали його у свої пітчдекі.

Як виявилося, суть vibe coding доволі проста і дійсно відзеркалює назву: вам не потрібно писати код построково. Ви просто задаєте «вайб» і описуєте штучному інтелекту те, що ви хочете побачити у фіналі. Це може бути що завгодно — веб-додаток для догвокерів; скрипт, який синхронізує ваші таблиці з Notion; дашборд, що автоматично оновлює метрики KPI або цілий сайт. Ви даєте ШІ намір, промпт, а модель домальовує деталі. І незалежно від того, чи ви сеньйор-інженер, чи ніколи не відкривав VS Code — на вашому екрані зʼявиться працюючий софт.

Згодом Карпати сам детальніше розкрив, що мав на увазі. Vibe coding, за його словами, — це «менше про чіткі інструкції, більше про передачу наміру — так, як ти б пояснював щось джуніору, що сидить поруч». Людина задає загальний напрям, а модель добудовує. Це не команда — це співпраця. Це вайб.

Володимир Обрізан, директор Design and Test Lab та автор блогу про vibe coding описує цей підхід так:

«Для мене вайб-кодинг — це в першу чергу стан, коли код пишеться не заради замовника, зарплатні або дедлайнів, а заради кайфу. Чомусь коли згадують застосування ШІ у програмуванні, то перше питання «чи багато клопоту підчищати за ШІ»? Але я би першим пунктом поставив те, що програмування з ШІ повернуло мені те, що ні за які гроші не купиш — це натхнення у програмуванні, яке в мене було, коли я хлопчиком в школі вивчав програмування на ZX Spectrum, або студентом з другом на канікулах писав компʼютерну гру на Delphi. Чи треба було тоді багато років тому виправляти свої ж помилки, або помилки в документації, «підчищати»? Так! Але для яка різниця для мене, якщо я роблю це з натхненням».

Подивимося на це більш практично. Застосовуючи vibe coding, замість описування логіки та синтаксису з нуля, ви починаєте діалог із промпта. Наприклад: «Створи мені односторінковий React-додаток, який показуватиме погоду за геолокацією, матиме перемикач темної теми і буде оновлюватися кожні 15 хвилин».

При цьому немає гарантій, що це завжди працюватиме з першого разу. Деякі розробники відзначають, що часто доводиться не просто «пояснювати» ШІ», а ще й перезапускати сесію, бо модель збивається або починає мислити в хибному напрямку.

«Він легко ламає проєкт. Навіть git не допоможе — він відновить код, але не витре «пам’ять» моделі. Іноді простіше почати з нуля», — зазначає Володимир Остапів, Java Developer у N-iX.

ШІ підхоплює це, створює структуру, підбирає пакети, налаштовує запити до API і, роблячи останні штрихи, видає вам результат. Іноді ШІ створює вже повністю готовий до деплою додаток. А іноді генерує просто хорошу стартову заготовку, з якою можна працювати далі. Але важливо те, що людина не писала код в класичному розумінні. Людина тільки задавала вайб.

Розробники, з якими я говорила, уже встигли випробувати vibe coding на практиці. І хоча підходи різняться, майже кожен знайшов для себе ситуації, де це справді економить сили або хоча б пробуджує інтерес.

Хтось як Василь Мухар, Technical Director у Edvantis, використовує AI для генерації юніт-тестів і зізнається, що це дозволяє більше зосередитись на архітектурі.

Роман Гелембюк, Software Engineer з компанії Nasuni, каже, що Copilot для нього є must-have для повсякденної роботи, а Cursor працює чудово в добре структурованих проєктах.

Володимир Остапів, девелопер з N-iX, тестує vibe coding у pet-проєктах, особливо на Python, і каже, що LLM добре справляються з типовими задачами, поки не доходить до чогось нішевого, як Lua. А Android developer Анатолій Кокулюк розповідає, що використовує ChatGPT для створення Django-моделей, шаблонів, JavaScript-функцій, генерації тестів і навіть формулювання завдань у навчальній платформі.

Дехто з них експериментує обережно, інші ж — повністю занурені в процес. Але всіх об’єднує те, що це вже частина їхніх робочих чи дослідницьких процесів. Тепер природна мова стає інтерфейсом для створення продуктів. Замість того, щоб вчити синтаксис, користувач вчиться чітко формулювати свої потреби. І на виході, замість боротьби з порожнім файлом ми маємо співпрацю з моделлю, яка вже бачила мільйон подібних запитів. З цього вимальовується інший важливий і, можливо, для когось приємний момент — vibe coding не лише для девелоперів. Дизайнери тепер можуть пропрацювати візуальну розмітку ще до того як відкрили стартову сторінку Figma, а sales-managers можуть попросити ШІ зробити «скелет» додатку, що аналізуватиме потенційний ріст продажів у різних регіонах в залежності від віку, фінансових можливостей або уподобань.

Звісно, це не магія поза Хогвартсом. Код може згенеруватись кривим, логіка запитів може бути неідеальною, а результати роботи ШІ не завжди такі, які очікує людина. Однак, перша суттєва перевага тут все ж є — цей підхід стискає час між ідеєю і реалізацією. Він не вбиває розробку як таку, а просто прибирає потребу в рутинних процесах, вивільняючи простір на UX, тестування або запуск продукту.

Vibe coding vs. традиційне програмування: де знаходиться межа між намірами і кодом?

Поки vibe coding провокує нові дискусії і привертає до себе увагу, традиційні підходи до розробки програмного забезпечення все ще залишаються актуальними. Так, vibe-кодування може стати новим витком еволюції у розробці ПЗ, затьмарюючи класичний coding, але давайте згадаємо, що саме відрізняє традиційне програмування і нові підходи.

Традиційне програмування

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

Low-code платформи

Деякі IT-спеціалісти кажуть, що вони з’явилися, щоб спростити життя. Людині достатньо мати базове розуміння концепцій програмування, а далі починається процес розробки, перетягування компонентів, налаштування параметрів. Тут немає перетинання з реальним кодом, а платформа як така все ж обмежує в можливостях. З low-code буде під силу впоратися тим, хто не готовий втрачати себе у технічних джунглях заплутаного та філігранного кодингу.

Vibe coding

Якщо в попередніх підходах йшлося про мінімальні зусилля у написанні коду, то як ми вже знаємо vibe coding не передбачає цього. Ви просто описуєте робочий софт, який хотіли б отримати, не використовуючи конфігурації, синтаксис. Якщо фінальний результат вас не влаштував, замість двобою з написанням коду, просто переформульовуєте промпт. При цьому код існує, але користувач з ним напряму не працює. Фактично немає потреби знати, чим == відрізняється від ===. Потрібна лише чіткість формулювання запиту.

AI-інструменти, що підсилюють Vibe Coding

Vibe coding не виник з порожнього простору, за ним звісно ж стоїть чималий стек AI-інструментів, які спершу непомітно, а зараз вже повноцінно стали частиною щоденної рутини розробників, дизайнерів і продуктових команд. Разом вони формують хребет нового способу створення софту.

Великі мовні моделі (LLMs)

У центрі всього — LLM'и. Власне, вони й генерують усе це добро.

• GPT-4 / GPT-4o— досі найпопулярніші для загальних задач програмування. Добре тримають контекст, розбираються в багатокрокових запитах. Доступні через ChatGPT або API.
• Claude 3 (Anthropic)— набирає обертів завдяки м’якому тону та меншій схильності «галюцинувати» при структурованих завданнях.
• Gemini (Google), Command R+ (Cohere), Mistral— часто використовуються в опенсорс-інструментах або нішевих застосунках.

Обирати одну не обов’язково. Багато vibe-кодерів постійно стрибають між різними LLM, залежно від задачі, або ж використовують інструменти, що комбінують їх у бекенді.

Результат дуже залежить від того, яку саме модель ви використовуєте. Наприклад, Claude чудово справляється з Python, але намагається «зшити» C++ проєкти без особливої структури. Як каже Володимир, Java Developer з N-iX, іноді потрібно паралельно тестувати одну й ту саму задачу на кількох LLM, щоб побачити, яка з них «не зламає вам усе».

Асистенти коду

Це досить зручні напарники в IDE. Вони підказують, генерують фрагменти, реагують на промпти.

Найвідомішим з них є Replit Agent, що діє як розробник програмного забезпечення на базі штучного інтелекту, який може генерувати фронтенд- та бекенд-код, налаштовувати бази даних і навіть автономно виправляти помилки. Його описують як дуже універсального асистента, здатного підтримувати багато мов програмування та фреймворків. До того ж, він надає повний доступ до коду, якщо комусь захочеться зануритися у кодування глибше.

Одна з головних переваг полягає в тому, що Replit автоматично керує розгортанням – коли ваш додаток готовий, ви можете миттєво поділитися ним за допомогою URL-адреси.

Не обійшли девелопери увагою й Lovable — платформу, розроблену без коду. Тут просто потрібно описати, що ви хочете і немає потреби розуміти код, що генерується. Тому девіз цього асистента і звучить ось так —  «Від ідеї до програми за лічені секунди». Також до переваг відносять попередній перегляд змін у реальному часі, підказки природної мови, інтуїтивно зрозумілий інтерфейс та експорт коду для розширеного налаштування.

Ще один популярний асистент коду під назвою Cursor здобув собі славу майже колеги-розробника, який завжди поруч, усе пам’ятає і нормально розуміє твій код. Не просто допоміжний засіб, а повноцінний учасник процесу. Як вказують розробники на форумах, якщо GitHub Copilot просто підставляє тобі код під час друку, то Cursor дає можливість спілкуватися з кодом. Можна виділити шматок функції й написати: «Додай обробку помилок» або «Чому тут падає запит?». Але здається найбільше Cursor люблять за те, що він зберігає історію запитів — і по файлам, і по задачах. Тобто можна повернутись до старого діалогу без зайвих пояснень. Не треба щоразу все заново формулювати як у звичайному чаті.

Cursor отримав багато схвальних відгуків і за зручність у вже структурованих проєктах.

«Один із моїх веб-проєктів має ідеальну організацію коду. Cursor проіндексував усе і добре повторював патерни», — каже Роман Гелембюк, Software Engineer у Nasuni.

Але додає, що на інших проєктах Cursor справляється гірше, особливо коли архітектура не впорядкована або стек менш популярний.

Серед ШІ-асистентів для створення вебзастосунків активно згадують і Bolt.new. Достатньо дати йому ТЗ, а далі він одразу генерує код і все відбувається в межах браузеру. Ніяких редакторів чи IDE, натомість відкриваєте вкладку, даєте задачу, отримуєте сайт. Під умовним «капотом» LLM, тож Bolt розуміє, що ви хочете і не просто генерує шаблони, а адаптує все під запит. Як і Replit Agent, він обробляє розгортання одним кліком тачпаду.

Дехто міксує ці інструменти: обирає Cursor для структури, Copilot — для дрібних доробок, ChatGPT — для генерації цілих фіч.

Василь Мухар, Technical Director у Edvantis, ділиться, що Copilot значно пришвидшує написання юніт-тестів, але вимагає ретельної перевірки:

«Із мінусів — потрібна більш уважна перевірка коду.»

Коли справа доходить до більш складних сценаріїв, на кшталт multi-agent workflow або автоматичного створення пайплайнів, то в гру вступають фреймворки.

Проте досвідчені інженери використовують vibe coding по-своєму.

«Copilot використовую для автодоповнення, ChatGPT — замість StackOverflow. Cursor — для роботи з цілим проєктом. Але якщо не подобається результат — видаляю без жалю», — пояснює Роман, Software Engineer.

LangChain, LlamaIndex, AutoGen виступають лідерами для зв’язування декількох викликів LLM в один логічний процес. А ось PromptLayer, Prompt Foo більше зосереджені на DevOps: логують, який промпт породив який результат, дозволяють тестувати й порівнювати різні підходи.

Поки важко говорити про весь арсенал інструментів, адже екосистема vibe coding ще тільки формується, але цікаво, що поки жоден інструмент не домінує і не виділяється настільки, щоб говорити про його лідерство у цій ніші. Всі асистенти рухаються в одному напрямку: формування запиту системі, а система реалізовує цей запит.

Vibe coding на словах і на ділі

Не кожен, хто працює з кодом, бачить у vibe coding готове рішення. Володимир Остапів, Java-розробник в компанії N-iX, розповідає:

«У роботі над комерційними проєктами я не використовую ШІ активно — є нюанси з безпекою та тим, куди можуть потрапити дані. Крім того, vibe coding у чистому вигляді — це коли ШІ змінює файли самостійно, або коли ти копіюєш код без жодної перевірки. Якщо людина переглядає код і вносить правки — це вже не зовсім вайб.»

Володимир використовує ШІ переважно для побічних проєктів: мікроконтролери, дрони, освітній YouTube. Там можна собі дозволити «повайбити», але навіть там він віддає перевагу промптам у окремому вікні, а не інтегрованим помічникам у IDE. Основна вигода, каже він, — зекономити час на тривіальних, повторюваних задачах, які не потребують глибокого мислення: згенерувати DTO, запит до бази, щось ізольоване.

«Підхід до структури коду не змінюється — це все ще я думаю, я ділю на модулі, я пишу тести. Просто деякі шматки делегую.»

Його спостереження підкреслюють межу, яка все ще існує: між автоматизацією і реальним розумінням системи. Навіть найкращі LLM часто «губляться» у малопоширених мовах, можуть некоректно змінити проект або оптимізувати несуттєве, ігноруючи очевидні вузькі місця.

«Якщо потрібно швидко зліпити MVP — це справді економить час. Але якщо планується розвиток і підтримка — навайбкодити вже не вийде. Треба чітко окреслювати зони відповідальності, писати тести, декомпозувати задачі. Без цього вся логіка розвалиться.»

Коли вайбкодинг рятує, а коли шкодить?

Чи можна стверджувати, що Vibe coding — це про швидкість та оптимізацію часу? Безперечно так. Але ця швидкість і простота мають свої обмеження, особливо якщо ви переходите від створення іграшкових апок до справжніх продуктів. AI-асистоване програмування дійсно пришвидшує роботу розробників, але водночас створює більше багів і вимагає додаткового часу на перевірку результату. Це і є основний компроміс: менше писати і більше перевіряти.

Що дійсно працює?

Прототипи за кілька годин. Ідеально для внутрішніх дашбордів, автоматизацій, скриптів — усього, що ніколи не отримало б свій спринт. Пишете ідею, вказуєте промпт, трохи правите — і вже щось працює.

Вхід стає значно ширшим. Йдеться про те, що продуктові менеджери, дизайнери, навіть нетехнічні тімліди створюють базові апки самостійно. Їм не треба знати, що таке middleware. Достатньо чітко пояснити, чого ви хочете досягти.

Менше рутини. Для девелоперів це спосіб позбутись нудного: юніт-тести, генерація API — усе, що пожирає час, але не потребує глибокої логіки.

З чим все не так гладко?

Код виглядає правильним, але це лише вигляд. Моделі генерують щось, що наче працює, але це не гарантує безпеки, читабельності чи продуктивності. Це скоріше передбачення патернів, а не розуміння архітектури.

Дебаг — це боляче. Щось пішло не так і ви застрягаєте в лабіринті виправлень. А якщо ви писали код не самі, то знадобиться час та зусилля, щоб зрозуміти, що саме передбачала модель.

Фальшиве відчуття завершеності. Особливо у нетехнічних людей. Якщо скрипт запустився, то на перший погляд здається, що все абсолютно добре. Але відсутній null check чи дірка в авторизації можуть зламати все в проді.

Відсутність масштабування. Володимир, Java-розробник із N-iX, чітко це сформулював: «Якщо треба MVP або щось одноразове — вайб-кодинг економить час. Але якщо далі підтримувати і розвивати, то треба структурувати, писати тести, окреслювати зони відповідальності. Навайбкодити не вийде.»

Як тільки виникне потреба у підтримці, довготривале володіння кодом і впевненість, що він не впаде на краях системи, то скоріше за все виявиться, що одних лише промптів недостатньо і тоді код треба розглядати як систему, а не як набір фрагментів.

Так чи ні: що думає про vibe coding IT-спільнота?

Не всі погоджуються з популярним трактуванням vibe coding, якщо брати до уваги тільки назву цього поняття. Хтось вважає це природною еволюцією програмування. Хтось — модною фішкою з гарною назвою. Але більшість стоїть десь посередині: обережний оптимізм, але з певними умовами.

Андрій Карпати, який і ввів термін у лютому 2025 року, описав його у твіттері з іронією:

«Є новий тип програмування, який я називаю «vibe coding»: ти повністю віддаєшся вайбу, приймаєш експоненціальність і забуваєш, що код узагалі існує».

Для деяких розробників це не така проста історія лише про вайб і тимчасове «забуття».

«Vibe coding — ох, огидний термін, приблизно як StackOverflow-driven development. ШІ-помічники — це інструмент, каталізатор. Може пришвидшити проєкт, а може й поховати його під шаром власної складності за кілька місяців», —  ділиться Android Developer Анатолій Кокулюк.

Але інші бачать у цьому зсуві щось глибше. Наприклад, для Володимира, директора Design and Test Lab, vibe-coding —  це більше про повернення до задоволення і натхнення, а не лайфхак:

«Для мене вайб-кодинг — це в першу чергу стан, коли код пишеться не заради замовника, зарплатні або дедлайнів, а заради кайфу. Чомусь коли згадують застосування ШІ у програмуванні, то перше питання «чи багато клопоту підчищати за ШІ»? Але я би першим пунктом поставив те, що програмування з ШІ повернуло мені те, що ні за які гроші не купиш — це натхнення у програмуванні, яке в мене було, коли я хлопчиком в школі вивчав програмування на ZX Spectrum, або студентом з другом на канікулах писав компʼютерну гру на Delphi. Чи треба було тоді багато років тому виправляти свої ж помилки, або помилки в документації, «підчищати»? Так!».

Навіть скептики визнають, що ШІ-інструменти мають своє місце. Роман Гелембюк, Software Engineer у Nasuni, каже, що Copilot став частиною його щоденного процесу, але в обмеженому вигляді:

«Я використовую Copilot вже понад півтора року. Зменшує час написання коду десь на 10–15%. Але майже не редагую код, згенерований AI: або зразу добре, або в смітник».

Він додає, що інструменти типу Cursor добре працюють у структурованих проєктах, але сиплються там, де хаос — особливо в мобільних додатках на Kotlin Multiplatform:

«Результати виглядали логічно, але були неробочими. Структура коду була не такою, як я вважаю правильною».

Інші погоджуються, що сліпе копіювання — це шлях у нікуди. Android developer Анатолій Кокулюк застерігає:

«Я починаю розбиратися з кодом, коли мені цікаво — а як це працює? Але якщо взагалі не аналізувати, то здатність до глибокого занурення просто атрофується. Як із водінням — місяць не їздив, і вже не пропустив зустрічне авто».

Інші ж обережно ставиться до ідеї доручати ШІ архітектурні рішення:

«Узагалі не раджу використовувати такі асистенти для проєктування архітектури. Це потребує більше часу на формулювання запитів, а результат усе одно часто не відповідає очікуванням», —  Василь Мухар, Technical Director в Edvantis.

Але й він бачить переваги:

«Ці інструменти відчутно прискорюють роботу. Особливо під час написання unit-тестів. Завдяки економії часу на шаблонному коді з’являється більше можливостей для архітектури».

Володимир Остапів, Java Developer з N-iX, не використовує ШІ в продакшн-коді — здебільшого з міркувань безпеки — але активно експериментує в побічних проєктах. Він вважає ШІ корисним, якщо зберігати контроль:

«Я делегую ШІ окремі частини, але це все ще я пишу код. Підхід до структурування не змінився. На простому пайтоні все ок, а от Lua — краще писати самому. Чим менше прикладів у публічному просторі, тим гірше модель справляється».

Він також звертає увагу на типову поведінку LLM:

«ШІ буде оптимізувати те, що займає 10 мілісекунд, щоб воно займало 5, але пропустить той факт, що підключення займає секунду. Він буде додавати логи для дебагу, але не спробує підійти з іншого боку. Тому тут якраз має вирішувати вже людина».

Серед інженерів точиться й дискусія про авторство. Якщо більшість фічі написана Copilot або GPT — то хто її справжній автор?

«Чи можна вважати себе автором сніданку, якщо приготував його з продуктів, до створення яких не маєш стосунку? Якщо відповідаєш за фічу — значить ти автор».

«Ми — останнє покоління, яке взагалі цей код бачить. Як колись казали: Сі — гарно, але тільки на асемблері пишеться справді ефективний код».

Втім, це не лише філософія. Щодня розробники приймають практичні рішення: як і чи варто інтегрувати ШІ в свій робочий процес. Хтось використовує ChatGPT у сусідній вкладці, хтось покладається на Copilot для швидкості. Але ясно одне — інженери все ще шукають свій підхід.

А ось в чому сходяться майже всі, так це в тому, що vibe coding — це інструмент. Не магія. Не кінець програмування. І точно не заміна інженерам. Однак це вже змінює щоденний досвід написання коду, якщо використовувати його з головою.

Vibe Coding пройшов стадію denial. Що буде далі?

Vibe coding поки не захопив світ розробки ПЗ настільки, щоб всі компанії почали пропонувати девелоперам використовувати цей метод, а девелопери, у свою чергу, перейшли на його постійне використання. Але і інтерес до vibe coding поки не знижується, а це про щось та й говорить. Те, що починалося в певному сенсі як щось поверхове з пропозицією «спіймати вайб» та flow, сьогодні балансує десь між приростом продуктивності та філософською зміною у ставленні до коду. І залежно від того, кого ви спитаєте про це, вам скажуть, що це або давно назрілий етап еволюції, або просто яскравий спосіб автоматизувати шаблонні задачі.

AI-допоміжні процеси як мінімум змінюють підхід до створення й підтримки софту. Рутинні завдання, які раніше забирали години, наприклад, написання unit-тестів, оновлення HTML-шаблонів або створення CRUD API, тепер виконують Copilot, ChatGPT або Cursor. І для команд, на яких тиснуть дедлайни, це цілком непогана альтернатива.

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

Володимир Остапів, Java-розробник з N-iX, порівнює це з молотком:

«Думаю всі дискусії про ШІ відбуваються по причині того, що багато хто не розуміє як ШІ працює. Хтось боїться втратити роботу, хтось шукає магічний спосіб перекласти роботу на плечі машини, але насправді ШІ це просто новий вид молотка. Треба навчитися забивати ним цвяхи, але звісно перед тим треба усвідомити, що таке цвях, щоб не забивати шурупи».

Це поєднання користі та ризику якраз і пояснює, чому багато інженерів обережні з ШІ. Він може стати мультиплікатором ефективності або ж швидким шляхом до технічного боргу.

Володимир Обрізан, директор Design and Test Lab, позитивно ставиться до сценарію, в якому компанії застосовуватимуть vibe coding і пояснює, що було б явно гірше, якби нових інструментів та підходів не зʼявлялося.

«Зрозуміло що є певна інерція: хтось не вірить, що ШІ взагалі може зробити більше ніж «привіт, світ!», хтось знайшов якусь помилку в коді ШІ та перекреслює усі переваги від його впровадження. Хтось взагалі не читає новин, не вчиться новому, та пише код як писав його останні 5 років. Як подолати цю інерцію? Навчатись самому, навчати інших. Як і з будь-якою іншою інновацією. Професія змінюється і це добре. Я би більше хвилювався, якщо би ніяких нових інструментів не зʼявлялося».

Тож, ніхто не відкидає ідею застосування vibe coding як таку. Більшість інженерів просто вибирають моменти, коли це доречно робити. Вони використовують vibe coding там, де це допомагає, і припиняють, коли це не приносить користі. Трюк у тому, щоб правильно розпізнати, коли це працює, а коли ні.

На думку Василя Мухара, технічного директора в Edvantis, все залежить від того, чи розробник розуміє, як працювати з цими інструментами і у здатності компаній навчати ефективній роботі з ШІ-помічниками.

«У кожного свій підхід, але здебільшого це справді про оптимізацію. Компаніям однозначно варто користуватися і vibe coding, оскільки за цим майбутнє. Але потрібно розробити чіткі правила і навчати команди ефективно користуватись такими інструментами. Головне - усвідомлювати, що це лише помічники, а не заміна експертизи».

Більшість розробників не планували ставати майстрами промптів. Вони вивчали мови, фреймворки, патерни, будували системи з нуля. Але якщо подивитися на те, що відбувається зараз, то точка входу змінюється. Там, де колись функціонал починався з коду, зараз він частіше починається з речення.

«Раніше було: постановка задачі → кодування → тестування → рішення. Зараз — постановка задачі → тестування → рішення,» — каже Анатолій Кокулюк, Android developer. «Кодування — як етап — зникає.»

Це не означає, що написання коду зникне зовсім. Але сам процес «написання коду» може трансформуватися і перейти до опису намірів штучному інтелекту, про коригування згенерованого коду, і про управління результатом. Або ні. Ми це побачимо дуже скоро.

В IT-світі працюють ті ж закони та принципи, що і в повсякденному житті — найкращі результати не приходять від людей, які чекають на диво. Вони приходять від тих, хто знає, як контролювати обсяг робіт, аналізувати проблеми і тестувати те, що вони отримали. І, можливо, в цьому і криється справжня зміна. Не те, що ШІ моделі тепер можуть писати код, а vibe coding стає нормальною робочою практикою, а те, що розробники зараз проводять більше часу, визначаючи, що запитати і що перевірити.

Чи буде наступне покоління розробників кураторами «вайбів», а не авторами коду? Це теж поки не ясно. Але, ймовірно, ми дізнаємось відповідь набагато швидше, ніж думаємо. Як сказав один із наших співрозмовників: «Ми — останнє покоління, яке бачить код. Як колись — асемблер. Далі будуть ті, хто просто формулює завдання».

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Shopify vs Prom: ключові відмінності

Shopify — це всесвітньо відома платформа для створення власного інтернет-магазину. Ви отримуєте окремий сайт зі своїм брендом, повний контроль над дизайном і функціоналом.

Shopify працює за підпискою: базовий план коштує близько від $29 на місяць. На ньому можна знайти тисячі додатків для інтеграції постачальників, оплат, маркетингу тощо. Shopify особливо популярна серед дропшиперів, оскільки має зручні інструменти для імпорту товарів (наприклад, додатки Oberlo чи DSers для роботи з AliExpress).

Prom.ua — це український маркетплейс, який поєднує в собі торговий майданчик і конструктор інтернет-магазину. По суті, ви орендуєте магазин на великому порталі.

Prom пропонує готові рішення без навичок програмування: достатньо обрати тариф, додати товари — і ваш магазин з’явиться на Prom.ua. Тарифи стартують від ~299 грн на місяць (є базовий пакет і розширені пакети для більшої кількості товарів).

Prom орієнтований на локальний ринок України: покупці знають цю платформу і довіряють їй, тому почати продавати тут відносно легко. Головна різниця: Shopify дає власний сайт і глобальне охоплення, а Prom — доступ до наявної аудиторії українського маркетплейсу.

Для дропшипінгу ці платформи пропонують різні можливості. На Shopify ви можете продавати по всьому світу, підключати міжнародні доставки та оплати. Наприклад, інтегрувати кур’єрські служби й навіть доставку Nova Poshta для України.

Натомість на Prom усе заточено під Україну: Prom-оплата (вбудований безпечний платіж карткою) і доставка Новою Поштою активуються автоматично, що спрощує логістику на старті. Але й підхід до залучення клієнтів різний: Shopify-магазин потребує зусиль на створення та підключення, а також власного маркетингу (реклама, SEO), тоді як Prom одразу дає вихід на великий трафік покупців усередині маркетплейсу.

Переваги та недоліки Shopify

З переваг найголовнішим є масштаб, а саме весь глобальний ринок. Shopify дає змогу одразу працювати на світовому ринку. Ваш магазин доступний покупцям із будь-якої країни, можна підключати різні валюти та мови.

Якщо маєте амбіції продавати за кордон, власний Shopify-магазин — чудовий старт. Пам’ятаю, як відкрив свій перший Shopify-магазин: мені було всього 19 років і так захопливо бачити перші замовлення від клієнтів з іншого боку світу!

Також важливою перевагою є повний контроль і побудова власного бренду. У Shopify ви створюєте власний бренд — дизайн сайту, логотип, опис — усе під вашим контролем. Ніхто не відволікає покупця на конкурентів, як це буває на маркетплейсах. Це дає можливість побудувати впізнаваність і лояльність клієнтів до вашого магазину, а не до платформи.

Ви можете збирати свою клієнтську базу і працювати з нею напряму (email-розсилки, ремаркетинг тощо). А на допомогу цьому є широкий функціонал і інтеграції!

Shopify має величезний вибір додатків (понад 6000) для будь-яких потреб — від автоматизації дропшипінгу до аналітики. Для дропшиперів є спеціалізовані рішення: інтеграції з AliExpress, з Print-on-Demand сервісами, каталоги товарів з США, Європи і т.д. Налаштувати прийом платежів теж можна під свої потреби — від PayPal для глобальних клієнтів до локальних шлюзів на кшталт Fondy.

Недоліки Shopify:

Вищі витрати на старті. Місячна абонплата Shopify відчутно дорожча за українські платформи. Базовий план ~$29 (близько 1100 грн) на місяць. Причому якщо ваш магазин зросте, можливо, доведеться перейти на дорожчі плани $79 або $299, щоб отримати необхідний функціонал. Також Shopify стягує комісію в розмірі приблизно 2% з обігу, якщо ви використовуєте сторонні платіжні шлюзи. Для початківців це значна сума, особливо порівняно з місцевими рішеннями.

Також найбільшим страхом для всіх — вкладатися в рекламу. Свій сайт не має вбудованого трафіку. Потрібно постійно працювати над SEO, запускати рекламу в Google/Facebook, співпрацювати з блогерами тощо, щоби про ваш магазин дізналися клієнти. Це додаткові витрати часу і грошей. Якщо про маркетинг нічого не знаєш, на початку важко - зізнаюся, свій перший Shopify-дропшипінг я “злив” трохи бюджету, поки вчився налаштовувати ефективну рекламу.
Ми про це говорили як плюс, але тепер і мінус - це сама конкуренція на глобальному рівні. З одного боку, Shopify дає доступ до всього світу, з іншого — ви конкуруєте з усіма іншими міжнародними магазинами. Дропшипінг-модель дуже популярна, тому в багатьох нішах висока конкуренція і потрібно знайти справді унікальний продукт або маркетинговий хід, щоб виділитися.

Іще технічні моменти і підтримка. Хоч Shopify і позиціонується як платформа “без знання коду”, для глибшої кастомізації іноді доводиться залучати розробника. Наприклад, підгонка нестандартного дизайну чи інтеграція з нестандартною системою може вимагати допомоги спеціаліста.

Підтримка Shopify — англомовна 24/7, але не завжди швидко вирішує локальні питання (на кшталт інтеграції з українськими службами). Для українських реалій буває складно під’єднати офіційні Shopify Payments (їх у нас немає), тож доводиться використовувати сторонні шлюзи і платити додаткові комісії.

Переваги та недоліки Prom

Переваги Prom для дропшиперів:

Легкий старт з мінімальними затратами. Почати продавати на Prom значно простіше та дешевше. Є базовий тариф (з помісячною оплатою близько 100 грн), який дозволяє завантажити до 1000 товарів. Фактично, за кількасот гривень на місяць ви вже отримуєте готовий інтернет-магазин на великому майданчику. Це особливо вигідно для новачків, які не хочуть одразу інвестувати багато грошей. Як кажуть підприємці, “дешевий і простий вхід” - одна з причин популярності маркетплейсів. На власному досвіді переконався: створити магазин на Промі можна буквально за день-два, без програміста.

Вбудована аудиторія і довіра. Prom.ua - один з найбільших маркетплейсів України, його щодня відвідують тисячі покупців. Розмістившись на Промі, ви автоматично отримуєте доступ до цього трафіку. Більше того, багато людей довіряють репутації великого гравця - покупці знають, що на Prom діє захист угод і служба підтримки, тому легше наважуються на покупку. Для нового продавця це великий плюс: не треба довго переконувати клієнта, що ваш магазин не шахрайський - бренд Prom.ua вже частково це гарантує.

Простота використання і підтримка. У Prom є зручний кабінет продавця та конструктор сайту. Не потрібно морочитися з хостингом, доменом, двигуном магазину - усе вже готово. Можна вибрати шаблон оформлення, налаштувати категорії й одразу завантажувати товари (вручну або імпортом з файлупо API). Також Prom надає підтримку: навчальні матеріали, відповіді на питання через службу підтримки. Для підприємців-початківців цей супровід важливий, адже на власному сайті ви сам на сам з усіма проблемами.

Локальні інструменти: оплата і доставка. Prom.ua має інтегровані рішення саме під український ринок. Наприклад, Prom-оплата - система безпечної оплати, де гроші перераховуються продавцю тільки після отримання товару покупцем. Це підвищує довіру клієнтів і знімає з продавця частину турбот про платежі. Також на Промі автоматично доступна доставка Новою Поштою (дані для відправлення підтягуються, можна швидко оформити посилку). Для дропшипера, який працює з українськими постачальниками, така інтеграція значно спрощує процес: постачальник може відправити товар від вашого імені, а ви просто передаєте йому дані замовлення з Прому.

Рекламні інструменти всередині платформи. Prom допомагає продавцям просувати товари: є внутрішня система реклами (кампанії), програма “ТОП-продавець”, акції і т.д. Наприклад, можна підключити платну рекламну кампанію, щоб ваші товари показувалися вище в каталозі. Також якщо магазин отримує статус “топ-продавця” (високі рейтинги, мало скасованих замовлень), товари ранжуються краще у пошуку на Prom. Тобто платформа сама стимулює вас покращувати сервіс і “нагороджує” більшим трафіком. Новачку це допомагає швидше отримати продажі без зовнішньої реклами.

Недоліки Prom:

Обмежене масштабування і аудиторія. Prom орієнтований на український ринок. Ваш магазин на Промі, по суті, обслуговує лише покупців з України (рідше - сусідніх країн). Вийти на міжнародний рівень через Prom не вдасться - для цього потрібні інші канали. Якщо ж у планах масштабувати бізнес глобально, рано чи пізно доведеться запускати окремий сайт або працювати через міжнародні маркетплейси. Сам Prom, як платформа, теж має обмеження в розвитку функцій - ви не зможете довільно додати якийсь нестандартний модуль чи інтеграцію, адже функціонал фіксований (тільки те, що пропонує маркетплейс). Це плата за простоту.

Менше контролю над брендом. Продаючи на маркетплейсі, ви граєте за його правилами. Вітрина вашого магазину має стандартний вигляд, можливості брендового оформлення обмежені шаблонами. Покупець часто навіть не запам’ятовує назву вашого магазину - він бачить, що купує на Prom.ua. Розвивати власний бренд важко, а своя клієнтська база майже не напрацьовується (клієнти залишаються в системі Prom, ви не маєте повних контактів для прямого маркетингу). Фактично, багато підприємців на Промі конкурують лише за ціною та відгуками, а не за унікальністю бренду.

Конкуренція поруч. На Prom.ua ви сусідите з тисячами інших продавців у тих самих категоріях. Коли покупець шукає товар, він бачить список пропозицій від різних магазинів. Ваш товар завжди можна порівняти з аналогічним у конкурента буквально в один клік. Це означає боротьбу за ціну, рейтинг і рекламу. Часто доводиться знижувати маржу, щоб переманити клієнта, або витрачатися на просування в межах платформи (платні підняття товарів тощо). Конкуренти можуть демпінгувати, і ви не зможете цьому завадити - увага покупця постійно розпорошена серед десятків інших продавців.

Комісії та додаткові витрати. Хоч вхід на Prom дешевший, реальні витрати “з’їдаються” комісіями з продажів. Prom.ua заробляє на тому, що утримує відсоток з кожного вашого замовлення (як правило, у вигляді плати за рекламну кампанію). Залежно від категорії товару, ця комісія може становити приблизно від 5% до 15% від суми замовлення. Наприклад, у базових налаштуваннях маркетплейс автоматично знімає з балансу продавця ~5-16% за кожне отримане замовлення. До того ж, розширені тарифні плани на Промі потребують передоплати наперед (кілька тисяч гривень на рік). Є відгуки продавців, які зазначають “драконівські” комісії до 15-20% у деяких категоріях і абонплату 5-8 тис. грн/рік за пакет послуг. Тому при великому обороті витрати на Prom теж відчутні. У підсумку маржа дропшипера на Промі може бути невисокою, адже ви не купуєте товар оптом і ще й платите комісію маркетплейсу.

Правила платформи і залежність від неї. Пром має свої правила щодо оформлення товарів, роботи з відгуками, умов доставки та повернень. Треба їх дотримуватися, інакше товар можуть заблокувати або знизити рейтинг магазину. До того ж, будь-які зміни політики Prom автоматично стосуються вас - підняли комісію чи тарифи, змінили алгоритм рейтингу - ви мусите підлаштовуватися. Деякі продавці скаржаться, що нововведення (наприклад, безкоштовна доставка по акції чи обов’язкова Prom-оплата) можуть впливати на їх конкурентоспроможність. Також ви залежите від стабільності самої платформи: якщо будуть технічні збої чи, не дай Боже, закриття сервісу - бізнес опиниться під загрозою. На власному Shopify-сайті таких ризиків менше, бо ви більш автономні.

Що вигідніше у 2025 році і кому яка платформа підходить

Питання “Shopify чи Prom - що краще?” не має універсальної відповіді. Все залежить від ваших цілей, досвіду і ринку, на який ви орієнтуєтесь.
Загалом:

🟢 Prom для початківців та локального ринку. Якщо ви тільки робите перші кроки в e-commerce і хочете протестувати бізнес-модель з мінімальними ризиками - почніть з маркетплейсу на кшталт Prom.ua. Вам буде простіше розібратися з основами, отримати перші замовлення без великих вкладень в рекламу. Prom ідеально підходить, якщо ваш цільовий клієнт - в Україні, а товари доступні від українських постачальників. Наприклад, багато українських підприємців, які втратили офлайн-роботу, під час війни 2022-2023 починали продавати на Prom, бо це швидко давало дохід. Крім того, якщо ви не плануєте брендувати товар чи будувати довгостроковий бренд - маркетплейс виконає роль простого каналу збуту.

🟢 Shopify для масштабування і міжнародного бізнесу. Якщо ж ви амбіційні, маєте трохи досвіду або бажання вчитися - Shopify відкриває набагато ширші горизонти. Ця платформа краща для тих, хто прагне створити повноцінний бізнес із власним обличчям. Ви зможете побудувати бренд, якому довіряють, встановлювати власні правила, збирати базу клієнтів. Shopify особливо вигідна, коли ви виходите на платоспроможні ринки (США, Європа тощо), де середній чек вищий - так ви швидше окупите витрати на рекламу і платформи. В 2025 році світовий e-commerce тільки зростає, і українські дропшипери все активніше працюють на глобальних майданчиках. Я, наприклад, після десятки магазинів на Шопіфай розумію, що дивився не туди, не на той майданичк, але все ж запустив магазин на Shopify під США - і хоч було непросто, але тепер отримую стабільні продажі та вибудовую власний бренд.

Щодо вигідності у 2025: Маржинальність дропшипінгу залежить від багатьох факторів - товарної ніші, умов постачальника, ефективності реклами. На Prom ви витрачаєте менше наперед, але платите комісії з кожного продажу, а конкуренція збиває ціни. На Shopify у вас більше витрат на старті (реклама, підписка), але при вдалому маркетингу ви можете ставити вигіднішу націнку, бо продаєте унікально і не поруч з десятком конкурентів. До того ж, на своєму сайті весь прибуток ваш, крім хіба що невеликих транзакційних зборів. Економія на платформі - не найбільша стаття витрат. Головне - де ви отримаєте більшу віддачу з реклами. Якщо товар масовий і добре “заходить” українській аудиторії, Prom може принести швидкий прибуток. Якщо товар унікальний і цікавий глобально, інвестиції в Shopify-рекламу можуть окупитися в рази більше.

Від себе додам: коли мене запитують, що краще для дропшипінгу, я відповідаю зустрічним запитанням: “А яка твоя мета як підприємця?” Якщо це спробувати сили й підзаробити тут і зараз - йди на Prom або подібний маркетплейс. Якщо це побудувати щось більше, власний бренд - однозначно пробуй Shopify (або українські аналоги для свого сайту).
Сподіваюся, цей аналіз допоміг вам зважити всі за і проти.
Беручи до уваги все викладене, робіть вибір свідомо. Бажаю успіхів у ваших дропшипінг-починаннях, незалежно від того, на якій платформі ви їх здійсните!

Джерела: під час підготовки матеріалу використані публікації та дані з відкритих джерел для підтвердження актуальної інформації.

Shopify - офіційні тарифи та можливості платформи.Prom.ua - умови для продавців, тарифи і комісії на маркетплейсі.

Аналітичні статті про порівняння маркетплейсу і власного магазину.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Суть Open Banking полягає в тому, що ви — як клієнт — отримуєте можливість ділитися своїми фінансовими даними з тими сервісами, яким довіряєте. Це робиться через спеціальні програмні інтерфейси — API. Уявіть, що всі ваші рахунки в різних банках можна зручно об’єднати в одному застосунку. Ви самі вирішуєте, хто може бачити ваші дані і як довго. Це не лише зручно — це новий рівень контролю.

Звичайно, це відкриває багато нових можливостей. Ви можете, наприклад, порівнювати банківські продукти в реальному часі, обирати найвигідніші пропозиції, користуватися послугами фінтех-компаній без зайвої паперової тяганини. Водночас банки, опинившись у більш конкурентному середовищі, прагнуть поліпшити свій сервіс, зменшити комісії та запускати інноваційні продукти. І що важливо — такі зміни стимулюють зростання загальної фінансової грамотності.

Проте, як це часто буває, разом із перевагами приходять і виклики. Open Banking — це про відкритість, а отже, і про новий рівень відповідальності, особливо з боку фінансових установ. Обмін даними має бути не лише зручним, а й безпечним. І тут виникає цілий спектр запитань: як уникнути шахрайства? Як дотримуватися регуляторних вимог? Як не витратити роки на розробку технічної інфраструктури?

На ці виклики вже є відповідь — платформа TESOBE Open Bank Project, яку компанія Integrity Vision впроваджує в Україні. Це комплексне рішення з відкритим кодом, яке дозволяє банкам та іншим фінансовим установам легко адаптуватися до нових вимог і розгорнути повноцінну Open Banking-інфраструктуру за доволі короткий час — у середньому за три-шість місяців.
Ця платформа вже давно довела свою ефективність у країнах Європи, Південної Америки та Близького Сходу. Завдяки співпраці Integrity Vision з компанією TESOBE українські банки отримують доступ до надійного інструменту, який підтримує міжнародні стандарти — такі як PSD2, Berlin Group, UK Open Banking тощо.

Що ж ви отримуєте, якщо працюєте з TESOBE Open Bank Project?

– Насамперед, це понад 550 готових API — усе, що потрібно для запуску обміну фінансовими даними вже з першого дня.

– Це також надійна система автентифікації та отримання згоди користувача, що повністю відповідає регуляторним вимогам.

– Платформа має зручний портал для розробників, аналітику використання API, а ще — вбудованого AI-асистента, який допомагає знайти потрібний API або оптимізувати роботу.

– Ви отримуєте гнучке управління доступом, тестове середовище (sandbox) і всі необхідні інструменти для безпечного масштабування.

Integrity Vision, зі свого боку, бере на себе весь процес: від налаштування та інтеграції до підтримки та навчання. Ви не залишаєтесь наодинці з новою технологією — у вас є команда, яка має реальний досвід впровадження подібних рішень в українських банках.
Тож якщо ви шукаєте спосіб вийти в Open Banking швидко, надійно й із мінімальними ризиками — TESOBE Open Bank Project разом із експертизою Integrity Vision є ідеальним поєднанням.
Готові до нової фінансової реальності? Напишіть нам: marketing@integrity.com.ua — і ми допоможемо вам зробити перший крок до відкритого банкінгу.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Розібратися із цими питаннями допоможе Акім Тонконоженко, QA Lead в ІТ-команді NIX. У статті експерт зібрав базові, практичні поради з написання дієвого bug report.

Що таке баг-репорт

Баг-репорт — це структурований звіт про помилку, баг, у цифровому продукті: мобільному застосунку, онлайн-сервісі, на сайті тощо. Зазвичай цей артефакт готують тестувальники. Для цього вони використовують різні інструменти для звітування про помилки. Та в реальності до процесу може долучитися майже будь-хто: від розробників і проєктних менеджерів до власників продукту та навіть користувачів (наприклад, через форму зворотного зв’язку). Але якісний bug report — це не просто повідомлення про помилку, що щось не працює. Звіт повинен описати місце, де стався збій застосунку, перерахувати умови, показати вплив на роботу продукту та юзерів.

Що вважати багом

Запитання із підзаголовка може здатися дивним. Але насправді це важливий момент в обговоренні, як написати баг-репорт. В різних командах можуть по-різному трактувати, що писати в документі та як вести наявні бази даних помилок. Десь говорять лише про критичні збої. Десь про будь-які відхилення у поведінці продукту від очікуваного результату. А десь — про усі знайдені проблеми. Тому як домовились на проєкті, так і буде відбуватись процес тестування, звітування й відстеження помилок.

Але все одно треба знати теорію й не плутати терміни, які деякі QA-фахівці часто використовують у bug report як синоніми. Ви маєте чітко розрізняти:

• Баг. Це виникнення помилки в коді, через яку щось працює не так, як треба. Відхилення можуть стосуватися функціональності (не реагує кнопка Зберегти), продуктивності (сторінка входу повільно завантажується), інтерфейсу (з’їхала фото на сторінці), безпеки (порушення в авторизації) тощо. Багом можуть бути навіть невірні повідомлення для користувачів і неточності у перекладі меню.
• Дефект. Це більш широке поняття у процесі звітування про помилки. Дефект вказує на будь-які відхилення від вимог чи специфікацій продукту. Тобто з одного боку, цим терміном можна назвати технічну помилку, баг. Але дефект може стосуватися й проблеми реалізації (дизайнери переплутали макет для кнопки) або помилки в описі бізнес-логіки (всі взагалі забули про ту кнопку).
• Іш’ю. Слово issue перекладається як «проблема». Але в контексті bug report воно скоріше означає будь-яку задачу у системах звітності про помилки. Тобто за issue можна вважати запис у Jira або GitLab про якийсь баг. Але також це про майже все інше: нову фічу, поліпшення (імпрувмент), технічний борг тощо. Тобто кожен баг — це іш’ю, але не кожен іш’ю — це баг.
• Прод-баг. У деяких випадках його називають інцидент. Це серйозне порушення роботи у продакшн-середовищі та у юзерів. Тобто це результат виникнення помилки, яку не виявлено на ранніх стадіях у тестовому чи дев-середовищі. Проблема вимагає швидкої реакції та навіть окремої обробки в програмному забезпеченні для звітності про помилки та власного процесу налагодження.

Чому bug report важливий

Звіт про помилку в програмному забезпеченні — це один із ключових способів комунікації тестувальників і розробників. Його часто порівнюють з діагнозом хвороби: якщо він точний і зрозумілий, то швидким і якісним буде лікування. Тобто виправлення помилок. Але це не єдина причина відповідально розібратися, як написати bug report. У нього є інші цілі:

• Фіксація проблеми. Коли все документується у системі відстеження, нічого в процесі тестування не загубиться (на відміну від повідомлень про помилку у тому ж Slack). А тому пошук в наявних базах даних помилок буде простим.
• Визначення серйозності багу. За допомогою звіту про помилку можна показувати й сортувати технічний рівень дефектів. Деякі з проблем можна виправити буквально в кілька кліків, а інші потребують серйозних змін у коді.
• Пріоритизація. Проблем у продукті може бути багато, а ресурсів — обмаль. Якщо не систематизувати відстеження помилок, складно вирішити, з чого починати. Дієві баг-репорти допомагають визначати більш важливі проблеми.
• Економія часу розробників. Добре складений bug report, де є якнайбільше деталей, дозволяє девелоперам одразу зрозуміти проблему. Інакше ці фахівці будуть вимушені звертатись до тестувальників з уточненнями, що призводить до зайвих витрати часу.
• Висока якість програмного забезпечення. Детальний опис знайдених проблем дає змогу з першої спроби виправити баг. Якщо ж буде поганий звіт про помилку, команди розробників можуть опрацювати дефект лише частково.

Структура баг-репорту

Єдиного універсального шаблону ефективного звіту про помилки не існує. Елементи у bug report можуть змінюватися відповідно до проєкту, типу тестів, формату у системі звітності про помилки на кшталт Bugzilla чи GitHub Issues та навіть традицій конкретної QA-команди. Але в будь-якому випадку документ повинен бути структурованим і мати тему, опис помилки, кроки для відтворення, очікуваний і фактичний результат та деяку додаткову інформацію. Про кожен із цих пунктів варто розповісти окремо.

Тема / Summary

Це перше, що бачить розробник. Тож саммері має повідомити про помилку. Але не слід писати у темі баг-репорту лише «Критичний збій застосунку!» чи «Поламка реєстрації». Потрібно коротко, але описово вказати на баг. Для цього можна використати підхід що-де-коли: «Не працює кнопка «Купити» (що сталося) у десктопній версії застосунку (де виникло) після вибори товару (коли проявляється)». Є й альтернатива: де-що-коли.

Опис / Description

В дескрипшені bur report необхідно в кількох реченнях розповісти про суть знайденої проблеми. Наприклад, «Коли користувач на iPhone 15 Pro зберігає в застосунку зміни у своєму профілі, система зависає на понад 20 секунд. Ніяких повідомлень на кшталт «Почекайте, йде синхронізація» немає. Журнали пристрою порожні». Такий опис помилки дозволить розробникам одразу прикинути варіанти виправлення дефекту.

Кроки для відтворення / Steps to Reproduce

В цьому розділі звіту про помилку слід перерахувати всі кроки, які ведуть до проблем. Це можна оформити як список дій, навіть на перший погляд саме собою зрозумілих. Наприклад, «1. Відкриваємо сайт у Chrome на Samsung Galaxy S24. 2. Обираємо будь-який товар. 3. Додаємо до кошика. 4. Не бачимо змін у кошику». Це повідомлення про помилку економить час розробника і гарантує: він повторить ваш шлях.

Очікуваний результат / Expected Result

Початківці доволі часто не приділяють уваги цьому пункту. Адже все ніби є очевидним: кнопка має працювати, реєстрація відбуватись, товар додаватись до кошика, сторінка завантажуватись швидко. Але тестувальники все одно мають прописати у bug report, що відбувається при нормальній роботі. З одного боку, це знімає ризик непорозуміння з розробниками. З іншого, інколи бізнес-логіка може бути дійсно складною, неочевидною.

Фактичний результат / Actual Result

Комусь із новачків може здатися цей розділ таким, що повторює те, що було вказано в інших пунктах. Але фактичний результат важливий в обговоренні правил, як написати дієвий звіт про помилку. Окремий пункт з чіткою фразою на кшталт «Сайт після реєстрації видає сторінку 404, після її оновлення вхід за вказаними кредами не відбувається» дозволяє розробникам звернути увагу на ключовий момент.

Технічні атрибути / Technical Attributes

Це інформація, необхідна для дотримання процесів розробки та QA на проєкті. Передусім серед таких атрибутів є дані про спринт, версію або реліз і середовище: білд, версія, операційна система, пристрій, браузер тощо. Також можуть бути журнали консолі чи серверу, розширення в браузері та навіть вказівки на тип зв’язку (WiFi або стільниковий). Все це значно прискорює процес обробки баг-репорту.

Додаткова інформація / Additional Information

Звіт можна доповнювати ще й іншими корисними даними. Насамперед це візуальні докази: скриншот або відео з відтворенням помилки. Вони дуже сильно спрощують розуміння проблеми для команди розробників. Окрім цього, ви можете додати в bug report майже будь-яку інформацію. Наприклад, чи відтворюється проблема на інших пристроях або чи спостерігались якісь дійсно незвичайні обставини.

Зверніть увагу на це при написанні баг-репорту

• У звіті про помилку має бути один баг. Не об’єднуйте проблеми — це може заплутати розробника. Виключення: кілька однотипних багів або вони пов’язані. Тоді один репорт спростить роботу девелопера та не буде спамити команду.
• Показувати серйозність. В системах звітності про помилки варто давати оцінку Severity, технічної серйозності: Blocker (блок застосунку або головної функції), Critical (серйозний дефект), Major (помилка, яку можна обійти), Minor (малі баги).
• Чіткий опис помилки. Інформація в якісному баг-репорті має бути конкретною і точною. Уявіть, що людина, яка буде знайомитись із цим документом, взагалі не знає продукту. А тому їй має бути зрозумілим все про баг лише з вашого тексту.
• Треба уникати емоційності. Гучні фрази про «все пропало», драматичні порівняння, потрійні знаки оклику — це зайве для bug reports. Ви маєте повідомити про помилку через сухі факти, без стилістичних прикрас.
• Детальна інформація. Ефективний баг-репорт має містити всі дані, які потрібні для розуміння та, що головніше, відтворення помилки. Не можна упускати якісь важливі нюанси. Інакше це заважатиме оперативному виправленню помилок.
• Лаконічність. Ця порада багато в чому пов’язана з попередньою. Початківці, намагаючись надати повну інформацію, інколи йдуть в інший бік — і починають в повідомленні про помилку «лити воду». Це заважає зрозуміти суть проблеми.
• Дотримуватись об’єктивності. У звіті про помилку не місце для припущень — потрібні факти. Тестувальники не можуть використовувати в документах для відстеження помилок слова на кшталт «мабуть» або «мені здається».
• Все перевірити. Деякі проблеми з’являються за умови 100500 факторів. Тому перед збереженням репорту у програмному забезпеченні для звітності про помилки слід переконатися, що баг дійсно відтворюється за вашим сценарієм.

Приклад якісного баг-репорту

Summary:

Не змінюється пароль користувача на Android.

Description:

Коли користувач Android-застосунку змінює свій пароль, система зависає після спроби збереження нових даних. Перезавантаження застосунку не допомагає. Одна й та сама помилка з’являється на різних смартфонах з цією ОС.

Steps to Reproduce:

1. Увійти в застосунок зі старим паролем.
2. Відкрити розділ Профіль.
3. Перейти в пункт меню Редагувати пароль.
4. Ввести старий пароль та двічі новий пароль.
5. Натиснути кнопку Зберегти.

Expected Result:

Пароль оновлюється. Користувачу демонструється повідомлення «Збережено новий пароль». Після 5 секунд юзера автоматично повертає до розділу Профіль.

Actual Result:

Продукт перестає реагувати, в циклі крутиться колесо. Після перезавантаження застосунку бачимо: нові дані не збереглися, доступ відбувається за старим паролем.

Additional Information:

• Пристрій: Xiaomi 14T, Pixel 7 Pro, Samsung Galaxy A55.
• Операційна система: від Android 13 і вище.
• Візуальний доказ: Додано запис відео.
• Журнали пристрою: помилки відсутні.
• Коментар: перевірено також на версії для iPhone 15 з iOS 17 — все працює коректно.

Поганий приклад

Summary:

Не працює кошик!!!

Description:

Це якийсь треш. Я додаю товари в кошик, але все зависає, нічого не оновлюється. Швидко виправте цей збій застосунку, бо ми втрачаємо тисячі клієнтів!

Steps to Reproduce:

1. Обрати товар.
2. Перейти в кошик.
3. Нічого не працює.

Expected Result:

Юзер купує товар.

Actual Result:

Продукт не працює!

Additional Information:

(відсутня).

Цей зразок — приклад того, як писати баг-репорт не треба. В ньому немає нічого, що дійсно має значення для процесу налагодження. Адже що таке звіт про помилку в програмному забезпеченні? Це корисна інформація в усіх деталях. А тут тема без конкретики. Опис сповнений емоційних висловів, але не об’єктивних фактів, як деталі середовища й багу. Відтворити дефект за вказаними у bug report кроками може бути дуже складно або неможливо. Очікуваний результат не про бізнес-логіку. А фактичний результат, візуальні докази та додаткова інформація відсутні. Тому треба справді відповідально заповнювати шаблон звіту про помилку — навіть якщо в центрі уваги буде лише якась незначна проблема інтерфейсу.

Поширені помилки при написанні баг-репорту

• Загальні теми. Початківці нерідко не вказують у саммері, що, де та за яких умов не працює. Це ускладнює сортування звітів у системі відстеження помилок.
• Спрощені кроки для відтворення. Часто новачкам здається: у використанні продукту все зрозуміло. Та розробники можуть не знати конкретного юзер-флоу.
• Емоції замість конкретики. Красиві слова — не для дієвого звіту про помилку. В описі та інших розділах все має бути сухо, з фактами та роз’ясненнями.
• Неочевидні умови. Інколи виникнення помилки спостерігається за особливих обставин — наприклад, коли користувач залогінений. На це треба акцентувати.
• Проблеми з фактичним і очікуваним результатами. Хтось вважає: це повтори. Тому не заповнює ці графи у bug report або виконує це формально.
• Без середовища. Часом помилки є лише на окремих пристроях чи операційних системах і браузерах. Без цих даних девелопер може й не побачити проблеми.
• Відсутність візуальних доказів. Додавання скриншотів, запису екрана, логів та інших артефактів дуже спрощує для розробників розуміння проблеми.
• Без додаткової перевірки. До надсилання баг-репорту слід переконатися, що ви нічого не забули (тут може допомогти чекліст), і перевірити саму помилку.

Знайте міру в деталізації

Бажання надати максимум інформації інколи грає поганий жарт із новачками — і вони витрачають час на другорядні деталі чи довгий збір візуальних доказів. Наприклад, перераховують і додають у bug report скриншоти про кожен крок для відтворення: відкрив браузер, прописав адресу, клацнув Enter для збереження у формі зворотного зв’язку. Або вказують зайві параметри середовища — типу Chrome 136.0.7103.114. Або додають великі файли журналів, де важко відшукати потрібну дрібницю.

Деталізація має бути виправданою. Не слід перетворювати якісний баг-репорт на покрокову хроніку дій. Не треба згадувати базові для будь-якого технічного фахівця моменти. Не варто занурюватися в параметри, які лише відволікають. Пам’ятайте: ви маєте надати ефективний звіт про помилку, аби допомогти командам розробників локалізувати та виправити дефект. Тож у вас має бути баланс між повнотою та стислістю. Тоді й відгук «користувачів» вашого документа буде виключно позитивний.

Як тип тестування впливає на написання баг-репорту?

Загальні структура та формат звіту про помилки є незмінними майже в будь-якому випадку. Тобто елементи та основні підходи до викладення інформації зберігаються, що б ви не перевіряли в цифровому продукті. Але залежно від виду тестів змінюються фокус та дані, які треба додавати в bug reports.

Функціональне тестування

Базові перевірки, чи працює система відповідно до очікуваного результату. В цьому випадку уся увага на юзер-флоу і реакції продукту. Тому в баг-репортах зростає роль послідовності кроків для відтворення помилки. Важливим є посилання на вимоги або цитата з них. Наприклад, що має відбуватись після натискання кнопки. Плюсом буде указівка ролі юзера (незареєстрований, адмін тощо) та окремі залежності в процесах.

Нефункціональне тестування

Ці тести перевіряють не те, що система робить, а як саме робить. Це може стосуватись продуктивності, безпеки, зручності. На перше місце виходять діагностична інформація та метрики: час відгуку і завантаження, ресурси, логи. Розробникам допоможуть і дані про інструменти. Наприклад, який у вас сканер безпеки чи які ваші дії у запуску JMeter. Ще варто у звіт про помилку додати тригер поламки — припустимо, кількість запитів.

Регресійне тестування

Перевірка працездатності після оновлень продукту — тобто чи не поламалось те, що раніше працювало. Треба не просто повідомити про помилку, а ще вказати зв’язки зі старими тестами й номери тест-кейсів. Слід навести і реліз, де така ж перевірка була успішна. Гарний тон у bug report — опис того, що змінилось у новій версії програмного забезпечення. Це допоможе розробникам у пошуках, з чим пов’язана нова помилка.

Тестування бекенду

Таке тестування найбільше відрізняється від традиційного з інтерфейсом. Перевірки йдуть через запити до API. Тому замість «Натиснув таку-то кнопку» і «Не оновлюється сторінка входу» у bug report будуть фрази на кшталт «Використав такий-то метод», «Передав ці параметри» чи «Отримав HTTP-респонс». Також слід вказувати структуру запитів і відповідей (JSON або XML), статуси, надавати журнал помилок.

Автоматизоване тестування

Баг-репорти для тестів, які запускаються автоматично, в чомусь схожі на попередні — тут важлива технічна інформація. Головне — це логи автотесту, фрагмент коду чи скрипт, які впали, та стек трейс самого багу. Ще варто дати посилання на джобу CI/CD (Jenkins, GitLab Pipelines тощо). Але не можна плутати фейл в автотесті з помилкою в продукті! Якщо проблема в самому тесті, для цього заводиться окремий документ.

А як впливає проєкт?

Інколи новачки, які вже вивчили, як написати ефективний баг-репорт, починають на проєкті випадати з робочих процесів. А все тому, що в цій команді існує свій шаблон звіту про помилку. В ньому можуть бути інший порядок елементів, деякі з них об’єднані, а деякі відсутні чи замінені. Це — цілком нормальна ситуація. Адже у вас може бути той самий процес, але — з певними відмінностями.

Особливості продукту

Залежно від галузі та бізнес-процесів конкретного сервісу чи застосунку акценти в роботі QA-команди можуть змінюватися. Це позначається й на підготовці bug report. Наприклад, на сайті для замовлення доставки їжі основна увага йде на відстеження помилок в UI. А в медичному застосунку — на стандартах безпеки. При цьому у звіті можуть з’являтися поля, припустимо, для специфічних ідентифікаторів контрактів.

Інструменти для звітування про помилки

Всі популярні тулзи для написання дієвих баг-репортів мають власні формати, шаблони та навіть назви для розділів — наприклад, Title замість Summary. Також трекер помилок може мати інші поля. Припустимо, в Jira це Pre-Conditions чи RCA, Root Cause Analysis. В GitHub Issues звіт може виглядати взагалі як текст із чеклістом. А в деяких випадках тестувальники все це ще й прив’язують до User Stories та тест-кейсів.

Формальні вимоги

Замовники можуть мати свої побажання щодо формату звітів про помилки. Наприклад, інколи вимагають вказувати у баг-репорті посилання на конкретний розділ специфікації. Або, припустимо, додати у цикл зворотного зв’язку HAR-файл з мережевими логами і відповідною фоновою інформацією. Вимоги можуть стосуватися й іншого — на кшталт визначення і Severity, і Priority тестувальниками (пріоритети традиційно є задачею PM).

Традиції в команді

Зазвичай на проєкті стандарт того, як писати bug report, задає хтось із менеджменту QA-команди — досвідчені техлід або тімлід. Це дозволяє добитися уніфікації, коли всі тестувальники дотримуються єдиного процесу звітування про помилки. Такий підхід економить час і нерви всієї команди. Адже спільні принципи дозволяють не гаяти зусилля на розуміння, що ж саме мав на увазі якийсь окремий QA-фахівець.

Як діяти новачку, якщо bug report має інший формат

Адаптуватися. З одного боку, початківці повинні знати універсальні принципи якісного звіту про помилки. Це основа роботи. З іншого, вивчення нових підходів до того, що таке bug report, може бути дуже корисним. Так новачок побачить, як можна працювати з іншими форматом звітів, полями, стилем подачі детальної інформації, інструментом відстеження помилок. Такі знання розширять професійний кругозір та допоможуть стати інженером з якості, а не простим тестувальником.

Якщо стикаєтесь з незвичним стандартом баг-репорту, не треба пручатися й говорити, що вас навчали іншого. Краще вивчіть локальні вимоги та дотримуйтесь їх деякий час. Лише згодом, якщо вам все одно здається, що можна писати звіт про помилки кращим чином — обговоріть конкретні пропозиції із досвідченими тестувальниками. Можливо, ваші ідеї впровадять у життя. А можливо — вам обґрунтують, чому це не спрацює.

Як переконатися, що ваш баг-репорт дієвий

Формати, шаблони, поля, особливості проєкту, види тестування, системи звітності про помилки чи звички команди — насправді це все деталі. Головне, пам’ятати: ваш bug report має бути зрозумілим. Тому після написання документа спитайте себе:

• Чи може розробник зрозуміти проблему з опису, не звертаючись до тестувальника?
• Чи може будь-хто за цим описом помилки повторити шлях до багу?
• Чи наявні в баг-репорті всі необхідні дані для локалізації знайденого дефекту?

Якщо відповідь ствердна на всі питання, можете сміливо передавати звіт далі — значить, ваш документ дійсно вийшов змістовний та корисний.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

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

Якщо я вам скажу, що SMM не існує*?

*принаймні у його традиційному Social Media Marketing-значенні, а це така широко вживана абревіатура!

З досвіду понад 8 років у публічних комунікаціях спостерігаю, як термін від дуже нішевого у значенні куратор соціальних мереж став загальним на рівні маркетолога як посади.

Чому? Бо так легше, бо всі так кажуть, бо не вдумалися (виберіть свій варіант), а ще бо самі спеціаліст(к)и обирають не навчати ринок, а прогнутися і підписують себе SMM-никами. Достатньо на порталі вакансій ввести цю святу абревіатуру, посадові описи більше схожі на швейцарські ножі.

SMM-ників за посадою можна зустріти у:

• веденні сторінок у соціальних мережах. Принаймні розумію;
• креативному письмі та графічному дизайні. Якщо із залученням ШІ-інструментів, як-от Apple Intelligence і Grammarly, Canva й Edits, то ще може бути;
• відповідях у вхідній скриньці та коментарях. Чекайте, це вже клієнтська підтримка;
• відеопродакшні. За винятком коли це User Generated Content, тобто і часто вдавано трушний вміст, відзнятий і поширений з особистого мобільного пристрою, але ж часто очікують роботи з технікою;
• модеруванні трансляцій. Із аргументом «ну це ж просто [назва платформи] Live», а це вже івентне, зовсім інше.

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

Все й одразу вміти не вийде, звісно, якщо цікавить якість. У власному і професійному житті я досить принциповий і або заглиблююся в щось, або прямо кажу (собі зокрема) — я цього не вмію. Так мислить мало хто, однак навіть із таким підходом потрібно розуміти все, хоча б поверхнево. Це убезпечить від помилок і невиправданих очікувань.

Саме тому як будуючи власні команди, так і консультуючи бізнеси, я завжди ставлю запитання, щойно доходимо до комунікацій: то кого ви шукаєте?

Цифрові комунікації як цілісний напрям

Соцмережного маркетингу не існує, оскільки цифрові комунікації не обмежуються соцмережами (інструмент), а маркетинг (функція) не обмежується цифровим виміром.

Існує ширший, диджитал-маркетинг, адже за чверть ХXI століття цифровий вимір став повсюдним і незамінним, а ще дуже взаємоповʼязаним. Потужності мобільних пристроїв дають можливість робити все на льоту, а просування лише в одному каналі комунікації, за винятком нішевих випадків, є неефективним.

Цифрові комунікації — це комплексне координування, а не просто розміщення публікацій. Це синхронна і послідовна бренд-комунікація у візуалах, тоні й форматах подання інформації.

На практиці основними платформами, крім соціальних мереж, зазвичай є:

• вебсайти — окремі розділи, як-от блогу, новин, стрічок-бігунців;
• Email Marketing — розсилки, дайджести й інші види листування;
• месенджери — спільноти (групи), канали. Не Telegram єдиним!

З кінця 2023 року канали стали доступними на платформах Meta — Facebook (Messenger), Instagram і WhatsApp — із відповідним адаптованим і широким функціоналом.

• медіаплатформи — YouTube та цілий край подкастів. Хоча якщо останні — це точно окрема категорія, то відеохостинги можна вважати частиною соціальних мереж.

Соцмережі — це дуже розтяжне поняття. Для різних аудиторій, регіонів, користувачів і, відповідно, бренд-присутності вони можуть виконувати різні функції.

Соціальні мережі — це дуже широкий спектр на всіх рівнях — від особистих сторінок до каталогів міжнародних брендів.

Так само різниться і просування — від органічних шляхів до платного таргетування. Можна завіруситися в китайському TikTok, а можна вкласти забагато ресурсу в одну платформу і загубитися в Search Engine Optimisation (для видавання в Google, наприклад).

Координувати цифрові комунікації або якщо вужче соцмережі (тоді це називають Social Media Communications) можливо, залежно від стратегії та особливостей бренд-позиціювання, або навіть потрібно. Знову-таки це послідовність іміджу, меседжу, чіткість цілей і запитів.

Водночас виконавчі ролі, якщо це не проєкт на етапі зародження (і те краще закладати), варто розділяти. Краще взяти кількох людей, можливо, на часткове навантаження, і вибудувати ланцюжки роботи, ніж очікувати всього від однієї людини.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

У фінтеху не можна зупинятися: якщо продукт не змінюється — клієнти йдуть. Якщо щось працює повільно — вони йдуть ще швидше. Тут усе вирішує зручність, швидкість і постійний розвиток. Як же знайти баланс між швидкістю запуску нових продуктів (Go-To-Market) з точки зору ІТ, стійкістю системи та вимогами регуляцій?

Високонавантажена фінансова система: що це означає для архітектури?

NovaPay — один із лідерів небанківського фінансового ринку України, що забезпечує платежі, перекази, еквайринг, кредити й інші повсякденні фінансові послуги для мільйонів клієнтів. Щодня наша інфраструктура обробляє майже 3 мільйони транзакцій, що ставить нас на один рівень із найбільшими банками країни.

Ми працюємо в умовах, коли швидкість виходу нового функціоналу є критичною, тому постійно скорочуємо час від ідеї до запуску. Робимо це обережно: будуємо системи так, щоб усе працювало швидко, але головне — стабільно й безпечно. Тож знайшли підхід, який дає змогу запускати нові продукти без шкоди для продуктивності чи безпеки.

Основні принципи ІТ-інфраструктури в NovaPay:

• Гібридна інфраструктура. Ми використовуємо як власні дата-центри, так і хмарні рішення Azure й Google Cloud. Такий підхід дає нам можливість заздалегідь продумувати, як масштабуватиметься система і як вона працюватиме під навантаженням. Наприклад, складні й ресурсомісткі частини ми тримаємо на фізичних серверах, бо їм важлива швидкість обробки транзакцій і надійне обладнання. Бізнес-логіку мобільного застосунку винесли у хмару, щоб гнучко розвивати її й оновлювати.
• Розділення функціоналу на мікросервіси. Кожен мікросервіс відповідає за свою частину роботи застосунку або платіжної системи. Завдяки цьому ми можемо легко масштабувати продукт під навантаження і створювати окремі команди, які повністю зосереджені на розвитку свого напряму. Це про ефективність.
• DevOps культура в розробленні та продуктових командах. Ми беремо фокус на автоматизацію рутинних дій. Це допомагає швидше передавати результати роботи від розробника до людини, яка перевіряє і приймає продукт.
• Фокус на продуктивності. Коли ми проєктуємо технічну архітектуру, в першу чергу думаємо про швидкість і продуктивність. Від цього й залежить вибір рішень. Наприклад, для аналітики використовуємо NoSQL бази даних — вони працюють швидше з великими обсягами даних. Складні, ресурсомісткі операції, як-от створення квитанцій і їх фіскалізація у податковій, ми винесли в окремі модулі й розмістили в хмарі, щоб не навантажувати основну систему.

Як ми швидко впроваджуємо нові продукти

Швидкість виходу нового продукту залежить не лише від технологій, а й від взаємодії команд. У NovaPay ми дотримуємося принципів, які дають можливість мінімізувати Go-To-Market, зберігаючи високу якість сервісів:

• Гнучкі кросфункціональні команди. Ми формуємо кросфункціональні команди по кожному з продуктів. Розробники, аналітики, продукт-менеджери, тестувальники та спеціалісти з безпеки — всі вони працюють спільно над кожним релізом. Це усуває бар’єри між підрозділами та дає можливість всій команді сфокусуватися над продуктом і максимально розуміти його логіку.
• Експерименти й A/B-тестування. Новий функціонал проходить багаторівневе тестування: починаючи з sandbox-середовища і предпродуктивного, далі — закритий запуск для контрольної групи користувачів. Такий підхід дає змогу виявити можливі проблеми на ранніх етапах і вийти на ринок із відшліфованим функціоналом.
• Розвиток за принципом API-first. Коли ми створюємо нові сервіси, то спочатку визначаємо, як вони будуть взаємодіяти між собою. Це допомагає їх швидко запускати, масштабувати та легко підлаштовувати під нові задачі бізнесу. Як один із прикладів такої взаємодії — дані про оплату посилок у відділеннях Нової пошти можна вже відразу використовувати для розрахунку кредитного ліміту.
• Модульність архітектури. Завдяки мікросервісному підходу ми можемо швидко оновлювати окремі компоненти системи без ризику для всієї інфраструктури. Це особливо важливо у фінтесі, де стабільність і безпека не менш критичні, ніж швидкість виходу нового продукту.

Комплаєнс і безпека: як ми забезпечуємо довіру користувачів

Запуск фінансових продуктів потребує не лише швидкості, а й дотримання жорстких стандартів безпеки. В умовах зростання кіберзагроз і посилення регулювання ми використовуємо такі підходи:

• Автоматизований контроль транзакцій. Ми автоматично відстежуємо підозрілі операції в режимі реального часу — за допомогою математичних моделей і ручного моніторингу. Це допомагає швидко реагувати на ризики, запобігати шахрайству та виконувати вимоги у боротьбі з відмиванням коштів (AML).
• Шифрування та багаторівневий захист. Усі дані користувачів зберігаються тільки у шифрованому вигляді, а доступ до всіх інформаційних систем реалізований через багатофакторну автентифікацію.
• Дотримання міжнародних стандартів. NovaPay відповідає вимогам PCI DSS, а плануючи вихід на європейський ринок, орієнтуємося на розбудову інфраструктури з урахуванням норм GDPR. Це гарантує безпечне зберігання, обробку та передавання платіжних даних.
• Безпека передусім. Перед кожним релізом раз на два тижні ми автоматично перевіряємо код застосунку і платіжної системи на вразливості. Крім того, постійно проводимо penetration-тестування всіх систем. Окрім стандартів PCI DSS та ISO, ми розширили цю практику: всередині команди є red-team, яка проводить пентести застосунку і всіх інформаційних систем, імітуючи дії хакерів. Це дає можливість оперативно виявляти та виправляти вразливості, якщо вони з’являються.

NovaPay — це приклад того, як фінтех-компанія може одночасно залишатися гнучкою у впровадженні нових технологій і зберігати високу надійність фінансової інфраструктури. Баланс між Time to Market та архітектурною стабільністю — це постійна робота, яка дає нам змогу масштабуватися, зберігати довіру клієнтів і розвивати фінансові сервіси для мільйонів українців.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

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

Це критично важливо ще й тому, що відсутність залучення працівників коштує компаніям дорого. За підрахунками McKinsey, низьке залучення в роботу серед працівників щороку призводить до $90 мільйонів втрат. Тож на досвіді у SoftServe поділюся, як працювати з фідбеком, мотивувати фахівців залишати його і створювати зміни.

Чому варто збирати фідбек?

Щасливі клієнти — це результат щасливих працівників. Тому ми уважно вивчаємо їхній досвід і шукаємо точки росту. Зворотний зв’язок — це не форма для галочки, це серйозний робочий інструмент. Через нього ми отримуємо розуміння, які теми актуальні, що турбує команди, які зміни справді працюють, а де ще є простір для вдосконалення.

Наш основний інструмент збору фідбеку — це платформа Peakon. Через неї щокварталу протягом двох тижнів проводиться анонімне опитування.

Середній рівень участі стабільно тримається на рівні 75%, це приблизно 6000 працівників. Люди оцінюють різні аспекти роботи (довіра, залученість, менеджмент, рівень стресу тощо) і можуть залишити довільні коментарі від себе про те, що їх турбує чи просто хочеться сказати.

Саме коментарі — це найцінніше. Ми аналізуємо їх як у загальному масштабі (по компанії), так і локально — на рівні проєктів, локацій, функцій. Для менеджерів у нас є доступ до дашбордів із даними саме їхньої команди. Вони бачать, які теми зростають або просідають, читають коментарі. У цьому процесі ми маємо принцип: фідбек має обробляти той, хто реально може вплинути або дати коректну відповідь.

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

Що робити з отриманими інсайтами?

Фідбек має сенс лише тоді, коли з ним щось роблять. У SoftServe ми свідомо будуємо процес прозоро. Наприклад, якщо хтось написав «дякую, все класно» — супер. Але якщо хтось поділився проблемою, важливо також не боятися негативу. Це не критика, це можливість для вдосконалення.

Водночас важливо розуміти, що не всі коментарі свідчать про системну проблему. Частина — емоційні, ще частина — ситуативні. Але якщо одна тема повторюється кілька опитувань підряд, якщо вона звучить у різних локаціях, це вже тренд, із яким треба працювати глибше. Наприклад, у 2024 році серед таких хронічних тем були ментальне здоров’я, бронювання, а також компенсація. Ми не ігнорували жодну з них.

Що допомагає людям бути активними? Відвертість і дії. Результати опитувань ми комунікуємо на всіх працівників всієї локації — країни, де ми присутні. Ми пояснюємо: ваша думка — це не в порожнечу. Це про майбутнє команди, процесів, рішень.

Як комунікувати?

Кожен Peakon ми підсумовуємо кількома способами: на Town Hall, щоквартальній зустрічі у форматі прямого ефіру. Так обговорюють питання стану бізнесу, внутрішніх змін, але мінімум третину виділяють на результати Peakon.

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

У нотатці ми виділяємо основні показники, драйвери й топтеми кварталу. Також комунікуємо нашу позицію щодо кожної з них та кажемо, як плануємо діяти. Ми чуємо фідбек, пояснюємо ситуацію і створюємо зміни. Так, оскільки одними з важливих для фахівців тем протягом 2024 року було ментальне здоров’я і бенефіти, то ми взяли це до уваги.

На початку 2025 року вирішили додати два додаткові дні відпустки на рік для відновлення сил — Self-Care Days. Завдяки зворотному зв’язку з березня також запрацювали оновлені умови для відшкодування відвідувань спортзалів.

І, наприклад, у київському офісі облаштували кілька нових просторів — кімнату для сну, що особливо актуально в умовах частих тривог. Зробили й нові зони для працівників із дітьми: кімнату для годування, переповивання та ігрову зону.

Висновки

Фідбек — це не завжди приємно, але ігнорування фідбеку набагато небезпечніше. Якщо людина поділилася думкою і не почула нічого у відповідь, наступного разу вона просто мовчатиме, а мовчання — це шлях до втрати довіри, залученості й у результаті — цінних людей.

Тому важливо реагувати. Навіть якщо не маємо швидкої відповіді, ми принаймні визнаємо запит і пояснюємо ситуацію. Це не про досконалість, а про повагу, бо коли всередині є простір для чесності — з’являється простір для змін.

Олена Лебедєва, People Lead Ukraine, SoftServe

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Автоматизація — не чарівна паличка

Річ у тім, що сучасні технології, якими б потужними вони не були, не можуть миттєво розв’язати всі проблеми компанії. Автоматизація має бути заснована на розумінні суті процесів, які вона покликана покращити. Саме процеси визначають ефективність роботи компанії, а автоматизація — це лише інструмент для їхньої оптимізації.

Наскрізні бізнес-процеси — ключ до успіху

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

Саме такі наскрізні процеси є найкращими кандидатами для автоматизації, навіть якщо не всі їхні етапи можна автоматизувати повністю. Головне — забезпечити ефективне управління всіма частинами процесу.

Чому важливо управляти процесами?

Грамотне управління бізнес-процесами дає можливість:

• Прискорити досягнення цілей (дохід компанії в тому числі).
• Забезпечити прозорість: хто, де, коли та як виконує завдання.
• Підвищити ефективність і знизити ризики.

Чому ми рекомендуємо саме Business Process Management (BPM)?

Тому що ця методологія дає можливість швидко адаптуватися до змін; виявляти й усувати вузькі місця; контролювати відповідність регуляторним вимогам і нормам; автоматизувати рутинні процеси, підвищуючи мотивацію співробітників, і покращити клієнтоорієнтованість.

То з чого ж варто починати?

Щоб ефективно керувати бізнес-процесами, їх необхідно спершу ідентифікувати; описати та каталогізувати (наприклад, за допомогою IDEF0, BPMN, EPC); провести аналіз для подальшої оптимізації та автоматизації.

Маючи вже описані процеси нашої компанії, ми можемо перейти до їхньої автоматизації.

Автоматизація: що це і як її правильно впроваджувати?

Автоматизація — це виконання завдань за допомогою технологічних систем із мінімальним втручанням людини або взагалі без людей. Вона дає можливість:

• прискорити виконання процесів;
• мінімізувати помилки;
• отримати повний контроль над виконанням процесів у режимі реального часу.

Автоматизація може охоплювати роботу окремих співробітників, департаментів або ж усю компанію. Важливо розуміти, що автоматизація ERP, CRM, HRM систем — це лише частина загального процесу, і вона не завжди розв’язує всі проблеми.

Як уникнути помилок при автоматизації?

Щоб автоматизація була ефективною, важливо проаналізувати всі процеси та визначити ключові для бізнесу; пріоритезувати процеси для автоматизації; обрати інструменти (наприклад, Camunda для складних бізнес-процесів); співпрацювати з експертами для впровадження.

Підхід Camunda: оркестрація та автоматизація

Підхід Camunda базується на поєднанні автоматизації окремих завдань та оркестрації всього процесу, що дозволяє забезпечити управління на рівні всієї компанії.

Є такі підходи до автоматизації:

• Почати з автоматизації окремих завдань, поступово додаючи оркестрацію.
• Відразу автоматизувати наскрізний процес, оркеструючи всі пов’язані завдання.

Незалежно від обраного підходу, головне — забезпечити баланс між автоматизацією завдань та управлінням процесами.

Отже, автоматизація — це не просто про впровадження технологій, а про грамотне управління бізнес-процесами. Якщо підходити до цього питання комплексно, автоматизація стане не джерелом розчарування, а ключовим фактором підвищення ефективності й конкурентоспроможності вашого бізнесу.

Чому варто обрати Integrity Vision?

Integrity Vision — це команда професіоналів із багаторічним досвідом у сфері автоматизації бізнес-процесів. Ми не просто впроваджуємо технології, а допомагаємо нашим клієнтам оптимізувати процеси, щоб вони працювали ефективніше.

Використовуючи передові рішення, такі як Camunda, ми створюємо надійні, масштабовані та безпечні системи, які відповідають потребам бізнесу. Обираючи Integrity Vision, ви отримуєте не лише інноваційні технології, а й стратегічного партнера для вашого успіху.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Сучасному ШІ знадобляться тисячі годин тренувальних даних для кожного конкретного автомобіля та умов. Натомість загальний штучний інтелект (AGI) зможе зрозуміти фундаментальні принципи водіння і застосовувати їх у широкому спектрі ситуацій.

AGI ставить за мету створення систем ШІ, які здатні справді узагальнювати знання та навички — засвоювати основні принципи, які можна застосовувати в абсолютно нових ситуаціях. Наприклад, керування автомобілем, гра в шахи, го чи Minecraft. Це помітно відрізняється від сьогоденних систем ШІ, включаючи великі мовні моделі (LLM), які здебільшого працюють через складне розпізнавання шаблонів у величезних тренувальних наборах даних.

Хоча сучасні великі мовні моделі (LLM) можуть вести, на перший погляд, інтелектуальні розмови та розв’язувати складні завдання, вони по суті працюють шляхом розпізнавання та комбінування шаблонів, які зустрічалися їм під час навчального процесу. Це швидше нагадує надзвичайно поглиблене запам’ятовування і статистичну кореляцію, ніж справжнє розуміння та узагальнення, оскільки таким чином вони не створюють справжніх причинно-наслідкових моделей чи абстрактних уявлень про світ. Коли здається, що вони здатні до узагальнення, насправді вони зазвичай просто знаходять тонкі статистичні закономірності у своїх тренувальних даних, а не розуміють глибші принципи.

Чому ARC (Abstraction and Reasoning Corpus) є важливим?

ARC вирішує критичну проблему вимірювання в дослідженнях ШІ — як ми можемо перевірити, чи здатна система ШІ до узагальнення?

Традиційні бенчмарки зазвичай вимірюють продуктивність виконання конкретних завдань із використанням великих тренувальних наборів даних, але високі результати в таких тестах не обов’язково свідчать про справжню здатність до узагальнення. ШІ може демонструвати гарні результати, просто запам’ятовуючи шаблони з тренувальних даних, а не розвиваючи справжнє розуміння.

Як пише Ф. Шолле: «Наскільки нам відомо, ARC неможливо виконати будь-якою наявною технікою машинного навчання, включно з deep learning».

Основні труднощі такі:

• Очікуваний результат — це не мітка чи набір міток, а кольорова сітка розміром до 30×30 клітинок із використанням до 10 різних кольорів. Таким чином, це завдання належить до області структурованого прогнозування.
• Прогнозований результат має повністю відповідати очікуваному. Якщо хоча б одна клітинка не збігається, завдання вважається проваленим. Через це на кожну вхідну сітку (input grid) дається три спроби.
• У кожному завданні зазвичай є від двох до чотирьох навчальних прикладів (вхідна сітка (input grid) + вихідна сітка (output grid) і один або два тестові приклади, для яких потрібно зробити прогноз.
• Кожне завдання ґрунтується на унікальному перетворенні вхідної сітки у вихідну. Зокрема, неможливо виконати жодне з тестових завдань шляхом повторного використання перетворення, вивченого на навчальних завданнях. Насправді кожне завдання є окремою проблемою навчання, а ARC оцінює саме здатність до широкого узагальнення та навчання на кількох прикладах (few-shot learning).

ARC пропонує більш суворий тест на узагальнення, подаючи кожну задачу лише з 3–5 прикладами (тільки few-shot). Такий мінімальний обсяг тренувальних даних означає, що ШІ не може покладатися на масштабне зіставлення шаблонів (pattern matching). Він має виділяти основні принципи та застосовувати їх у нових ситуаціях, як це роблять люди. Задачі також навмисно розроблені так, щоб уникнути спрощених рішень або стратегій запам’ятовування.

ARC особливо цінний тим, що дає можливість кількісно оцінити здатність до узагальнення. Замість дискусій про те, чи ШІ розуміє у філософському сенсі цього слова, можна виміряти його реальні результати з допомогою цих ретельно розроблених завданнях на мислення. Це надає дослідникам чіткий показник прогресу загального штучного інтелекту.

Якщо ви хочете дізнатися більше про бенчмарк ARC і його роль у розвитку ШІ, ось відео, з якого варто почати:

Методи вирішення ARC

1. Brute force

У 2020 році змагання Kaggle продемонструвало один із перших методів розв’язання ARC — повний перебір у просторі попередньо визначених перетворень. Переможці створили предметно-орієнтовану мову програмування (DSL), яка охоплювала 142 операції з сітками, розроблені вручну. Систематичний пошук комбінацій цих операцій забезпечив точність у 20% на закритих тестових завданнях. Інше подібне рішення, яке використовувало граматичну еволюцію (grammatical evolution) для пошуку перетворень, досягло точності 3–7,68%.

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

2. Принцип мінімальної довжини опису (MDL)

Поточний підхід ґрунтується на фундаментальному принципі, який використовується для виявлення шаблонів і створення моделей, що найбільш стисло та ефективно пояснюють дані. Основна ідея MDL полягає в тому, що найкраща модель для будь-яких даних — це та, яка дає можливість максимально їх стиснути.

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

На найвищому рівні кожна задача представлена у вигляді пари та містить дві сітки:

• Вхідна сітка (in).
• Вихідна сітка (out).

Кожна сітка визначається трьома компонентами:

1. Вектором розміру (визначає висоту та ширину).
2. Фоновим кольором.
3. Списком шарів, що містять об’єкти.

Об'єкти є розміщеними фігурами, причому кожна з них може бути:

• Крапкою одного кольору.
• Прямокутником із заданим розміром, кольором і маскою.

Система маскування є особливо ефективною, оскільки вона дає можливість прямокутникам набувати різних форм:

• Повноцінний (суцільний прямокутник).
• Контур (лише обрис).
• Шаховий візерунок (парні або непарні клітинки).
• Перехресні візерунки (знаки плюса або множення).
• Нестандартні bitmap візерунки.

Ця мова дає можливість системі стисло описувати складні шаблони сіток. Наприклад, замість того, щоб зберігати сітку 10x10 піксель за пікселем (100 значень), її можна зберегти як чорний фон із червоним прямокутником 3x3 з розташуванням (2,2), використовуючи значно менше значень, але зберігаючи основну структуру.

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

Цей підхід показав хороший результат (розв’язання 94 із 400 завдань), що свідчить про те, що ця мова вловлює багато шаблонів ARC задач, але залишається достатньо обмеженою та уникає перенавчання конкретних прикладів.

3. Прогнозування безпосередніх результатів базових LLM

Хоча великі мовні моделі (LLM) продемонстрували дивовижні можливості в різних галузях, їхнє пряме використання для вирішення ARC має як переваги, так і певні складнощі. Прямолінійний підхід полягає в тому, щоб надати LLM приклади вхідних і вихідних даних і попросити його передбачити відповідь для нових вхідних даних. Однак у цього методу є суттєві обмеження. Моделі LLM демонструють дуже обмежені можливості просторового мислення в цьому контексті та намагаючись передбачити перетворення сіток, є схильними до галюцинацій.

4. Chain-of-Thought (CoT) and Thinking LLMs

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

Агенти ШІ та їхня роль в AGI

У WLTech.AI ми розуміємо важливість агентів штучного інтелекту у досягненні AGI. Ці агенти розроблені для динамічної взаємодії з оточенням, адаптації на основі отриманих знань і самостійного навчання. На відміну від статичних моделей, які здатні тренуватися лише один раз, агенти ШІ можуть навчатися через безперервну взаємодію та адаптуватися до змін, що робить їх незамінними в розвитку AGI.

Агенти ШІ виконують роль мозку операції, координуючи різноманітні техніки, що адаптуються до вимог конкретного завдання. Символьні системи чудово підходять для точного, правило-орієнтованого мислення, що робить їх ідеальними для завдань, які вимагають розуміння перетворень, таких як обертання чи відображення. Нейронні мережі відмінно розпізнають шаблони та можуть узагальнювати дані, а це надзвичайно корисно для виявлення основних структур у завданнях ARC.

Однак труднощі ARC не обмежуються лише символьними маніпуляціями або розпізнаванням шаблонів. Для вирішення багатьох завдань потрібен глибший рівень абстракції, включно зі здатністю створювати нові правила, знаходити зв’язки й адаптуватися до нових ситуацій. Тут на допомогу приходять мовні моделі, оскільки їх можна використовувати для таких завдань, як синтез програм та абстрактне мислення.

Алгоритми пошуку — це ще один інструмент у наборі, оскільки вони можуть ефективно досліджувати можливі перетворення для знаходження рішень. З іншого боку, системи планування надають структуру, яка дає можливість розбивати складні задачі на частини та вирішувати їх крок за кроком.

Здатність агентів ШІ об’єднувати всі ці різні підходи робить їх надзвичайно розумними. Вони не використовують лише один метод за раз. Натомість вони оцінюють і застосовують найкращу комбінацію технік для розв’язання унікальної проблеми. Здатність до моментальної адаптації є тим, що вирізняє людей, і водночас є важливим кроком на шляху до розвитку AGI.

Агенти ШІ — це по суті інтелектуальні координатори. Вони фіксують, які підходи працюють, а які ні, щоб навчатися на основі минулого досвіду.

Наше рішення Agentic AI

Наше рішення можна знайти за посиланням чи на Github.

Наш прорив став можливим завдяки наслідуванню людської поведінки під час розв’язання задач: аналіз прикладів, висування гіпотез щодо правил, тестування та удосконалення. Замість використання brute force наш ШІ зосереджується на написанні функцій генерації — Python-коду, який визначає перетворення, та негайному тестуванні їх на тренувальних даних.

Основні етапи:

1. Аналіз шаблонів: ШІ виявляє взаємозв’язки у парах вхідних і вихідних даних.
2. Генерація функції: На основі спостережених шаблонів ШІ пише функцію transform(input): output.
3. Негайне тестування: Функція тестується на тренувальних даних. Якщо вихідні результати повністю збігаються, рішення вважається правильним і застосовується до тестових даних.
4. Ітерація: Якщо тестування не вдається, функція вдосконалюється та повторно тестується.

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

Нові ідеї замість удосконалення

Замість того, щоб вдосконалювати помилкові припущення, ми зрозуміли, що ефективніше:

1. Повністю відмовитися від хибного підходу.
2. Сформувати нову гіпотезу з нуля, опираючись на свіжі спостереження із тренувальних даних.

Це нагадує людську поведінку, коли у випадку непродуктивного рішення, люди схильні перезавантажувати та переосмислювати процес, а не намагатися виправити невдалу стратегію.

Чому генетичні алгоритми не спрацювали

Це усвідомлення також пояснює, чому генетичні алгоритми не змогли покращити результати. За своєю природою генетичні алгоритми поступово еволюціонують рішення, вдосконалюючи їх із кожним поколінням. Однак, якщо фундаментальні припущення є хибними, поступові зміни лише ускладнює розв’язання задачі та ще більше віддаляє від правильного перетворення.

Оцінювання фундаментальних LLM: Claude 3.5 Sonnet — лідер

Для вирішення проблеми ARC ми провели масштабне тестування кількох великих мовних моделей (LLMs), щоб використати їх для розроблення функцій генерації. Серед усіх моделей Claude 3.5 Sonnet показав найкращі результати, значно перевершивши своїх конкурентів.

Claude 3.5 Sonnet проти GPT-4o:

• Продуктивність: Claude 3.5 Sonnet розпізнав більше шаблонів, ніж GPT-4o, досягнувши більше ніж удвічі вищої точності у розпізнаванні шаблонів.
• Ефективність: Claude досяг таких самих результатів, що й GPT-4o від OpenAI, проте за 1/7 часу, що робить його не тільки ефективнішим, але й швидшим.

Падіння продуктивності GPT-4o:

• Ми зафіксували помітне падіння продуктивності GPT-4o через деякий час. Початкова версія GPT-4o значно краще виконувала завдання ARC порівняно з наступними версіями, що свідчить про можливі зміни в його оптимізації, які негативно вплинули на здатність розпізнавання шаблонів та міркування для цієї задачі.

Чому Claude 3.5 Sonnet виділяється серед інших

Перевага Claude полягає в його здатності узагальнювати та розпізнавати ледь помітні перетворення, що є ключовим для роботи з few-shot задачами ARC. Стабільна продуктивність та ефективність зробили його ідеальним кандидатом для інтеграції в основу нашого AI-агента, створюючи новий стандарт LLM мислення у структурованому розв’язанні задач.

Результати

Наш підхід забезпечив майже 30% точності на тестовому наборі ARC, що значно перевищує результати базових методів. Це досягнення підкреслює ефективність підходу, який імітує людське мислення, використання нових гіпотез замість ітеративних покращень і залучення найбільш здібних мовних моделей як Claude 3.5 Sonnet. Хоча ще залишається значний простір для вдосконалення, це досягнення демонструє важливий прогрес у вирішенні викликів ARC і розвитку у напрямку широкого узагальнення у ШІ.

Майбутні напрями розвитку ARC

У WLTech.AI ми переконані, що майбутнє розв’язання задач ARC полягає у подальшому розвитку можливостей LLM у поєднанні з високорівневими структурами міркування, такими як принцип мінімальної довжини опису (MDL) або подібними підходами для стислого пояснення шаблонів.  Ці вдосконалення можуть дозволити моделям краще абстрагувати й узагальнювати перетворювання.

Крім того, інтеграція системи самовдосконалюваних запитів на основі зростаючої бази рішень дала б змогу моделям поступово покращувати свої міркування та використовувати попередні успіхи, створюючи більш адаптивний та ефективний механізм розв’язання задач. Синергія між передовими LLM, структурованими поясненнями й адаптивним навчанням може стати ключем до нових досягнень у розвитку ARC і AGI.

Видатні люди, які розв’язали ARC

ARC (Abstraction and Reasoning Corpus) бенчмарк став ключовим методом оцінки того, наскільки добре ШІ може застосовувати загальні правила та мислити більш абстрактно. З плином років з’явилося кілька видатних рішень, кожне з яких зробило свій внесок у цю сферу.

Підхід Раяна Грінблатта

У 2024 році Раян Грінблатт, інженер із Redwood Research, досяг значного успіху, набравши 42% на відкритому тестовому наборі ARC-AGI та 43% за верифікаційним показником. У своїй методиці він застосував GPT-4o для створення та оптимізації кількох Python-програм, обравши найкращі з них для заявки на конкурс. Це демонструє, як саме ми можемо використовувати великі мовні моделі для синтезу програм, щоб розв’язувати складні задачі на мислення.

Icecuber 2020

Рішення «Icecuber 2020», яке стало переможцем попереднього конкурсу, отримало 39% на відкритому тестовому наборі та 17% за верифікаційним показником. Хоча методологія цього підходу повністю невідома, він відіграв важливу роль у встановленні вищих стандартів для майбутніх учасників ARC.

Таблиця лідерів ARC Prize 2024

До найкращих учасників у таблиці лідерів ARC Prize 2024 належать:

• MindsAI очолюють список із результатом 55,5%.
• The ARChitects зайняли друге місце з результатом 53,5%.
• Гільєрмо Барбадільо на третьому місці з результатом 40%.
• Alijs на четвертому місці також із результатом 40%.
• TuMinhDang на п’ятому місці з результатом 38%.

Ці результати демонструють, як активно учасники працюють і впроваджують нові підходи для розв’язання завдань ARC. Вони також свідчать про різноманітність стратегій, які використовують команди.

Як ARC надихає дослідників ШІ

ARC бенчмарк залишається чудовим інструментом для перевірки здатності систем ШІ до мислення та узагальнення. Попри значний прогрес у цій сфері, жодна модель поки що не змогла повністю впоратися із завданнями ARC, що підкреслює наскільки складно досягти загального штучного інтелекту (AGI). Дослідники та фахівці продовжують шукати способи поєднання різних підходів, використовуючи символічне мислення та нейронні мережі, щоб наблизитися до розв’язання задач.

Такі бенчмарки, як ARC, дають можливість зазирнути в майбутнє досліджень ШІ. Вони спрямовують розвиток галузі у бік систем, здатних мислити й адаптуватися як люди. Хоча прогрес у цій сфері рухається повільно, ARC уже окреслив чіткий шлях до досягнення AGI.

Фокус зміщується в бік узагальнення

У майбутньому системи ШІ проєктуватимуться для узагальнення, а не для спеціалізації. Як показують завдання ARC, здатність розв’язувати нові проблеми без необхідності повторного навчання є ключовою ознакою справжнього інтелекту. Ймовірно, дослідники створять моделі, які будуть чудово справлятися з навчанням на кількох прикладах (few-shot) та без прикладів (zero-shot), опираючись на принципи роботи нашого мозку.

Гібридні моделі стануть нормою

Успіх рішень ARC вже показав, що системи, побудовані на одному підході, є дещо обмеженими. У майбутньому ШІ розвиватиметься через гібридні моделі, що інтегрують нейронні мережі, символічні системи та ймовірнісну логіку. Такі моделі не лише успішно вирішуватимуть завдання ARC, а й зможуть впоратися з реальними проблемами, де ключовими є гнучкість і адаптивність.

Когнітивна архітектура набуває все більшого значення

ARC спонукає задуматися над когнітивними архітектурами, що імітують здатність людського мозку поєднувати різні способи мислення. Ми побачимо більше досліджень у сферах робочої пам’яті, метанавчання та багатоагентних систем, що прокладуть шлях до створення ШІ, який зможе мислити, навчатися та адаптуватися на ходу.

Коли ШІ стане розумнішим, він не тільки виконуватиме нашу роботу, а й працюватиме разом із нами. Такі бенчмарки, як ARC, сприяють розробленню ШІ-систем, які будуть допомагати людям, пропонуючи нові ідеї та рішення у складних сферах, таких як наукові відкриття та творчі підходи до розв’язання проблем.

Такі змагання дійсно стали джерелом натхнення для спільноти дослідників ШІ. З грошовим призом у понад $1 мільйон ARC Prize є чудовим стимулом для розробників створювати open-source рішення, які зможуть перевершити поточні стандарти.

У WLTech.AI ми розуміємо, що цінність таких рішень значно перевищує $1 мільйон, і ми будемо раді знову взяти участь у цьому змаганні наступного року, щоб продовжити розвивати галузь.

UPD 2025

OpenAI заявляє, що досягла 88% точності на ARC-AGI, використовуючи спеціально налаштовану модель o3-high. Це значно перевищує попередні результати й наближає модель до вирішення тесту, що довгий час залишався непідкореним.

Команда OpenAI стверджує, що ключовими факторами прориву стали збільшена глибина міркувань і нові підходи до навчання, які дозволили моделі краще узагальнювати патерни. Однак навіть при 88% точності ARC-AGI залишається викликом, що продовжує випробовувати межі штучного інтелекту.

Цей прорив підкреслює важливість нових архітектурних рішень у розвитку AI. Просте збільшення масштабів попередніх моделей, таких як GPT-4, не призвело б до таких результатів. Подальший прогрес залежить від впровадження нових ідей і підходів у навчанні моделей.

Таким чином, хоча досягнення OpenAI є значним кроком уперед, ARC-AGI продовжує залишатися важливим еталоном для оцінювання здатності AI до адаптації до нових, невідомих завдань, що наближає нас до розуміння і створення справжнього AGI.

Про компанію

WLTech.AI, заснована у 2013 році Олександром Книгою, займається створенням спеціалізованих ШІ команд і рішень повного циклу. Наш підхід корпоративного рівня охоплює хмарну інфраструктуру, комплексну frontend-розробку, масштабовані архітектури та стратегії розгортання продукту.

Наша експертиза включає великі мовні моделі (LLM), розробку моделей ШІ, інженерія даних, машинне навчання (ML), обробку природної мови (NLP), автоматизацію ШІ, агентів ШІ. Від початкового збору даних і тренування моделей до розгортання продукту та безперервної оптимізації ми реалізуємо повноцінні, готові до роботи рішення, що відповідають суворим корпоративним стандартам і забезпечують суттєві зміни у бізнесі.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

У цій статті IT-юрист Дмитро Кондратьєв розповідає про власний досвід підготовки документів для безперешкодного виїзду клієнта за кордон. Процес збору необхідної інформації, оформлення довідок, перевірки всіх даних та підготовки пакета документів тривав тиждень. Протягом цього часу довелося отримувати документи від роботодавця, запрошення від приймаючої сторони, збирати податкові документи та документи про бронювання. Деталі — нижче.

Хто в компанії із військовозобов’язаних чоловіків може виїхати у відрядження?

Чоловіки, які заброньовані на підприємстві, яке визнане критично важливим для економіки. При цьому інформація про бронювання має бути внесена до системи «Оберіг». Тобто просто працювати на підприємстві недостатньо — потрібне офіційне підтвердження бронювання.

Які документи потрібні?

Щоб успішно перетнути кордон у службовій поїздці, потрібно мати три основні групи документів.

Перші група складається з документів для перетину кордону. До них відносяться закордонний паспорт громадянина України та військово-обліковий документ із підтвердженням бронювання, внесеного до системи «Оберіг».

Друга група передбачає документи, що стосуються бронювання, а саме: наказ про визнання підприємства критично важливим, документ, який підтверджує бронювання, а також витяг із порталу «Дія» щодо внесення до списку заброньованих осіб.

До документів, необхідних для службового відрядження, належать: наказ про відрядження з детальним описом мети поїздки, строків і місця перебування, довідка з місця роботи, лист від керівництва компанії з підтвердженням згоди на виїзд, а також (за наявності) запрошення від приймаючої сторони, квитки в обидва боки й підтвердження бронювання житла.

Якщо у вас не буде всіх необхідних документів, це може викликати додаткові питання з боку прикордонників. У такому випадку вам доведеться надавати додаткові пояснення щодо мети поїздки, джерел фінансування, тривалості перебування та інших важливих деталей. Це може затримати процес перетину кордону або у деяких випадках стати причиною відмови у виїзді.

Ось приклад як виглядає лист від керівництва компанії із підтвердженням, що роботодавець не заперечує проти виїзду.

Ось приклад запрошення від приймаючої сторони з Казахстану.

Що варто врахувати перед поїздкою?

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

Крім того, варто пам’ятати, що всі документи потрібно подавати в оригіналах — жодні копії не підійдуть. Будь-які помилки або неточності можуть стати причиною відмови у перетині кордону, тому варто кілька разів перевірити їхню відповідність вимогам. Не забувайте, що прикордонники наділені правом відмовити вам у перетині кордону або запросити інші докази. Наприклад, показати надходження заробітної плати або отримання коштів на відрядження, довідки з податкової про нарахування доходу і сплату податків, бронювання готелів чи квитків, а також інші документи, що підтверджують мету та забезпечення поїздки.

Важливі нюанси з практики

З мого досвіду закордонних відряджень — будьте готові до додаткових питань на кордоні. Якщо це ваша перша поїздка за кордон під час воєнного стану, прикордонники можуть запитати додаткові документи та інформацію. Варто бути готовим до тривалішої співбесіди з перевіркою надходжень заробітної плати та виплат у звʼязку із відрядженням, документів про компанію та необхідність відрядження.

Наступні виїзди зазвичай проходять простіше. Наприклад, якщо конференція триває 3 дні, а ваша поїздка — 7 днів, будьте готові пояснити інспектору, чим ви займатиметеся в решту часу. Якщо ви їдете машиною, впевніться, що ви прочитали вимоги до перетину кордону машиною.

Як мінімізувати ризики на кордоні?

• заздалегідь підготуйте всі документи, особливо ті що стосуються бронювання, яке має бути зареєстроване у системі «Оберіг»;
• переконайтеся, що інформація в документах збігається — невідповідності можуть викликати підозру у прикордонників;
• завчасно бронюйте квитки та житло — це додатковий доказ серйозності поїздки, в наших кейсах у хлопців це питали.

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

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Який вплив ця ідея має на менеджерів у довгостроковій перспективі? Детальніше розповіла Олеся Ульянова, Ph.D, MBA, СЕО Telesens, Founder ITGC, Еx-менторка USAID.

Позитивні аспекти hustle для менеджерів

Hustle, попри свою суперечливу репутацію, може мати низку позитивних аспектів для менеджерів. Тож завдяки чому hustle-культура таки може стати потужним інструментом для підвищення ефективності, мотивації й лідерських якостей менеджерів?

Збільшення результативності

Hustle-культура спонукає менеджерів до максимальної віддачі у своїй роботі. Вони стають більш дисциплінованими, цілеспрямованими та зосередженими на досягненні цілей компанії.

Створення іміджу лідера

Керівники, які постійно працюють, подають приклад своїм підлеглим, мотивуючи їх до кращої роботи. Це може створювати образ лідера, відданого своїй справі.

Швидке досягнення цілей

Коли менеджер зосереджений на швидкому виконанні завдань, він може досягти значних результатів у короткі строки. Це особливо важливо у стартапах або кризових ситуаціях.

Негативний вплив hustle-культури на менеджерів

Попри певні переваги, hustle-культура має і негативний вплив на менеджерів. Постійна гонитва за продуктивністю та ідея «працюй більше, спи менше» часто призводять до професійного вигорання, стресу і зниження якості ухвалення рішень.

Емоційне вигорання

Постійний стрес, довгі робочі години та відсутність відпочинку призводять до емоційного вигорання. Менеджер починає втрачати мотивацію, знижується рівень енергії, а продуктивність падає.

Проблеми з фізичним здоров’ям

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

Погіршення стосунків

Культура hustle змушує менеджерів нехтувати сім’єю, друзями й особистим життям. Це призводить до конфліктів, самотності та втрати підтримки близьких.

Втрата креативності

Коли менеджер постійно зайнятий операційними завданнями, у нього залишається менше часу для стратегічного мислення та інновацій. Це може знизити конкурентоспроможність у довгостроковій перспективі.

Як менеджерам уникнути негативного впливу цієї культури?

Менеджерам необхідно знаходити баланс між продуктивністю й особистим добробутом, щоб не стати жертвою виснаження чи вигорання. Кілька практичних порад допоможуть керівникам мінімізувати негативний вплив hustle-культури: від впровадження гнучких робочих графіків до підтримки ментального здоров’я.

Встановлення меж

Менеджери мають вчитися казати «ні» завданням, які не відповідають їхнім пріоритетам. Чітке планування часу та виділення годин для відпочинку допоможуть зберегти баланс.

Делегування

Не всі завдання обов’язково виконувати самостійно. Делегування дає можливість менеджерам зосередитися на стратегічних аспектах і зменшити робоче навантаження.

Фокус на якість, а не кількість

Культура hustle часто наголошує на кількості виконаної роботи. Проте для успіху важливіша якість. Ефективне управління ресурсами та пріоритезація завдань допомагають досягати більшого з меншими зусиллями.

Турбота про здоров’я

Фізична активність, правильне харчування та регулярний сон — це основа продуктивності. Інвестуючи у здоров’я, менеджери підвищують свою витривалість і знижують ризики розвитку хронічних хвороб.

Ментальне благополуччя

Практики mindfulness, медитація та перерви на роздуми сприяють відновленню внутрішніх ресурсів і розвитку креативності.

Культура smart work як альтернатива hustle

Замість сліпої гонитви за результатами менеджери можуть впроваджувати підходи «розумної роботи». Це передбачає:

● Використання технологій для автоматизації процесів.

● Зосередження на основних пріоритетах, а не багатозадачності.

● Підтримку здорового робочого середовища для команди.

Культура hustle може дати короткострокові переваги, але у довгостроковій перспективі вона створює серйозні виклики для здоров’я й ефективності менеджерів.

Баланс між роботою та особистим життям, інвестування у власне благополуччя та адаптація підходів до «розумної роботи» — ключ до сталого успіху. Менеджери, які відмовляються від hustle-мислення на користь розумного підходу, здатні досягти високих результатів без шкоди для себе.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Підготовка

Перш ніж експериментувати, врахуйте деякі моменти.

Дослідіть історію попередніх збоїв

Цілей для дослідження хаосу в роботі системи безліч, але важливі пріоритети. Найпростіший шлях — звернутися до логів. Вони покажуть, які проблеми вже «горять». Звісно, далеко не все навіть в історії збоїв може бути зрозумілим. Шукайте закономірності, обговоріть із колегами неочевидні причини проблеми. У процесі брейнстормінгу стане у пригоді візуалізація даних.

Якщо певні частини системи жодного разу «не ‎падали», це не означає, що їх не потрібно перевірити. Поряд із дослідженням слабких місць додайте в план «сплячі» проблеми.

Побудуйте мапу залежностей

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

Побудову залежностей можна автоматизувати, наприклад, за допомогою AWS X-Ray.

Налаштуйте алерти та бекапи

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

Сплануйте всі роботи

Якщо ви тестуєте щось на production, то стартувати краще з невеликих компонентів і простих тестів. Так ви зможете досліджувати систему поступово і знизите ризик виникнення масштабних проблем у реальності. В будь-якому разі до початку тестів оцініть можливий рівень ураження по кожному з напрямів. Також варто викочувати зміни на обмежену кількість користувачів. Це дасть реалістичну картинку, але не призведе до великого падіння продажів чи зниження рівня задоволеності юзерів.

Якщо ж йдеться про тестування на закритих середовищах, можна діяти протилежним чином. Спочатку запускайте перевірки на всій системі, щоб виявити bottle necks, проблемні місця, де можна очікувати падіння перфомансу. Потім переходьте до тестування окремих компонентів.

Як провести Chaos Testing

Суть полягає у створенні контрольованого збою для вивчення поведінки застосунку поза межами нормальних умов. У цьому процесі виокремлюють такі етапи:

1. Зафіксувати нормальний стан системи

До початку експерименту потрібно зрозуміти, як все працює за замовчуванням. На це є дві причини. По-перше, ви маєте від чогось відштовхуватися, щоб знати, що пішло не так. По-друге, після тестування потрібно переконатися, що все стало на свої місця. Адже не виключено, що збій у межах тестування призведе до непередбачуваних наслідків і негативно вплине на роботу всієї системи. Інколи навіть після відновлення пошкоджених компонентів застосунок може працювати хибно.

2. Сформулювати гіпотезу

Подібно до наукових експериментів у Chaos Testing теж має бути гіпотеза. Спробуйте передбачити поведінку певних компонентів під час збою із заданими форматом та масштабом. Наприклад, чи зможе система перенаправити трафік на інші регіони, якщо один перестане працювати? Як зміниться показник відмов юзерів при збільшенні затримки на 200 мілісекунд? Що трапиться, коли переповниться кеш і як система повідомить про це? Краще почати тестування з однієї простої чіткої гіпотези.

Але проста гіпотеза — не значить очевидна. Навіщо перевіряти те, що однозначно «‎впаде»? Корисніше спрямувати зусилля на ті компоненти, поведінка яких здається стабільною. Тоді є шанс знайти цікаві інсайти та використати їх задля покращення продукту.

Залучайте до обговорення гіпотези всю команду. Розробники, тестувальники, девопси, дизайнери та менеджери можуть зауважити те, на що ви не звертали увагу в поведінці системи, або підказати шляхи пошуку слабких місць.

3. Визначити межі експерименту

Маєте гіпотезу — пропишіть умови тестування. Потрібні чіткі KPI, що підтвердять або спростують ваші здогадки. Наприклад, кількість і частота помилок, затримка, відмови, пропускна можливість тощо. При визначенні KPI орієнтуйтеся на конкретний сервіс. Наприклад, у Netflix вимірюють SPS, starts-per-second. Це кількість кліків на Play. Коли сервіс гальмує, люди часто повторно тиснуть на цю кнопку. Ця метрика вказує, що є й технічна, і користувацька проблема.

На цьому етапі також слід прорахувати тривалість експерименту та зону ураження (її ще називають радіусом вибуху). Мова про конкретні частини системи, функціонал застосунку та кількість юзерів, які зіткнуться з проблемою. Якщо ви тільки дебютуєте у Chaos Engineering, краще обмежитись не просто малою частиною системи й аудиторії, а взагалі локальним середовищем. На старті навіть на цьому рівні вся команда дізнається чимало нового про поведінку системи. Хоча прод-середовище — пріоритет.

4. Провести тестування

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

Обов’язково попередьте всіх учасників команди про старт «‎хаосу». Але якщо сценарій передбачає таємність процесу для певних фахівців (щоб перевірити їхню реакцію та подальші дії), то, звісно, дотримуйтеся «‎режиму інкогніто».

Виконувати хаос-тестування можна кількома способами:

• Мануально — самостійно вносити деструктивні елементи в роботу системи, коду, обладнання тощо. Так ви повністю контролюватимете процес, але це потребує досвіду.
  
• Автоматизовано — за допомогою спеціальних інструментів. Це можуть бути вбудовані механізми Linux та хмар або застосунки чи сервіси, які надають контейнери для інтеграції в середовище (детальніше про інструменти поговоримо нижче).

5. Проаналізувати результати

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

Також важливо ставити часові мітки у звітах. Вони покажуть, у якому стані була система на кожному етапі. Відповіді на ці питання дадуть чимало корисної інформації для роздумів та подальших покращень:

• Коли почалися проблеми?
• Скільки часу минуло до появи алертів на пошті чи в месенджері?
• У який момент продукт зазнав найбільшої втрати функціоналу?
• Через який проміжок часу система запустила автоматичне відновлення (якщо взагалі почала)?
• Коли все повернулося до початкового стану?

6. Внести зміни в системі

Передусім зміни можуть стосуватися тих частин застосунку, які виявилися нестабільними. Змініть усе, що несе в собі ризики подальших збоїв. А потім знову перевірте, як «‎падає» ця частина системи. Варто переконатися, що засвоєні уроки дійсно принесли користь для продукту та користувачів. Повторюйте експеримент і модифікуйте його, поки не впевнитеся в стабільності системи. Подекуди може бути дві-три, а то й більше ітерацій.

Другий напрям для змін — інтеграція хаос-тестування в конвеєри CI/CD. Це тестування може виконуватися разово чи як окрема послуга (наприклад, на аутсорсі), але насправді помітний ефект хаос-тестінг дає лише при системному підході. DevOps-інженери разом із девелоперами та QA мають побудувати комплексну систему хаос-інжинірингу. Це вимагає кардинальних змін робочих процесів і залучення додаткового бюджету. Але реальні несправності можуть коштувати бізнесу набагато більше.

Інструменти для хаос-тестування

Спеціальні утиліти

Це невеликі консольні програми під вузькі задачі, найбільш корисні на початку тестування. Наприклад, за допомогою iptables можна змінювати роботу брандмауера, wrk створений для бенчмаркінгу HTTP, а stress-ng може перевантажити ресурси системи. Інструмент tc використовують для конфігурації планувальника пакетів ядра, а pkill — для завершення окремих процесів.

Комплексні програми

А це вже повноцінні сервіси та платформи для хаос-інжинірингу, які виконують оркестрацію несправностей різного типу й масштабу. Серед таких інструментів варто виділити Chaos Toolkit. Він має відкритий API, підтримує інтеграцію з AWS, Azure та GCP, має розширення з наборами тестів (можна створювати свої сценарії).

Поширений також Gremlin — для експериментів з усіма частинами системи. Він здатен пріоритезувати знайдені проблеми. Існують і сервіси для окремих середовищ, такі як LitmusChaos для Kubernetes і Pumba для Docker.

Simian Army створили айтівці в Netflix для тестів на AWS. На жаль, цей проєкт закритий, але окремі його частини доступні. Simian Army об’єднував кілька тулзів для збоїв різного типу й масштабу. Наприклад, Chaos Monkey, який нині розвивається як опенсорс-проєкт, може рандомно відключати інстанси. Latency Monkey створював затримки між клієнтом і сервером, Chaos Gorilla викликав збій зони AWS, а Chaos Kong — збої в цілому регіоні. Doctor Monkey перевіряв працездатність окремих екземплярів і компонентів системи, а Janitor Monkey знаходив та видаляв ресурси, які не використовуються (зараз ця тулза відома як Swabbie).

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

Анна Молодцова, Performance QA Engineer в NIX

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Не плутайте зі стрес-тестуванням (Stress Testing) і тестуванням навантаження (Load Testing). Ці підходи, які можна узагальнити під гаслом Perfomance-тестування, теж спрямовані на вивчення поведінки системи в позаштатних ситуаціях. Але порівняно з Chaos Testing є важливі відмінності:

● Фокус. Perfomance-тестування може застосовуватися до системи в цілому або до окремих компонентів, а «‎хаотичне» — завжди до дуже багатьох факторів у розподілених середовищах. Це те, що треба для мікросервісної архітектури із сотнями зв’язків. Тут часто стаються каскадні збої, коли одна проблема «‎ламає» систему в кількох інших місцях.

● Мета. Stress Testing і Load Testing перевіряють систему під критичним навантаженням, чи зміниться робота продукту при якихось змінах. А ось у хаос-тестуванні це другорядне. Важливо не те, чи «‎впаде» система. Головне: як і коли це відбудеться, яким чином ми дізнаємося про проблему, як будуть поводитися користувачі, чи спробує система самостійно відновитися тощо.

● Середовище. Тестування продуктивності зазвичай виконується в test- і stage-середовищах, що не впливає на бізнес-процеси. Chaos Testing може проводитись і на закритих середовищах, зокрема prodlike, але й ще на відкритому — production. Адже деякі проблеми неможливо виявити без реальних користувачів. Наприклад, на проді можна побачити реакцію юзерів на збільшену затримку у завантаженні.

Звідки починається Chaos Testing?

Про схоже тестування можна знайти згадки в роботі Amazon та Google ще у 2000-х, а в команді Apple — навіть у 1980-х роках. Нині вважається, що підхід до «‎хаотичного» тестування зародився в Netflix, коли у 2011 році компанія почала переносити центри обробки даних в AWS.

Тоді хмари здавалися безперебійними: в них відсутня єдина точка входу, середовища розподілені, легко переспрямовують ресурси й трафік, роблять бекапи, замінюють кластери. Але 2015 року Netflix зазнали простою у кілька годин і щоб краще підготуватися до можливого повтору, команда запровадила глибокі перевірки системи в режимі хаосу.

Що перевіряють за допомогою хаос-тестування

Підхід спрямований на всі складники цифрової системи. Серед основних місць впровадження несправностей можна виокремити такі:

● Інфраструктура. Netflix використовували хаос-тестування якраз для перевірки стійкості своєї інфраструктури. Варіантів, куди спрямувати руйнування, чимало: зупинка випадкових інстансів, відключення окремих зон чи регіонів, від’єднання від повноцінного центру обробки даних тощо.

● Мережа. Це невіддільна частина хаос-інжинірингу для будь-яких систем, особливо розподілених. Тут можна створювати затримки, відправляти пакети у чергу або задавати їх втрату, змінювати файл hosts і налаштування DNS або імітувати пошкодження мережі.

● Ресурси. На цьому рівні впровадити помилки можна в ядро чи кеш CPU, файлову систему, оперативну пам’ять, операційну систему, API, віртуальні машини тощо. Також можна вичерпати місце на жорсткому диску, відключити напругу на сервері або окремі планки пам’яті.

● Застосунок. Цей шар найоб’ємніший, і залежно від структури продукту поламатися можуть сотні частин. На бекенді можуть бути проблеми з базами даних, падіння окремих процесів, наприклад, Java, помилки в лямбда-функції. На фронтенді можуть відмовити плагіни, певні функції сервісу чи вбудовані інтеграції.

● Люди. Критичні сценарії можна запускати на рівні команди. Наприклад, щоб перевірити, як фахівці зреагують та розв’язуватимуть проблему, чи будуть вони слідувати прописаним процедурам тощо. Можна навіть «відключити» ключового інженера (імітація відпустки чи лікарняного) та подивитись, чи зможе команда самотужки забезпечити роботу системи в разі несправності.

З чим допоможе Chaos Testing

● Виявити проблему до «‎падіння» системи. Вкрай важливо побачити потенційні точки відмови до небажаного моменту. Це дозволить якісно змінити роботу всієї системи, підвищити її стійкість і доступність. Врешті це знизить і втрати компанії: ресурсні, фінансові, репутаційні.

● Знайти приховані проблеми та краще зрозуміти, що відбувається «під капотом‎». Сучасні розподілені системи подекуди заскладні, з великою кількістю компонентів та зв’язків. Тож навіть досвідчені фахівці можуть не знати всіх їхніх слабких місць. Хаос-тестування виявляє приховані вразливості та показує поведінку системи під час різних за форматом і масштабом збоїв.

● Покращити моніторинг несправностей. Неможливо впровадити Chaos Testing без побудови й налагодження великої системи телеметрії. Вона ж корисна не тільки в процесі хаос-тестування, але й у повсякденній роботі. Операційні команди отримують більше показників для аналізу стану системи та можуть заздалегідь виявляти певні проблеми.

● Розробити «рятівні» сценарії. Одразу виправити всі знайдені проблеми складно, але можливо підготуватися до них. Розуміння ризиків дозволяє прописати детальний план дій на випадок тих чи інших збоїв. Також документація спрощує онбординг новачків у команді, дає змогу швидше розібратися в особливостях побудованої системи.

● Покращити команду роботу. Будь-які збої — завжди стрес. А в таких умовах команда часто зосереджується на пошуку винних, хоч насправді це не розв’язує проблему. Куди важливіше налаштувати процес таким чином, щоб проблема не повторилась. Практика показує: системне хаос-тестування якісно змінює комунікацію в команді та підвищує ефективність роботи.

Пам’ятаймо про недоліки

Збільшення ресурсів. Додатковий етап тестування тягне за собою додаткові витрати по часу і грошах. До того ж Chaos Testing часто об’ємніший, ніж інші QA-задачі. Хоча для ІТ-фахівців користь від змін очевидна, та далеко не кожен власник бізнесу погодиться на впровадження стресових перевірок у власному продукті. Доведеться зібрати аргументи, щоб переконати замовника в необхідності такого тестування на благо проєкту.

Складність виконання. Знадобляться глибокі знання в кількох сферах: програмування, тестування, DevOps, досвід роботи з хмарними середовищами, вміння працювати зі складною архітектурою. І цей список далеко не вичерпний. Щоб тестування пройшло ефективно, потрібно прописати якісні тестові сценарії, налаштувати їх і правильно ввести в систему без зайвих ризиків. На додачу — ще й грамотно проаналізувати результати. Адже у великих розподілених системах причини збоїв можуть бути неочевидними.

Ризик виникнення реальних збоїв. Створюючи помилки в межах хаос-тестування, обов’язково контролюйте їх. Ви не просто запускаєте «‎хаос» — ви маєте розуміти, в якому напрямку він розвивається та як повернути все назад. Врахуйте, що такі перевірки часто відбуваються на продакшені, і неприпустимо «‎обвалити» всю систему. Тож треба ретельно готувати бекапи й інші страховки для швидкого відновлення.

Потреба у зміні пріоритетів. Іноді за результатами хаос-інжинірингу зміни доходять до рівня архітектури. Це знову ж тягне за собою додаткові витрати. Замовник може зауважити: зараз важливіші, наприклад, нові фічі. Але який в них сенс, якщо система не працює, як треба? Враховуйте, що й тут потрібен час на обговорення пріоритетів. Але це виправдано, якщо врешті всім потрібен якісний продукт.

Не панацея від проблем, але спробувати варто

Хаос-тестування доцільне в проєктах, яким критично важлива безперебійна робота. Зокрема, цифровим продуктам у сфері фінансів, охорони здоров’я, державним реєстрам, соціально важливій інфраструктурі, телекомунікаціях, логістиці, кібербезпеці, для стрімінгів та eCommerce.

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

Це стосується внутрішніх сервісів компаній, простих корпоративних та освітніх платформ, MVP. І хоч Chaos Testing — не панацея від усіх можливих проблем на проді, але однозначно це дієвий спосіб прокачати на стійкість свою команду і продукт загалом.

Про те, як підготуватися до хаос-тестування, які інструменти для цього потрібні та які етапи передбачає процес, розповімо в наступному матеріалі.

Анна Молодцова, Performance QA Engineer в NIX

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

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

Широка адаптація та революційний прогрес використання AI-технологій значно підвищують ризики та, з одного боку, надають переваги зловмисникам, оскільки значно спрощують прості й типові атаки, написання шкідливих листів і спам-листів, а з іншого боку, це додає можливостей і захисникам.

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

З огляду на наш досвід, часто компанії малого й середнього бізнесу використовують не більше ніж 50–70% функціоналу систем захисту, які вони купили.

Таким чином, можна говорити про те, що ви просто втрачаєте принаймні 50% своїх грошей і не завжди ефективно використовуєте вкладені інвестиції. Якщо у вас немає підрозділу Security Operation Center (SOC), то ці кіберпомилки можуть стати фатальними для вашого бізнесу.

Для усунення таких недоліків і з’явився сегмент компаній, які фокусуються на керованих послугах. На сьогодні все більше сучасних бізнесів вибирають Manage Service провайдерів MSP, MSSP і MDR сервіси, які можуть забезпечувати не лише захист і підтримку систем, а й проактивний моніторинг ваших сервісів і критичних даних.

Що таке Managed Services

Managed Services — це модель аутсорсингу, коли професійний партнер бере на себе управління та підтримку вашої ІТ-інфраструктури. Це не просто передавання завдань, а інтеграція висококваліфікованих рішень для забезпечення роботи ІТ (ІТ-інфраструктури), систем захисту з питань налаштування, технічної підтримки (конфігурування, оновлення), а також моніторингу та виправлення можливих проблем.

Приклад: Компанія АБВ вирішила відмовитися від команди власного відділу SOC і покластися на провайдера послуг MSSP/MDR. Результат? Зниження витрат на 30%+ і покращення захищеності даних, адже фахівці MSSP/MDR розгорнули системи кібербезпеки, взяли на себе всі функції підтримки, а також завдання з детектування, аналізу ескалації інцидентів, подальшу спільну роботу з розслідування та реагування на інциденти, а також покращення роботи систем ІТ і кібербезпеки.

MSSP VS Аутсорсинг

На відміну від звичайного аутсорсингу, де передаються «в оренду» люди або окремі завдання чи системи, Managed Services гарантують постійне управління, інтеграцію з вашими бізнес-процесами та проактивний моніторинг. Це означає, що ви отримуєте комплексну підтримку, яка значно покращує якість роботи систем ІТ і кібербезпеки та зменшує ризики кібератак.

MSP, MSSP і MDR — у чому різниця

Дуже часто ці терміни плутають. Це пов’язано з тим, що вендори використовують ці терміни у вільному трактуванні. Однак деяка різниця є, і вона пов’язана з фокусом цих послуг.

MSP (Managed Service Provider)

Забезпечує стабільну роботу ІТ-ресурсів: адміністрування мереж, резервне копіювання, оновлення програмного забезпечення.

MSSP (Managed Security Services Provider)

Фокусується на кібербезпеці. Відповідає за всі роботи, пов’язані з налаштуванням і підтримкою систем кібербезпеки.

MDR (Managed Detection & Response)

Це вже розвинута послуга, але з фокусом на операційну діяльність систем захисту (EDR/XDR, NDR, Cyber Deception, SOC тощо) та операції, пов’язані з детектуванням, аналізом, розслідуванням і реагуванням, які можуть відбуватися як у межах одного рішення (наприклад EDR/XDR) або всього комплексу рішень, так і в межах підрозділу SOC (зрозуміло, що це більш ефективна послуга).

У різних компаній-замовників різний погляд на використання цих сервісів. Попри те, що кваліфікації або кількості персоналу може бути не досить для забезпечення ефективної роботи систем ІТ і кібербезпеки, CIO/CISO компаній не готові залучати зовнішні компанії для таких керованих послуг.

Насамперед це питання довіри та кваліфікації партнерів. Тут єдина експертна порада — ретельно вивчати й аналізувати ринок, оцінювати практичний досвід і відгуки замовників, проводити пілотні проєкти.

Варто акцентувати, що постійне ігнорування відсутності персоналу або персоналу потрібної кваліфікації рано чи пізно може призвести до сумних наслідків, зокрема і ризиків неприпустимих подій, включно зі значними фінансовими збитками та штрафними санкціями.

Чому це важливо та вигідно для МСБ в Україні

Серед переваг використання послуг MSR, MSSP, MDR можна виокремити такі:

• Швидкий старт. Без зайвих витрат на розгортання інфраструктури.

• Відсутність дефіциту експертів. Професіонали на місці замість пошуку й утримання власного персоналу.

• Можливість цілодобового моніторингу. Постійний контроль за роботою систем (навіть у режимі 24/7) із миттєвим реагуванням на загрози, без значних інвестицій у команду замовника.

• Гнучкість і масштабованість. Сервіси адаптуються під ваші поточні потреби та зростання бізнесу.

• Доступ до передових технологій. Використання новітніх засобів захисту, таких як SIEM, XDR, EDR, NDR і SOAR, — і ви можете бути впевненими, що сучасні технології будуть працювати на всі 100%.

• Зменшення витрат. Економія на утриманні внутрішньої команди, оскільки якісні спеціалісти коштують дорого і їх потрібно навчати, утримувати та давати цікаву роботу, водночас утримуючи високий рівень захисту.

• Зовнішній погляд на ваші системи ІТ і кібербезпеки. Дає можливість оцінити, чи дійсно все налаштовано і працює правильно згідно з кращими практиками та рекомендаціями, чи не існує проблем, пов’язаних із кібербезпекою.

• Синергія співпраці команд замовника й оператора послуг. Дає змогу інженерам і керівникам замовника сфокусуватися на складніших чи стратегічніших завданнях.

Технології, що стоять за MDR і MSSP

MSSP

Сучасні NG-FW міжмережеві екрани, або UTM-системи (Cisco, Fortinet, Palo Alto Networks), системи виявлення аномалій (UEBA), системи контролю доступу PAM, системи захисту електронної пошти, системи аналізу WEB-трафіку, антивірусні системи, вебсервери й інше. Тобто фокусування насамперед на керуванні системами захисту.

MDR

SIEM, XDR, EDR, NDR, Cyber Deception, SOAR-інструменти для глибшого аналізу, детектування, розслідування й оперативного реагування на інциденти. Всі ці системи є, по суті, системами збору й аналітики даних. З ними має працювати експертна команда, яка розуміється на тому, як не просто ефективно налаштувати систему, а й виявити інцидент, провести розслідування щодо обставин його виникнення та відповідне реагування і вжити заходів для мінімізації повторення. Це саме те, що зазвичай передається команді Security Operation Center, яка заточена під операційну модель використання цих технологій.

MSP, MSSP і MDR — це не просто послуги, а стратегічний інструмент керівника CxO рівня, що дає змогу захистити бізнес від сучасних кіберзагроз, оптимізувати витрати та забезпечити безперебійну роботу ІТ-інфраструктури й основних сервісів. Зробіть свій бізнес стійкішим до кібератак і відкрийте нові можливості для зростання навіть в умовах «першої світової кібервійни».

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Держава вирішила скоригувати правила гри, збільшити податкові надходження й водночас підтримати економіку в умовах воєнного стану. Що ж тепер змінилося? Давайте розберемося. IT-юрист Дмитро Кондратьєв розповів про це у своїй колонці.

Що нового для резидентів Дія.City?

Компанії, що працюють у правовому режимі Дія.City, отримали певні податкові пільги. Наприклад, тепер не оподатковуються суми, які вони сплачують за працівників у межах пенсійного забезпечення та медичного страхування. Головне, щоб ці витрати не перевищували 30% від заробітної плати чи винагороди спеціаліста.

Ще один важливий момент — на час дії воєнного стану операції, пов’язані з передаванням коштів, товарів чи послуг на потреби Збройних Сил України або гуманітарної допомоги, не підлягають оподаткуванню. Це важливий крок, який допоможе бізнесу підтримувати армію без додаткових податкових зобов’язань.

Водночас для спеціалістів, які працюють у компаніях-резидентах, з’явилася не дуже приємна новина: окрім 5% податку на доходи, тепер потрібно сплачувати ще й 5% військового збору. У результаті ефективна ставка зросла до 10%. Щоправда, цей варіант усе одно є значно вигіднішим, аніж стандартні 18+5% для інших працівників.

Як зміниться оподаткування для ФОП?

Найвідчутніші зміни стосуються фізичних осіб-підприємців. По-перше, вводиться обов’язковий військовий збір. Тепер ФОПи 1, 2 та 4 груп щомісяця сплачуватимуть 800 гривень (10% від мінімальної зарплати). Для ФОП 3 групи військовий збір становитиме 1% від доходу.

Тобто класична схема роботи через ФОП 3 групи, яка раніше передбачала сплату лише 5% єдиного податку, тепер коштуватиме вже 6% (5% ЄП + 1% військового збору) + ЄСВ.

Ось ще одна зміна, яку точно не можна ігнорувати: повертається обов’язкова сплата ЄСВ. Протягом воєнного стану підприємці могли не сплачувати внески до Пенсійного фонду, але з 2025 року це вже не варіант. Мінімальний ЄСВ становитиме 1760 гривень на місяць (22% від мінімальної зарплати).

Окремо варто згадати ліміти доходу для спрощеної системи. Вони не зазнали радикальних змін, але все-таки їх варто мати на увазі:

• ФОП 1 групи — до 1 336 000 гривень.
• ФОП 2 групи — до 6 672 000 гривень.
• ФОП 3 групи — до 9 336 000 гривень.

Якщо перевищити ці ліміти, доведеться перейти на загальну систему оподаткування, а це вже зовсім інші суми податків і звітності.

Що це означає для IT-фахівців і компаній?

Зміни в податковій системі вплинуть на вибір податкової моделі для IT-спеціалістів. ФОПи більше не зможуть ігнорувати військовий збір, а також повинні будуть сплачувати ЄСВ. Це збільшує навантаження, але поки що ФОП-модель залишається вигідною для тих, хто заробляє до 9,3 мільйона гривень на рік.

З іншого боку, резиденти Дія.City зберегли пільгову ставку, хоча військовий збір у розмірі 5% трохи погіршив умови. Попри це, оподаткування гіг-спеціалістів (10%) все ще є актуальним, особливо порівняно із класичним працевлаштуванням, де загальні податкові витрати можуть сягати понад 40%.

Якщо ж ви працюєте як ФОП, то доведеться переглянути фінансову модель і вирішити, чи варто залишатися на спрощеній системі, чи, можливо, розглянути варіант переходу в Дія.City.

У будь-якому випадку, краще заздалегідь проконсультуватися з бухгалтером і продумати свою стратегію, адже 2025 рік обіцяє бути цікавим.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Впровадження ERP — це складний процес, що потребує поєднання різноманітних компетенцій, узгодження очікувань і розвінчування міфів. Тому роль керівника проєкту тут є вирішальною.

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

Вибір керівника ERP-проєкту – це одне з найважливіших рішень, яке впливає на успіх усього проєкту. Ідеальний кандидат має поєднувати в собі технічні знання, розуміння бізнес-процесів, лідерські якості та досвід управління проєктами. Проте на практиці буває дещо інакше.

Хто ж краще впорається із цим завданням?

IT-менеджери: Їхньою сильною стороною є технічна підкованість. Вони знайомі з процесами впровадження цифрових інструментів, розуміють принципи розроблення, роботи з базами даних та інтеграції систем. Їхня головна мотивація — створення стабільної, сучасної та масштабованої системи, що легко інтегрується в наявну інфраструктуру.

Фінансові менеджери: Вони мають глибше розуміння бізнес-потреб і цілей упровадження ERP. Відповідають за фінансову звітність та ефективність компанії, чітко усвідомлюють необхідність контролю даних та автоматизації бізнес-процесів. Їхня мета — отримати потужний інструмент для оперативного й достовірного аналізу даних про діяльність підприємства.

Практика показує, що успішними керівниками ERP-проєктів ставали як IT-менеджери, так і фінансисти, а іноді й окремо залучені фахівці. Вибір залежав від специфіки компанії та наявних ресурсів. Наприклад, у компаніях зі слабким IT-відділом проєктом часто керував фінансист. Однак зустрічались і CIO, які демонстрували глибоке розуміння бізнес-процесів та управління фінансами.

Найефективнішим підходом є призначення керівником проєкту фахівця, який володіє комбінацією основних компетенцій:

• IT-компетенції: знання архітектури ERP-систем, досвід роботи з кодом, тестуванням та розуміння функціоналу.
• Бізнес-компетенції: розуміння принципів бухгалтерського обліку, формування собівартості, логістики та виробництва.

Ідеальний кандидат — це фахівець з успішним досвідом упровадження ERP, який підпорядковується одночасно CIO і CFO, забезпечуючи баланс між технічними й бізнес-вимогами.

Окрім технічних знань і розуміння бізнес-процесів, ідеальний керівник ERP-проєкту має володіти такими якостями:

• Здатність мотивувати команду, вирішувати конфлікти й ухвалювати рішення у складних ситуаціях.
• Вміння ефективно спілкуватися з різними категоріями співробітників — від топменеджменту до рядових працівників.
• Здатність успішно впроваджувати зміни в організації та долати опір до них.
• Мати досвід у плануванні, організації й контролюванні проєктів.
• Займатися так званою адвокацією бюджету проєкту й контролювати зайві вимоги від внутрішніх замовників до команди партнера з інтеграції ERP-рішення.

На успіх упровадження ERP впливають й інші фактори:

• Активна участь користувачів у проєкті з самого початку. Не чекати запуску у go-live, слухати тренінги, тестувати, вивчати систему, моделювати сценарії разом із командою партнера.
• Чітка позиція керівництва щодо важливості проєкту, можлива додаткова мотивація драйверів проєкту серед команди.
• Розуміння того, що впровадження ERP — це тривалий і складний процес.
• Готовність адаптувати проєкт до змінних умов, виокремити основні проєктні MVP. Якщо зростають обсяги вимог, то бути готовими до збільшення бюджету на впровадження, або поділяти на етапність план проєкту, якщо він вбачається спільній команді занадто громіздким.

Типові помилки при виборі керівника проєкту

• Призначають на роль керівника проєкту співробітника, який має вільний час, але не має необхідних компетенцій. Просто за фактором доступності.
• Акцент лише на технічних знаннях, без урахування лідерських якостей і комунікативних навичок. Софт-скіли рулять, правильна комунікація й точки контролю можуть суттєво допомогти вашому проєкту.
• Призначення на роль керівника проєкту співробітника, який раніше не стикався з подібним софтом, не знає принципів упровадження ERP — його навчання оплатите по факту ви.

Вибір керівника ERP-проєкту — це стратегічно важливе рішення. Його компетенції, досвід і лідерські якості безпосередньо впливають на строки реалізації, бюджет і загальний успіх проєкту. Тому не варто недооцінювати цей аспект, адже саме від керівника залежить, стане впровадження ERP успішною історією чи черговим прикладом невдалого проєкту.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Обов’язково ознайомтесь із примітками, перш ніж ви почнете читати далі.

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

Примітка 2. На те, що зараз, працюючи на Європейську економічну зону (ЄЕЗ), ми керуємося принципом Privacy by Default, вплинуло багато «законів». Найбільше GDPR та DMA, але є й інші. Зверніть увагу, трішки раніше я вжив слово «закони», хоча насправді той же DMA є актом, але я не хочу перевантажувати цей матеріал юридичними термінами, тому для спрощення завжди буду використовувати слово «закони».

Примітка 3. Я також не хочу перевантажувати текст технічними термінами, тому буду використовувати термін «cookie». Водночас матиму на увазі різні сховища даних: власне cookie, Local Storage та  Session Storage та інші технології. Детальніше про це буде в пункті № 3 «Чи стосується «cookie» виключно файлів cookie, чи включає також інші подібні технології збору даних?»

1. Чи налаштування згоди стосується тільки cookie третьої сторони?
2. Чи можна хоча б якісь cookie назначити користувачу без його згоди?
3. Чи стосується cookie виключно файлів cookie, чи включає також інші подібні технології збору даних?
4. Чи стосуються правила згоди лише даних, що передаються третім сторонам?
5. Чи поширюються ці вимоги лише на Європу, чи діють також в інших регіонах?
6. Чи поширюються ці налаштування на Україну?
7. Чи стосуються налаштування згоди лише сервісів Google, чи охоплюють й інші платформи?
8. Чи стосується консент сайтів, які купують рекламу, а не продають її?
9. Чи потрібно мати окрему сторінку із Privacy Policy?
10. Чому краще робити банер консенту через CMP?
11. Чи можна використовувати GTM (Google Tag Manager) для управління згодою? Чи дозволяється використання GTM, якщо користувач заборонив використання cookie?
12. Чи вважається порушенням консенту, якщо банер згоди, що налаштований через GTM, не показується через використання блокувальників реклами?
13. Чи потрібно кожного разу, коли користувач заходить на сайт, збирати згоду-повтор?
14. Замість висновку.

№ 1. Чи налаштування згоди стосується тільки cookie третьої сторони?

Це одне з найпопулярніших питань. Відповідь — ні.

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

№ 2. Чи можна хоча б якісь cookie назначити користувачу без його згоди?

Так, можна. Якщо такі cookie прямо необхідні для надання послуги кінцевому користувачу.

У статті «Чому Consent це не просто банер і як налаштувати його правильно» я розповідав, що завжди є група обов’язкових cookie. Якщо вони потрібні для коректної роботи сайту, наприклад, коли користувач додає товар у кошик в інтернет-магазині, то було б дуже незручно, якби при переході на наступну сторінку цей товар зникав.

Ще один приклад використання обов’язкових cookie збереження ваших даних входу в Facebook, або інші сервіси, щоб вам не потрібно було постійно вводити логін і пароль при кожному оновленні сторінки. Тобто, якщо ці cookie є обов’язковими для функціонування сайту, ви маєте право їх використовувати.

Ще один важливий момент: коли користувач заповнює форму, він також вказує свої персональні дані. Згідно з GDPR, збирати такі персональні дані дозволено. Але важливо, щоб ви проінформували користувача, і він надав згоду щодо політики роботи з цими даними. Навіть якщо користувач натиснув на банері Deny, але заповнив форму та погодився на вашу політику роботи з даними, бажаючи, щоб ви зв’язалися з ним і залишив свої контактні дані, ви маєте право зібрати цю інформацію й перенести її, наприклад, у CRM-систему.

Резюмуючи, нам не потрібно просити згоду користувача на збір персональних даних, які необхідні для забезпечення функціоналу надання основної послуги користувачу. Але обов’язково потрібно отримати дозвіл на збирання даних для інших цілей.

№ 3. Чи стосується «cookie» виключно файлів cookie,чи включає також інші подібні технології збору даних?

Коли ми говоримо про закони щодо захисту персональних даних користувачів, під загальним терміном «cookie» маються на увазі не лише cookie, але й Local Storage, Session Storage, певні піксельні теги, індекс DB та багато іншого. Загалом ці правила стосуються всіх вебтехнологій, які дозволяють зберігати інформацію про користувачів.

Переходимо до наступного питання. Воно схоже на перше, але має певну відмінність.

№ 4. Чи стосуються правила згоди лише даних, що передаються третім сторонам?

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

Незалежно від того, чи збираєте ви дані для власних потреб або для третіх сторін, ці правила стосуються всіх етапів обробки персональних даних ваших відвідувачів і клієнтів.

№ 5. Чи поширюються ці вимоги лише на Європу, чи діють також в інших регіонах?

Якщо ми говоримо про GDPR то він працює саме у Європі, а якщо точніше то в Європейській економічній зоні. Але у інших країнах є схожі закони: один з найбільш відомих CCPA в Каліфорнії. Також подібні закони діють у Колорадо, Бразилії, Південній Африці, Японії та інших країнах і регіонах.

Загалом, майже в усіх країнах, де приділяють увагу захисту персональних даних, є відповідне законодавство. Проте, у деяких регіонах ці правила є лише рекомендаціями, а в інших — обов’язковими до виконання. Наприклад, у деяких країнах принципом є «дозволено, доки користувач не заборонить», тоді як у Європі, зокрема завдяки GDPR, діє правило, що «доки користувач не надасть згоди, збирати дані не можна».

№ 6. Чи поширюються ці налаштування на Україну?

Так, ці вимоги поширюються і на Україну, хоча на трохи іншому рівні.

Я б сказав, що є більш і менш прогресивні підходи, і, на жаль, Україна наразі використовує менш прогресивний. У нас також є аналог GDPR, прийнятий уже багато років тому. Але якщо дивитись на ту ж Європу: GDPR почав діяти там у 2018 році, але основні зміни почалися в березні 2024-го, коли вступив у силу DMA. Тому те, що зараз відбувається, є скоріше наслідком впровадження DMA, ніж впливом GDPR.

В Україні є аналог GDPR, але оскільки у нас немає DMA, то рекомендація щодо банерів є бажаною, але не обов’язковою. Тобто якщо в Європі збирати дані можна тільки після отримання згоди користувача, в Україні в більшості випадків дозволено збирати дані, доки користувач прямо не заборонить цього. Наприклад, банери з кнопкою «ОК», які вважаються некоректними в ЄС, в Україні наразі не є порушенням.

Отже, Україна тут дещо осторонь. Але пам’ятайте, що є дві групи вимог: перша стосується законодавства, а друга — вашої взаємодії з рекламними та аналітичними системами. На законодавчому рівні в Україні це все ще перебуває на початкових етапах. Можливо, Google з часом вимагатиме передачі сигналів про згоду користувачів і від українських сайтів.

Поки що це не є обов’язковим, але є дуже рекомендованим. Наразі можна використовувати альтернативні варіанти, такі як OK-банери з умовою, що користувач дає згоду, залишаючись на сайті. Ну і не забувайте про моральну сторону питання: завжди добре, коли твої дані використовують зі згоди.

№ 7. Чи стосуються налаштування згоди лише сервісів Google, чи охоплюють й інші платформи?

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

Але я здогадуюсь, чому складається враження, що ці вимоги більше стосуються Google. Спробую пояснити це детальніше. На законодавчому рівні правила стосуються всіх, але дійсно здається, що Google запровадив найсуворіші вимоги.

Наприклад, поки що Facebook не обмежує рекламу, якщо немає сигналів згоди користувача, а Google вже почав впроваджувати це на деяких рекламних кабінетах. Саме тому складається враження, що ці правила стосуються переважно Google. Але, як уже згадувалося, вони діють для всіх платформ. У тих же Facebook і Bing вже теж з’являються відповідні розділи в довідках.

№ 8. Чи стосується консент сайтів, які купують рекламу, а не продають її?

Так, стосується.

Це питання регулюється дещо іншим законом — TCF (Transparency and Consent Framework). Ви можете детальніше про це почитати за цим посиланням. Проте повертаємося до відповіді на перше питання: це стосується будь-яких дій компанії, які пов’язані зі збором, збереженням чи аналізом персональних даних користувачів.

№ 9. Чи потрібно мати окрему сторінку із Privacy Policy?

Офіційної вимоги немає, але я та юристи, з якими я спілкувався, однозначно рекомендуємо створити таку сторінку. Це допомагає користувачам отримати всю необхідну інформацію, а вам — відповідати вимогам прозорості. Більше про вимоги до інформування користувачів можна знайти у GDPR Article 13: Personal Data Collected.

№ 10. Краще робити банер консенту через СМР чи власний?

CMP є зручним і швидким рішенням для компаній малого та середнього розміру. Вона значно зменшує витрати ресурсів на розроблення, забезпечує автоматичне оновлення відповідно до змін у законодавстві, що дає змогу бізнесу дотримуватися вимог GDPR та інших регуляцій без необхідності вручну відслідковувати зміни.

CMP також дозволяє легко кастомізувати банери з урахуванням бренду і підтримує мультимовність та геотаргетинг для відповідності локальним вимогам. Однак є один суттєвий недолік — це вартість послуг, що може стати значним витратним фактором для великих бізнесів.

Самостійне налаштування через GTM — це безкоштовний метод, що дає більше гнучкості. Однак він вимагає більше часу на розробку та тестування, а також вищого рівня технічних знань. Для налаштування через GTM необхідно створити власні теги, тригери й змінні, що може бути складним для компаній без технічних фахівців. Крім того, власноручне налаштування вимагає постійного моніторингу змін у законодавстві та їх адаптації.

Вибір між CMP і GTM залежить від розміру бізнесу, наявних ресурсів і технічних можливостей. CMP є оптимальним рішенням для бізнесів, які шукають простоту, автоматизацію і швидку відповідність вимогам, тоді як GTM підходить для тих, хто має ресурси на налаштування та хоче більше контролю над процесом.

Тому, на мою думку, використання готового рішення CMP є більш доцільним. Консент — це переважно юридичний аспект, і штрафи за його недотримання можуть бути суттєвими. Тому краще довірити це питання професіоналам, які вже мають досвід та необхідні інструменти для відстеження всіх аспектів цього процесу.

№ 11. Чи можна використовувати GТМ (Google Tag Manager) для управління згодою? Чи дозволяється використання GТМ, якщо користувач заборонив використання cookie?

Так, звісно, можна використовувати GTM, але є нюанси.

Поясню. Перше, якщо ми говоримо про чистий код тег-менеджера, то слід розуміти, що він не встановлює ніяких cookie.

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

Для відвідувачів сайту GTM ніяких cookie самостійно не встановлює, саме код тег-менеджера. Однак через GTM можна запускати скрипти, які можуть встановлювати cookie.

Тобто, резюмуючи, сам по собі GTM не є порушенням GDPR. Дуже важливо, щоб всередині нього без згоди користувача не запускалися коди, які встановлюють cookie, які вже можуть порушувати GDPR.

№ 12. Чи вважається порушенням консенту, якщо банер згоди, що налаштований через GTM, не показується, через використання блокувальників реклами?

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

Уявіть, на сайті встановлено банер згоди, налаштований через Google Tag Manager, але певні блокувальники реклами можуть блокувати не тільки рекламу, а й GTM. І в результаті банер не відображається користувачу, хоча він зайшов на сайт.

Правильна реалізація означає, що є Google Tag Manager із реалізованою згодою через CMP або власний банер. Основний код і всі маркетингові та аналітичні коди також знаходяться всередині Google Tag Manager. Якщо GTM не заблоковано, то все працює правильно: з’являється банер, людина дає згоду, і всі коди запускаються, або банер з’являється, користувач не дає згоди, і коди не запускаються. Все чітко. Якщо є блокувальник реклами, він блокує GTM і показ банера, а разом з цим не запускаються аналітичні та маркетингові коди.

Таким чином, персональні дані не збираються, і це не є порушенням GDPR. Більше того, розширення, яке блокує певні скрипти, — кастомізація сайту з боку користувача. Ви виконали вимоги закону, а те, що банер не з’явився, — це наслідок розширення користувача, яке заблокувало GTM.

Висновок: використання GTM для управління згодою — це нормальна, навіть дуже хороша практика.

№ 13. Чи потрібно кожного разу, коли користувач заходить на сайт, збирати згоду-повтор?

Кожного разу показувати банер згоди немає сенсу, щоб не втомлювати користувача. Але в законодавстві різних країн є додаткові вимоги: час від часу вам може бути потрібно оновлювати дані згоди. Найменший рекомендований інтервал — раз на пів року, у деяких країнах — раз на рік. Це потрібно для того, щоб банер не надокучав користувачу і щоб дозвіл не був «вічним».

Рекомендую уточнити вимоги в конкретній країні, де ви працюєте.

Замість висновку

Сподіваюся, що ви знайшли тут відповіді на запитання, які шукали або в яких не були впевнені. Якщо вам цікаво заглибитися в тему більше, дізнатися нюанси та подробиці налаштувань ви можете пройти безкоштовний курс Consent & GDPR in Marketing, де зібрано не лише теорію, але й вказівки по практичним налаштування консенту з додатковими матеріалами для кращого засвоєння.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Що таке хмара?

Хмара, або хмарні обчислення — це модель віддаленого користування інфраструктурою передавання даних, серверів, сховищ інформації, сервісів, застосунків тощо. Доступ до цих платформ надається замовникам від провайдерів оперативно та з мінімальними експлуатаційними витратами.

Тобто бізнес делегує відповідальність за інфраструктуру, а інколи й інші складові хмарної архітектури провайдеру. І не витрачає власні ресурси на побудову та підтримання роботи навіть невеликої серверної кімнати.

Якщо ж простими словами, то хмари — це віртуальне середовище з віддаленим доступом. Хмарна інфраструктура надає можливість безпечно опрацьовувати та зберігати великі обсяги даних. За допомогою хмари можна заощадити на додатковому технічному устаткуванні та деяких послугах IT-відділу. Водночас тут не йдеться про те, що від роботи останніх можна відмовитися.

Що таке хмарна безпека?

Насамперед це комплекс заходів і конфігурацій технологій для захисту інфраструктури. Кооперація всіх елементів системи забезпечує стійкість хмари від загроз різного напряму й типу.

Одним із найбільших ризиків є хакери. Зловмисники у мережі часто діють приховано: їхні мотиви складно визначити, а слідів часто годі й шукати. Притягнути хакерів до відповідальності складно, а подекуди і практично неможливо.

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

Хакери діють різними способами. Інколи для здійснення нападів залучають внутрішніх працівників компанії, оскільки компрометувати мережеві протоколи може власний сисадмін. Геть не завжди він діятиме зумисно, хоча й такі випадки теж непоодинокі. Інфікувати систему шкідливим ПЗ цілком можливо й випадково, клікнувши на замаскований хакерами лист, надісланий на електронну пошту.

Переваги

Хмарна міграція бізнесу останніх років мала чіткі підстави. В умовах пандемії компанії шукали оптимізацію можливостей для віддаленої роботи, водночас вибудовуючи контроль віддаленої інфраструктури та захищеність для чутливих даних.

Безпека інформації стала пріоритетом великих компаній при переході на хмарну інфраструктуру. Її назвали щонайменше 40% опитаних за результатами дослідження Google.

Ще 38% відзначили гнучкість хмарних платформ, які легко поєднуються з іншими безпековими рішеннями. Водночас для 31% учасників дослідження найціннішою стала автоматизованість процесів протидії загрозам у мережі.

Загалом переваги хмарної безпеки можна окреслити так:

• Автономність гарантує своєчасну реакцію на загрози системі й експертну ліквідацію хиб.
• Адаптивність до ризиків забезпечується залученням штучного інтелекту й технологій нейромережевого навчання.
• Оперативність дає змогу без зволікання отримати доступ до хмарної інфраструктури в режимі реального часу.

Вберегтися від усіх загроз

Неможливо. Однак ретельна підготовка — це запорука захищеності в мережі та стабільної роботи хмарної інфраструктури.

Способів, як убезпечити себе в мережі, багато, але класичний розробив американський Національний інститут стандартів та технології (National Institute of Standards and Technology — NIST). Складається він лише із 5 складників: ідентифікувати, захистити, виявити, зреагувати та відновити.

Кілька важливих подробиць:

• Управління ідентифікацією та доступом. Цей підхід тісно пов’язаний із принципом «нульової довіри» (Zero Trust). Тобто сприйняттям усіх мереж, користувачів та їхніх намірів як зловмисних і скомпрометованих. Будь-хто, хто захоче проникнути в систему, має пройти етапи верифікації, тому навіть натяки на підозрілу активність мають відстежуватися та в разі потреби блокуватися.
• Запобігання втратам даних. Крадіжка інформації з метою вимагання — один із найпоширеніших видів кіберзагроз. Поцупити дані, зашифрувати та вимагати за них викуп — на такий гачок потрапляють навіть великі компанії. Подібну операцію російські хакери влаштували проти інфраструктури системи нафтопроводів США Colonial Pipeline у 2021 році.

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

Безвідмовним способом є бекап, бажано у кількох локаціях. Наприклад, в UCLOUD ми пропонуємо розміщувати дані не тільки в Києві, але й у Варшаві чи Франкфурті.

Понад 30% користувачів переконані, що хмари допоможуть підвищити захищеність чутливих даних у мережі. Воно й недаремно, адже останні кілька років минули в умовах пандемії та війни. Під час локдауну компанії усвідомили цінність дистанційної роботи. Під’єднатися до корпоративного сервера прямісінько із власного дому зручно, але й може бути небезпечно.

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

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!‌‌

Що сталося в Dell

Наприкінці весни 2024 року американський виробник електроніки Dell розіслав 49 мільйонам клієнтів повідомлення про витік їхніх персональних даних. Мова йшла про імена, адреси та замовлення техніки впродовж 2017–2024 років. Представники Dell заявили, що ні фінансова чи платіжна інформація, ні електронні пошти та номери телефонів клієнтів під час атаки зловмисник не дістав, але ризики все одно суттєві. На той момент база з викраденими даними вже продавалася на одному із «чорних» форумів. Цієї інформації вистачить для персоналізованого спаму на адреси користувачів Dell.

Здійснив кібератаку хакер Menelik. Він скористався вразливістю в API партнерського порталу компанії, призначеного для співпраці з торговими представниками виробника. На сайті можна відстежувати інформацію про замовлення товарів, гарантію тощо. Menelik створив на порталі фейкові акаунти та отримав доступ до великої кількості чужих даних. І хоча сам хакер повідомив Dell про свою «діяльність» мейлом, від компанії він так і не отримав жодної реакції.

Які прогалини в безпеці призвели до кібератаки

Інцидент виявив низку вразливостей у кіберзахисті компанії. Та як показує практика, ці проблеми не поодинокі для багатьох ІТ-команд. Пропоную на прикладі Dell розглянути кожну «дірку» в системі безпеки та способи їх вирішення.

Відсутність верифікації користувачів

Що не так?

Для створення акаунту на партнерському порталі Dell достатньо було вказати назву компанії та емейл. Ба більше: ці дані ніяк не перевірялися, тому їх можна легко підробити. Наприклад, вказати вигадану компанію й одразу отримати доступ до порталу. Завдяки цьому хакер зміг швидко та без перешкод створити безліч акаунтів у системі Dell.

Як правильно?

Найпростіше зробити «живу» верифікацію користувача. Тоді новий підрядник не зможе автоматично створити акаунт на партнерському порталі. Для цього треба надіслати компанії запит, а далі працівник фірми-виробника перевіряє вказану інформацію: чи це дійсно реальний підрядник, чи взагалі він існує. І тільки після цього Dell самостійно створював би акаунт партнера та надавав би заявнику відповідні креди (доступи до персональної сторінки).

Але цей спосіб є не універсальним й іноді буває неможливим. Якщо компанія має тисячі партнерів, вручну обробити значну кількість запитів важко. Тоді має сенс застосувати автоматизацію. Наприклад, створити бази даних із переліком партнерів, з яким система звірятиметься самостійно. Також при підписанні партнерської угоди виробник може передавати спеціальний код для створення акаунту на порталі.

Неправильні налаштування ролей доступу до даних

Що не так?

В роботі партнерів із порталом Dell використовувались унікальні семизначні сервісні теги — ідентифікатори, які надсилаються в API-запиті для отримання даних юзера. Як виявилось, у Dell не налаштували обмеження ролей. Тобто залогінившись, можна перебирати теги за принципом брутфорсу, відправляти їх через API та отримувати дані чужих замовлень. Menelik для генерації тегів навіть створив окрему програму.

Як правильно?

Це типова проблема в побудові будь-якої закритої бази даних. Після успішної ідентифікації та автентифікації користувача має відбуватися авторизація — керування доступами до тих чи інших ресурсів відповідно до ролі юзера. Адже пів біди, що хакер зміг створити акаунт фіктивної компанії. Куди гірше, що завдяки цьому він отримав дані з акаунтів реальних партнерів Dell.

Користувачам завжди слід налаштовувати доступи, щоби вони могли дивитися тільки свої дані. Раптом через помилку хтось надішле чужий тег, йому надійде повідомлення про відсутність доступу до цієї інформації. Можна навіть не ускладнювати створення тегів — вони можуть йти підряд як простий ID. Зловмисник, надсилаючи запит із цими ключами, все одно нічого не отримає через обмеження ролі.

Некоректні ліміти на запити

Що не так?

Зазвичай розробники обмежують кількість запитів на API від юзера за певний проміжок часу, скажімо, за за хвилину чи секунду. Але на порталі Dell ліміти були або високі, або їх не було в принципі. Врешті хакер виконував до 5000 запитів на хвилину. Сам по собі показник для цієї системи, можливо, й не є критичним, але зловмисник працював на цій  частоті досить довго, що фахівцям компанії могло би здатися підозрілим.

Як правильно?

Ліміти API мають бути завжди, і це слід пам'ятати всім — розробникам, security-інженерам, SOC-командам. Обмеження діють на одного юзера або на IP-адресу в залежності від бізнес-логіки застосунку. Ліміти щонайменше допомагають збалансувати навантаження на застосунок, коли всі користувачі мають рівні можливості доступу. Водночас ці обмеження підвищують безпеку, бо скорочують можливі втрати при витоку даних.

Я би не радив встановлювати конкретні ліміти API, все залежить від специфіки проєкту. Для одних програм 5000 запитів забагато, для інших — норма. А може бути і так: десь користувачі зазвичай створюють 100 запитів на хвилину, але раз на рік за певних обставин показник підвищується до 1000. Тож треба аналізувати бізнес-логіку сервісу або окремого ендпойнту та вираховувати адекватні для цієї системи показники.

Відсутній моніторинг

Що не так?

Menelik не просто мав змогу збирати дані на високій швидкості, він створив кілька фіктивних акаунтів, кожен з яких на максимальній «потужності» працював тривалий час. Атака на партнерський портал Dell відбувалась три тижні поспіль, ніхто не помічав підозрілої активності користувачів. Саме цей чинник дозволив хакеру отримати велику кількість персональних даних.

Як правильно?

Для зменшення наслідків зламу потрібно створити моніторинг з алертами на аномальні події. Аномалії можуть бути різними: юзер задає декілька API-запитів або десятки користувачів одночасно запитують одні й ті самі дані, або ж з IP-адресу надходять запити із заданою регулярністю. Суть моніторингу полягає в тому, щоб при появі будь-якої підозрілої активності ви отримували повідомлення на пошту або в месенджер.

Важливо грамотно налаштувати моніторинг, адже не кожна аномалія свідчить про злам. Можна орієнтуватися не на кількість запитів, а на якість відповідей. Наприклад, у разі брутфорсу тегів або ID періодично надходитимуть відповіді з кодами 404 (не знайдено) або 500 (Internal Server Error). Хоч все залежить від проєкту, помилки можуть бути і в реального юзера, та якщо таких відповідей 90%, краще все перевірити.

Повільне реагування на вже вчинений злам

Що не так?

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

Як правильно?

Створити систему швидкого реагування на наявність вразливості та власне зламу — задача не стільки фахівців із безпеки, скільки самого бізнесу. Але Security-спеціалісти можуть бути на крок попереду та запропонувати шляхи убезпечення компанії. Наприклад, підключити до електронної пошти інструменти сортування листів. Таких тулзів зараз безліч, зокрема на базі штучного інтелекту. Вони можуть аналізувати вміст повідомлень та надсилати алерти про знайдені задані стоп-слова.

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

Як побудувати систему захисту даних

Описані проблеми могли би бути не критичними, але всі разом вони призвели до масштабного й водночас простого на рівні технологій зламу.

До питання безпеки слід підходити комплексно та системно. Врахуйте наступні кроки:

• Сформуйте Security Operations Center

Команда не обов’язково має бути великою, іноді достатньо двох фахівців. Але це мають бути досвідчені спеціалісти, задіяні в проєкті, щоб активно взаємодіяти з командою розробників, тестувальників, власників бізнесу тощо. SOC в режимі реального часу моніторить активність користувачів, реагує на інциденти та в особливих випадках самостійно розв'язує проблеми. Фахівці повинні мати можливість швидко заблокувати підозрілих юзерів та IP-адреси.

• Проводьте комплексні перевірки безпеки

На етапі розробки за сек’юрність відповідають девелопери і тестувальники. SOC-команда долучається до пошуку вразливостей після запуску проєкту, зокрема під час penetration-тестів (тестування на проникнення). Фахівці не обмежуються моніторингом та реакцією на алерти. Девелоперам вони можуть створювати тікети для виправлення помилок. Перевірки системи можуть бути складними й довгими, все залежить від проєкту, ролей у команді, бюджету. За бажанням замовника це бути додаткова послуга.

• Створіть сценарії взаємодії з користувачами

Задача бізнесу серед іншого — вести коректну та регулярну комунікацію з клієнтами. В компаній мають бути чіткі стратегії оперативного інформування юзерів про потенційні ризики. Потрібно розділяти, кому надіслати повідомлення — всім користувачам чи лише «‎жертвам» витоку даних, якщо вони відомі. Продумайте поради для своїх користувачів.

Інколи достатньо змінити пароль, але в деяких ситуаціях, щоб убезпечити аккаунт, зміни потрібні суттєвіші. Наприклад:

• Увімкнути двофакторну аутентифікацію для додаткового рівня захисту.
• Перевірити список пристроїв, підключених до облікового запису, та вийти з непізнаних сесій.
• Оновити контактну інформацію для відновлення доступу, в тому числі email та номер телефону.
• Відкликати доступ сторонніх застосунків та перевірити дозволи API.
• Сканувати пристрій на наявність шкідливого ПЗ та оновити антивірусне програмне забезпечення.
• Змінити паролі на всіх сервісах, де використовувався скомпроментований пароль.

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

Владислав Безродний, Application Security Engineer в NIX

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Як створити працюючу схему технічної підтримки, що задовольнить потреби замовника та не перевантажить команду? Розглянемо один із підходів на прикладі нашої компанії.

Я розвиваю аутсорсинг ІТ-інфраструктури для компаній малого та середнього бізнесу вже понад 16 років, і ми розробили трирівневу систему підтримки, яка забезпечує високий рівень сервісу та контролю.

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

Хочу описати нашу систему підтримки, яка передбачає три рівні та певний патерн взаємодії із клієнтом. Можливо, це стане у пригоді тим, хто будує власну систему технічної підтримки з нуля або перебудовує чинну. Наша трирівнева система підтримки L1, L2 та L3 дає змогу якісно обслуговувати запити будь-якої складності.

Перша лінія підтримки — L1

L1 Support Team — це перший контакт клієнта із нашою командою.

Інженери L1 приймають і класифікують звернення в Service Desk за типом і пріоритетом (маємо напрацьовані та перевірені на практиці методології класифікації). Швидко розв’язують стандартні питання (наприклад, проблеми з доступом, друком чи налаштуванням програмного забезпечення) або делегують складніші запити на L2 чи L3, визначаючи оптимального виконавця.

L1 — це команда оперативної реакції, яка закриває більшість типових питань на місці.

Друга лінія підтримки — L2

Інженери другого рівня підтримки вирішують складніші технічні завдання:

1. Обслуговують сервери, мережеву інфраструктуру, а також налаштовують і підтримують обладнання.

2. Реалізують проєкти зі створення IT-інфраструктури відповідно до технічних завдань.

3. Ескалюють до L3 лише ті запити, які потребують адміністративного впливу або стратегічного чи інноваційного підходу.

L2 — це команда, яка працює над більш технічно складними завданнями, забезпечуючи стабільність IT-інфраструктури клієнтів.

Третя лінія підтримки — L3

L3 — це наша команда топових експертів, які:

1. Аналізують бізнес-потреби клієнтів, пропонують і впроваджують індивідуальні IT-рішення.

2. Розробляють технічні завдання для реалізації інфраструктурних проєктів.

3. Запускають пілотні рішення, проводять презентації та навчання IT-підрозділів клієнтів.

4. Вирішують найбільш складні та нестандартні технічні питання.

L3 — це стратегічний рівень підтримки, який сприяє довгостроковому розвитку бізнесу клієнтів. Тобто це візіонери, що розбудовують ІТ-інфраструктуру замовника під його поточні чи планові потреби, вимоги імплементованого ПЗ, релокацію офісу чи масштабування бізнесу.

Прямий контакт інженерів із клієнтами

Одна із головних особливостей нашого підходу — це прямий контакт інженера із клієнтом незалежно від рівня підтримки.

Як тільки інженер отримує запит у свою відповідальність, він напряму взаємодіє із клієнтом, минаючи посередників. Ми проти операторів чи проміжних консультантів, оскільки це збільшує тривалість обробки тікета.

Що це дає і чому ми не використовуємо зворотного ходу звернення знизу вгору?

✓ Не витрачається час на передання інформації через інші лінії підтримки.

✓ Мінімізується ризик викривлення даних через людський фактор.

✓ Клієнт спілкується безпосередньо з відповідальним виконавцем, що підвищує довіру до процесу.

Що ми отримали завдяки такій структурі?

✓ Кожен рівень працює у своїй зоні компетенції.

✓ Ми мінімізували час на вирішення завдань.

✓ Це підвищує довіру і знижує ризик виникнення непорозумінь.

У середньому ми обробляємо понад 800 звернень на місяць від майже 100 компаній. Середній час реакції на звернення — 10 хвилин, але ми покращуємо цю цифру. Час відповіді на дзвінок — 15 секунд, середня тривалість контракту — 6 років. Тобто, ми систематично збираємо статистику й оптимізуємо власні показники, щоб забезпечувати стабільно високий рівень підтримки.

А як із цим у вас? Чи застосовуєте ви прямий контакт спеціалістів із клієнтами у своїх процесах? Можливо, у вас є кейси, які допомогли суттєво покращити підтримку? Поділіться своїм досвідом у коментарях.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

У цій статті Олеся Ульянова, Ph.D, MBA, СЕО Telesens, Founder ITGC, Еx-ментор USAID, розглянула п’ять найболючіших помилок відкритого лідерства, які варто знати кожному керівнику, і запропонувала найефективніші способи їх вирішення.

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

Здається «магічну пігулку» знайдено і це майже ідеальний підхід до менеджменту: результатів у бізнесі досягнуто, а команда — самостійна, мотивована і свідома. Дійсно, відкрите лідерство може значно покращити роботу команди та компанії загалом. Проте ця відкритість і довіра команді може зіграти злий жарт, особливо, коли лідер працює у корпоративному сегменті із зарегульованими та бюрократичними процедурами.

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

Надмірна прозорість

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

Які негативні наслідки від надмірної прозорості?

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

● Розкриття конфіденційних даних. Ненавмисне розкриття стратегічних планів, фінансових показників або особистої інформації може поставити під загрозу безпеку компанії та довіру клієнтів і партнерів.

● Підвищення тривоги серед спеціалістів. Невідфільтрована інформація про проблеми або ризики без належного контексту може викликати паніку або погіршення морального стану в команді.

● Зниження авторитету лідера. Якщо лідер постійно ділиться всіма подробицями, команда може почати сумніватися у його здатності
фільтрувати інформацію й ухвалювати стратегічні рішення.

● Відволікання від основних завдань. Надмірна кількість інформації може відволікати спеціалістів від їхніх основних обов’язків.

Як цьому запобігти?

1. Встановіть чіткі межі інформації. Визначте, яка інформація є критичною для роботи спеціалістів, а яка може бути зайвою або шкідливою. Діліться тим, що допоможе команді виконувати свої завдання ефективніше.

2. Фільтруйте інформацію відповідно до аудиторії. Різні рівні фахівців можуть потребувати різної глибини інформації. Менеджерам може бути потрібна детальніша інформація, тоді як іншим спеціалістам достатньо знати основні моменти.

3. Забезпечте контекст і рішення. Якщо ви ділитеся проблемами або викликами, обов’язково надавайте контекст і можливі шляхи їх вирішення. Це допоможе знизити тривогу і показати, що ситуація під контролем.

4. Дотримуйтеся принципу «потрібно знати». Діліться інформацією лише з тими, хто дійсно потребує її для виконання своїх обов’язків. Це допоможе захистити конфіденційність і зберегти фокус команди на головному.

5. Консультуйтеся із командою з управління ризиками. Перед тим, як розкрити важливу або чутливу інформацію, обговоріть це з фахівцями, щоб оцінити потенційні ризики та наслідки. Якщо лідер детально розповідає всій команді про фінансові проблеми без плану дій, це може викликати паніку, зниження мотивації та навіть звільнення команди. Повідомлення про можливі реорганізації або скорочення без конкретних деталей може створити атмосферу невпевненості та чуток.

Відсутність чітких меж

Відсутність чітких меж виникає, коли лідер не встановлює або не підтримує необхідну дистанцію між собою та командою. Це може проявлятися у відсутності визначених ролей, відповідальностей або у занадто дружних відносинах, які розмивають професійні межі.

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

Що може призвести до відсутності чітких меж?

● Бажання бути «своєю людиною». Лідер може прагнути до популярності серед команди, що змушує його стирати професійні межі.

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

● Культурні особливості. У деяких компаніях чи культурах
неформальний стиль управління може бути нормою, але без належних меж це може створити проблеми.

● Прагнення до максимальної відкритості. Хоча відкритість є позитивною рисою, без чітких меж вона може призвести до розмивання ролей і відповідальності.

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

Якщо лідер не може встановити та підтримувати межі, команда може сумніватися в його компетентності та лідерських якостях. Без чітких меж процес ухвалення рішень може бути уповільнений або паралізований, оскільки немає ясності щодо того, хто має остаточне слово.

Як цьому запобігти?

1. Встановіть чіткі ролі та відповідальність. Документуйте обов’язки кожного члена команди та регулярно їх переглядайте. Обговорюйте прогрес та очікування, щоб переконатися, що всі на одній хвилі. Використовуйте офіційні канали комунікації для робочих питань (електронна пошта, корпоративні месенджери). Визначте години, коли спеціалісти можуть звертатися із запитаннями, особливо щодо невідкладних справ.

2. Підтримуйте професійну дистанцію. Гарні відносини важливі, але не забувайте про професійні межі. Будьте дружніми, але пам’ятайте про свою роль лідера. Ставтеся до всіх спеціалістів справедливо та рівноцінно.

3. Чіткі процеси ухвалення рішень. Ухвалюйте рішення на основі фактів, а не особистих симпатій. Встановіть, які рішення ухвалюються колективно, а які — індивідуально лідером. Пояснюйте, як і чому ухвалюються ті чи інші рішення. Встановлення та підтримка чітких меж є критично важливим аспектом ефективного лідерства. Це не означає створення бар’єрів або відсторонення від команди, а навпаки — створення структури, у якій кожен знає свої ролі, відповідальність та очікування.

4. Чіткі межі, які сприяють побудові професійних, довірливих і продуктивних відносин у команді. Лідер, який уміє встановлювати межі, допомагає команді працювати злагоджено, ефективно й зосереджено на досягненні спільних цілей. Пам’ятайте, що межі — це не обмеження, а інструмент для створення здорового і продуктивного робочого середовища.

Нездатність ухвалювати остаточні рішення

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

Чим це може бути спричинено?

● Страх помилитися. Лідер боїться, що неправильне рішення може мати негативні наслідки для команди чи компанії, що паралізує його
здатність діяти.

● Невпевненість у професійних навичках. Недостатня віра у власні
компетенції та знання може заважати ухваленню рішень.

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

● Надмірне залучення команди. Постійне прагнення отримати схвалення або думку від усіх членів команди може уповільнювати процес ухвалення рішень.

● Відсутність чіткої стратегії. Без ясного бачення та цілей лідеру складно ухвалювати рішення, які відповідають довгостроковим інтересам організації.
Затримки в ухваленні рішень можуть призвести до простоїв, утрати
можливостей і невиконання завдань у встановлені терміни. Команда може відчувати невизначеність і втрату довіри до лідера, що знижує мотивацію і продуктивність. Повільна реакція на зміни ринку або внутрішні проблеми може призвести до відставання від конкурентів.

Як це побороти?

1. Розвивайте впевненість у собі. Самоосвіта та підвищення кваліфікації для цього чудово підходить. Поглиблюйте знання в галузі, щоб відчувати себе більш компетентним. Аналізуйте свої успіхи. Розглядайте попередні успішні рішення, щоб зміцнити віру у свої здібності.

2. Встановіть чіткі цілі та пріоритети. Розробіть довгострокову стратегію, яка буде направляти процес ухвалення рішень. Визначте, які рішення потребують негайної уваги, а які можуть почекати. Не намагайтеся тягнути все і відразу на собі.

3. Обмежуйте час на ухвалення рішень. Встановлюйте дедлайни для ухвалення рішень. Це допоможе уникнути затягування процесу і стимулює до дії. Також використовуйте метод «достатньо добре». Ухвалюйте рішення, коли маєте достатньо інформації, а не повну.

4. Консультуйтеся з експертами, але пам’ятайте, що остаточне рішення — за вами. Не завжди можливо досягти повного консенсусу. Інколи потрібно ухвалювати рішення самостійно. Розуміння, що помилки — це частина розвитку, зменшить страх перед рішеннями. Плануйте дії на випадок, якщо рішення не дасть очікуваних результатів.

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

6. Лідер повинен усвідомити свою відповідальність за ухвалення рішень та активно працювати над розвитком цієї навички. Важливо знайти баланс між аналізом інформації та необхідністю дії, між залученням команди й особистою відповідальністю.

Ігнорування негативних наслідків

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

Чим це може бути спричинено?

● Безоглядний оптимізм. Лідер може бути надто впевненим у
позитивному результаті своїх дій, що заважає йому побачити
потенційні ризики та проблеми.

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

● Уникання конфліктів. Бажання уникнути дискусій або конфронтацій може спонукати лідера ігнорувати негативні аспекти та фокусуватися лише на позитивних моментах.

● Прагнення до швидких результатів. Тиск із боку менеджменту або
власні амбіції можуть змусити лідера ухвалювати рішення без належного аналізу.

● Недооцінка важливості зворотного зв’язку. Відсутність уваги до думок команди або експертів може призвести до пропуску важливих сигналів про потенційні проблеми.

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

Як не впадати в безоглядний оптимізм?

1. Проводьте ретельний аналіз ризиків. Визначте сильні та слабкі сторони, можливості та загрози для проєкту або рішення. Можете для цього використовувати будь-який інструмент. Визначте ймовірність виникнення ризиків та їхній потенційний вплив. Ведення реєстру ризиків як компанії, так і команди допоможе уникнути несподіванок.

2. Розробляйте плани дій на випадок непередбачуваних обставин.
Розробіть план Б, а краще В і Г. Чим більше пропрацюєте варіантів, тим менше часу будете витрачати на вирішення цих ризиків потім.

3. Розвивайте культуру відкритості та критичного мислення. Створіть середовище, де спеціалісти не бояться ставити під сумнів ідеї та рішення. Показуйте на власному прикладі, що ви цінуєте конструктивну критику. Не обіцяйте більше, ніж можете виконати. Це допоможе уникнути розчарувань.

Ігнорування негативних наслідків є серйозною помилкою, яка може
мати далекосяжні та руйнівні наслідки для лідера, команди та компанії в цілому. Відкритий лідер повинен не лише фокусуватися на позитивних аспектах і можливостях, але й активно ідентифікувати, аналізувати й управляти потенційними ризиками.

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

Врахування негативних наслідків — це не песимізм, а реалістичний і відповідальний підхід до управління, який дозволяє максимально використовувати можливості та мінімізувати ризики.

Залежність від зворотного зв’язку

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

Чим це може бути спричинено?

● Невпевненість у своїх лідерських якостях. Лідер може сумніватися у своїх навичках, знаннях або компетенції, що змушує його шукати
підтвердження від інших.

● Страх. Побоювання зробити неправильний вибір може спонукати
лідера постійно шукати схвалення, щоб розділити відповідальність за рішення.

● Бажання бути демократичним. Лідер може вважати, що постійне
залучення команди до ухвалення рішень підвищує мотивацію та
залученість спеціалістів.

● Відсутність досвіду та відповідальності за вчинки. Недосвідчені лідери можуть не відчувати себе впевнено при ухваленні рішень без
підтримки колег.

● Культурні особливості компанії. У деяких компаніях може бути заведено колективне ухвалення рішень, що може спонукати лідера до надмірної залежності від зворотного зв’язку.

Постійне очікування зворотного зв’язку уповільнює процеси та може призвести до втрати можливостей. Фахівці можуть відчувати перевантаження від постійних запитів на зворотний зв’язок, що відволікає їх від основних завдань. Команда може почати сумніватися у компетентності та рішучості свого лідера.

Як цьому запобігти?

1. Вибудуйте чіткі процеси ухвалення рішень. Визначте, які рішення ви можете делегувати, а які повинні ухвалювати самостійно. Розробіть чіткі критерії та принципи, які допоможуть ухвалювати обґрунтовані рішення. Просіть зворотний зв’язок щодо важливих питань, але ухвалюйте оперативні рішення самостійно.

2. Беріть відповідальність за свої рішення. Аналізуйте успіхи та помилки, щоб краще розуміти свої сильні й слабкі сторони. Розумійте, що помилки — це частина процесу навчання та розвитку. Бажано не наступати на ті ж «граблі» знову і знову, але право на помилку є у кожного.

3. Розвивайте культуру довіри та демонструйте впевненість. Вона буде передаватися команді й підвищить її довіру до вас. Цінуйте думки команди, але не дозволяйте їм паралізувати вашу здатність діяти. Якщо ви впевнені у рішенні на 70%, дійте. Часом краще ухвалити рішення із неповною інформацією, ніж не ухвалитти його взагалі.

Тренуйтеся ухвалювати швидкі рішення в менш важливих ситуаціях, щоб розвинути цю навичку. Отримуйте зворотний зв’язок після ухвалення рішення, щоб вчитися і вдосконалюватися, але не перед ним. Залежність від зворотного зв’язку може стати серйозною перешкодою на шляху до ефективного лідерства й успіху команди.

Важливо знайти баланс між залученням команди та здатністю ухвалювати самостійні рішення. Розвиваючи впевненість у собі, встановлюючи чіткі процеси та критерії ухвалення рішень, лідер може подолати цю проблему.

Лідерство — це не лише про те, щоб бути популярним або завжди мати підтримку, але й про відповідальність за ухвалення рішень, які ведуть команду вперед. Ваша рішучість і здатність діяти надихатимуть команду, підвищуватимуть її ефективність та сприятимуть досягненню спільних цілей.
Кожен із цих пунктів підкреслює важливість балансу в лідерстві.

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

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Ці зміни стали особливо помітними з появою в Україні концепції IT-аутсорсингу. За кордоном передача обслуговування IT-інфраструктури стороннім компаніям вже давно стала нормою для бізнесів сегменту SMB (малий і середній бізнес).

В Україні цей вид сервісу перебуває на етапі стрімкого зростання. Ще 5 років тому IT-аутсорсинг був маловідомим серед широких бізнес кіл, проте сьогодні ситуація кардинально змінилася.

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

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

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

Переваги IT-аутсорсингу

Компанії все частіше вибирають IT-аутсорсинг через очевидні переваги:

1. Фокус на бізнесі

Аутсорсинг дозволяє підприємству сконцентрувати свої зусилля на основних бізнес-процесах, не відволікаючись на вирішення технічних завдань.

2. Оптимізація витрат

Замість того щоб утримувати штат IT-фахівців, компанія отримує можливість гнучко керувати витратами на обслуговування IT-інфраструктури.

3. Зниження ризиків

Аутсорсингові компанії беруть на себе частину відповідальності за стабільність роботи IT-систем, що знижує ризики для бізнесу.

Конкурентна перевага аутсорсингових компаній

Однією із ключових переваг аутсорсингових компаній є доступ до колективного досвіду. Штат таких компаній зазвичай складається із фахівців різних профілів, що дозволяє ефективно вирішувати широкий спектр завдань. У нас, наприклад, до реалізації складних завдань долучаються спеціалісти із 20-річним досвідом роботи.

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

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

Стандарти якості IT-аутсорсингу

Зростання конкуренції на ринку формує стандарти якості, дотримання яких є обов’язковим для успішного функціонування IT-аутсорсингової компанії. Розглянемо основні з них:

1. Система прийому та обробки заявок

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

2. Система моніторингу обладнання

Аутсорсингові компанії використовують системи моніторингу для відстеження стану техніки та оперативного реагування на збої. Чим швидше виявлена проблема, тим менше простоїв у роботі бізнесу.

3. Швидке реагування

Один із важливих стандартів — забезпечення виїзду спеціаліста на територію замовника протягом 1–2 годин із моменту виникнення несправності.

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

4. Використання системи віддаленого адміністрування

Системи віддаленого адміністрування дозволяють вирішувати понад 60% технічних проблем упродовж кількох хвилин, що значно підвищує ефективність роботи IT-сервісу.

Висновки

IT-аутсорсинг — це не лише сучасний тренд, а й стратегічний вибір для компаній сегменту SMB. Він дозволяє знизити витрати, підвищити якість обслуговування та мінімізувати ризики, пов’язані з управлінням IT-інфраструктурою.

Вибираючи досвідченого та надійного партнера, бізнес отримує змогу зосередитися на своєму основному завданні — розвитку та зростанні.

Також ми радимо прописувати у договорі SLA (Service Level Agreement), у якому обумовлюється рівень сервісу (час реакції та вирішення), який сервісна компанія зобов’язується надати вам. За невиконання умов SLA передбачено штрафи.

Можна провести і попередній аудит ІТ-інфраструктури та виявити вигоду співпраці на річному контракті з абонентського обслуговування в аутсорсера або утриманні власної штатної команди.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Надважливо — готувати команду. Люди мають бути лояльними до змін, а ще краще рушіями цих змін. Вмотивовуйте команду проактивно рухати проєкт, готуватися до зустрічей, вивчати проєктну документацію і проходити тренінги. Тоді перехід на нову ERP-систему буде м’яким і результативним для компанії.

Навіщо ERP-система ІТ-компанії?

Якщо говорити про ERP-системи загалом, то з одного боку системи цього класу надають компаніям певні переваги: більш цілісну картину прибутковості бізнесу, запроваджують принципи аудійованості облікових даних, знижують ризик «людського фактору» при обліку, надають більшої контрольованості. З іншого боку, широко відомо, що впровадження комплексних ERP-систем є досить складною задачею і потребує від компаній визначення власних вимог до обліку та наявності кадрових і фінансових ресурсів.

Такі характеристики ERP-систем можуть не дуже в’язатися із самим характером IT-компаній, які часто починають свій шлях як стартапи й тривалий час свого життя залишаються в такому стані.

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

Який стан обліку в ІТ-компаніях зазвичай

Звісно, всі компанії так або інакше мають облікові інструменти. У відносно невеликих гравців облік ведеться за допомогою суміші гугл- або ексель-таблиць, іноді частково використовуються умовно бесплатні та досить прості за функціоналом облікові системи на кшталт QuickBooks, Xero, Zoho Books. Дехто розробляє власні системи, спираючись на той факт, що в компанії є розробники.

У більших гравців, що давно на ринку, питання з ERP може бути вирішено. Нерідко вони впроваджували такі системи власними силами, оскільки мали власну ERP практику та in-house команду.

Наприклад, EPAM є історично потужним партнером SAP, відповідно, компанія впровадила і давно використовує саме цю ERP. Ciklum свого часу обрав Microsoft Dynamics NAV (тепер Dynamics 365 Business Central) і після впровадження започаткував цю ж практику у себе. Хоча з часом її припинив, але система залишилась і досі служить компанії.

Що ж спонукає IT-компанії залишити стартаперський запал, полишити гугл- таблиці з вірним QuickBooks і вирушити у складну мандрівку ERP-проєктом?  Базовою причиною є масштабування бізнесу.

Як ERP допомагає ІТ-бізнесу зростати?

Річ у тім, що зростання IT-компанії відбувається в кількох напрямках: збільшується людський ресурс, з’являється більше замовників, відповідно, ускладняється організаційна і юридична структура. Вчора це була одна юридична особа в одні країні, сьогодні — це кілька компаній у різних юрисдикціях.

Архітектура взаємодії зі співробітниками стає нетривіальною. Частина членів команди може бути штатними співробітниками, частина — контракторами, і, з огляду на кількість юридичних осіб, збільшуються ланцюжки розрахунків із персоналом. На це накладається валютний облік із курсовими різницями.

Також сценарії отримання виручки виходять на новий рівень. Коли йдеться про IT-компанії, умовно їх можна поділити на дві категорії: сервісні та продуктові. Це впливає на облікову політику і, відповідно, на вимоги щодо функціоналу ERP-систем. Хоча в багатьох аспектах потреби у цих двох категоріях компаній однакові.

Особливості обліку в ІТ-компаніях

Для сервісних IT-аутсорсингових компаній актуальним є облік годин (або інших одиниць виміру: дні, місяці, вартість роботи команди), які продаються різним замовникам від різних джерел.

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

За такого сценарію потрібно отримати дані про витрачені одиниці часу команди на проєкті, сформувати коректний інвойс замовнику, а також інвойси по ланцюжку для сплати отриманих послуг від компаній нашого холдингу, від яких ми залучали фахівців у загальну команду для німецького замовника. Частина членів команди може бути штатними працівниками, а частина — контакторами.

У цьому досить типовому прикладі переплітаються управлінський і локальні обліки. Управлінський облік дає прозору картинку так, наче у вас немає тої великої кількості юридичних осіб, від яких залучаються ресурси, і ви бачите одну зв’язку «проєкт клієнта — надані послуги». Локальні обліки всіх залучених юридичних осіб у цьому проєкті потрібні, щоб мати коректні бухгалтерські дані та облік відповідних податків.

Для наведеного прикладу потрібно автоматизувати всі ланцюжки перетворень одних транзакцій в інші і водночас мати інструмент для відображення внутрішньохолдингових операцій (intercompany) і побудови консолідованої звітності.

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

Схожа історія із продуктовими IT-компаніями. Не важливо, що є продуктом — програмне забезпечення (якийсь застосунок) або пристрій чи обладнання. Продаж продукту відбувається по багатьох каналах (мерчантах), тому постає питання щодо обліку доходів у розрізі різних юридичних осіб із різних країн і локацій, у різних валютах. При цьому система має зручно забезпечити облік доходів для різних типів продажів — від звичайного ціноутворення, типового для виробника/дистрибутора обладнання, до схем підписок, якщо йдеться про продаж ліцензій.

Складна та насичена ІТ-екосистема

Додатковим викликом для реалізації впровадження ERP-системи в IT-компаніях стає інтеграція з іншими системами. Серед розповсюджених інтеграцій:

1. Отримання даних про облік годин співробітників. Це можуть бути трекінгові системи власної розробки або системи на кшталт Jira та Azure DevOps. 

2. Маленькі системи локального обліку. Можливо, такі, в яких працюють бухгалтери на аутсорсі в деяких віддалених офісах.

3. Платіжні та банківські системи, а також інтеграція з маркетплейсами, через які продають власні застосунки IT-продуктові компанії.

4. Інші системи. Наприклад, управління персоналом і CRM.
 
Список не вичерпний. Методи інтеграцій також. Важливо, щоб нова ERP- система підтримувала сучасні (а іноді й не дуже, якщо є вимога побудувати інтеграцію з якимось досить давнім рішенням) методи обміну даними.

Як впровадити ERP, що релевантна вашим потребам?

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

Наприкінці хочемо навести універсальні поради, якщо ви на порозі вибору нової ERP-системи:

1. Щодо вибору певної ERP-системи. Сприймайте її як таку, з якою вам прийдеться працювати багато років. Чи є за нею надійний вендор, чи є достатньо фахівців на ринку, чи присутній цей продукт в інших країнах, чи містить у своїй базовій поставці перелічені функції: фінансова консолідація, можливість поєднати локальний і управлінський облік, облік проєктних робіт із різними ставками часу, можливість біллінгу підписок тощо. Чи легко система модифікується та які є показники масштабування, якщо говорити про великі обсяги транзакцій.

2. Уважно придивіться до команд партнерів із впровадження, з якими плануєте виконання проєкту. Отримайте відгуки, бажано по ринку власними незалежними джерелами.

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

3. Насамкінець підійдіть ретельно до формування обсягу проєкту. Коли створюється оцінка майбутнього проєкту (вартість і тривалість), то важливо мати адекватне уявлення щодо того, які вимоги є наразі. І це уявлення потрібно передати партнеру із впровадження.

Гарним кроком тут буде витратити трохи додаткового часу і бюджету на мініпроєкт із діагностики (так званий Discovery або «пілот»). Це допоможе більш чітко розрахувати ваш майбутній обсяг проєкту. Ви отримаєте реалістичну оцінку і зважено поставитеся до підготовки ресурсів — власної команди та бюджету на фінансування проєкту.
 
За даними тогорічної статистики, українська IT-спільнота генерує 4,5% ВВП України та становить 12% у загальному експорті. У нашій практиці значно побільшало запитів на впровадження ERP саме від ІТ-сегменту, а це означає, що IT-компанії у своєму життєвому циклі виходять на той рівень масштабу, який потребує ERP-систему.

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

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

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Уявіть ситуацію: вам дістався код, у якому немає ані структури, ані розуміння, де й як шукати певні частини коду, куди вносити зміни. «‎Змучена» папка компонентів нагадує перелік слів із тлумачного словника, але без жодного визначення, що означає кожен зі складників.

Ні, це не старий проєкт, він тільки нещодавно вийшов у продакшн. Ви отримали завдання від замовника: покращити та збагатити застосунок новими фічами. Відкриваєте його, а там — і хаотично розкидані по різним дерикторіям файли, і дублікати коду, яких мали позбутися «‎ще вчора». Починаєте думати, як тут навести лад, гуглите… І згодом натрапляєте на описи різних методологій, які частково або повністю можуть вирішити ваші проблеми. То що ж обрати?

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

Переваги архітектурних методологій

Простота у використанні, розширенні та підтримці коду

З використанням того чи іншого підходу зʼявляється можливість організувати весь застосунок у вигляді окремих незалежних частин. Розробник може не турбуватися, чи впливатимуть подальші зміни у коді на роботу інших частин системи.

Додавати новий функціонал також буде простіше, адже вся команда однаково розумітиме, куди та як вносити зміни. Розробники будуть притримуватись архітектурних рішень і правил. Кожен працюватиме з логічно відокремленою, визначеною згідно обраної архітектури частиною проєкту. Наприклад, модулем, компонентом або файлом.

Повторне використання коду

Відокремлення функціоналу з використанням певної структури та правил дозволяє легко використовувати його в окремих частинах застосунку або навіть за межами проєкту.

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

Доступність для нових членів команди

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

Полегшення тестування коду

З чіткою архітектурою зʼявляється можливість протестувати кожен модуль окремо, що робить тестування контрольованим і зменшує ризик виникнення помилок.

Масштабованість коду

Незалежні частини програми легше змінювати та розширювати без необхідності вносити зміни до всього коду. Всі учасники команди можуть бути одночасно задіяні в роботі над певною частиною застосунку, маючи мінімальну залежність один від одного.

Недоліки архітектурних методологій

Додаткові часові витрати

Створення абстракцій, додатковий код для налаштування комунікації між різними частинами системи, старт проєкту та підтримка всіх умов обраної архітектури — все це потребує чимало додаткових годин.

Складно для початківців

Junior-розробнику, скоріш за все, буде складніше влитися у проєкт, адже деякі правила, умови та обмеження можуть бути незрозумілими та неочевидними для нього.

Джунам важче розібратися зі складними концепціями. Відповідно, їм потрібно більше часу на адаптацію та онбординг у проєкті. Не виключаємо і можливі помилки на початку роботи.

Щоб досягти зазначених переваг, розробники постійно вдосконалювали структуру своїх у своїх проєктах. Згодом стало зрозуміло, що напрацювання команди з одного проєкту можна використати в іншому або поділитися ними з колегами з іншого проєкту. Так почали зʼявлятися самостійні архітектурні методології, які поступово набирали популярності й завоювали нових прихильників серед розробників.

Розібравши переваги та недоліки використання архітектурних підходів, пропоную перейти до прикладів.

Різновиди архітектурних методолій

Модульна архітектура

Одна з найбільш поширених методологій, проста у використанні. В такій архітектурі застосунок розділяють на різні рівні, де кожен має свою роль і відповідальність. Ось як це виглядає:

Розглянемо кожний елемент окремо.

Pages (Сторінки): рівень сторінок відповідає за відображення модулів, не маючи в собі бізнес-логіки. Наприклад, сторінка входу в застосунок передбачатиме відображення таких модулів, як «‎шапка», футер застосунку та форма входу.

Modules (Модулі): це ядро логіки застосунку. Модулі обробляють помилки, працюють з API, відповідають за бізнес-логіку, зберігають власний стан та мають свої константи чи утиліти, які використовує компонент.

Вони мають певну структуру, що реалізує концепт публічного API за допомогою індекс-файлу, що своєю чергою експортує тільки ті частини модуля, які ви зробите доступними. Це і реалізує принцип інкапсуляції, якщо провести аналогію з ООП.

Прикладами тут можуть бути форма входу в застосунок або список продуктів. Модулі працюють незалежно один від одного і не взаємодіють напряму з іншими модулями.

Components (Компоненти): це елементи, що можуть містити певну логіку, але на відміну від модулів не реалізують специфічну функціональність. Наприклад, компонент картки товару може обробляти події або відображати передані в нього дані.

UI (Компоненти інтерфейсу): рівень UI включає базові елементи інтерфейсу: кнопки, поля введення, підказки тощо. Це невеликі компоненти, які використовуються як будівельні блоки в інших частинах програми.

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

Переваги модульної архітектури:

• Ізоляція модулів за допомогою публічних API: кожен модуль має свій індекс-файл, який експортує лише ті функції та компоненти, які необхідні ззовні. Це знижує ризик ненавмисного втручання в логіку інших модулів.
• Повторне використання модулів: завдяки чітко визначеній структурі модулі згодяться для повторного використання в окремих частинах застосунку або в різних проєктах.
• Легкість у видаленні модулів: завдяки ізоляції можна видалити або замінити окремий модуль без значних змін у всьому застосунку.
• Гнучкість використання feature flags: модулі просто включити або відключити за допомогою feature flags, а це спрощує розгортання нових функцій.

Щодо недоліків, то маємо такі:

• Модулі не можуть напряму використовувати інші модулі. Це обмеження викликає труднощі, коли модулі потребують обміну даними або встановлення залежностей між ними.
• Складно визначити, куди помістити код: розробники можуть зіткнутися з дилемою: чи має певний функціонал належати до модуля, чи краще, щоб він залишався окремим компонентом.
• Глобальні змінні та стан: хоча цей різновид архітектури орієнтований на ізоляцію, все одно можуть існувати глобальні константи чи стан (наприклад, загальний глобальний store), які використовуються по всій програмі.

Модульну архітектуру можна застосовувати у проєктах будь-якої складності та в різноманітних за чисельністю командах.

Існує й інший підхід, складніший порівняно з модульним, але з власною документацією і навіть спільнотою. Архітектура, яку розглянемо далі, підійде як для середніх, так і для великих команд і проєктів.

Atomic Design

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

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

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

Структура рівнів в архітектурі Atomic Design має такий вигляд:

Atoms (Атоми): основні, найдрібніші одиниці інтерфейсу, які не можна розділити далі. Не містять складної логіки або взаємодій і використовуються для створення більших компонентів. Атоми є базовими компонентами інтерфейсу. Наприклад, кнопка або поле вводу.

Molecules (Молекули): комбінації атомів, які працюють разом як єдиний функціональний блок. Це компоненти середнього рівня, які можуть містити просту логіку. Вони мають інкапсулювати та виконувати просту задачу. Наприклад, поле вводу з текстовим лейблом до нього.

Organisms (Організми): складніші компоненти, що складаються з молекул та атомів, утворюючи функціональні блоки інтерфейсу. На цьому рівні зазвичай присутня бізнес логіка. Організми зазвичай відповідають за значну частину UI. Наприклад, навігаційні панелі, таблиці або картки.

Templates (Шаблони): рівень шаблонів відповідає за розташування організмів на сторінці. Вони визначають структуру інтерфейсу без конкретного наповнення даними. Тобто по суті шаблони є прототипом майбутньої сторінки вашого застосунку. Саме тут визначається позиціонування функціональних блоків сторінки. Наприклад хедеру, футеру або сайдбару з навігацією.

Pages (Сторінки): цей рівень наповнює шаблони конкретним контентом. Сторінки відображають кінцевий вигляд інтерфейсу з усіма даними та стилями, які будуть відображені користувачу.

Для зберігання загальних ресурсів, конфігурації, констант можна створювати додаткові директорії на вищому рівні.

Архітектура Atomic Design має такі переваги:

• Легко зорієнтуватися в коді: чітка структура полегшують розуміння коду та навігацію по проєкту.
• Гнучкість: виходить просто додавати, видаляти або замінювати окремі частини застосунку.
• Легка підтримка: зміни в базових компонентах автоматично відображаються на всьому інтерфейсі.
• Масштабованість: сприяє масштабуванню як застосунку, так і команди розробників.

Серед недоліків:

• Орієнтованість на UI: методологія більше фокусується на інтерфейсі, а не на бізнес-логіці.
• Додаткові часові витрати: підхід вимагає додаткових витрат на створення абстракцій у вашому застосунку, таких як шаблони.

Згадані у статті методології та інші приклади, які ви можете зустріти в інтернеті, на перший погляд здаються складними тим, хто раніше не стикався з подібними рішенням для організації архітектури на проєкті. Однак опанування цих підходів неодмінно стане вам у пригоді та допоможе в рутинних задачах. А з ними точно стикається кожен розробник: це і формування структури проєкту, і правильне розташування та повторне використання коду.

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

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Експерти ІТ-команди NIX зібрали варті уваги книги для Java-розробників із різним досвідом.

Книги для Junior Java Developer

Clean Code: A Handbook of Agile Software Craftsmanship

Автор: Robert C. Martin.

Українська назва: «Чистий код: Створення і рефакторинг за допомогою Agile».

Роберт Мартін на прізвисько Дядько Боб (Uncle Bob) є знаковою фігурою для розробки ПЗ. Цей інженер та програміст народився в 1952 році та вже у 17 років почав займатися програмуванням.

За своє життя він реалізував сотні проєктів на Java та інших мовах, долучився до створення Agile-маніфесту і є автором підходу SOLID, який знайомий кожному сучасному розробнику.

Дядько Боб написав понад десяток книг по Java, C++ і C# та загальні принципи із програмування. Саме до останніх належить Clean Code. У ній автор послідовно розкриває, чому важлива чистота коду.

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

The Pragmatic Programmer: From Journeyman to Master

Автор: Andrew Hunt, David Thomas.

Українська назва: «Програміст-прагматик».

Ендрю Хант разом із Девідом Томасом написали понад десяток книг по Java для початківців та інших технологіях і заснували серію The Pragmatic Bookshelf про прагматичні підходи до програмування.

Також вони були співавторами Agile-маніфесту та авторами багатьох відомих в IT-розробці понять. Як, наприклад, DRY, метод каченяти або Code Kata.

The Pragmatic Programmer — це не Java-книга в чистому вигляді. Вона була першою роботою авторів і багато в чому революційною.

У книзі Хант і Томас зібрали багато корисних порад для новачків, які допоможуть писати мовою Java гнучкий і динамічний код, уникати помилок у коді або логіці, налагоджувати стабільне тестування тощо.

Книга написана в легкому стилі. У ній багато прикладів із практики, цікавих аналогій і навіть анекдотів. У 2019 році було випущено оновлене видання, в якому автори актуалізували більшу частину матеріалу. Тож книга відповідає сучасним стандартам програмування на Java.

Head First Design Patterns: A Brain-Friendly Guide

Автор: Eric Freeman, Elisabeth Robson, Bert Bates, Kathy Sierra.

Українська назва: «Head First. Патерни проєктування».

Кожен із чотирьох авторів має чим похвалитися. Ерік Фріман займав позицію CTO в Disney Online, Елізабет Робсон заснувала освітню платформу WickedlySmart, а Кеті Сієрра та Берт Бейтс фактично й створили серію Head First. Це посібники для початківців, де наука об’єднується з яскравою візуалізацію, цікавими історіями, головоломками й живим гумором.

У вказаній серії існує ще одна книга по Java (йдеться про Head First Java), але у підбірку варто додати саме Design Patterns.

Книга потребує певних знань, але є гарним міксом з універсальних питань про програмну інженерію і програмування Java. У ній детально розбираються характерні шаблони проєктування програмного забезпечення, яке буде гнучким, надійним, масштабованим і функціональним. І все це — на реальних прикладах коду в Java API та вбудованої підтримки патернів мови.

Head First Design Patterns стала справжньою класикою, яка ані трохи не застаріла, адже у 2020 році вийшло оновлене видання.

Книги для Middle Java Developer

Effective Java

Автор: Joshua Bloch.

Українською книга не видавалася.

Джошуа Блох — це гуру в Java. За його плечима досвід роботи на керівних посадах у Google та Sun Microsystems, але головне надбання — участь у створенні самої мови Java (особливо JDK 5.0).

Так, Джошуа спроєктував фреймворк Java Collections, пакети java.math, механізм assert. А ще — написав чи не головне видання серед Java-книг.

Йдеться про Effective Java, яка здобула кілька галузевих премій і пережила вже два оновлення (у 2008 та 2017 роках). Головна цінність полягає у тому, що ця книга дає максимально всебічну презентацію теми для початківців і тих, хто має певний досвід на Java.

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

Також Блох показує, як уникати характерних помилок. Ця книга по Java у кожній із глав містить невелике есе із прикладами коду, які допоможуть вам краще розуміти логіку такого програмування.

Java Performance: In-Depth Advice for Tuning and Programming Java 8, 11, and Beyond

Автор: Scott Oaks.

Українською книга не видавалася.

За плечима у Скотта Оукса — багаторічна робота архітектором у Sun Microsystems та Oracle Corporation.

Хоча він доклав зусилля до багатьох проєктів (зокрема до програмування ядра операційки SunOS і RPC для систем Windows), головну увагу у своїй кар’єрі він спрямував безпосередньо на Java. Він є справжнім «євангелістом» цієї мови та написав кілька книг про неї.

Чи не найбільш популярна його робота як письменника — Java Performance. Ця Java-книга з’явилася у 2014 році та була оновлена у 2020 році. Вона обов’язкова для всіх, хто прагне отримати максимум продуктивності від Java-застосунків. При цьому особливий акцент зроблено на ефективному використанні JVM.

Оукс ретельно розбирає все, що позначається на швидкості: налаштування віртуальної машини, використання JDK, проблеми в API Java, роботу з базами даних, вплив збирача сміття, продуктивність Jit-компіляторів тощо. Також докладно розписує принципи тестування продуктивності.

High-Performance Java Persistence

Автор: Vlad Mihalcea.

Українською книга не видавалася.

Влад Михальча 11 років веде блог про Java, JPA, Spring і бази даних, проводить тренінги по продуктивності застосунків, написав понад 300 туторіалів по SQL і Hibernate. До речі, до останнього проєкту Михальча й сам доклав чимало зусиль як розробник.

У своїй книзі High-Performance Java Persistence автор надає багато корисної інформації про те, як застосунки взаємодіють із базами даних і як цю взаємодію покращити.

Вказана книга по Java розділена на три частини. У першій автор розповідає про реляційні БД як такі, роботу інтерфейсу JDBC, управління з’єднанням, кешування операторів тощо.

Друга частина присвячена JPA та Hibernate. Михальча показує, як, наприклад, механізми вилучення та управління паралелізмом підвищують продуктивність програм, написаних мовою Java.

У третій частині книги надано всю інформацію про бібліотеку jOOQ — від DML-операторів до збережених процедур.

Книги для Senior Java Developer + Software Architect

Designing Data-Intensive Applications: The Big Ideas Behind Reliable, Scalable, and Maintainable Systems

Автор: Martin Kleppmann.

Українською книга не видавалася.

Колись Мартін Клеппман був розробником масштабованих інфраструктур даних у великих компаніях, зокрема LinkedIn і Rapportive. Останніми роками він працює у Кембридзькому університеті дослідником розподілених систем, постійно виступає на конференціях про програмування, є блогером та учасником кількох OpenSource-проєктів на Java й інших мовах.

Книга Designing Data-Intensive Applications — це послідовний аналіз різноманітних технологій обробки та зберігання даних.

Автор показує, як створювати системи даних, які здатні витримувати потік мільйонів юзерів. Розбирає, як мінімізувати час простою застосунків. Роз’яснює, як зробити систему даних простішою в обслуговуванні навіть після змін вимог або технологій.

Важливо розуміти: це не ще одна Java-книга з покроковими інструкціями. Наприклад, для розгортання пакетів. Ціль Клеппмана — дати розуміння архітектури систем даних та їхньої інтеграції у кінцевий продукт.

Grokking Algorithms: An Illustrated Guide for Programmers and Other Curious People

Автор: Aditya Bhargava.

Українська назва: «Грокаємо алгоритми: ілюстрований посібник для програмістів і допитливих».

Адіт’я Бхаргава має дві вищі освіти: інженера комп’ютерних технологій і спеціаліста у сфері мистецтв, тож все життя поєднує їх.

З одного боку, Бхаргава пише ігри на Basic із 14 років, працює у стартапах і викладає курс «Вступ до Python». З іншого, віддає перевагу таким проєктам про арт, як Etsy, де він є штатним інженером.

Автор вдало комбінує програмування та дизайн. На відміну від багатьох книг про Java, ця містить понад 400 оригінальних і кумедних ілюстрацій. Хоча головне, звичайно, зміст.

Книга простою і зрозумілою мовою розповідає про використання складних алгоритмів під час розв’язання типових задач у розробці.

Бхаргава охоплює безліч прикладів: від пошуку та сортування даних до їх стискання й використання в AI-системах. Усе це доповнюють діаграми, графіки та приклади коду.

Останні, щоправда, на Python, але це видання настільки цікаве, що його не можна не включити в перелік кращих книг для вивчення Java.

У вивченні Java не обмежуйтеся лише перерахованими книгами. Читайте будь-яку цікаву вам літературу: про розробку, менеджмент, роботу в команді. Адже тільки з різноманітними знаннями можна дійсно зростати в ІТ.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Camunda — це потужна платформа для моделювання та автоматизації бізнес-процесів, яка використовує стандарт BPMN (Business Process Model and Notation) 2.0. Вона дозволяє компаніям ефективно візуалізувати та реалізувати робочі процеси, що значно спрощує управління ними.

У цій статті ми розглянемо, чому Camunda BPMN є незамінним інструментом для бізнесів, які прагнуть до оптимізації своїх процесів.

Що таке Camunda?

Camunda — це open-source BPMN платформа для керування бізнес-процесами, яка підтримує DMN (Decision Model and Notation). Платформа пропонує гнучкість, швидкість реалізації та можливість інтеграції із системами, які вже функціонують у компанії.

Основні елементи BPMN дозволяють детально моделювати бізнес-процеси. Camunda забезпечує автоматизацію завдань та управління робочими потоками, що підвищує ефективність і знижує витрати.

Елементи BPMN

BPMN 2.0, або Business Process Model and Notation, — це стандарт моделювання бізнес- процесів, розроблений для візуалізації та автоматизації робочих процесів.

BPMN 2.0 надає набір символів, який дозволяє бізнес-аналітикам і розробникам чітко описувати послідовності задач, подій і рішень, щоб полегшити взаємодію між бізнесом і технічними фахівцями. Camunda, наприклад, використовує BPMN 2.0 для створення ефективних і наочних бізнес-процесів, підтримуючи інтеграцію з різними системами та мікросервісами.

BPMN-діаграми складаються з таких основних елементів:

1. Об’єкти потоку. Включають дії (tasks) і події (events), які визначають завдання чи моменти, які ініціюють, змінюють або завершують процес. Дії представляють конкретні завдання, а події сигналізують про їх початок, завершення чи інші стани.
2. Поєднуючі елементи. Використовуються для потоку керування (flow), що з’єднує об’єкти між собою. Наприклад, стрілки показують напрямок послідовності.
3. Ролі. Представлені через «пули» (pools) і «доріжки» (lanes). Пули — це основні учасники процесу, а доріжки уточнюють ролі або департаменти всередині пулів.
4. Артефакти. Включають документи й дані, що доповнюють процес. Це додаткові елементи для кращого розуміння й організації процесу.

Ці компоненти допомагають створювати наочні та зрозумілі BPMN-діаграми для ефективної комунікації бізнесу й технічних спеціалістів. Вони дозволяють моделювати як прості, так і складні процеси, забезпечуючи узгодженість і зрозумілість для всіх учасників.

Camunda 8 організовує складні бізнес-процеси, які охоплюють людей, системи та пристрої. З Camunda бізнес-користувачі співпрацюють із розробниками для моделювання й автоматизації наскрізних процесів за допомогою блок-схем на основі BPMN, а також таблиць рішень DMN, які сприяють швидкості, масштабуванню та логіці ухвалення рішень.

Компоненти Camunda 8

Camunda 8 включає шість компонентів, які разом створюють повноцінний робочий досвід для проєктування, автоматизації та вдосконалення бізнес-процесів:

1. Console. Це центральна програма для керування такими продуктами, як Modeler, Tasklist, Operate та Optimize.

За допомогою Camunda Console можна створювати та видаляти кластери, керувати клієнтами API для взаємодії з Zeebe і Tasklist, налаштовувати сповіщення про помилки робочого процесу, обмежувати доступ за допомогою списків дозволів IP, контролювати управління організацією і використовувати API адміністрування (REST) для програмного керування кластерами.

2. Modeler — інструмент для проєктування та налаштування BPMN, що необхідно для будь-якого процесу. BPMN-діаграми візуально представляють потік процесу, роблячи робочі процеси більш зрозумілими для зацікавлених сторін.

У Camunda користувачі можуть налаштовувати події, умови шлюзу та деталі сервісних завдань, щоб керувати механізмом робочого процесу при виконанні конкретних завдань.

Camunda Modeler доступний у двох форматах: Web Modeler, інтегрований з Camunda 8 SaaS і самокерованими інсталяціями, і Desktop Modeler, локально встановлений застосунок, який
дозволяє переглядати, редагувати та безперешкодно інтегруватися з локальними середовищами розробки.

3. Connector. Це багаторазовий компонент, який забезпечує інтеграцію із зовнішніми системами. Він необхідний для виконання завдань у робочих процесах, які вимагають взаємодії за межами Camunda.

У таких процесах, як організація завдань, коннектори сповіщають учасників за допомогою таких інструментів, як Slack або Teams.

Представлені у вигляді завдань BPMN, коннектори дозволяють користувачам налаштовувати інтеграції без власного коду, пропонуючи доступний, багаторівневий досвід кодування для користувачів із різним рівнем технічних навичок.

4. Zeebe — основний рушій автоматизації Camunda 8, розроблений для масштабованої автоматизації процесів. Він дає змогу користувачам графічно визначати процеси BPMN 2.0 та інтегруватися з системами обміну повідомленнями, такими як Apache Kafka.

Zeebe можна використовувати як частину SaaS від Camunda або розгортати через Docker і Kubernetes, підтримуючи як хмарні, так і локальні середовища.

Відомий своїм горизонтальним масштабуванням, відмовостійкістю та високою доступністю, Zeebe полегшує моніторинг та аналітику завдяки експорту даних і потужній підтримці спільноти для керівництва й девелоперів.

5. Operate. Це інструмент для моніторингу й усунення несправностей у процесах Zeebe, що дає змогу бачити як активні, так і завершені елементи процесу. Він підтримує такі операції, як вирішення інцидентів, оновлення змінних процесу, а також повторний запуск або скасування кількох елементів одночасно.

Крім того, Operate дозволяє користувачам видаляти завершені процеси та змінювати активні для продовження виконання й пакетно переміщувати для полегшення безперебійного управління потоком
процесів.

6. Tasklist. Це готовий до використання застосунок в Camunda для управління бізнес-процесами, які включають завдання користувачів, що робить його ідеальним для організації людських робочих процесів.

За допомогою Tasklist користувачі можуть отримувати сповіщення про призначені завдання після розгортання процесу в Zeebe та виконувати їх.

Він має REST API для запиту завдань і змінних, що дозволяє інтегруватися з користувацькими застосунками або розширеннями.

Цей API у поєднанні з API Zeebe дозволяє призначати, оновлювати та завершувати завдання, спрощуючи оркестровку процесів за допомогою зручного інтерфейсу.

Як розробники й аналітики можуть використовувати Camunda?

Розробники й аналітики можуть використовувати Camunda для ефективного управління процесами, автоматизації завдань і гнучкої інтеграції з іншими системами, такими як CRM та ERP.

Основні можливості платформи:

● Підтримка BPMN 2.0. Інструмент для стандартизованого моделювання бізнес-процесів, що дозволяє зручно візуалізувати й оптимізувати їх.

● Оркестрація робочих процесів. Camunda допомагає координувати завдання між різними учасниками та підрозділами, забезпечуючи безперебійний процес навіть у складних сценаріях.

● Автоматизація бізнес-процесів. Автоматизуючи рутинні завдання, Camunda мінімізує людські помилки та збільшує ефективність, що дозволяє працівникам зосередитися на більш пріоритетних задачах.

● Процесна аналітика. Аналітичні інструменти Camunda дозволяють відстежувати ефективність процесів у реальному часі, що сприяє швидкій реакції на затримки чи неефективність.

● Гнучка інтеграція через API. Потужний API дозволяє інтегрувати платформу з CRM та ERP-системами, забезпечуючи синхронізацію даних і безперебійну передачу інформації.

Завдяки підтримці REST і GraphQL API Camunda легко підключається до інших систем і підвищує рівень автоматизації бізнесу. Camunda стає важливим інструментом для компаній, які прагнуть оптимізувати процеси, інтегруватися з іншими системами та покращити загальну продуктивність.

Чому варто використовувати Camunda?

Camunda пропонує безліч переваг, які роблять її однією з найкращих платформ для управління бізнес-процесами:

1. Гнучкість. Camunda легко адаптується до динамічних ринкових умов та унікальних потреб бізнесу. Вона дозволяє компаніям налаштовувати процеси відповідно до специфічних вимог, що полегшує адаптацію до змін.

2. Швидкість. Camunda забезпечує ефективне впровадження рішень завдяки автоматизації. Це підвищує швидкість обробки процесів і знижує затримки, що в кінцевому результаті покращує продуктивність.

3. Open-source. Платформа безкоштовна у базовому доступі, що дозволяє уникнути великих витрат на ліцензування. Розробники можуть модифікувати її, налаштовуючи під конкретні задачі організації, що є особливо цінним для індивідуальних процесів.

4. Інтеграція. Camunda підтримує просте підключення до різних бізнес-систем, включаючи CRM та ERP, завдяки потужним API, що полегшує роботу з існуючими інструментами компанії. Інтеграція з REST та GraphQL API дозволяє легко зв'язати Camunda з іншими сервісами.

5. Продуктивність. На відміну від Bizagi чи Creatio, Camunda пропонує більше свободи для налаштування, автоматизацію рутинних процесів і гнучку інтеграцію, забезпечуючи баланс між простотою використання та функціональністю.

Порівняно з іншими BPM-системами, такими як Bizagi та Pega, Camunda відрізняється простотою використання, потужними функціями автоматизації та значними можливостями інтеграції, що робить її найкращим вибором для багатьох підприємств.

Приклад впровадження

UKRSIBBANK і Camunda

У 2021 році UKRSIBBANK BNP Paribas Group, розпочав трансформацію процесу видачі кредитів за допомогою Integrity Vision на основі Camunda, що дозволило усунути проблеми старих систем і ручних робочих процесів.

Проблема:

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

Рішення:

Впровадження робочого процесу кредитування на базі Camunda. Банк ухвалив рішення радикально скоротити час, необхідний для оформлення кредиту, у п’ять разів.

Необхідно було поставити клієнта у пріоритет, забезпечивши йому швидке отримання коштів. Це вимагало оптимізації процесу та залучення зусиль багатьох співробітників одночасно. Саме тому UKRSIBBANK за допомогою Integrity Vision вирішив реалізувати Camunda для автоматизації процесу видачі кредитів.

Основні переваги:

1. Уніфікація процесів. Створено єдине вікно для всіх активностей, що зменшило залежність від кількох систем і підвищило ефективність.
2. Стандартизація. Запроваджено єдиний процес кредитування, що забезпечило чітке розуміння ролей учасників і зменшило кількість помилок.
3. Покращення аналітики. Інформаційні панелі Camunda надають реальні дані про процес, що допомагає в управлінні й ухваленні рішень.

Результати:

У 2025 році UKRSIBBANK планує завершити міграцію на Camunda 8, що вже позитивно вплинуло на ефективність, клієнтське задоволення та мотивацію працівників.

Стандартизовані процеси скоротили час на виконання певних складних процесів із 28 до 12 днів із подальшим планом зменшити цей період до 5.

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

Висновки

Camunda 8 є потужним інструментом для автоматизації бізнес-процесів, який дозволяє компаніям оптимізувати свої операції, знизити витрати та підвищити загальну продуктивність.

З огляду на всі переваги, варто звернути увагу на цю платформу та її можливості. Співпраця з Camunda може стати вирішальним кроком на шляху до успіху вашого бізнесу.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Давайте подумаємо, як саме він здатен допомогти вам заробляти більше.

Переваги монетизації

Розширення ваших професійних навичок

Кожен Pet Project дає унікальну можливість вивчати нові технології, процеси та підходи. Ви вчитеся на реальних кейсах та експериментах, які не завжди можна застосувати в основній роботі. Це свого роду інвестиція у власні навички.

Коли ви володієте актуальними знаннями, вам значно легше отримувати вигідніші пропозиції від клієнтів або підвищення на роботі.

Додаткове джерело доходу

Pet Project може поступово перерости в бізнес або стати продуктом, який інші готові купувати.

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

Побудова особистого бренду

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

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

Можливість залучення інвестицій

Якщо ваш Pet Project виявиться успішним і цікавим для ринку, ви можете знайти інвесторів, які допоможуть масштабувати вашу ідею.

Багато успішних стартапів починалися саме як Pet Projects. Це ідеї, створені для себе, але з часом вони виросли у великі прибуткові компанії. Інвестиції дають змогу перетворити невеликий проєкт на глобальний бізнес, здатний приносити великий дохід.

Як Pet Project Partners допомагають у розвитку?

Pet Project Partners — це перша в Україні команда професіоналів, яка готова підтримати ваш проєкт на кожному етапі. Їхні знання та досвід допоможуть вам досягнути максимального успіху.

Вони можуть допомогти перетворити ваш Pet Project на бізнес, адже:

• Надають консультації з розвитку продукту, проаналізувавши ваш продукт, код, і підказати, як краще оптимізувати його, або навіть додати нові функції.
• Допомагають із маркетингом і запуском. Команда Pet Project Partners має знання про ринки, аудиторії, а також підходи до залучення користувачів, що може стати вирішальним для успіху проєкту.
• Для масштабування проєкту вам знадобиться команда. Тому ці фахівці мають великий досвід у створенні ефективних команд розробників, тестувальників, дизайнерів і менеджерів проєктів. Вони допоможуть вам знайти необхідні ресурси, щоб розширити свій проєкт.
• Pet Project Partners мають контакти з венчурними фондами й інвесторами, які можуть зацікавитися вашим проєктом. Вони допоможуть вам підготуватися до презентації перед потенційними інвесторами, скласти бізнес-план і фінансові прогнози.

Монетизація Pet Project — це не лише про гроші. Це про розширення можливостей, розвиток навичок, досягнення фінансової незалежності та створення впливу.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Ми в Tet також регулярно проводимо пен-тестування. Цей метод передбачає залучення так званих етичних хакерів і допомагає виявити вразливості корпоративних ІТ-програм і мереж. Як це працює і які ще переваги надає вказане інноваційне рішення, розглянемо нижче.

Тестування на проникнення є імітацією кібератаки та методів, які зловмисники можуть застосувати для доступу до корпоративної системи. Таким чином можна виявити вразливі місця ще до моменту, коли це зроблять кіберзлочинці.

Зазвичай тестування проводиться із залученням сторонніх сторін — компаній і спеціалістів у сфері кібербезпеки, які можуть допомогти бізнесу зміцнити захист важливої інфраструктури. Всередині Tet ми з командою працюємо in-house.

Як і кожен процес, пентест відбувається у кілька етапів. Кожна стадія дає змогу максимально ефективно виконати основне завдання — ідентифікувати чутливі до зламів елементи та якомога краще убезпечити їх.

Основні етапи:

Планування

На цьому етапі компанія визначає свої потреби, а також цілі й обсяги тестування.

Важливо «оглянути» кожен компонент інфраструктури, щоб переконатися у його безпеці та врахувати юридичні аспекти. Tet, до прикладу, у процесі планування створює чіткі принципи роботи для того, щоб пентест проходив ефективно та законно.

Збір інформації

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

Сканування

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

Злам

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

Аналіз

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

Фіналізація

На завершення готується докладний звіт про кожен етап реалізації тестування, а також про проблеми та вразливості системи, виявлені під час виконання імітованої кібератаки.

На цьому етапі прописується механізм запобігання таким атакам, а системи компанії повертають до первинного стану до тестування.

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

Під час пен-тестувань корпоративні команди з безпеки навчаються новому та мають змогу здобути корисні навички, які в майбутньому знадобляться для захисту під час імовірних кіберзагроз.

Виявлення слабких місць за допомогою пентесту дозволяє краще спланувати інвестиції в кібербезпеку та забезпечити надійний захист від неминучих атак.

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Відновлювати енергосистему треба на нових засадах: замінювати обладнання та інфраструктуру, автоматизувати всі процеси, зокрема контроль за споживанням і виробництвом. У цьому контексті інноваційні технології (EnergyTech) можуть стати критичним фактором перетворень.

Розумні мережі (Smart Grids): стійкість і безпека

Традиційна енергосистема України сильно централізована, що робить її вразливою до пошкоджень великих електростанцій і ліній передач. Розумні енергомережі можуть стати відповіддю на ці виклики.

Smart Grids дають змогу оптимізувати використання електроенергії, автоматично перерозподіляти навантаження й підключати локальні джерела енергії до загальної системи. Це значно підвищує стійкість системи та дає змогу швидше відновлювати електропостачання у разі аварій чи атак.

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

Додатково системи накопичення енергії, зокрема на базі літій-іонних акумуляторів, можуть згладжувати пікові навантаження та забезпечувати резервне живлення.

Південна Корея була в авангарді впровадження технології розумних мереж. В основі складної інтелектуальної мережевої інфраструктури країни лежить складна мережа програмних систем, які «оркеструють» симфонію ефективного управління електроенергією, реагування на попит та інтеграцію відновлюваних джерел енергії.

Ініціативи Південної Кореї щодо інтелектуальної мережі підвищили надійність мережі, зменшили втрати та підвищили енергоефективність.

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

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

У Європі маємо такий приклад у Данії, яка використовує Smart Grids для управління децентралізованою енергосистемою, де велика частка енергії надходить від вітрових електростанцій. Данія розробила систему, яка дозволяє гнучко реагувати на зміну обсягів генерації та споживання. Вартість впровадження Smart Grids у країні оцінюється приблизно у $1,5-2 мільярди.

На 2024 рік 40% запланованих інвестицій в енергетиці членів ЄС припадатиме саме на такі мережі. В Україні цей показник ледь дотягує 5%. За рахунок площі та розгалуженості мережі впровадження Smart Grids може становити $4-6 мільярдів, враховуючи необхідність модернізації наявних інфраструктур та інвестування у нові технології.

Враховуючи «вік» нашої енергосистеми, впровадження інтелектуальних мереж може вимагати значної модернізації інфраструктури, систем керування даними та модернізації мережі.

Енергетична кібербезпека

Із впровадження «розумних» мереж витікає друге надважливе питання — кібербезпека. Розумні мережі повинні бути захищені від кіберзагроз, щоб забезпечити стабільність мережі та запобігти збоям.

Україна — друга серед найбільш атакованих країн світу у кіберпросторі після США.

Хакерські атаки мають на меті виведення з ладу енергетичних систем, порушення роботи електростанцій і створення перебоїв у постачанні електроенергії. Основні вразливості енергетичної інфраструктури: залежність від цифрових технологій, систем автоматичного керування і «розумних» мереж (smart grid).

Однією з найвідоміших атак стала атака на Прикарпаттяобленерго у 2015 році, коли понад 225 тисяч українців залишилися без електроенергії. Це був один із перших відомих випадків, коли хакери змогли вивести з ладу енергетичну систему. Для цього використовувалося шкідливе ПЗ BlackEnergy.

У 2016 році хакери атакували вже Укренерго. Сталася атака з використанням шкідливого ПЗ Industroyer, що націлювалося на енергетичну інфраструктуру. Це програмне забезпечення було розроблене спеціально для атак на системи управління промисловими об’єктами.

З початком повномасштабної війни росії проти України, кількість і складність атак значно зросли. Хакерські групи, пов’язані з росією, постійно атакують ключові енергетичні об’єкти, намагаючись дестабілізувати роботу енергосистеми.

Так, протягом 2022 року в Україні сталося майже втричі більше кіберінцидентів, ніж у 2021-му. Подій, геолокація яких пов’язана з рф, за даними Державної служби спецзв’язку і захисту інформації України, побільшало на 26%.

Наприклад, у квітні 2022 року була спроба атаки на одну з великих електростанцій із використанням вдосконаленої версії Industroyer, відомої як Industroyer2, яка, однак, була успішно відбита завдяки швидкій реакції українських фахівців.

Наразі перед нами стоїть завдання розробки та впровадження сучасних систем кіберзахисту, які поєднують моніторинг і реагування на атаки в реальному часі. Для цього необхідна тісна співпраця з міжнародними партнерами, такими як НАТО, ЄС і фахівцями з кібербезпеки по всьому світу для обміну досвідом і технологіями та постійне навчання й підготовка персоналу енергетичних компаній для протидії новим кіберзагрозам.

Штучний інтелект і технології аналізу великих даних здатні не лише відслідковувати аномалії у роботі системи, а й прогнозувати потенційні кіберзагрози. Це дає змогу своєчасно реагувати на можливі атаки та забезпечувати стабільність енергомережі.

Впровадження рішень для захисту енергетичної інфраструктури від кіберзагроз може коштувати $500 мільйонів — $1 мільярд, включаючи апаратне забезпечення, програмне забезпечення та підготовку кадрів.

Децентралізація енергетики та мікромережі

Мікромережі (Microgrids) — це невеликі локальні енергосистеми, які можуть працювати автономно або бути підключеними до національної енергомережі. Такі рішення дають змогу забезпечити безперебійне енергопостачання критично важливих об’єктів, таких як лікарні, військові бази, комунальні служби, а також сприяти сталому розвитку регіонів.

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

Наприклад, США (Каліфорнія) активно використовує мікромережі для забезпечення автономного енергопостачання, особливо в районах із підвищеним ризиком природних катастроф. Успішні пілотні проєкти вартістю близько $200-500 мільйонів показали можливість створення автономних систем для критично важливих об’єктів.

В Україні розвиток мікромереж для критично важливих об’єктів, таких як лікарні, школи та стратегічні підприємства, може коштувати від $500 мільйонів до $1 мільярда залежно від масштабу проєктів.

EnergyTech відкриває перед Україною величезні можливості. Впровадження інноваційних технологій у відновлювану енергетику, розумні мережі, децентралізацію енергосистем і кібербезпеку дозволить країні побудувати сучасну, стійку та захищену енергосистему. Це не лише підвищить енергетичну незалежність України, але й сприятиме її економічному зростанню та стійкості в умовах глобальних викликів. Україна має всі шанси стати прикладом для інших країн у тому, як поєднання технологій та стратегії може сприяти відновленню і модернізації енергетичної системи, одночасно забезпечуючи безпеку і сталий розвиток.

Величко Володимир Анатолійович обіймає посаду заступника голови наглядової ради ПАТ "Центренерго" із серпня 2023 року. Доктор економічних наук, професор Києво-Могилянської бізнес-школи.

У 2013-2023 роках працював на посаді генерального директора Державного підприємства "Харківський регіональний науково-виробничий центр стандартизації, метрології та сертифікації". У 2010-2020 роках представляв Україну у UNЕCE (WP.6) Regulatory Cooperation and Standardization Policies/ Європейська економічна комісія ООН (Женева, Швейцарія).

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

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

Перш ніж заглиблюватися в інформаційну безпеку, важливо зрозуміти різницю між інформаційною та кібербезпекою.

У широкому сенсі кібербезпека — це захист комп’ютерних систем від крадіжки або пошкодження зловмисниками через Інтернет. Вона включає різні аспекти захисту мережі, програмного забезпечення та даних.

На відміну від цього, інформаційна безпека зосереджена на захисті даних, як фізичних (документи, флешки), так і цифрових (файли, бази даних). Інформаційна безпека є особистою відповідальністю кожного працівника і є першим бар’єром на шляху до захисту критично важливої інформації.

Нагадуємо на дуже простих прикладах, що може зробити кожен для захисту своїх пристроїв та інформації:

1. Надійні паролі та двофакторна автентифікація

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

2. Регулярне оновлення програмного забезпечення

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

3. Безпека вашої електронної пошти

Фішингові атаки залишаються одним із найпоширеніших методів, які використовують зловмисники. Будьте уважні до підозрілих електронних листів, не відкривайте вкладення від невідомих відправників і не переходьте за підозрілими посиланнями.

4. Безпечне зберігання даних

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

5. Навчання та обмін досвідом

Інформаційна безпека — це не лише індивідуальна, але й колективна відповідальність. Підтримуйте культуру безпеки у вашому офісі, регулярно проходячи курси з безпеки та ділячись своїми знаннями з колегами. Організовуйте семінари для обговорення нових загроз і методів захисту.

Кожен із нас може допомогти захистити інформацію, дотримуючись простих та ефективних практик. Пам’ятайте, що інформаційна безпека — це не лише відповідальність ІТ-відділу, а спільна відповідальність усіх співробітників, адже тільки разом ми можемо створити безпечний офіс.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

У проєктуванні інтерфейсів дизайнери спираються на Data Driven-підхід. Простіше кажучи, на конкретні показники поведінки користувачів під час взаємодії із застосунком чи вебресурсом.

У цій статті я розповім, чим вказаний підхід корисний у розробці дизайну та яка інформація про юзерів є найбільш цінною.

Переваги Data Driven-підходу

Підвищує лояльність користувачів

Чітке розуміння реальних потреб користувачів дасть змогу зробити інтерфейс, який дійсно допоможе людям дійти до їхньої кінцевої мети (знайти потрібні контакти на сайті, оформити замовлення, розібратися з новим для себе застосунком тощо). Максимально user friendly інтерфейс оцінить кожен.

Вирішує бізнес-задачі

Чим простіший у використанні продукт, тим позитивнішим є користувацький досвід. Із залученістю юзерів зростає конверсія на сайті, а з нею — і кількість замовлень. Все-таки основна мета будь-якої комерційної вебсторінки чи застосунку — приносити бізнесу гроші.

Полегшує комунікацію з клієнтом і колегами

Спираючись на дослідження, можна впевненіше пояснити стейкхолдерам і розробникам виправданість тих чи інших дизайнерських рішень.

Чи є тут місце для креативності?

Дані диктують певні рішення, але дизайнер завжди має простір для кількох нестандартних способів їхньої реалізації.

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

Так і в дизайні. У процесі пошуку ідей чи тестуванні гіпотез теж є місце інтуїції та вашому попередньому досвіду. Додайте сюди актуальні дані про користувачів — і продукт стане ще більш клієнтоорієнтованим.

Пам’ятайте: ви створюєте дизайн, орієнтований на конкретні потреби людей.

Завдяки Data Driven-підходу ваша робота стає ефективнішою в багатьох напрямках.

Вибір усвідомлених рішень

Дизайнерам важливо мати розвинену «‎надивленість»: досліджувати світові тренди та рішення конкурентів, оцінювати їх і намагатися обрати краще для свого продукту. Це слід робити усвідомлено й добре розуміти потреби своїх користувачів.

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

Розуміння аудиторії

Замало зібрати дані. Треба вміти їх оцінювати та прогнозувати, як спрацює рішення.

Те, що класно виглядає на макеті, в реальності тестування може «‎забракувати». Бо від нового рішення може бути гірша конверсія.

У такому разі треба розібратися, що не так. Може, новий дизайн не подобається лише постійним користувачам, а з нещодавніми конверсія зростає, як і очікувалося. Тоді можна не переходити на нове рішення відразу, а додати тимчасовий вибір між старим і новим, допоки постійна аудиторія не звикне до нововведень.

Пріоритизація задач

На великих проєктах, як правило, багато задач з оновлення дизайну різних частин продукту. Може бути запит на редизайн кошика, на зміни в шаблоні карток товарів, правки в меню каталогу. Виконати все одночасно неможливо. Тож UI/UX-дизайнерам разом із менеджерами чи продукт-оунерами передусім варто виставити пріоритети.

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

Професійний розвиток

Додаткові знання в цій галузі значно підсилять вашу експертизу та цінність як фахівця. До того ж, далеко не в кожній команді вистачає аналітиків. Тому інколи UI/UX-дизайнерам доводиться брати на себе додаткову роль і «заходити на чуже поле». Тим не менше, це плюс і для скілів, і для кращого розуміння продукту.

Типи даних, на які варто спиратися дизайнерам

1. Кількісні дані

Це числові, вимірювані дані про поведінку користувачів. Наприклад, скільки людей відвідує сайт у заданий проміжок часу, скільки кліків отримує елемент на сторінці, як часто юзери користуються розділом у застосунку тощо. Кількісні дані відповідають на запитання: «Що?», «Де?», «Коли?».

Існує багато способів збору такої інформації, але найбільш поширені в Data Driven-дизайні такі:

• A/B-тестування (спліт-тестування). Знайомий більшості UI/UX-фахівців метод. Порівняння поведінки людей на двох чи більше варіантах дизайну. Наприклад, у вас є макети з різним дизайном кнопок. За допомогою цього тестування можна виміряти та порівняти кількість кліків на всіх елементах та визначити, який дизайн найбільше приваблює цільову аудиторію, що для них зручніше.
• Теплові мапи. Візуалізують, куди люди найчастіше клікають або на чому затримуються поглядом. Так ви можете побачити, що юзери часто клікають на фото товару, намагаючись перейти до картки з описом продукту, хоча лінк є в його назві. Тож має сенс зробити і клікабельне зображення.
• Вебаналітика. У звітах на кшталт Google Analytics є безліч корисної для дизайнера інформації. Наприклад, те, що допоможе порівняти ефективність і зручність дизайну за демографічними показниками. Може виявитися, що молоді люди з однієї країни інакше контактують із вашим дизайном, ніж старші за віком користувачі. І все це може відрізнятися залежно від геолокації.

2. Якісні дані

Це вже не об’єктивні, а суб’єктивні показники. Вони сфокусовані на оцінці відчуттів і настроїв користувачів.

Якісні дані інформують не про дії, а про причини цих дій. До прикладу, чому люди зупиняються у процесі оформлення замовлення на тій чи іншій сторінці? Що саме їм заважає в поточному функціоналі, як вони оцінюють цей досвід?

Серед основних способів збору якісних даних виділяють такі:

• Опитування. Це прості Google-форми для відгуків про продукт. Як правило, в опитуваннях використовують числові оцінки. Наприклад, пропонують юзерам стисло описати причини відмови від покупки й оцінити за шкалою від 1 до 10, чи порадять вони друзям цей сайт.
• Інтерв’ю. Розгорнуте обговорення користувацького досвіду. Тут вже можна уточнювати будь-які дрібниці. Чому користувач клікнув на певний елемент? Чим він привернув його увагу? Чи виправдав результат його очікування? Що запам’яталося в дизайні? Зазвичай інтерв’ю проводять після тестових сесій.
• Тестування юзабіліті. Тобто оцінка зручності використання інтерфейсу. У процесі ви спостерігаєте за поведінкою та реакціями відібраних користувачів-тестерів. Цей метод допомагає зрозуміти, де, скажімо, переривається продуманий вами юзер-флоу, коли користувач зупиняється та не досягає потрібної вам цілі. Зібрані дані ляжуть в основу майбутнього рішення.

У зборі даних намагайтеся втримати баланс

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

Погодьтеся, навряд чи виправдано витрачати кілька тижнів на обширне дослідження, як колір окремої кнопки впливає на кількість покупок у невеликому інтернет-магазині.

Якщо така ідея виникла у проєкті, де пофіксили наявні критичні чи потенційні проблеми, і вистачає бюджету — сміливо тестуйте. Тим паче, якщо маєте натхнення. Загалом має бути почуття міри, щоб фокусуватися на пріоритетах і не витрачати час і сили дарма.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Його поява стала величезним кроком вперед з огляду важливості організації віддаленої роботи, звільнення від прив’язки до місця розташування офісу. Це було щось на кшталт появи персонального авто, яке дало людям нечуване відчуття свободи.

Сьогодні реклама ноутбуків наголошує на тому, що з ноутбуком можна працювати будь-де, відстань не має значення, його можна легко транспортувати з собою і навіть носити на собі, швидко включитись у роботу, буквально розгорнувши.

Команда проєкту може бути розосереджена по світу на відстані тисяч кілометрів. А ігрові ноутбуки можуть «помірятися» зі стаціонарними ПК своїми характеристиками.

Це все чиста правда, якщо не брати до уваги нюанси. Адже врешті решт ноутбук не став «вбивцею» стаціонарних комп’ютерів, оскільки стаціонарні ПК все ще потрібні та навіть незамінні там, де функціональність переважає над мобільністю.

Питання «ноутбук чи ПК» не має сенсу, доки не з’ясовані додаткові подробиці.

Головні з них — для яких цілей нам потрібна комп’ютерна техніка і яка специфіка умов роботи. Відповіді на них будуть визначальними для вибору між цими двома форм-факторами.

Не заглиблюючись у «критику» ноутбуків, оскільки це просто не має сенсу, бо тут завжди буде нічия, адже обидва форм-фактори в чомусь кращі, в чомусь гірші, розглянемо, які ж сильні сторони мають ПК.

1. Масштаб і специфіка вирішуваних задач (вимоги до відеокарти, обчислювальної потужності, інших технічних характеристик)

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

2. Мінімізація вірогідності механічних пошкоджень

Ноутбук, який так легко носити з собою, так само легко можна і пошкодити. Вірогідність такого випадку зі стаціонарним ПК чи робочою станцією майже нульова.

3. Обмеження доступу до конфіденційних даних

Доступ до кінцевої точки, як правило, складніший коли йдеться про ПК, розташований в офісі. Принаймні фізично до нього важко дістатися, на відміну від ноута.

Крім паролів є охорона, пріоритетність доступу до кабінетів тощо. Це лише у фільмах злочинці миттєво отримують доступ до ПК в офісах за кілька ударів по клавішах.

4. Мінімізація вірогідності втрати чи крадіжки

Ноутбук завдяки його перевазі (мобільності) зловмисникам легше вкрасти або ж користувач може його загубити. Зі стаціонарними ПК це набагато складніше.

5. Можливість апгрейду

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

6. Цінова перевага

У випадку співставних за технічними характеристиками моделей стаціонарний ПК коштує дешевше. Надзвичайно потужна робоча станція може коштувати від 1500 умовних одиниць, співставний за характеристиками ноутбук — приблизно у 1,5 рази дорожче.

7. Економічна вигода

Якщо компанії потрібно оснастити офіс на 50, 100 та більше робочих місць, закупка ноутбуків виллється у значні суми. Аналогічні конфігурації стаціонарних комп’ютерів значно заощадять бюджет.

8. Вплив на здоров’я

Для роботи за стаціонарним ПК потрібен комп’ютерний стіл і стілець. Сучасні моделі столів і стільців чи крісел ергономічні та зручні. Це набагато здоровіше, ніж працювати на ноуті, розташувавши його на власному кухонному столі чи лежачи в шезлонзі (хоча картинка для реклами виглядає привабливо).

Крім того, компанії проєктують офіси з урахуванням санітарно-гігієнічних вимог до рівня освітленості, ергономіки тощо.

9. Варіабельність конфігурації, кастомізація

Під замовлення можна зібрати робочу станцію згідно із запитом на характеристики. Наприклад, Prime PC легко і швидко виготовляє як прості офісні конфігурації ПК, так і потужні робочі станції для специфічних задач.

10. Швидкість постачання

Як свідчить досвід нашої компанії, зокрема воєнного часу, виробити та передати замовнику кілька сотень стаціонарних комп’ютерів — набагато швидше і реальніше, ніж за той самий час знайти та доставити аналогічну кількість ноутбуків із необхідними характеристиками.

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

Персональні комп’ютери та інші сучасні гаджети, зроблені в Україні? Так, це реально. А ще — інноваційно та відповідно до потреб будь-якого споживача.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

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

Для банків і фінансової сфери кібератака взагалі може поставити під сумнів репутацію та навіть існування бізнесу.

Що українські компанії роблять для того, щоб забезпечити собі та своїм клієнтам багаторівневий кіберзахист?

Основні принципи кіберстійкості фінансового сектору

Фізична безпека

Ще на початку повномасштабного вторгнення Національний банк України дозволив гравцям фінансового ринку розміщувати свою інфраструктуру та сервіси у хмарних сервісах і дата-центрах на території Європейського Союзу.

Це рішення стало одним із ключових у забезпеченні безперервної діяльності фінансового сектору, адже стало можливим використовувати європейські дата-центри та публічні хмарні сервіси: Amazon, Google Cloud, Azure та інші. У перші тижні й місяці війни український бізнес робив проєкти міграції, які раніше планувалися і впроваджувалися роками.

Цей підхід дав змогу компаніям мінімізувати ризики, пов’язані з фізичною безпекою ІТ-інфраструктури та забезпечити доступність і надійність послуг для своїх клієнтів.

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

Ретельна перевірка

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

З початку війни ми повністю змінили підхід до побудови інтеграцій. Незважаючи на впевненість, що партнери максимально захищені, їх можуть атакувати в будь-який момент. Тому принцип Zero Trust вийшов на перший план.

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

Міжнародна співпраця

Сучасні стратегії кібербезпеки передбачають обмін інформацією про атаки між міжнародними організаціями. Отримуючи інформацію, наприклад, від CSIRT і Cisco talos про нові потенційні вектори кібератак, можна завчасно впровадити компенсаційні заходи.

Від кібератак ніхто не застрахований

Навіть із цими заходами загроза кібератак залишається високою. Українська «кіберармія» успішно атакує ресурси агресора. Водночас супротивник не припиняє спроб здійснювати масштабні кібератаки на фінансові сервіси та критичну інфраструктуру України.

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

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

Важливі кроки для підвищення кібербезпеки:

• Правильне використання паролів. Використовувати складні паролі, що складаються з різних символів, цифр і літер, регулярно їх змінювати та не використовувати однакові паролі для різних сервісів.
• Захист від фішингових атак. Не відкривати підозрілі листи та не переходити за сумнівними посиланнями. Перевіряти справжність відправника перед відкриттям вкладених файлів. Використовувати антифішингові програми для захисту від шкідливих посилань та електронних листів.
• Захист особистих даних. Не ділитися особистими даними через незахищені канали зв’язку. Використовувати двофакторну автентифікацію для доступу до важливих акаунтів. Шифрувати важливі файли та інформацію.
• Регулярне оновлення програмного забезпечення. Оновлювати операційні системи та програмне забезпечення до останніх версій. Використовувати антивірусні програми й регулярно перевіряти пристрої на наявність шкідливих програм.
• Навчання та підвищення обізнаності. Регулярно проходити навчання з кібербезпеки та бути в курсі нових загроз.

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

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

Захист критичної інфраструктури, забезпечення безперебійної роботи фінансових сервісів — це ті завдання, які український бізнес повинен виконувати з максимальною відповідальністю та увагою до подробиць.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

За даними IDC, цей напрям хмарних технологій демонструє невпинне і стрімке зростання — від 0,9 мільярда доларів у 2015 році до 14 мільярдів доларів у 2022 році.

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

Чому вигідно користуватись HCI і як вони допоможуть вашій роботі, читайте у цьому матеріалі.

HCI. Що ти таке?

Конвергентною інфраструктурою називається програмно-апаратне рішення, що складається з кількох компонентів: серверів, що пройшли сертифікацію вендора, систем збереження даних та мережевого обладнання. Це в комплексі дозволяє створити систему оперування даними, що швидко розгортається та керується прозоріше за звичайні ІТ системи острівного типу.

Звичні комерційні дата-центри базуються на окремих автономних обчислювальних потужностях, системах зберігання даних, мережевих пристроях. Вони можуть надавати місце для оренди, наприклад.

Конвергентна система уніфікує менеджмент цих компонентів під єдиним «дахом». Саме завдяки цьому можна скоротити час розгортання нових систем, спростити та зменшити вартість користування і техпідтримку.

Що ж до гіперконвергенції, то це інтегрована структура, на відміну від конвергентної системи, де кожен компонент є логічним і не може використовуватися окремо.

Таким чином, у гіперконвергентній інфраструктурі (HCI) обчислювальні модулі, сховища даних, сервери та мережі об’єднані програмним забезпеченням. Оперувати такою системою може один адміністратор через спільну консоль.

Першою на ринок таке рішення вивела компанія-стартап Nutanix. Її Complete Cluster став першою гіперконвергентною інфраструктурою (Hyperconverged Infrastructure, HCI).

Конфігурації апаратної платформи доступні для будь-якого робочого навантаження шляхом гранульованого масштабування блоками (CPU+RAMM+SSD) і можуть бути надані з графічним процесором або без нього для графічного прискорення.

Один із варіантів, коли вузли оснащені флешпам’яттю для оптимізації продуктивності сховища, а вузли, що складаються виключно з флешпам’яті, забезпечують максимальну пропускну здатність введення-виводу із мінімальною затримкою для всіх корпоративних програм.

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

У HCI реалізуються три типи масштабування: добре відоме за кластерами горизонтальне (scale out), за мейнфреймами та Unix-серверами вертикальне (scale up) та scale through.

Вертикальне масштабування реалізується завдяки додаванню апаратних модулів: процесорів, блоків пам’яті, що формують окремі вузли (ноди).

Його застосовують тоді, коли наявне «залізо» досягло своєї пікової продуктивності і не дозволяє збільшити потужність стеку. Таке рішення вимагає інвестування в hardware для постійного оновлення системи.

Організації використовують загальнодоступні хмарні сервіси, такі як Amazon Web Services (AWS), Microsoft Azure чи UCloud, для розгортання ІТ-застосунків для ведення свого бізнесу. Служби загальнодоступної хмари є гнучкими та дають змогу компаніям динамічно адаптуватися до потреб бізнесу.

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

Крім того, використання ресурсів загальнодоступної хмари може обходитися дорожче, аніж використання локальної інфраструктури.

В чому переваги?

Як зазначалося вище, HCI пропонує простішу систему обслуговування даних, зменшення витрат, вищу продуктивність у компактнішому форм-факторі за рахунок оптимізації використання «заліза», зростання продуктивності IT-команд. Така система швидко розгортається, демонструє високу продуктивність і стійкість до відмов.

Також HCI об’єднує в один кластер необхідну кількість модулів, яка виходить із потреб компанії, високу гнучкість обсягів сховища, програмних та апаратних потужностей. Це дозволяє максимально ефективно виконувати одночасно декілька робочих навантажень будь-якої інтенсивності.

Ще однією перевагою HCI є компактність. Завдяки скороченню кількості типових стеків до блоків, що об’єднують у собі апаратно-програмну інфраструктуру, можна отримати аналогічні обчислювальні потужності на значно меншій площі.

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

На ринку серед таких рішень часто використовують Azure Stack HCI. Перевагою цього рішення є й те, що Microsoft постійно розвиває свої продукти, розширює географію і програмну потужність сервісу, а також має свій R&D для цієї технології.

Такі рішення більш вигідні, якщо порівнювати з класичними. Щоб розгорнути працюючу гіперконвергентну інфраструктуру, може бути достатньо 3 серверів, 1 комутатора, стійки та 1 безперебійника. В аналогічній класичній інфраструктурі сюди потрібно додати ще дискове сховище, виділити окремий фізичний простір.

Ефективна робота на HCI рішеннях компенсується використанням програмних технологій, а не апаратних. Тобто програмна мережа, програмне дискове сховище, програмні пули ядер і пам’яті. Завдяки цьому воно компактне й ефективне.

Ще однією перевагою є простота ліцензування рішення та можливість отримати програмний продукт у тест самостійно. А після успішного тестування — прозоро сплачувати за користування ним через провайдера.

Azure Stack HCI вигідно використовувати тим компаніям, кому потрібно розгортати зв’язані або граничні інфраструктури у різних країнах.

Розберемо на прикладі нашої компанії. UCloud працює з дата-центрами в Україні та Польщі. Тобто частина нашої технічної бази розташована у Києві, частина — у Варшаві.

Нам потрібно, аби дані знаходились близько до кінцевого користувача і швидко у нього відтворювались. Маючи рознесену по країнах інфраструктуру, ми у певній країні розгортаємо екземпляри (instances) і об’єднуємо все в єдину мережу для адміністратора замовника. Так все буде швидше працювати для замовника і його працівників. Нам вдається досягати 55k IOPS проти 5к для віртуальної машини за конкурентнішою ціною.

Тож якщо потрібно робити запуск периферійних робочих навантажень, VDI, SQL Server, кластера Kubernetes, можна скористатися Azure Stack HCI.

До того ж цим рішенням буде легко користуватися тим адміністраторам, хто знайомий із Hyper-V — платформою віртуалізації Microsoft.

Чи використовують HCI в Україні?

Актуальних досліджень щодо HCI в Україні бракує. Однак існує деяка інформація про ринок, яку експерти збирали ще до початку повномасштабного вторгнення.

За даними консалтингової компанії DX Agent, у 2019 році ринок HCI досяг позначки майже в 11 мільйонів доларів. Однак впродовж наступного року відразу зменшився на 40%.

Як стверджує дослідження, найбільший попит на гіперконвергентні системи серед українських систем у фінансовому секторі, мобільному телекомі, ритейлі та державних органах на кшталт Пенсійного фонду.

Для чого компаніям рухатись у гіперконвергентні інфраструктури?

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

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

НСІ не є універсальним рішенням і не замінює AZURE за дуже вигідними умовами. Щоб зрозуміти це, просто порівняйте можливості, які можуть бути надані за такою ж ціною у глобальній хмарі.

Отримання приватної хмари за сервісною моделлю із прозорим ліцензуванням та можливістю отримувати необхідну потужність може стати ключовим в оптимізації вартості й ефективності ІТ.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.‌‌

Під час запуску бізнесу за кордоном важливо врахувати безліч дрібниць: від офісу та персоналу до правової підтримки й особливостей місцевого ринку. Але часто підприємці забувають про обовʼязкову відповідність стандартам кібербезпеки.

Глобальні тренди на посилення кібербезпеки

Перше, що варто зрозуміти: кібербезпека — це не просто мінливий тренд, і навчити співробітників не переходити за незнайомими посиланнями.

Кіберзагрози щодня стають все небезпечніші та постійно змінюються, а тому уряди держав та компанії усіх розмірів і галузей активно інвестують у розвиток кіберзахищеності.

85% компаній планують збільшувати свій бюджет на розвиток кібербезпеки. За останнє десятиріччя виникло більшість обов’язкових регуляцій у галузі кібербезпеки та безпеки даних, яким мають відповідати організації на ринках ЄС, Америки та Азії.

Як не дивно, для України попереду ще багато роботи в питаннях створення регуляцій кібербезпеки. З одного боку навіть західні партнери відзначають наш досвід боротьби з кіберзагрозами в межах кібервійни, але в нас досі немає обов’язкової сертифікації навіть для державних установ. Хоча за ініціативи USAID в межах проєкту “Кібербезпека критично важливої інфраструктури України” об'єкти критичної інфраструктури почали проходити перевірки на відповідність фреймворку кібербезпеки NIST CSF, де IT Specialist — це компанія, яка надає повний спектр відповідних послуг.

Станом на зараз Україна посідає 78 місце у світовому рейтингу кібербезпеки.

Окрім захисту, відповідність стандартам кібербезпеки — це також питання репутації й довіри до вашої організації на міжнародному рівні.

Наприклад, за даними CISCO, для 86% опитаних важлива приватність їхніх даних, а 79% респондентів готові витрачати час і гроші, щоб убезпечити свої персональні дані.

Тож із якими регуляціями може зіткнутися бізнес під час виходу на міжнародні ринки?

Загальні та галузеві стандарти: кого вони стосуються?

Якщо ваш бізнес хоч якось взаємодіє з даними громадян ЄС, наприклад ваш вебсайт збирає персональні дані про них, вам доведеться дотримуватись вимог GDPR (General Data Protection Regulation, з англ. Загальний регламент про захист даних).

Його вимоги включають безпечне зберігання і прозорий збір та обробку персональних даних резидентів ЄС. У разі невідповідності компанія може зіткнутися із судовими позовами та штрафами або ж навіть зазнати витоку даних й отримати ще більші штрафні санкції. Наприклад, за 2023 рік організації зазнали штрафів на понад €1,6 мільярда через невідповідність GDPR.

Хороша новина полягає в тому, що достатньо лише сумлінно дотримуватися вимог GDPR, сертифікація для підтвердження не потрібна.

SOC 2

Стандарт SOC 2 (System and Organization Controls) є важливим стандартом для компаній, які надають сервісні послуги іншим організаціям.

Він був розроблений Американським інститутом сертифікованих громадських бухгалтерів (AICPA) для оцінки контролю за безпекою, доступністю, цілісністю обробки, конфіденційністю і приватністю даних.

Процес аудиту відповідності SOC 2 включає такі пункти:

• Щоквартальне сканування вразливостей усіх внутрішніх систем. SOC 2 відстежує всі вразливості критичного та високого рівнів до моменту, коли вони будуть виправлені.
• Використання інструментів управління журналами подій (log management) для виявлення інцидентів, які потенційно можуть вплинути на безпеку.
• Тестування на проникнення (penetration testing) виконується щонайменше раз на рік. Розробляється план відновлення, а зміни для усунення вразливостей впроваджуються відповідно до SLA.

ISO 27001

ISO 27001 є міжнародним стандартом, який визначає вимоги до системи управління інформаційною безпекою (СУІБ). Цей стандарт розроблено для захисту інформаційних активів організації та забезпечення їхньої конфіденційності, цілісності й доступності.

Сертифікація за стандартом ISO 27001 підтверджує, що компанія дбає про кібербезпеку та ефективно управляє ризиками інформаційної безпеки.

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

Крім того, ISO 27001 може стати чудовим путівником для організації у побудові ефективної СУІБ.

Спеціалізовані стандарти за галузями

Від загального перейдемо до конкретного.

Чи знали ви, що окремі галузі мають свої унікальні вимоги до кібербезпеки? Фінансові установи, медичні заклади — більша частина галузей, що має справу із персональними даними користувачів чи від діяльності якої залежать цілі країни або сектори економіки, зазвичай мають спеціальні вимоги з кібербезпеки.

NIS2 для критичної інфраструктури та сервісів ЄС

Нова директива ЄС NIS2 (Network and Information Security Directive) спрямована на підвищення рівня кібербезпеки компаній, що надають критично-важливі послуги у ЄС. Вона в першу чергу стосується об’єктів та підприємств критичної інфраструктури. Також до її охоплення входять надавачі цифрових послуг і хмарних рішень, фінансовий сектор, хімічна та харчова промисловості тощо.

Розповсюдженим галузевим стандартом кібербезпеки є й PCI DSS (Payment Card Industry Data Security Standart, з англ. Стандарт безпеки даних індустрії платіжних карток). Причому походить він не від державних установ, а від платіжних систем VISA та Mastercard. Без нього компанії, які надають платіжні послуги чи обробляють дані платіжних карток, не зможуть проводити транзакції за посередництва цих компаній.

Однак директива не поширюється на компанії зі штатом менш ніж 50 осіб та річним оборотом меншим за €10 мільйонів або ж річний підсумковий баланс яких не перевищує €10 мільйонів.

Якщо ви думаєте, що кібербезпека стосується лише великих IT-компаній, то це не так: 1 із 10 малих та середніх підприємств зазнає кібератаки щорічно, а 75% не могли продовжувати свою діяльність після зламу.

Американський ринок та його особливості

Не менш важливою є кібербезпека, якщо ви плануєте працювати з американським ринком.

Так, за даними ISACA, в Америці кожен третій клієнт припиняє співпрацю з компанією, якщо в неї стався кіберінцидент.

Золотим стандартом для організації в США є фреймворк кібербезпеки NIST CSF і рівень відповідності йому. Це не обов’язково, але високий рівень відповідності стане конкурентною перевагою організації як перед клієнтами, так і перед партнерами, особливо коли йдеться про співпрацю з державними установами.

У США діють спеціальні регуляції для певних штатів чи галузей:

• CCPA (California Consumer Protection Ac) та CPRA (California Privacy Rights Act) — це свого роду аналог GDPR, але для резидентів штату Каліфорнія, що встановлює регуляції для обробки персональної інформації споживачів із Каліфорнії.
• COPPA — цей акт вимагає від організацій, що надають послуги, спрямовані на дітей, отримувати від батьків згоду про збір й обробку персональних даних, а також регулює зберігання та використання таких даних.
• HIPAA (Health Insurance Portability and Accountability Act) та HITECH (Health Information Technology for Economic and Clinical Health). Ці стандарти регулюють конфіденційність пацієнтів і визначають, як медичні дані мають бути захищені та передаватися в електронному вигляді.

Перш ніж почати діяльність в іншій країні, необхідно глибоко дослідити не тільки юридичне поле, але й вимоги кібербезпеки, які мають здійснюватись залежно від сфери бізнесу. Наприклад, HIPPA та HITECH для медичної сфери в Америці чи NIS2 для хмарних сервісів у ЄС.

Варто пам’ятати: запускаючи бізнес за кордоном, важливо забезпечити відповідність як загальним нормам кібербезпеки країни, так і спеціальним вимогам вашої галузі.

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

Витрати на підтримку відповідності стандартам та забезпечення захисту від кіберзагроз є інвестицією у стабільність та розвиток вашого бізнесу.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.‌‌

Поява ШІ свого часу спричинила фурор. Одразу з’явилася безліч прогнозів щодо блискучого майбутнього штучного інтелекту та його застосування буквально в усіх аспектах життя людини.

З одного боку, ШІ полегшує працю та щоденне життя людини, а з іншого — загрожує зникненням десятків професій.

З одного боку, сприяє швидкому та ефективному рішенню задач, що вимагають великих обчислювальних потужностей, а з іншого — має багато негативних побічних ефектів (вплив на довкілля, енергоємність, етичні питання тощо).

Та як би ми не ставилися до ШІ, він вже став невід’ємною частиною нашого життя. Тут говоримо про всі види ШІ: ML, генеративний ШІ й так далі.

В ШІ інвестуються неабиякі гроші, а отже маємо результати та постійну еволюцію. Голосові асистенти, чатботи, вбудовані у пошуковики чати GPT (генеративний попередньо тренований трансформер) — це лише невеличка видима частина айсберга під назвою штучний інтелект.

Той, хто розгледів потенціал ШІ років 10-15 тому, сьогодні «знімає вершки»:

1. Минулого року відомі світові компанії, орієнтовані на ШІ, відзвітували про значний ривок у капіталізації (Microsoft, NVIDIA, Meta Platforms і Alphabet). Кількість компаній, які працюють у сфері штучного інтелекту в Україні, у 2023 році сягнула 243.

2. Дві українські AI-компанії стали єдинорогами. Це Grammarly та People.ai.

3. Широке застосування ШІ знаходить в «оборонці». Це автономні системи озброєння, спостереження та рекогносцировка, РЕБ, захист кібербезпеки й інше.

І це лише початок, як стверджують аналітики.

Проте є і дві суттєві перепони до розвитку ШІ, а одночасно загрози для сучасного світу. Так, ця технологія потребує величезних обчислювальних потужностей та енергетичних навантажень.

Щоб зрозуміти масштаб запитів ШІ на потужності, оцініть лише дві наведені цифри:

1. Під час створення GPT-3 було спожито 1287 мегават-годин електроенергії та викинуто 552 тонни CO2. Це еквівалентно 123 автомобілям, які працюють на бензині протягом року.

2. Споживання електроенергії у США із 2019 року збільшилось на 1%, і це збільшення пов’язують саме із розробкою ШІ.

Звісно, розробники ШІ постійно працюють над тим, щоб зробити моделі більш енергоефективними. Наприклад, Google DeepMind розробила нову технологію навчання ШІ під назвою JEST, яка у 13 разів швидша й у 10 разів енергоефективніша за аналогічні.

Також одним із найвагомішим «каменів спотикання» для розвитку генеративного ШІ у 2024 році став дефіцит чипів разом із потребою у великих обсягах «заліза», яких потребує штучний інтелект.

Беззаперечними є переваги використання ШІ у сфері системної інтеграції як частини ІТ-галузі:

1. Штучний інтелект дуже помічний для оптимізації роботи операторів ЦОДів (для надання аналітичних звітів, підказок щодо регламентних робіт тощо).

2. ШІ може бути ефективно використаний в інфраструктурі датацентру — для оптимізації охолодження обладнання. Наприклад, Equinix підвищила енергоефективність свого центру обробки даних на 9% за допомогою охолодження на основі штучного інтелекту.

3. Ще один напрям, де ШІ знаходить зараз широке застосування в усьому світі, — це захист кіберпериметру, зокрема у структурі SOC.

Сьогодні в умовах «першої світової кібервійни» кібератаки на державні та приватні підприємства, датацентри, об’єкти критичної інфраструктури можуть тривати днями й тижнями. Задачі SOC і сучасних SOAR-систем полягають у тому, щоб вчасно розпізнати та зреагувати на кіберзагрозу.

Завдяки тому, що ШІ, який використовується в цих системах, здатний до самонавчання, він діє проактивно і розпізнає навіть ті атаки, які не були прописані у регламентах. І не лише розпізнає, але й швидко діє.

Як відомо швидкість реакції на кіберзагрозу — це левова частка успіху. Саме тому провідні вендори, продукцію яких застосовує у своїх проєктах наша компанія, використовують ШІ у своїх розробках: Microsoft, Cisco, Splunk, CrowdStrike та інші.

Яким буде штучний інтелект завтра, можемо лише фантазувати. Прогнози щодо його майбутнього корегуються чи не щодня.

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

У будь-якому випадку, попри всі негативні сторони сьогодні ШІ все ще лишається однією з найперспективніших розробок останніх років. Нам як фахівцям в ІТ-сфері він також допомагає вирішувати безліч рутинних задач. Отже це технологія, яка має великі перспективи й у всіх інших сферах життя людини.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.‌‌

Переваги, недоліки та особливості парного програмування розглянемо далі.‌‌

Що таке парне програмування?

Це підхід, за якого девелопери кооперуються в пари і разом пишуть код.

Зазвичай практика використовується в Agile- та Scrum-командах. Адже парне програмування орієнтоване на структурування роботи. Хоча і в традиційній Waterfall-моделі така організація робочого процесу може спрацювати.‌‌

У парному програмуванні є дві ролі: драйвер і навігатор

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

У мене ж був досвід, коли до кодингу долучалися троє розробників. Один пише на 15-20 хвилин, інші асистують, і потім ротація. На тому ж проєкті була схожа команда із п’ятьох фахівців, які теж одночасно працювали над кодом.‌‌

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

Наприклад, дані йдуть із точки A в точку B через точку C. А при парному програмуванні ви разом і при створенні коду обираєте формат даних, оптимізуєте його та перевіряєте, щоб все працювало згідно з очікуваннями.

Навіть якщо на верхньому рівні ідея хороша, на нижньому можуть з’явитися баги. Тож наявність ще одного девелопера поряд підвищить шанси знайти потенційні проблеми. Фактично це код-рев’ю «‎у прямому ефірі».‌‌

Як підібрати розробника в пару?

Фахівців слід обирати ретельно. Важливо все: спеціалізація, досвід, роль на проєкті, темперамент, особисті відносини тощо.

Головне, щоб ви з колегою мали приблизно однаковий рівень знань. Інакше є ризик виникнення непорозумінь. Наприклад, драйвер знає, що відбувається, і швидко виконує задачу сам, а навігатор не розуміє нічого і стає просто спостерігачем.

Особливо критичне поєднання джуна і сеньйора. Перший у ролі драйвера буде виконувати, що каже другий, а у ролі навігатора лише споглядати за напарником. Та й сеньйору це все видаватиметься нудним.‌‌

Але навіть якщо розробники одного рівня, це не вбереже від спірних моментів. Класична ситуація: обидва знають і розуміють код, але кожен пропонує своє рішення. Тоді девелопери чимало часу витрачають на обговорення нижнього рівня.

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

Перевага парного програмування — є можливість сходу вирішити спірний момент і розробити рішення, яке позбавить заминок у майбутньому.‌‌

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

Раджу орієнтуватися на принципи Agile. Не можете зробити ідеально? Робіть так, щоб працювало тут і зараз. Працюючий продукт є головним показником прогресу. Це також допоможе уникнути конфліктів у команді.

Розробники завжди мають розуміти, що працюють не заради власного его, а для написання якісного коду, який і покликаний розв’язувати проблеми користувача.‌‌

Як виглядає процес парного програмування?

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

Визначте, де і який код буде знаходитись, де і які компоненти потрібно створити, які функції потрібні та де вони мають знаходитись.‌‌

Наступний крок — визначити періодичність ротації. Зміна ролей залежить від багатьох факторів. Наскільки складна задача? Наскільки кожен із розробників знається на тій чи іншій частині проєкту? Хто має більше досвіду з обраними технологіями?‌‌

У деяких випадках комусь доведеться більше працювати як драйвер або ж як навігатор. Інколи хтось у парі може сказати: «‎Я це добре знаю, дай мені, швидко зроблю сам». Не сприймайте ролі як догму, не обов’язково чекати своєї зміни.

Можете змінювати ролі відповідно до ситуації. Буває, що пара може взагалі розпаралелитись. Якщо ж навігатору нічого робити, він може за узгодженням сторін почати працювати над іншою частиною задачі.‌‌

Що стосується організаційних моментів, то в ідеалі розробники перебувають в одній кімнаті та мають, наприклад, дві сесії по 3 години на день. Вони працюють за одним комп’ютером і передають один одному клавіатуру та мишку або ж ноутбук при зміні ролей.

У реальності ж це подекуди складно реалізувати. У мене був досвід такого програмування з колегами зі Сполучених Штатів. Ми мали лише чотири години спільного часу на день. На додачу доводилося використовувати Zoom для спілкування та Visual Studio Code Live Share для шерінгу коду. Всім важливо було мати однаковий сетап.‌‌

Зміна ролей

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

Звичайно, не без винятків. Парне програмування має недоліки, через які в деяких випадках виявляється малоефективним. Про це окремо поговоримо згодом.‌‌

Повертаючись до роботи в парі, зверніть увагу, що напарник може бути як постійними, так і змінюватися час від часу. Це питання комфорту.

Якщо людям подобається працювати разом і вони ефективні, то краще залишити їх сталим «дуетом». Якщо ж людина хоче працювати один тиждень з одним колегою, а наступний — з іншим, то чому б і ні? Нормальна ситуація, яка може піти на користь обом розробникам.‌‌

Пам’ятайте, що колега може «випасти» з робочого процесу. У житті трапляються лікарняні, відпустки, несинхронізовані вихідні. В будь-якому випадку робота не має зупинятися.

Якщо відсутність одного з розробників нетривала, інший може повернутися до індивідуального кодингу. Якщо ж пауза затягується, краще знайти тимчасового партнера. Так ви збережете темп і якість роботи.‌‌

Окрема частина процесу — оверв’ю для нового партнера або для колеги, який брав паузу у роботі. Розкажіть, над якими тікетами зараз працюєте, на якому ви етапі, чому обрали ті чи інші рішення, які результати.

Знову ж таки: комунікація майже в режимі 24/7 є основою для ефективного парного програмування. Не може бути так, що один пише, а інший, грубо кажучи, скролить стрічку соцмережі. І повернувшись до парного програмування, і при зміні пари обговорюйте якомога більше деталей.

Добре, коли кожен знає особливості різних частин проєкту. Хорошою практикою є передача фіч між парами. Це дає змогу розшарити знання про застосунок чи платформу, над якою працює команда, що особливо корисно у великих проєктах.‌‌

Як покращити навички парного програмування?‌‌

Розвивайте соціальні зв’язки

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

Хибний підхід — зациклюватися на своєму «я» і зневажати партнера. Ви вдвох відповідальні за код. Навіть початківець інколи пропонує щось цікаве чи розповідає про незнайомий вам підхід до роботи.‌‌

Спілкуйтеся під час парних сесій

Незалежно від ролі проговорюйте всі свої дії. Якщо ви драйвер, розповідайте, що пишете, і чому. Інколи ви навіть самі відразу будете усвідомлювати, де криється проблема.

У ролі навігатора аналізуйте код напарника та запитуйте, чому він робить так, а не інакше. Ви маєте розвивати критичне мислення й шукати сенс у своїх діях і діях партнера.‌‌

Не сприймайте коментарі як мікроменеджмент

Парне програмування — це про деталі. Ви обговорюєте дрібниці, але завдяки цьому зменшуєте вірогідність виникнення багів.

Наприклад, драйвер фільтрує масив, а навігатор каже: «‎Тут пропущено кейс, потрібен чейндж». Або взагалі ви забули крапку з комою, використали не той протокол, не переназвали змінну. Ці ж коментарі ви б отримали в код-рев’ю. Часом, ніхто і не помітить проблему, але рано чи пізно десь вона себе проявить.‌‌

Переваги та недоліки парного програмування

За правильної організації парне програмування має суттєві переваги:

• Вища якість коду. Обговорення навіть низькорівневих рішень підвищує шанс одразу обирати кращі рішення. При цьому частковий код рев’ю відбувається прямо під час створення коду, що зменшує кількість примітивних помилок.‌‌
• Розподілення знань. При роботі в парах усі в команді знатимуть, чому обрані ці рішення. Тобто люди розуміють ідею коду та чому він написаний саме так. Це забезпечує гнучкість команди й знижує вірогідність дублювання коду.‌‌
• Мінімізація координації поза сесіями. При парному програмуванні природно зменшується кількість традиційної комунікації типу коротких мітингів. Хоча, звичайно, вони не зникнуть цілком, оскільки є потреба в обміні знаннями поза парами.‌‌
• Вищий рівень дисципліни. Коли розробник пише код наодинці, є ризик, що він буде відволікатися на інші справи. Але якщо фахівці працюють разом, то це допомагає обом утримуватися в межах робочого процесу й конкретної таски.‌‌
• Навчання на практиці. Програмування в парі можна розглядати як навчання. І не тільки новачків, а й досвідчених фахівців. Але це не обов’язково будуть глобальні речі. Можна вивчати й дрібниці: нові хоткеї, оператори тощо.‌‌
• Міцніше відчуття командної роботи. Щільна співпраця допомагає формуванню команди. Це ж не дейліки на 15 хвилин, де ви перекидаєтесь лише парою слів! У парному програмуванні більше часу на соціальні інтеракції поза межами робочих тем.‌‌

Однак пам’ятаємо і про недоліки цього підходу:‌‌

• Нижча продуктивність на проєкті. Два розробники пишуть код, який із приблизно такою ж швидкістю міг би писати один. Звичайно, якість вище, але не кожен замовник погодиться на додаткові витрати та зайве очікування.‌‌
• Складність вибору пари. Важко знайти розробників з однаковим рівнем знань, які швидко та з комфортом для себе працюють у парі. А деяким людям взагалі не зручно при написанні коду так багато спілкуватись із кимось.‌‌
• Можливі проблеми із доступом до напарників. Складно скоординувати людей на один час. Завжди комусь треба до лікаря, хтось хоче обідати на годину раніше, у когось вранці спортзал. І це не кажучи про згадані вище відпустки або різні часові зони.‌‌

Коли краще використовувати парне програмування?

Вважається, що парне програмування не дуже підходить для рутинних задач, мовляв, це механічна робота з готовими компонентами та інструментами. У такому разі немає сенсу залучати двох розробників.

Хоча з досвіду скажу: і з простими тасками можна працювати в парі. Один пише задачу, другий — юніт-тест до неї.

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

У цілому ж парне програмування не є поширеною практикою. Кілька років тому воно було популярніше, але сьогодні багато задач розробник може реалізувати самостійно, швидко і досить якісно.

З одного боку, дедалі більше з’являється бібліотек і фреймворків для не базових задач. З іншого — ви завжди можете звернутися по допомогу до ChatGPT або Copilot, які замінюють напарника-навігатора.‌‌

Як на мене, парне програмування чудово підходить для задач «на подумати». У нестандартних тасках двоє людей можуть швидше знайти креативне рішення.

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

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.‌‌

Історія створення BookNote.AI

WebLab Technology — це команда AI-інженерів, яка прагне розширювати межі в таких галузях, як Conversational AI, AI Agents, Reinforcement Learning та Generative NLP. Окрім наших технологічних захоплень, ми любимо віддавати свою увагу книжкам, які, зокрема, ще й формують нашу культуру.

Політика «необмежених книг», яку ми лагідно називаємо «книжкові черв'яки», надає кожному члену команди доступ до широкого спектра книг будь-якою мовою, незалежно від того, чи це робоча література, чи ні. Ця політика допомогла зібрати нам різноманітну бібліотеку, що відображає нашу віру в те, що знання не повинні мати кордонів.

Вказана культура читання та інновації якраз і сформувала ідею BookNote.AI. Ми подумали: що, якби ми могли використати наш досвід у галузі ШІ для оптимізації пошуку книг? Що, якби ми могли створити інструмент, який не лише допомагає знайти цікаві книги, але й сприяє глибоким, змістовним дискусіям щодо них?

Так народилася BookNote.AI — платформа, покликана революціонізувати взаємодію з книгами, сприяючи глибшому зв'язку з літературою.

Що відрізняє BookNote.AI?

Традиційний підхід ознайомлення з книжками, коли треба перечитати купу інформації, щоб вирішити, чи варто читати книжку чи ні, може відлякувати в наш час.

Відеоогляди, рецензії, короткий зміст — це все звісно існує, але список книжок зростає і зростає, поки людина намагається охопити всі ці формати знайомства з потенційними творами. Саме тут стають у пригоді так звані keynotes, які формуються під будь-яку книжку, яку ви відкриєте у BookNote.AI.

Вони розвʼязують кілька важливих питань:

• Обмеженість у часі: сучасне життя часто не лишає місця для тривалого читання. Keynotes дають контекст книги, що дозволяє не витрачати години на вивчення основних ідей.
• Інформаційне перевантаження: серед величезної кількості книг важко вибрати ті, що справді варті уваги. Стислі огляди допомагають читачам зробити свідомий вибір.
• Проблеми запам'ятовування: навіть якщо книга прочитана від початку до кінця, важко запам'ятати всі ключові моменти. Keynotes допоможуть тримати їх в купі і до них можна буде звернутися, коли в тому буде потреба.
• Оптимальне прийняття рішень: для особистого чи професійного розвитку, розуміння основних концепцій книги може сприяти прийняттю кращих рішень та економії часу.

Сервіси на кшталт GetAbstract, Blinkist, Instaread, Storyshots і MakeHeadway конденсують книжковий контент, а BookNote.AI йде далі, реалізуючи інтерактивне, персоналізоване читання. Це забезпечує глибше усвідомлення.

Фактично книги можуть безпосередньо продемонструвати вам свою цінність під час розмови. Це унікальний підхід, з яким не можуть зрівнятися інші сервіси.

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

Інтуїтивно зрозумілий процес:

1. Шукайте й обирайте: легко знаходьте потрібну книгу на інтуїтивно зрозумілій сторінці пошуку.
2. Долучайтеся та досліджуйте: пориньте в інтерактивне обговорення книги з нашим ШІ-асистентом.
3. Вивчайте і прогресуйте: швидко вихоплюйте ключові ідеї, покращуючи розуміння та заощаджуючи час.
   

Можна вибрати будь-яку тезу для початку діалогу, вибрати з основних питань, пов'язаних із книгою, або поставити власні.

Виберіть питання чи тезу, що інтуїтивно цікавить вас, для кращого розуміння книги.

Інтерактивність і персоналізація: новий підхід до взаємодії з книгами

Як ми згадували раніше, BookNote.AI розроблювали для взаємодії з книгами на новому рівні, який забезпечує персоналізований та захопливий досвід. І він не зупиняється на простих анотаціях. Завдяки ШІ ця платформа дає змогу вести динамічний діалог із книгою, відкриваючи основні теми, ідеї та відсилки.

Дозвольте книзі зацікавити вас через інтерактивне спілкування

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

Водночас BookNote.AI дає змогу легко ділитися читацьким досвідом з іншими. Нам завжди хочеться обговорити прочитане зі знайомими або ж зафіксувати примітні моменти, що стосуються ідей книги. На жаль, передати кожну деталь майже неможливо. Наша команда знайшла рішення, дозволивши ділитися взаємодією з ШІ, надсилаючи іншим посилання на діалог із книгою, а також виокремлювати певні моменти й показувати, як розвивався діалог.

Погляд зсередини: як працює BookNote.AI?

В основу BookNote.AI покладено ШІ-асистент, ретельно навчений зчитувати й аналізувати книги. Асистент є центральним елементом платформи та має чудові здібності до аналізу й інтерпретації тексту.

Коли ви починаєте обговорювати книгу, ШІ-асистент на базі LLM стає вашим провідником, використовуючи передові технології обробки природньої мови й узагальнення тексту.

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

Ви перейдете від ролі пасивного спостерігача до ролі активного учасника діалогу з книгою. Ви визначаєте, як ШІ має представити контекст книги та в який спосіб.

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

WebLab Technology є провідною B2B SaaS компанією та має понад 10 років досвіду у формуванні dedicated teams для складних проєктів. На чолі з Олександром Книгою наша команда розпочала активну роботу з ШІ у 2019 році, беручись за класичні завдання евристичної оптимізації та проєкти комп'ютерного зору.

Спеціалізуючись на таких технологіях, як ШІ, хмарні сховища та SaaS, ми набули репутацію постачальника інноваційних та ефективних рішень для наших клієнтів, серед яких Shaman, AstraZeneca, Bryj та Emaar Properties.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

У цьому матеріалі розглянемо трансформаційний вплив штучного інтелекту на вебдизайн та його вплив на користувацький досвід у 2024 році.

Вплив штучного інтелекту на оптимізацію дизайну

Однією із ключових переваг штучного інтелекту у вебдизайні є його здатність покращувати користувацький досвід за рахунок оптимізації.

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

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

Автоматизоване створення дизайну

ШІ змінює правила гри для вебдизайнерів, впроваджуючи алгоритми генеративного дизайну та допомагаючи у створенні візуальних елементів і навіть повних макетів вебсайтів.

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

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

Покращена персоналізація

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

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

Контент на автопілоті: ШІ на службі креаторів

Штучний інтелект змінює спосіб створення і покращення контенту. Завдяки спеціальним технологіям ШІ може аналізувати і створювати тексти, які легко читаються людьми. Це дозволяє автоматизувати написання контенту для вебсайтів, блогів, описів товарів і навіть цілих сторінок.

Також інструменти ШІ можуть оцінювати існуючий контент і давати поради щодо покращення читабельності, пошукової оптимізації (SEO) та загального впливу. Це спрощує процес створення контенту і гарантує, що він буде привабливим, корисним і добре оптимізованим для пошукових систем.

Підвищення доступності й інклюзивного дизайну

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

Інструменти на основі штучного інтелекту можуть оцінювати вебсайти на відповідність стандартам доступності, таким як Керівництво з доступності вебконтенту (WCAG), пропонуючи поради щодо покращення контрастності, використання відповідного альтернативного тексту для зображень та оптимізації структури контенту для різних пристроїв.

Еволюція веб-дизайну з використанням штучного інтелекту

З розвитком штучного інтелекту його вплив на веб-дизайн лише поглиблюватиметься. Прориви в таких галузях, як комп'ютерний зір, обробка природної мови та генеративні змагальні мережі (GAN), відкриють нові можливості для створення захопливого та інтерактивного вебдосвіду.

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

Крім того, створені штучним інтелектом 3D-моделі та анімації можуть змінити спосіб демонстрації товарів і послуг в Інтернеті, надаючи користувачам захопливу та реалістичну взаємодію.

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

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

Вплив штучного інтелекту на вебдизайн є значним, він впливає на створення, розвиток і взаємодію з користувачами вебсайтів. ШІ змінює цифрову сферу, оптимізуючи користувацький досвід, автоматизуючи процеси розробки та покращуючи доступність.

У міру розвитку ШІ вебдизайнерам і розробникам необхідно використовувати його можливості, вирішуючи наявні проблеми та етичні дилеми. Використовуючи потенціал штучного інтелекту, вони можуть розкрити творчий потенціал, підвищити ефективність і задоволеність користувачів, стимулюючи еволюцію інтернету в бік більш привабливого та інклюзивного середовища.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

У чому різниця між монолітами та мікросервісами

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

QA-спеціалістам слід вміти працювати з обома архітектурами. Перш ніж перейти до підходів у тестуванні, згадаймо, що являють собою мікросервіси та моноліти.

Монолітна архітектура — традиційна модель розробки програмного забезпечення, з єдиним модулем, який працює незалежно від інших.

Часто слово «моноліт» використовують для позначення чогось великого і незграбного. Ці слова досить добре описують монолітну архітектуру з погляду розробників. Така архітектура призводить до створення великої, незалежної мережі серверів зі спільною кодовою базою, яка поєднує всі бізнес-задачі. Бодай одна зміна в такому продукті вимагає оновлення продукту цілком, що забирає багато часу та зусиль команди.

Мікросервісна архітектура — принципово інший спосіб організації системи. В її основі — сервіси, що розгортаються незалежно один від одного. Вони мають власні бізнес-логіку і бази даних для окремих цілей. Оновлення, тестування і масштабування відбуваються всередині сервісів.

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

Принцип роботи мікросервісів чудово поєднується з CI/CD-моделлю та DevOps-практиками й дозволяє швидко адаптуватися до вимог користувачів.

Як тестувати мікросервіси

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

Мікросервіси можуть писати на різних мовах та використовувати в основі різні технології. Інколи це ускладнює схему взаємозв’язків між сервісами. Тому чи не головною проблемою у їхньому тестуванні може стати низька база знань тестувальників.

Тестування мікросервісів розділяють на кілька рівнів.

Unit-тестування

Потрібно написати тести для кожного методу (функції). При виконанні тесту це дасть якомога більший рівень покриття логіки застосунку. Так уже на ранній стадії розробки ви знайдете початкові баги за найменших витрат та ризиків для проєкту. Покриття такими тестами допомагає визначити, чи не призвели зміни коду до помилок. Але для цього юніт-тести мають бути інтегровані в CI-процеси, щоб команда оперативно отримувала фідбеки.

Unit-тестування монолітної та мікросервісної архітектури має такі відмінності:

• Об’єкт тестування. При тестуванні монолітів тестовим об’єктом є вся кодова база з усім функціоналом застосунку. У мікросервісах тестування сфокусоване на кожному сервісі.

• Налагодження тестів. У моноліті всі компоненти знаходяться в одному застосунку, тому юніт-тестування прямолінійне та досить просте. А от у мікросервісах кожен окремий сервіс вимагає ізоляції під час тестування від усієї системи. Загалом це ускладнює роботу.

• Робота з залежностями. В мікросервісній архітектурі кожен сервіс можна тестувати окремо від інших, що спрощує юніт-тестування. А в моноліті всі компоненти мають пряму залежність один від одного, тому їх важче ізолювати для такого типу тестів. Це ускладнює логіку тестів або систему керування моками.

• Розгортання. В монолітах розробка та деплой застосунку зазвичай відбуваються разом. Юніт-тестування є централізованим та інтегрованим. У мікросервісів кожен елемент має свій цикл розробки. Тму QA зосереджені на юніт-тестуванні своєї частини і не чіпають інші.

Функціональне тестування на рівні сервісу

У застосунках з монолітною архітектурою функціональність зазвичай об’єднана в одному блоці. Тоді тестування направлене на перевірку основних функцій та взаємодій усередині програми. Через те, що розробка та розгортання застосунку відбуваються разом, функціональне тестування може бути частиною цього процесу.

У випадку ж мікросервісної архітектури таке тестування включає перевірку функцій кожної частини окремо. Мета тестів — підтвердити, що компоненти правильно виконують завдання та обробляють дані. Тестові сценарії повинні базуватися на вимогах та очікуваній поведінці конкретного сервісу.

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

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

Проста локалізація проблем та відсутність масштабного ретестінгу при внесенні змін до системи — беззаперечні плюси в тестуванні мікросервісів. Адже всі зміни будуть обмежені ретестестуванням самого сервісу та його контрактів.

Контрактне тестування

У мікросервісах з’являється такий вид тестів як контрактні тести. Причина цьому — мережеві взаємодії між сервісами системи. Тож вам потрібно проводити ще й перевірку контрактів API. Контрактне тестування стає важливим інструментом забезпечення сумісності та узгодженості між версіями сервісів. При внесенні змін до контрактів API або взаємодії між сервісами необхідно перевірити, що все відбувається без збоїв.

Тестування контрактів гарантує, що дві сторони здатні взаємодіяти одна з одною. Споживач фіксує зв’язок із постачальником та створює контракт, який є специфікацією запитів від споживача та відповідей від постачальника. Для такого типу тестів можна використовувати фреймворк Pact. Він перевіряє зв’язок між споживачем та постачальниками за протоколом HTTP.

Інтеграційне тестування

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

Інтеграційне тестування моноліту може бути складнішим. Вам необхідно перевірити велику кількість шляхів виконання застосунку та взаємодій. Також тут важливо забезпечити консистентність і валідність тестових даних. Наприклад, це можуть бути попередньо налаштовані тестові дані або ті, що ви створили в процесі тестування.

Е2Е-тестування

На цьому рівні не дуже помітна різниця між тестуванням монолітної та мікросервісної архітектур. Еnd-to-end тести передбачають повну інтеграцію — або всіх мікросервісів, які створюють цілісну систему, або всього застосунку-моноліту.

Як моки допомагають при тестуванні мікросервісів

Використання моків дуже пошире при тестуванні застосунків із мікросервісною архітектурою. Це пов’язано з тим, що компоненти системи розділені на окремі служби, які взаємодіють через мережеві виклики або API. Мікросервіси часто залежать від зовнішніх служб або компонентів (баз даних, черг повідомлень, сторонніх API тощо). Моки дозволяють ізолювати від залежностей окремий сервіс, що тестується. З’являється контрольоване середовище для тестування, що дозволяє створювати стабільніші тести.

Що варто знати при роботі з моками:

• Тестові двійники. Цим терміном позначають різні техніки:

Моки. Імітують поведінку реальних об’єктів або компонентів, з якими взаємодіє код. Моки надають відповіді на виклики методів і можуть бути налаштовані для перевірки правильності взаємодії з ними. Зазвичай такі двійники використовують для тестування взаємодії між компонентами системи.

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

Заглушки. Замінюють реальні реалізації та повертають заздалегідь визначені значення. Їх часто використовуються для ізоляції коду від зовнішніх залежностей та емуляції конкретних сценаріїв або умов проведення тестів.

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

• Манкі-патчинг. Техніка програмування, що дозволяє змінювати або розширювати поведінку наявного коду під час виконання застосунку без його прямої модифікації.

• Проксі та інтерсептори. Використовуються для перехоплення та зміни поведінки об’єктів або систем. Тут варто окремо сказати про ці складові:

Проксі — це об’єкт, що виступає як проміжна ланка між клієнтом і цільовим об’єктом. Він перехоплює виклики та може втручатися у їхню обробку. Проксі забезпечує додатковий рівень абстракції та контролю доступу до цільового об’єкта та може використовуватися для різних цілей: обмеження доступу, кешування, логування, керування транзакціями тощо.

Інтерсептори — перехоплюють та обробляють виклики до об’єктів чи методів у системі. З ними можна втручатися у виклики до, після або під час їхнього виконання. Ви зможете модифікувати поведінку системи, додавати функції та забезпечувати гнучку, контрольовану розробку ПЗ.

• Мок-сервіси. Це імітації або замінники реальних сервісів та компонентів, що використовуються для тестування й розробки застосунків. Мок-сервіси допомагають ізолювати код від реальних залежностей і створити контрольоване середовище. Зазвичай для цього використовують особливі фреймворки або спеціальні інструменти. Ви отримуєте API або інтерфейс, схожий на реальний сервіс. Так ваш код буде взаємодіяти без зв’язку з реальним сервісом або зовнішніми ресурсами (базами даних, мережевими сервісами, сторонніми API). Це спрощує розробку та забезпечує надійність і швидкість тестів.

Архітектура продукту впливає на вибір стратегії тестування

Моноліти завдяки цілісній структурі дозволяють легко налаштовувати тестові середовища та проводити E2E-тестування всього застосунку. Водночас розширення моноліту ускладнює його підтримку та тестування, оскільки будь-яка зміна може вимагати ретестування всього продукту.

Мікросервісні застосунки розподілені на менші, автономні сервіси. Це дозволяє локалізувати зміни та зменшити обсяг ретестування. Однак тестування таких систем потребує налаштування складних тестових середовищ, які відтворюють взаємодію між сервісами.

Окреме місце у тестуванні мікросервісів займає створення моків та керування ними. Вони допомагають ізолювати сервіси та гнучкого керувати їхнім станом.

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

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Для уряду зараз пріоритет № 1 — забезпечення електропостачання критичної інфраструктури та виробничих потужностей, а ось український бізнес, як завжди, має діяти проактивно і подбати про свою енергонезалежність самотужки. Звісно, це потребує залучення коштів та певних зусиль, проте не виглядає неможливим.

З початку повномасштабного вторгнення робота нашого виробничого підрозділу не зупинялося жодного дня, проте ми добре розуміли, що без електроенергії будь-який комп’ютер безкорисний, хай який він високотехнологічний та надійний. Перші блекаути 2022 року виявили тотальну залежність нашого сектору від електропостачання.

Разом із нашими клієнтами ми занурились у цю тему і сьогодні можемо озвучити свої рекомендації та надати допомогу щодо рішень незалежного електропостачання для офісів, обладнаних стандартною ІТ-інфраструктурою, зокрема і стаціонарними ПК.‌‌

Найбільш реалістичні варіанти забезпечення безперебійного живлення, які можуть дозволити собі компанії та офіси державних установ, — це системи на основі зарядних станцій, сонячні панелі, дизельні/бензинові генератори.

Які варіанти найчастіше використовуються для забезпечення енергонезалежності невеликого офісу чи будівлі?

Якщо ваш бізнес-центр не є об’єктом, де має бути передбачене незалежне джерело живлення, для забезпечення роботи комп’ютерів розглянемо чотири варіанти, які можна реалізувати дуже швидко.

Джерело безперебійного живлення (UPS)

Дороге, але стабільне рішення. Саме UPS забезпечує якість електроживлення, безперервність, відсікає перепади, імпульсні перешкоди, відхилення частоти, високочастотні перешкоди, тощо. Але набір акумуляторних батарей до нього — це дуже вартісне рішення.

Враховуючи інтенсивність відключень, яку ми мали на початку червня, АКБ вичерпають свій ресурс дуже швидко. Через 1,5-2 роки постане питання закупівлі нових та утилізації старих АКБ.

Джерело безперебійного живлення (UPS) + генератор (дизель чи бензин)

Оптимальне, перевірене рішення. Стандартна схема: UPS підхоплює обрив електропостачання і тримає до 5-10 хвилин до увімкнення (та розігріву взимку) дизель чи бензинового генератора.

З недоліків: необхідність зберігання та заправки пального, обслуговування генератора, який десь треба розмістити. У мирні часи встановлення генератора потребувало обов’язкового узаконення у трьох інстанціях (екології, пожежної безпеки, енергонагляду). Наразі постановою Кабміну ця вимога (в частині екології по викидах забруднюючих речовин та енергонагляду) на паузі до закінчення дії військового стану й на 3 місяці після його закінчення.

Зарядна станція (готове рішення, що має у своєму складі інвертор/зарядний пристрій та акумуляторні батареї)

Сучасне рішення, яке доречне, якщо в офісному центрі немає площ, де можна безпечно розташувати генератор та запас пального до нього.

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

Також, на відміну від UPS (у яких зазвичай використовуються свинцево-кислотні АКБ), у ЗС застосовуються сучасні АКБ, наприклад літій-залізо-фосфатні, які мають довший термін експлуатації (забезпечують понад 3000 циклів заряду/розряду), більш стабільну напругу при розряджанні, більшу пікову потужність.

Крім того, літій-залізо-фосфатні АКБ більш термічно та хімічно стабільні, що істотно підвищує безпеку при їх експлуатації.

Зарядна станція енергоємністю 1260 Вт·год обійдеться приблизно в 40 тисяч гривень.

Найбільш на слуху зараз ЗС Ecoflow та Bluetti. Крім них, є ще багато менш відомих брендів.

«Зроби сам»: окремо придбані та змонтовані інвертор/зарядний пристрій та акумуляторні батареї

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

Приклад розрахунку для створення енергонезалежного офісу

Припустимо, у вас 20 робочих місць, обладнаних стаціонарними ПК (не важливо, це ПК «Прайм» чи будь-який інший бренд), які ви бажаєте забезпечити електроживленням. Щоб визначити необхідну енергоємність пристрою, помножимо потужність ПК у ватах (Вт) х кількість ПК (для зручності визначимо потужність ПК у 200 Вт).

Крім того, необхідно врахувати коефіцієнт корисної дії (ККД) пристрою, який визначає, скільки енергії здатен віддати пристрій, а скільки витрачається на перетворення струму (визначимо цей показник на рівні 80%).

Таким чином отримаємо: 20 х 200/0,8 (ККД) = 5000 Вт·год (або 5 кВт·год) при загальній номінальній потужності пристрою 20 х 200 Вт = 4 кВт.

Отже, щоб забезпечити офісні комп’ютери живленням протягом 4 годин, вам потрібен пристрій із номінальною потужністю 4 кВт та з ємністю АКБ 20 кВт·год. Залежно від ваших потреб, сюди слід додати потреби інших «клієнтів»: роутер, Starlink, кавоварку, освітлення тощо.

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

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

«Зелені», але не альтернативні варіанти

Прогнози на зиму невтішні. Вірогідні ситуації, коли зимові блекаути триватимуть по 20 годин. Поки триває літо, цікавим рішенням виглядає використання вітряної або сонячної енергії. Компанія Yasno недавно запропонувала свою експертизу у проєктуванні та встановленні сонячних електростанцій.

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

Вітряки на фоні сонячних панелей взагалі виглядають фантастичним варіантом з огляду на їхню вартість та ефективність.

Офіс як корпоративний пункт незламності

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

І якщо забезпечити стійке інтернет-з’єднання можна самостійно за допомогою Starlink, то мобільний зв’язок та мобільний інтернет — це відповідальність оператора. У цій царині теж є певні зрушення, оператори все більше звертають на це увагу.

Наприклад, Vodafone робить значні інвестиції в енергонезалежність, Kyivstar вже інвестував в енергонезалежність та стійкість мережі до блекаутів 1 мільярд гривень.

Також гарна новина в тому, що провайдери інтернету та мобільні оператори для стабільного інтернет-підключення все частіше використовують технологію високошвидкісної передачі даних оптоволоконними лініями зв’язку PON.

Оснащення кінцевих вузлів зв’язку батереями не таке ефективне, бо при довготривалих відключеннях батареї просто не встигатимуть зарядитись.

Як бачимо, крім роботи комп’ютерів для створення прийнятних умов для співробітників, слід передбачити заживлення модемів, варіанти інтернет-зв’язку, опалення офісу, роботу насосів, ліфтів тощо. Наведені вище рішення можна у відносно стислі терміни реалізувати в межах офісу чи бізнес-центру, скорегувавши залежно від ваших потреб.

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

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Але є винятки. На перший погляд ваш навіть максимально чистий код не завжди можуть зрозуміти інші девелопери. У таких випадках не завадить додати синтаксичного цукру.

Що це за підхід до кодування, як він спрощує роботу та коли ліпше уникати цього прийому, пояснює Сергій Лещенко, Full Stack .NET Software Engineer у команді NIX.

Що таке синтаксичний цукор?

Це синтаксис, який спрощує розуміння наявного функціоналу. Все працюватиме так само, як в аналогічному варіанті коду, без цукру. А далі вже компілятор трансформує «цукрові» рядки у базові функції.

Умовно кажучи, якби без цукру ви б написали 100 рядків коду, а з цукром 50, то компілятор спочатку зробив би з них ті самі 100 рядків, а потім перетворив би їх на машинний код.

Деякі розробники вважають це засміченням коду і проти використання зайвих «підсолоджувачів». Однак за правильного використання цей синтаксис все ж може спростити роботу всієї команди й зробити її ефективнішою.

У моїй практиці були проєкти, де такі можливості мови програмування настільки дивували колег, що розробники забували, що це взагалі цукор, а не окремий функціонал. Тобто якби хтось написав код по-класиці, за правилами «‎чистоти», це могло б викликати питання.

Навіщо додавати синтаксичний цукор?

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

Пришвидшується і робота команди. Колеги починають краще розуміти ваш код, а отже якісніше опрацьовують пул реквести та легше підхоплюють написані вами фічі. У результаті загальна продуктивність зростає. А це вже оцінять як керівництво проєкту, так і замовники.

Найпростіший приклад синтаксичного цукру – крапка з комою наприкінці рядка

У випадку C# це не цукор, а обов’язковий до використання елемент. Але, скажімо, в JavaScript у ньому немає потреби, оскільки компілятор визначає місце завершення виразу. Тоді крапка з комою виступатиме як цукор. З одного боку елемент є зайвим, та з іншого – покращує читабельність коду. Для багатьох розробників це звичний символ, який дає їм змогу швидше структурувати код.

Тому моя порада: краще завжди використовуйте крапку з комою, щоб девелоперам легше працювалося з вашим кодом, незалежно від їхньої мови програмування. Втім, зі складнішими прикладами «цукрових» елементів не все так просто.

Використання такого синтаксису має два основних ризики:

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

Щойно виходить нова версія мови програмування, я завжди раджу заглянути в Release notes. Там детально описані нововведення та їхні цілі. Наприклад, якісь фічі покращують перфоманс, якісь фактично є синтаксичним цукром. Ніхто не напише, що це саме цукор. Але з опису буде зрозуміло, що такий прийом підвищує читабельність коду.

Трапляються і більш прозорі натяки: коли в Release notes показують, як нова фіча спрощує написання наявного блоку коду. А саме, надаючи приклади, як розробники один і той самий код писали раніше і як тепер його можна зробити лаконічним. Тобто і без цього розробники обходились, але так вдасться працювати швидше.

Як приклад із C# – null coalescing operator. Нічого нового не вносить, тільки заміняє:

if (variable is null)
{
variable = string.Empty;
}

Можна написати...

variable ??= string.Empty;

... Таким чином код виглядатиме лаконічно.

Бувають і складніші випадки. Уявімо кейс із декількома умовами, залежно від яких код виконує різну логіку. Це можна реалізувати за допомогою if/else або ж switch. Здається, що вони дублюють один одного, відрізняється лише кількість коду. Тому один із варіантів ніби-то є цукром. Однак це різні прийоми для різних задач. Варіант з if/else добре працює для списку із двох-трьох кейсів. Для більшої ж кількості краще застосувати switch.

До прикладу, вам необхідно порівняти змінну типу int із конкретним числом. Компілятор сформує switch statement у статичний масив, де буде доволі ефективно порівнюватися фактичне значення змінної з кейсами у світчі. При використанні if/else statement порівнюватися буде кожна умова, допоки не дійде до першої true. Якщо ж порівнювати з рядком, то switch сформує хеш-таблицю, що підвищить швидкість обробки.

Як працює if/else:

Як працює switch:

Уникайте додавання синтаксичного цукру, коли...

На проєкті є свої правила написання коду

Єдиний код стайл значно покращує читабельність проєкту в цілому, спрощує підтримку та розуміння коду. Легше з ним проходить і онбординг нових учасників команди. Тож якщо за код стайлом прописана заборона на синтаксичний цукор або на окремі його зразки, уникайте подібного синтаксису.

Використовуються різні мови програмування

Наприклад, одні працюють із Java, інші – з C#. Тоді код має бути максимально очевидним і прозорим для всіх. Адже синтаксичний цукор, притаманний одній мові програмування, може бути зовсім незрозумілим для «носіїв» іншої. Щоб не заплутатись, намагайтеся працювати без допоміжного синтаксису.

Помітне зловживання «‎цукром»

Через велику кількість доданих елементів чи рядків розробникам стає складніше розібратися в коді та виокремити функціональні частини. Доведеться бути обережними й знати міру, щоб не страждала читабельність.

Останнє пропоную розглянути на реальному кейсі. Чи не найкраще це ілюструють тернарні оператори. В них одразу видно, що відбувається у коді.

Тернарні оператори чудово зменшують кодову базу: один рядок заміняє умовно 10 рядків із використанням if/else. Інколи у роботі з тернарними операторами у розробників є спокуса використати цю можливість по-максимуму. Наприклад, зробити декілька рівнів вкладеності. Виглядає логічно. Але в реальності, коли одне вираження має три та більше тернарних оператори, девелоперу стає набагато важче читати й осягнути весь масив коду.

У такому випадку краще використати switch-вираження. По своїй суті воно теж сприймається як синтаксичний цукор, але виглядає зрозуміліше:

Інший приклад – global using directives. Можна натрапити на думку, що розробникам вони не подобаються, і на це є декілька причин. По-перше, такі юзінги не дають повної картини. Не зрозуміло, які типи з інших неймспейсів використовуються в кожному файлі. Це збиває з пантелику.

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

Якщо використовувати методи або інші члени типу в інших файлах без написання юзінгу в цьому файлі, а застосовувати глобал юзінги, це призведе до такої проблеми:

Погодьтеся, виглядає занадто складним для розуміння. Хоча ніби все створювалося для підвищення читабельності.

Краще оформити код ось так:

Зауважу, що тут треба вказувати юзінг у потрібному файлі. Використання static-слова в юзінгах допомагає краще працювати зі статичними членами статичного типу, якщо їх надто багато в одному файлі. Без статік юзінгу потрібно було б прописувати назву типу і назву методу. А якщо ще й назва класу задовга, то це призведе до справді важкого для розуміння синтаксису.

З описаним прийомом ви зможете досить ефективно скоротити кодову базу. Без використання глобал юзінгів в окремому файлі код виглядатиме краще:

Додавати чи не додавати синтаксичний цукор – справа розробника. Ви самі маєте розібратися, наскільки це доцільно, чи буде корисно іншим девелоперам на проєкті. Але знати й пам’ятати про перераховані вище ситуації точно варто.

Цукор – не єдина «приправа» для коду. Ще є синтаксична сіль

Це прийом, де в чому схожий на «цукровий». Такий синтаксис теж не додає функціоналу, «солоний» код працюватиме так само, як і «чистий». Але якщо без цукру ви просто довше читаєте код, то без солі зростає ризик виникнення непорозуміння в команді.

На відміну від цукру, сіль не робить код читабельнішим. Кількість символів навпаки збільшується. Але використання солі виправдано тим, що завдяки такому синтаксису розробник точно розуміє, що відбувається, не пропускає деталі та показує іншим девелоперам мету застосованих ним рішень. Загалом це дає змогу знизити вірогідність помилок як автором коду, так і тими, хто працюватиме над продуктом надалі.

Поясню на прикладі. Уявімо чайлд-клас, який походить від базового класу. У цьому чайлд-класі потрібно створити новий член класу, який ховає член базового класу.

З одного боку, не обов’язково додавати до назви нового члену ключове слово new. Програма працюватиме коректно, і новостворений член класу буде використовуватися саме так, як вам потрібно. Але з іншого боку, додавання солі у вигляді слова new дасть змогу всім зрозуміти, що це ховання було явним. Тож не дарма навіть компілятор в C# видасть попередження: «‎Чи ви впевнені у своєму коді, чи не варто додатково прописати new?».

Як і використання синтаксичного цукру, сіль у коді має свої переваги й недоліки. Додавання деталей часом рятує від помилок. Код гарантовано буде якісним. Певно, це оцінять розробники, у яких багато однотипних задач, коли око, що називається, «‎замилюється» і можна не помітити важливих дрібниць.

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

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Ці поради будуть корисними батькам-айтівцям і тим, хто не має досвіду в ІТ, але бачить у своєї дитини інтерес до технологій.

Робота в ІТ залишається затребуваною

Експерти глобального інституту McKinsey прогнозують, що до 2030 року зростатиме кількість робочих місць для айтівців.

Крім того, у повоєнному відновленні України не обійтись без розробників програмного забезпечення, аналітиків Big Data, фахівців із кібербезпеки.

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

У виборі майбутньої професії можна орієнтуватися на перспективні, популярні спеціальності. Але набагато краще, коли ці перспективи підкріплені особистими амбіціями й інтересами дитини.

У пошуках «свого‎» напряму раджу батькам дотримуватись такого плану:

1. Підтримуйте та довіряйте вибору своєї дитини

Це найважливіше, що ви можете зробити. Так етап вибору професії стане для неї менш стресовим.

Підлітки можуть відчувати страх та відповідальність за своє рішення. Підтримайте своїх дітей – дайте їм більше можливостей зрозуміти себе та дослідити сучасні напрями.

Цікавтесь, які професії подобаються та чому, запитуйте, як ще можете допомогти у виборі (і робіть це). У такій атмосфері підлітки знайдуть спеціальність своєї мрії, а тому зможуть швидше стартувати в кар’єрі (без потреби у перевиборі фаху).

2. Досліджуйте разом кар’єрні можливості в ІТ

Якщо ви працюєте в ІТ-компанії, залучайте дитину до своєї роботи.

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

Батькам, які не мають досвіду в ІТ, складно допомогти дитині з вибором професії у цій галузі. Але це не означає, що зовсім неможливо. Ознайомтесь із найбільш затребуваними ІТ-напрямами. Це дасть вам змогу краще орієнтуватись у специфіці галузі та не пропусти жодної можливості.

ІТ – це мультипрофесійна галузь, у якій працюють:

• Розробник. Пише код для програмного забезпечення, вебсайтів, мобільних застосунків, ігор.
• QA-тестувальник. Перевіряє (тестує) ІТ-продукти та знаходить помилки.
• Project-manager. Керує роботою над проєктом. Слідкує, щоб команда виконала роботу якісно, у домовлений строк та не перевищила бюджет.
• Product-manager. Задає вектор розвитку продукту (програмного забезпечення, технологічного рішення) та відповідає за його вихід на ринок.
• Data-інженер. Працює з великими базами та джерелами даних: збирає, зберігає та робить готовими до подальшого використання.
• IT-рекрутер. Знаходить людей, які можуть стати частиною ІТ-команди.
• UI/UX-дизайнер. Створює візуально привабливі інтерфейси для вебсайтів, мобільних застосунків, ігор.
• PR-manager. Розробляє стратегію і план дій, як підвищити впізнаваність компанії в країні та на міжнародній арені.
• Event-manager. Організовує і проводить різні заходи: конференції, майстер-класи, воркшопи, тімбілдінги та інші.
• Копірайтер. Наповнює текстом сайти, мобільні застосунки, пише про технології й галузь у цілому.

3. Аналізуйте навички й інтереси дитини

Схильність до певних шкільних дисциплін не визначає майбутній фах.

Знання математики не гарантують, що ваша дитина зможе стати крутим розробником. Як і високі оцінки з мови не вказують на те, що треба пов’язати кар’єру із написанням текстів.

Зацікавленість гаджетами не потрібно плутати із захопленням ІТ. Вашу дитину не відірвати від комп’ютерних ігор? Ймовірно, що їй просто подобається така розвага. Інша справа – якщо підлітку цікаво, як створювати ігри, що для цього потрібно вчити. Тоді варто звернути увагу на можливу схильність до ІТ.

Така сама ситуація із соцмережами. Діти діляться фотографіями, думками, спілкуються один з одним, бо це популярно серед їхніх однолітків. Бажання створити гарний профіль (особисту сторінку), інтерес до привабливих акаунтів брендів може перерости у майбутню професію.

4. Пройдіть профорієнтаційний тест

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

В інтернеті є чимало таких тестів, зокрема для ІТ-спеціальностей. Але враховуйте, для кого їх розробили. Це можуть бути сервіси для людей із досвідом роботи та без. Від цього залежать питання, відповідно – і точність результату.

Також орієнтуйтесь на країну, для якої створили профтести. Вимоги до освіти та попит на фахівців можуть змінюватись залежно від регіону.

В Україні є сервіс для вступників на ІТ-спеціальності в українські виші. Це проєкт від ІТ-команди NIX під назвою ITs WAY.

На платформі доступна інформація про популярні напрями: QA, проєктний менеджмент, бізнес-аналітика, розробка програмного забезпечення, Data-інжиніринг, DevOps та UI/UX-дизайн.

Абітурієнти можуть пройти тест, щоб визначити свою схильність до цих напрямів і в яких університетах навчають за ними.

Особливість сервісу – це розрахунок ймовірності вступу у провідні ЗВО Харкова та Полтави. Для цього потрібно ввести бали НМТ (ЗНО) у відповідні строки за додати за наявності сертифікат про закінчення підготовчих курсів.

5. Сформуйте в дитини стійкий інтерес до професії

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

Формуйте інтерес дитини із задач та активностей, які не потребують багато часу. Не «навантажуйте» її відразу книгами чи фаховими статтями, інакше можете спровокувати внутрішній протест.

Пам’ятайте: Альберт Ейнштейн захопився наукою завдяки маленькому компасу, а не величезній енциклопедії.

Щойно дитина звернула увагу на якусь спеціальність, дайте їй можливість «затестити» свій вибір і змінити рішення, якщо щось не сподобається у процесі. Встановіть потрібні програми.

Підлітку не обов’язково розбиратись у таких інструментах як профі, достатньо ознайомитись із функціоналом. Це може бути Adobe Photoshop для створення графіки й обробки фото, Figma – для спільної роботи над дизайном сайту чи застосунку, пакет програм MATLAB для обробки чисел, Git – щоб управляти процесом розробки.

Найкращий спосіб переконатися, чи вдало дитина вибрала професію, – це запропонувати їй виконати завдання з майбутньої спеціальності.

Хоче розвиватись у дизайні – допоможіть створити дизайн блокноту, книги, листівки тощо. Це можна зробити в онлайн-програмі, як-от Canva, чи створити ескіз на аркуші.

Мріє про кар’єру тестувальника – потестити застосунок чи сайт і написати відгук, чи зручно ними користуватись, як відображається інформація на сторінках, чи інтуїтивно-зрозумілий інтерфейс на ресурсах.

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

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

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

6. Розвивайте навички, необхідні в обраній сфері

«Підключайте» книги, ресурси з корисною інформацією, курси або репетиторів. Таке навчання потребуватиме чимало зусиль, тож попіклуйтеся, щоб процес приносив підлітку задоволення.

Ось декілька ресурсів, які, на мій погляд, дозволять школярам та абітурієнтам краще познайомитись із популярними ІТ-напрямами:

• Scratch. На платформі можна створити інтерактивну історію, анімацію та гру. Учасники діляться своїми роботами, надихаються проєктами інших та обговорюють їх.
• Fundamenta. Безоплатний мобільний застосунок для вивчення основ JavaScript, Java, Python та інших мов програмування. Навчання – українською мовою.
• CodinGame. Ігрова платформа для вивчення програмування. Учасники керують сюжетом ігор за допомогою написання коду.

Важливо, щоб дитина фокусувалася не лише на тому, що знадобиться в майбутній роботі. Успіхів у кар’єрі досягають фахівці з широким світоглядом. Тож корисними будуть будь-які нові знання та навички, дотичні до ІТ.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.‌‌

Ми у NovaPay розуміємо, що безпека коштів наших клієнтів – це наша першочергова мета. Тому системи кіберзахисту – для нас не побажання, а стандарт роботи. Ми інвестуємо в цей напрям третину нашого ІТ-бюджету, щоб наші клієнти знали, що їхні гроші та дані – під надійним захистом. Розповідаю, що саме для цього робимо.

Багаторівнева «броня»

Ми плануємо архітектуру наших ІТ-систем таким чином, наче будь-якої миті вони можуть опинитися або під потужною DDoS-атакою або під кібератакою. Як-то кажуть, краще перестрахуватися, ніж долати наслідки.

Ми керуємось принципом zero trust – нульової довіри. Це означає, що системи та їхній захист будуються по принципу відсутності довіри до будь-чого.

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

Ми будуємо системи кіберзахисту NovaPay за принципом ешелонованого захисту. Такий підхід забезпечує багаторівневий захист і дає змогу ізолювати компоненти систем та мінімізувати ризики зламу і витоку інформації.

Маємо такі рівні:

• Захист периметра (первинний захист): захист зовнішніх мереж і точок взаємодії з системою. Ми використовуємо комплексні рішення, які покривають безпеку вебзастосунків (Web Application Firewall), забезпечують захист від DDoS-атак та безпеку периметра.
• Захист застосунків і внутрішнього контуру (середній захист) – найцікавіша історія. Це і планування захисту мережі, і рішення з шифрування, і антивірусний захист, контроль потоків даних та SIEM-система.
• Кінцевий рівень (глибокий захист): захист пристроїв, застосунків і даних. Наша система будується за принципом Secure-by-Design. Це означає, що ще на етапі проєктування вони проходять Security review – ми перевіряємо, чи коректно ухвалили технічні рішення з урахуванням ризиків інформаційної безпеки.

Цей підхід дає змогу NovaPay забезпечити повний та комплексний захист своїх інформаційних активів на різних рівнях, допомагає мінімізувати ризики. Бо тоді, коли в світі зазвичай у кібербезпеку інвестують десь 10% від бюджету ІТ, у нас це – близько 34%.

Платіжний застосунок, сертифікати безпеки та законодавчі вимоги

З огляду на те, що надійність клієнтських операцій для нас – пріоритет № 1, ми маємо не тільки внутрішні стандарти безпеки, а й керуємося зовнішніми. NovaPay має чинний сертифікат PCI DSS (стандарт безпеки для індустрії платіжних карток) та повністю відповідає правилам щодо кіберзахисту від Національного банку України.

Payment Card Industry Data Security Standard (PCI DSS) для нас не тільки сертифікат із захисту конфіденційних даних та інформації платіжних карток. Це універсальний стандарт з інформаційної безпеки, який дозволяє довести процеси до рівня зрілості.

Ми пішли трохи далі та розширили вимоги стандарту PCI DSS на всі інформаційні системи компанії. Це означає, що всі сервіси NovaPay відповідають вимогам міжнародних платіжних систем.

Ви можете сміливо сплачувати чи переказувати кошти за послуги й товари звичайною карткою, у застосунку, за допомогою Apple чи Google Pay, не остерігаючись шахрайства, адже сертифікація PCI DSS підтверджує, що ваші гроші у безпеці на кожному етапі платежу.

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

Наприклад, нещодавно ми дуже швидко спроєктували додатковий контур захисту в застосунку NovaPay на основі скорингу Device ID. Якщо простіше, то на пристрої потенційного зловмисника неможливо буде навіть зайти у застосунок без додаткової верифікації.

Захист ізсередини

Для кожної компанії однією із загроз кібербезпеці є співробітники, їхні робочі станції та доступи. Щоб зменшити ці ризики, працюємо і в цьому напрямі. Контролюємо доступи співробітників. У кожній із систем вони суворо регламентовані.

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

Але намагаємось будувати процеси так, щоб не заважати роботі колег. Для обмеження доступів оцінюємо ризики щодо кожного ІТ-сервісу, інформаційної системи за класичним підходом: конфіденційність, цілісність, доступність. Де цих ризиків більше – там правила жорсткіші. Ця історія переглядається щонайменше раз на квартал.

«Прилетіти може будь-якої миті», або Відновитись за 15 хвилин

Ми будуємо нашу стратегію кіберзахисту за принципом «прилетіти може будь-якої миті».

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

Щокварталу ми робимо тести на проникнення – імітуємо в реальному часі хакерську атаку за принципами Black Box та White Box (умовно коли атакуючий не знає нюансів про нашу систему або ж навпаки знає, як все влаштовано).

Також моделюємо ситуації, коли одна команда акумулює атаку, а друга її відбиває. За результатами кожного зі сценаріїв ми вносимо покращення до наших ІТ-систем. Бо не маємо права на помилку й небезпеку для клієнтів.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.‌‌

Суть справи: компанія Microsoft нещодавно анонсувала нову лінійку ноутбуків з оновленою Windows 11, у складі якої буде штучний інтелект Copilot (читається «ко-пайлот», типу «напарник-пілот»), а його фішкою буде функція Recall. Назва асоціюється із легендарним фільмом Total Recall («Пригадати все» з Арнольдом Шварцнеггером).

Полягає функція Recall у тому, що штучний інтелект постійно записує всю активність користувача та робить скріншоти кожні кілька секунд, щоб у випадку втрати даних можна було «повернутися у минуле» та переглянути свої дії. Які застосунки відкривалися, з якими документами працював і навіть які клавіші натискав. У тому числі записуватимуться онлайн-зустрічі та фінансові операції з онлайн-банкінгом.

Уся ця інформація буде індексуватися системою і зберігатися локально на комп’ютері, щоб потім можна буде повернутися до потрібного місця за кілька секунд, причому простим словесним запитом. Така собі «машина часу». Пам’ятаєте, «ой, я шось нажала і все зникло»? Ото воно.

Шо тут почалося. Тисячі фахівців із кібербезпеки та захисту приватності почали заявляти, що це неприкрите слідкування за користувачем, що дані можуть передаватися назовні «для навчання ШІ», для продажу рекламодавцям, що це Клондайк для спецслужб та хакерів.

Microsoft клявся-божився, що ці дані «надійно зашифровані» і будуть зберігатися виключно на комп’ютері користувача, і сам Майкрософт не матиме до них доступ. А також що функцію Recall можна налаштовувати або повністю відмикати і що вона ніколи-ніколи не буде ввімкненою за замовчуванням, а щоб її увімкнути, потрібно буде пройти спеціальну процедуру. І щоб стороннім особам отримати доступ до даних, які записує Recall, потрібно буде мати фізичний доступ до пристрою.

Але нарід продовжував кричати «Джордж Оруелл не міг цього передбачити», «це кошмар для приватності». Деякі юзери казали «це остання крапля» та обіцяли перейти на Linux.

Професор зі штучного інтелекту Університету Меріленду Jen Golbeck сказала так:

«Матеріали можуть залишатися на вашому пристрої, але це не означає, що люди не можуть до них отримати доступ. У вас не буде можливості захистити себе, навіть якщо ви використовуєте режим анонімного перегляду або очищаєте історію, оскільки інструмент [Recall – KK] має доступ до всього, що було на вашому екрані».

Ілон Маск назвав Recall «епізодом із «Чорного дзеркала» і пообіцяв обов’язково її вимкнути, коли ця функція буде доступна. Відповідно, його слова миттєво рознесли по Інтернету легіони його прихильників і світові медіа.

Після такої світової реакції британський регулятор захисту персональних даних направив до Дрібном’яких запит, щоб «розуміти заходи безпеки для захисту конфіденційності користувачів».

До чого я все це розказав. Щоб нагадати і ще раз показати, як у великому Світі люди цінують свою приватність і боряться за неї. Тому що вважають це справді важливим. На їхньому боці також незалежні спеціалізовані агенції, і вони уважно дослухаються суспільної думки. І у них немає чогось типу «Дії», це правда. Немає саме тому, що є працююча система захисту приватності та персональних даних. Там є розуміння «безпека даних громадян = безпека держави».

Там слово «безвідповідальність» є тяжким звинуваченням, яке може призвести до багатомільйонних фінансових втрат або відставки уряду.

А не те, шо у нас.

Більше про цей кейс та ризики кібербезпеки майбутньої (?) функції Recall можна почитати тут (англійською).

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

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

Опрацьовуючи до сотні таких запитів на місяць навіть у воєнні роки та відслідковуючи всі тренди світового виробництва у сфері ПК, сьогодні ми рекомендуємо звернути увагу на основні складові вибору якісної та сучасної комп’ютерної техніки для вашого підприємства.

Вимоги користувачів до офісних ПК, моніторів та периферійного обладнання

У сучасному офісному середовищі вимоги до персональних комп’ютерів або ж ПК перш за все визначаються вимогами для забезпечення ефективної роботи та зручного використання програмного забезпечення.

Зазвичай такі мінімальні вимоги сьогодні включають 8 ГБ оперативної пам'яті та накопичувач SSD об’ємом 240 ГБ форм-фактору 2,5” або M.2.

Щодо процесорів, то більшість сучасних користувачів віддають перевагу моделям Intel 10-го, 11-го та 12-го поколінь із підтримкою операційної системи Windows 11. Враховуючи розвиток технологій, на ринку також вже доступні моделі процесорів Intel 13-го та 14-го поколінь, що забезпечують ще більшу продуктивність та ефективність роботи.

Щодо відеокарти, то в офісному середовищі зазвичай використовується інтегрований у процесор графічний адаптер, оскільки для більшості офісних завдань його цілком достатньо.

Основною ж операційною системою, яка використовується на сьогодні, є Windows 11, оскільки вона забезпечує більший рівень безпеки та функціональності порівняно із попередніми версіями. Однак деякі компанії можуть залишатися на Windows 10 залежно від їхніх потреб і політики використання програмного забезпечення.

Вимоги до офісного обладнання у 2024 році визначаються не лише його характеристиками, але й зручністю використання та доступністю на ринку.

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

Щодо моніторів, то більшість офісів зараз використовують стандартні Full HD монітори з частотою оновлення екрану 60 або 75 Гц. Для звичайних офісних завдань цих параметрів вистачає для зручної роботи. Однак, якщо потрібно працювати з більшою роздільною здатністю, наприклад, 2K або 4K, потрібно враховувати можливості вбудованого графічного адаптеру, який у деяких випадках може не забезпечити необхідний рівень зручності використання.

Щодо підключення монітора до ПК, найбільш поширеним інтерфейсом на сьогодні є HDMI, який зазвичай присутній в усіх офісних ПК та ноутбуках. Однак у випадку моніторів з роздільною здатністю 4K як правило використовується інтерфейс DisplayPort.

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

Чинні норми щодо сертифікації обладнання

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

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

Україна активно впроваджує ці стандарти та підтримує ініціативи щодо зменшення впливу на екологію. Це сприяє створенню здорового та безпечного робочого середовища для співробітників компаній. І ми також підтримуємо ці ініціативи.

Найбільш популярні в Україні виробники комп’ютерної техніки

Україна, як і багато інших країн, має свої «улюблені бренди» ПК та ноутбуків, які користуються популярністю серед користувачів. Серед них, наприклад, значно виділяються Lenovo, HP та Dell, як найбільш відомі та широко використовувані бренди.

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

HP також має значний вплив на ринок комп’ютерної техніки в Україні. Їхні продукти відзначаються високою якістю збирання та функціональністю, що також робить їх популярними серед бізнес-користувачів.

Dell займає третє місце серед найбільш популярних брендів. Їхні продукти відомі своєю надійністю та продуктивністю.

Проте, якщо мова йде про надійні та доступні моделі саме вітчизняного виробництва, наші конфігурації комп’ютерів від Prime PC є беззаперечним лідером серед користувачів підприємств і в державному, і в комерційному секторі.

Вибір конфігурацій та супровід спеціаліста при виборі мережевого обладнання і програмного забезпечення в офісах

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

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

У випадках, коли потрібен обов'язковий супровід спеціаліста з боку постачальника або виробника, це може стосуватися діагностики обладнання, необхідності усунення несправностей, або при потребі у технічному обслуговуванні обладнання.

Наприклад, в рамках укладеного договору на технічне обслуговування, великий постачальник рівня нашої компанії може забезпечувати встановлення обладнання та виконання всіх необхідних налаштувань, а також проведення діагностики та ремонту в разі потреби.

Також, у випадках складного налаштування чи специфічних вимог до обладнання, обов'язковою може бути присутність спеціаліста на місці для забезпечення правильного функціонування системи.

Отже, правильний вибір конфігурацій та супровід спеціаліста при виборі мережевого обладнання і програмного забезпечення в офісах гарантує ефективну роботу системи та уникнення проблем з її функціонуванням.

Кібербезпека та SOC в офісному середовищі

При виборі обладнання та програмного забезпечення, важливо обов’язково враховувати принципи кібербезпеки, такі як розмежування прав доступу, шифрування даних та встановлення захисту від несанкціонованого доступу.

Окрім того, наявність локальних адміністраторів з окремими правами доступу може додатково забезпечити безпеку системи та запобігти можливим атакам.

Під час вибору та налаштування обладнання та програмного забезпечення в офісах, забезпечення кібербезпеки, а за можливості, і інтгерація SOC (Security Operations Center) сьогодні відіграють надзвичайно важливу роль у забезпеченні безпеки інформаційних систем.

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

Основна функція SOC полягає в постійному моніторингу стану безпеки системи та реагуванні на виявлені загрози. Він забезпечує постійний контроль за функціонуванням системи та вчасну відповідь на потенційні загрози.

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

При облаштуванні офісу малого бізнесу, наприклад, до 10 співробітників, існують мінімальні ключові компоненти мережевого обладнання та програмного забезпечення, які забезпечують ефективну роботу організації.

1. Інтернет-провайдер

Для забезпечення доступу до Інтернету і забезпечення безперебійної роботи офісу, малому бізнесу потрібно укласти угоду з провайдером. Одного провайдера може вистачити для малих компаній, але для великих підприємств рекомендується мати декілька провайдерів.

2. Мережеве обладнання

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

3. Корпоративна Wi-Fi

Забезпечення бездротового з'єднання для пристроїв у офісі може бути важливим, особливо для мобільних пристроїв та збільшення мобільності працівників.

4. Комп'ютери та ноутбуки

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

5. Програмне забезпечення

Необхідною частиною є офісні програмні продукти, такі як Microsoft Office (Word, Excel), бухгалтерське програмне забезпечення, програми для документообігу, тощо. Для спеціалізованих потреб можуть знадобитися програми для дизайну, редакторські програми та інше.

6. Операційна система та антивірус

Використання корпоративних версій операційних систем, таких як Windows, є важливим для забезпечення безпеки та управління комп'ютерами в мережі. Також необхідно встановити антивірусне програмне забезпечення для захисту від шкідливих програм та загроз в Інтернеті.

Для великого бізнесу можуть додаватися такі компоненти, як розширена мережева інфраструктура, сервери віртуалізації, додаткові програмні засоби для автоматизації бізнес-процесів, а також сервіси і системи забезпечення безпеки мережі.

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

Працюємо разом на Перемогу!

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Хмари приваблюють підприємців через різні причини. Переважно бізнес цікавить перспектива вищих прибутків, надійності та широкого спектра додаткових послуг. Проте вже тривалий час саме кібербезпека – беззаперечний пріоритет для глобальних організацій.

Слід пам’ятати, що панацеї від ризиків у мережі не існує. Хмари не гарантують всебічну недоторканість підприємства.

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

Чого варто остерігатися?

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

Зловмисники в мережі – це ледь не найбільша загроза стійкості підприємства. Хакери можуть викрасти дані, підірвати логістику або ж взагалі зруйнувати мережеві протоколи. Передовсім це тягне за собою суттєві репутаційні втрати для компанії.

Перебої з логістичними лініями загрожують на певний час паралізувати виконання зобов’язань. Водночас витік чутливої інформації підвищує ризики невідповідності нормативним вимогам, оскільки компанія не змогла вберегти доручені персональні дані клієнтів.

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

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

Як захищатися?

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

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

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

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

Нині технології масштабуються. Швидкість передачі та складність хмарних процесів можуть призвести до перевантаження системи. Кількість сповіщень про ризики зросте настільки, що оператори будуть не в змозі подолати всі виклики одночасно. Тож аналіз ризиків – це насамперед розставлення правильних пріоритетів, аналіз загроз та ресурсів, а також напрацювання сценаріїв чіткого плану дій.

Дані у хмарі не убезпечені від зламів і крадіжок. І хоча бекап дає гарантію аварійного відновлення, більшість критичних даних, зокрема персональні, опиняться в руках зловмисників.

Один зі способів мінімізації цієї загрози – шифрування інформації. Інструмент переслідує одразу дві цілі: перешкодити доступу даних як ззовні, так і зсередини.

Шифрування даних у хмарі необхідне, але поки не отримало достатнього поширення. Щонайменше 40% усіх приватних даних у хмарах – це саме чутлива інформація, а зашифровано з неї менше половини.

Підсумки

Міграція у хмари – це системне рішення для компанії. Варто зрозуміти, навіщо взагалі його ухвалили та чого саме підприємство намагається домогтися?

Переваги хмар очевидні, але певні ризики теж існують. Один із них – неналежне використання наданих послуг, ненадійний провайдер або хибний план кризового менеджменту.

Управління ризиками у хмарі зводиться найперше до аналізу середовища. Зокрема, які загрози стоять перед хмарною інфраструктурою компанії першочергово і які системні дані варто рятувати пріоритетно? Лише відповіді на ці питання дозволяють коректно й ефективно керувати ризиками у хмарі.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Неважливо, в якій ви групі. Опанувавши мистецтво «‎гугління» як профі, ви станете тим, до кого звертатимуться колеги. На власному досвіді це перевірила Олександра Цаглова, Lead UХ/UI-дизайнер в ІТ-команді NIX.

У цій статті експертка ділиться лайфхаками, як дизайнерам знаходити потрібні референси та будь-яку іншу інформацію для роботи. А також, що робити, коли Google не впорався із запитом.

Поради будуть корисними всім, хто користується Google.

Вміння «гуглити» покращує якість роботи

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

Уміння «‎гуглити» – це важлива навичка для кожного. Знаючи, що та як запитати в Google, вас не обтяжить самостійно впоратись із різними задачами, навіть із чимось незнайомим і спершу занадто складним. Це додає самозарадності в будь-якій ситуації. До того ж, навчившись ефективно користуватися пошуковиком ви не будете відволікати колег. І що важливіше також:

• Скоротите час виконання завдань

Ви зможете уникнути перегляду великої кількості результатів, які не дають жодної користі вашому проєкту. Швидше знайдете референси або відповідь на питання. Наприклад, хочете дізнатись, як відобразити анімацію з використанням CSS. Загальні запити можуть «розтягнути» пошук на цілий день. Та й немає гарантії, що так ви дійсно вирішите задачу. Якщо подивитесь документацію або конкретизуєте пошук, це збільшить шанси на успіх.

• Будете в курсі кращих практик

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

• Отримуватиме схвальні відгуки клієнтів

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

5 кроків до пошуку вдалих референсів

1. Пишіть запити англійською мовою

Більшість ресурсів, пов’язаних з ІТ, доступні англійською. Інформація про тренди першочергово з’являється в англомовних джерелах. Тож ви обиратимете серед усього масиву актуальні дані. Бонус такої практики — «підтягнете» знання з мови.

Можна було б залишити тут кілька корисних посилань, де почитати про тренди в дизайні на 2024 рік. Але починайте вчитись «гуглити» вже зараз 🙂

2. Формулюйте «вузькі» запити

Чим конкретніший запит, тим швидше знайдете потрібне. Припустимо, вам треба розробити сайт у мінімалістичному стилі, де переважає білий колір. «Загугливши» white minimalistic site, ймовірно, витратите багато часу на нерелевантні результати. Краще шукайте кожен елемент лендінгу окремо: white minimalistic header, white minimalistic footer тощо.

Порівняйте наведені нижче результати:

3. Використовуйте правильну термінологію

Наприклад, щоб дізнатись, як розташувати елементи на сторінці у CSS. На сторінці це реалізується через відступ (padding) та поле (margin). Краще окремо «загугліть» терміни. Padding задає відступ навколо вмісту елемента, а margin – зовнішні поля навколо елемента.

4. Шукайте інформацію на форумах

Додайте до запиту слово forum. Пошукова система покаже сторінки, де користувачі обговорювали вашу проблему або схожі запити.

До речі, через «Розширений пошук» можете обрати, якою мовою хочете бачити результати.

5. Додайте у запит спецсимволи та назви дизайнерських інструментів

• Лапки

Ключові слова мають відповідати вашому питанню. Наприклад: «UX-дизайн», «користувацький досвід», «UI-тренди». Введіть обрані ключові слова в поле пошуку.

Якщо намагаєтеся знайти конкретну фразу, візьміть її в лапки. Google шукатиме слова саме в цій послідовності та у вказаній вамі формі. Це один зі способів перевірити коректність цитати та знайти чітку відповідь.

• Знак «плюс» (+)

Додає слово до пошукового запиту й робить його обов’язковим у видачі. Наприклад, «UX + дизайн» шукатиме результати, де зустрічаються обидва слова «UX» і «дизайн».

• Знак «мінус» (–)

«Мінусує» слово з результатів. Наприклад, «Аналіз – конкурентів» усуне сторінки, де є слово «конкуренти».

• AND

Google шукатиме тільки тоді, коли обидва слова (або більше) є в результаті. Наприклад, «UX AND UI» покаже сайти, де можна почитати про «UX» та «UI».

• intitle:

Обмежує пошук до заголовків сторінок. Наприклад, «intitle: Книги для дизайнерів» надасть матеріали з такими назвами.

• Часові межі

Один із найефективніших способів пошуку першоджерела. Зазначивши обмеження за датою, ви швидше знайдете нову інформацію (або в разі потреби минулі дані для порівняння з нинішніми).

Для цього введіть запит у пошукове поле, натисніть «Інструменти». У розділі «Час» оберіть потрібний період. Можете вказати конкретну дату, останній тиждень чи добу, протягом якої в інтернеті з'явилася інформація.

• Права на використання

Оберіть «Інструменти» – «Розширений пошук», а потім – «Права на використання». У випадаючому списку натисніть на той варіант ліцензії, який вам підходить. Таким чином можете знаходити фото та ілюстрації, дозволені для використання в комерційних проєктах. Так ви безкоштовно отримаєте матеріал та не порушите авторські права.

Зберігайте посилання на сайти, де знайшли корисну інформацію

Перегляньте ці сторінки. Можливо, пізніше повернетесь до них із новими запитами. Закріпіть вкладку в браузері або створіть перелік корисних лінків у нотатках. Це можуть бути корисні ресурси і для роботи, і для особистих цілей.

Поділюсь кількома своїми знахідками:

• Awwwards – сайт конкурсу у сфері дизайну та розробки сайтів. На платформі зібрані кейси переможців з усього світу, багато статей про вебдизайн.
• Harvard Business Review – тут зібрані статті з різних галузей: технології, дизайн, менеджмент, фінанси, маркетинг, комунікація тощо. Знайдете багато досліджень, статистики та інших матеріалів від фахових авторів.
• Trend Watching – світова компанія, що займається дослідженням трендів. Тут повно аналітики. Зокрема, може допомогти вам перетворювати тенденції на технічні рішення.

Інколи активне «‎гугління» може не принести бажаного результату. Тоді в хід ідуть генеративні нейромережі. Я використовую такі платформи для створення референсів.

Генеруємо зображення за допомогою AI. Практичні поради дизайнерам

Існують різні нейромережі, які на основі тексту генерують візуальний контент. Найпопулярнішими є такі:

• Midjourney. Платний сервіс із безплатним демо-доступом. Генерує зображення через бот у Discord.
• DALL-E2. Розроблена компанією OpenAI. DALL-E використовує мовну модель GPT-3.
• Stable Diffusion. Компанія-розробник – Stability AI. З 2022 року сервіс став загально доступним.
• Lexica Aperture. Безкоштовна нейромережа. Дозволяє створювати фотореалістичні ілюстрації.
• Leonardo AI. На платформі можна згенерувати ілюстрації в різних стилях. На день доступно 150 безплатних спроб.

Нейромережі схожі між собою за принципом роботи. Особисто я найчастіше працюю із Midjourney. Пропоную розглянути, як згенерувати віжуал на цій платформі.

Перед початком роботи...

Для генерації зображень якомога конкретніше опишіть, що хочете отримати. У Midjourney це називається промт – текстовий запит.

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

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

Ловіть базові поради, які допоможуть отримати від Midjourney потрібний віжуал:

Будьте конкретними

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

Спочатку вкажіть, що (хто) буде основним об’єктом. Наприклад, домашній кіт. Потім вкажіть додаткову інформацію про цей об’єкт: рудий кіт із великими зеленими очима, тримає в лапах смартфон, сидить на дивані та обирає продукти із супермаркету в застосунку. Поясніть, що оточує об'єкт, наприклад, предмети інтер’єру.

Опишіть стиль зображення: реалізм, експресіонізм, абстракціонізм, футуризм, символізм тощо. Можете посилатися на відомих художників (стиль Сальвадора Далі або Ван Гога). Дописуйте конкретні вимоги до ілюстрації, поки не побачите необхідну картинку.

Далі на прикладах покажу, як деталізація запиту впливає на результат.

Промт – «Домашній кіт».

Промт – «Домашній кіт». Експериментуючи із синонімами, можна отримати інший результат.

Промт – «Рудий домашній кіт із зеленими очима».

Промт – «Рудий домашній кіт із зеленими очима сидить на дивані й тримає смартфон».

Промт – «Рудий домашній кіт із зеленими очима сидить на дивані й тримає смартфон, мультяшний стиль, блакитний фон».

Промт – «Рудий домашній кіт із зеленими очима сидить на дивані й тримає смартфон, стиль Вінсент ван Гог».

Порівнюйте речі з відомими сюжетами

Отримуючи запит, штучний інтелект звертається до своєї бази. А там – безліч інформації про фільми, книги, твори мистецтва. Це різноманіття дозволяє ШІ краще зрозуміти ваше питання й обрати підходящий референс.

Наприклад, якщо потрібно згенерувати світловий меч, зробіть відсилку до «Зоряних війн». У вашого персонажа має бути червоний плащ, як у Супермена? Так і скажіть йому.

Промт – «Дарт Вейдер у червоному плащі Супермена тримає світловий меч, Сімпсони».

Додайте художні засоби

Поясніть свій запит через порівняння, метафори, гіперболи, епітети. Так вдасться влучніше розкрити ваш задум. Замість промту «космічний єдиноріг» можна написати так: «Білий єдиноріг із довгою гривою з мерехтливих зірок і великими очима, на фоні комет». Змінюйте запит, допоки результат вас не влаштує.

Промт – «Білий єдиноріг із довгою гривою із мерехтливих зірок і великими очима на фоні комет».

Промт – «Білий єдиноріг, довга грива, мерехтливі зірки, великі очі, на фоні комет».

Промт – «Білий єдиноріг із довгою гривою із мерехтливих зірок і великими очима, в яких відображається сяйво комет». Як бачимо, програма згенерувала персонажа зі звичайними очима. Тому знову ж таки – не забувайте деталізувати запит.

Промт – «Білий єдиноріг у повний зріст, довга грива, мерехтливі зірки, великі очі, на фоні комет».

Використовуйте спецсимволи

Знаки «плюс» (+) і «мінус» (–) додають або прибирають конкретні елементи з об’єктів ілюстрації. Наприклад, промт «ялинка + сніг» зробить засніжене дерево. Зазначивши «дівчина – окуляри», отримаєте персонажа без окулярів.

Дужки () і коми (,) групують елементи для точнішого результату. Промт «(Чоловік + капелюх), (жінка + морозиво)» створить зображення із чоловіком у капелюсі та жінкою з морозивом.

Складно почати роботу з нейромережою? Шукаєте натхнення? Спробуйте генератори підказок:

• Prompt Inspiration. Пропонує для створення промтів різні теми: архітектура, техніка, мистецтво, люди, тварини, аніме тощо. За категоріями можна швидко знайти ідею і сформувати за нею власний запит.
• Hugging Face. Сервіс запропонує різні варіанти промтів. Наприклад, якщо написати cute cat, отримаєте такі варіанти: cute cat painting – w 1080 — h 720, cute cat in cyberpunk city, cute cat anime characters.
• Promptbase.com. Маркетплейс із готовими промтами. На платформі можна придбати готовий опис або створити власний для продажу.

Кожен пошуковий запит – індивідуальний. Якийсь спосіб спрацює з одним, але може не спрацювати з іншим. Комбінуйте всі можливі підходи, щоб знаходити найцікавіші ідеї, першоджерела або тренди. Будьте певні: в інтернеті ви знайдете все, якщо вмієте правильно ним користуватись. 😉

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Хоча інтерфейс платформи і комфортний для використання у бізнес-сфері, можливості LinkedIn можна значно підвищити за допомогою розширень та додаткових інструментів.

Іван Прокопець, CEO та Co-Founder компанії Prok Tech, поділився найкращими інструментами, що дають змогу використовувати потенціал LinkedIn на максимум, а також розповів про політику платформи стосовно них та можливі обмеження.

Експерт зазначає, що платформа ефективна й без розширень, проте модифікації дозволяють зробити всі дії простішими, швидшими та працювати з більшою аудиторією.

Умовно, стандартний LinkedIn можна оцінити на 7/10, проте з додатковими інструментами його можливості зростають до 10/10.

Варто відзначити такі програми:

• Dux-Soup. Розширення для браузера, що дозволяє автоматизувати надсилання запитів на додавання в мережу. Завдяки цьому розширенню є змога сфокусуватися на опрацюванні відповідей, а не механічному надсиланні запитів.
• Expandi.io. Інструмент, що автоматизує роботу з LinkedIn та Email Outreach. Вміє автоматизувати взаємодію з лідами, надсилати запити на додавання в мережу, проставляти уподобайки та відправляти листи, хоча остання функція потребує доопрацювання.
• Phantom Buster. Розширення, що допомагає парсити аудиторію та вивантажувати її у зручному форматі CSV для подальшої лідогенерації. Платформа має набагато ширший функціонал, який включає автоматизацію дій у різних соціальних мережах, в тому числі LinkedIn. З останніх оновлень там з'явилася функція генерації та надсилання запитів на додавання у мережу із використанням ШІ.
• Apollo.io. Розширення, що поєднує велику базу потенційних покупців та інструменти для автоматизації й роботи із ними.
• Snov.io. Набір інструментів, що поєднує інструменти для пошуку та перевірки поштових скриньок, Email-розсилки, CRM-систему та багато інших застосунків.

Крім сторонніх інструментів, не слід забувати про підписку Sales Navigator, яка компенсує більшість недоліків безкоштовної версії.

Звісно, найкращий результат дає її поєднання зі згаданими інструментами, а також детальне розуміння алгоритмів LinkedIn. Іноді достатньо знати деякі лайфхаки, як-от збільшення ліміту кількості запитів на тиждень завдяки надсиланню InMails та пошуку Open Profiles.

Проте LinkedIn має своєрідне ставлення до стороннього софту. На питання, чи можна отримати блокування акаунту за встановлення розширень, відповідь – ні, якщо використовувати їх правильно та обережно.

За надсилання великої кількості запитів можливо отримати тимчасові обмеження. Якщо ж порушувати правила користування LinkedIn, то можна отримати тимчасове або ж постійне блокування.

Існує ймовірність отримати обмеження через такі інструменти, як Expandi або Dux-Soup, проте зазвичай не доходить до перманентного блокування. Найкращою порадою буде використання антидетект браузера і проксі.

Експерт наголошує, що варто заходити в акаунт не більше ніж із 3-х IP-адрес та однієї країни й уникати поведінки, що суттєво відрізняється від людської.

Також компанія Prok Tech має кілька цікавих кейсів, що стосуються роботи зі згаданими розширеннями. Наприклад, за допомогою Dux-Soup вдалося забронювати 24 зустрічі з клієнтами для відомого бізнес-клубу за 6 тижнів. А в травні минулого року вдалося встановити рекорд з одного особистого акаунта та забронювати близько 30 зустрічей за допомогою розсилки на IT-аудиторію в Україні.

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

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

На ці та інші питання з напряму QA відповів Євген Онищенко, Manual QA Team Lead у Telesens із 13-річним практичним досвідом.

– Мanual VS Automation Testing. Для яких завдань підходить кожен вид?

– Automation Testing або Autotest потрібен для повторюваних задач. Наприклад, які повторюються із релізу в реліз чи зі спринта у спринт. Для того, щоб спеціаліст не робив однотипні завдання вручну. Це дає змогу звільнити час тестувальника для інших цілей.

Manual Testing – для випадків, коли вийшла якась нова фіча і її потрібно перевірити ретельно і уважно. Автотестинг тут теж може допомогти, але очима можна побачити більше неточностей, хоча й часу буде витрачено також більше.

– Який із видів тестування популярніший в Україні?

– Це все індивідуальні особливості, які залежать від бюджету і просто питання «А чи доречно це у цьому проєкті?».

Багато є нюансів і не завжди це виправдано по часозатратності. Наприклад, витрачений на написання автотесту час можна виділити на мануальне тестування.

– А який вимагає більших фінансових вкладень?

– Я не експерт, але, наприклад, QA-автоматизатори отримують більше, ніж мануальники.

З точки зору компанії (бізнесу) купити й оформити інфраструктуру, розвернути оточення буде більш затратно, але скоріш за все воно себе з часом окупить.

– З якими челенджами часом доводиться стикатися QA-фахівцеві?

– По-перше, це незнання програми. Наприклад, вперше стикаюся із програмою і мені потрібен час на те, щоб із нею розібратися та вивчити її бізнес-логіку. Після цього зрозуміти, що хотів отримати замовник на виході, і думати при цьому саме як замовник, а не як машина.

По-друге, робота у команді. Коли у команді багато людей, то мені як тім-ліду треба зробити так, щоб усі були задоволені один одним, допомагали та підтримували.

Також, хоч і не такий вже великий, та все ж челендж – постійно бути на контакті з бізнесом, розуміти потреби замовників і правильно доносити їх команді.

Поділюся тим, що мені подобається, – ми класно побудували роботу. Всі люди у моїй команді є взаємозамінними. Немає такого, що людина є спеціалістом лише в одній сфері, а про інші процеси не має поняття.

– Що вам найбільше подобається у роботі тестувальником?

– Коли я був саме тестувальником, а не тім-лідом, мені подобалося тестувати новий функціонал і нові фічі. Але це все залежить від проєкту. Наприклад, є монотонні проєкти, де нового зовсім трохи.

Бувають короткі та дуже цікаві проєкти. Наприклад, проєкт, який передбачав можливість вироблення струму, коли ти крутиш колеса, і подачу інтернету. Раніше я не міг подумати про існування такого, а зараз брав участь у розробці.

І що є найприємнішим – це коли у продакшн виходять проєкти, над якими ти працював. Це кайфове відчуття причетності.

– А що навпаки може дратувати?

– Криві та незрозумілі вимоги, які потрібно багато разів переуточнювати. Якщо все чітко і правильно оформлено, то і мій performance буде на висоті, бо немає зайвої біганини.

– Як підбираєте людей у команду? Які Soft Skills при цьому є важливими?

– Чесність. Я не люблю, коли мене обманюють. Коли можуть зникнути з роботи, а не чесно прийти та сказати про потребу у відсутності на роботі. Коли мені потрібно людині написати чи щось від неї отримати, а у відповідь – тиша.

Буває всяке – стоматолог, невідкладні справи тощо. Я нормально до цього ставлюся.

Також я не люблю людей, які ухиляються від роботи. І які беззмістовно, не слухаючи, «підтакують». Часом, коли це дуже допече, можу спеціально якусь дурницю сказати та перевірити, чи справді слухає людина те, що я їй кажу. :)

– Завдяки чому QA-відділи можуть забезпечувати високий рівень якості тестування?

– На мою думку, завдяки взаємозамінності, яку я згадав вище, і knowledge sharing. Наприклад, у нас процес так налагоджений, що якщо спеціалісти нашої команди мають відкриті питання, то вони знають, до кого їм із ними йти. А у разі серйозних ситуацій ми організовуємо зустрічі й колективно обговорюємо все.

– Які виклики очікують напрям QA у 2024 році?

– Я думаю, як і всю IT-індустрію. Не те щоб занепад, але певні проблеми. Зараз стало гірше, ніж було років 3-5 тому.

Є велика кількість кандидатів, які подають свої резюме, конкуренція просто величезна. Але коли ти наймаєш кандидата – він все одно виявляється слабким.

Водночас у компаній дуже великий вибір і вони можуть маніпулювати компенсацією. Наприклад, запропонувати десь меншу зарплату. Але через те, що претендентів багато і конкурс на вакансію великий, люди погоджуються.

– Які Hard Skills є важливими для тестувальника?

– Знання технік тестування. Не просто знати, а з розумом підходити та застосовувати їх.

Знати REST, API, SQL, SOAP. Оскільки зараз зв’язок QA і Back End йде саме через API чи SQL.

– Який ваш улюблений мем про QA?

– Оцей.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Чим же займаються AppSec-інженери та як опанувати цю професію? Розповім із власного досвіду.

Дещо про роботу AppSec-інженерів

Ці інженери відповідають за безпеку програмного забезпечення на всіх рівнях. Зазвичай AppSec-фахівці мають досвід розробки, тому розуміють процеси побудови ПЗ. Знання про те, що і як працює зсередини, а відповідно як це може зламати хакер, допомагають інженеру створити краще захищений софт.

В ІТ вирізняють Red Team і Blue Team. Перші фахівці шукають вразливості системи та її організації. Це етичні хакери, penetration-тестувальники, соціальні інженери.

Blue Team безпосередньо працює над захистом: створює firewall'и, полісі, стандарти. Фактично це Social Operation Center, який для запобігання атак моніторить системи, організацію та мережі, а під час атаки використовують інцидент-плани. Наприклад, відключають користувача, якщо проникнення відбувається через його акаунт.

Application Security можна віднести до Purple Team («‎пурпурної команди»), що стоїть між двома попередніми. В AppSec-інженерів є вміння і знання з обох напрямів.

У більшості проєктів Application Security-команда невелика, тому часто просто ні в кого навчатися азів професії. Для старту важливо базово знатися на процесах та ролях в ІТ-команді. Вам доведеться взаємодіяти з розробниками, архітекторами, продуктовими аналітиками, тестувальниками та багатьма іншими спеціалістами. Навички написання, читання та рев’ю коду теж будуть плюсом.

З чого складається робота в Application Security

1. Моделювання загроз та рев’ю дизайну/архітектури

Інколи можна почути думку, що ця робота починається ще з вимог, щоб зрозуміти порушення комплаєнсів. Але недоцільно долучати AppSec-ів уже на цій стадії проєкту. Фахівець має зрозуміти, як буде побудована система та які в ній потенційно вразливі місця.

Наприклад, у продукті використовуються не ті протоколи взаємодії чи неправильно організовано збереження даних про кредитні картки. Вимоги прописані недостатньо чітко, тому й реалізувати все можна по-різному. Тож лише після створення архітектури та плану розробки вдасться проаналізувати можливі загрози й «підсвітити» девелоперам порушення безпеки.

2. Створення безпечного коду

Включає в себе комплексне рев’ю коду на всіх етапах. Йдеться не стільки про перевірку як таку (хоча і вона потрібна), скільки про запровадження best practices та автоматизацію процесів розробників.

AppSec-інженери прописують полісі та гайди безпечного кодстайлу та допомагають налаштувати різноманітні інструменти автоматизації: від плагінів для IDE на машинах девелоперів до сканерів, які інтегровані в CI-процес.

3. Навчання команди практикам захисту софту

Передбачає тренінги для різних фахівців на проєкті. Програми таких зустрічей можуть бути загальними, з описом базових правил на кшталт «Не використовуйте флешки на комп’ютері» або «Не відкривайте емейли від незнайомих людей». А можуть бути й спеціалізованими: для розробників, QA, бізнес-аналітиків.

Застосовуючи шифрування даних, потрібно використовувати ті чи інші алгоритми. Багато чого залежить і від бізнес-домену. Наприклад, в американській Healthcare-індустрії важливі HIPAA-комплаєнси. AppSec має нагадати колегам: обов’язково перевірте, чи надійно захищені дані пацієнтів саме за цими державними стандартами.

4. Автентифікація, авторизація та контроль доступу

Це один із найважливіших етапів Application Security. Його важко стандартизувати, бо чи не на кожному проєкті автентифікація й авторизація реалізуються по-своєму. Ніколи не будуються стандартні моделі забезпечення рівня доступу до даних – завжди комбіновані.

Зазвичай це не є цілком вдалим рішенням, адже можуть з’явитися проблеми з перфомансом чи невідповідність бізнес-вимогам. У гіршому ж – команда знехтує безпекою. Тому AppSec-інженери мають наголошувати на ціні помилок усім стейкхолдерам: як своїм колегам, так і технічним фахівцям на боці замовника і самому клієнту.

5. Тестування безпеки

У проєктах, де немає можливості залучити тестувальників із Red Team, AppSec-фахівці проводять перевірки безпеки. Якщо ж на проєкті є пенештрейшен-тестувальники, спеціалісти з Application Security співпрацюють із ними.

Тести на проникнення здебільшого виглядають як робота з чорною/сірою скринькою. QA достеменно не знають, де виникла проблема. AppSec-інженер, розуміючи побудову системи, зможе відшукати ці вразливі місця. Тож тестувальники витратять менше часу на пошуки й відразу візьмуться за свою справу.

AppSec-інженери бачать цілісну картину проєкту і можуть допомогти розшифрувати знайдені тестувальниками помилки та навіть запропонувати рішення. Особисто для мене, наприклад, це і є найцікавішим у всій роботі AppSec: знайти прогалину в безпеці та придумати, як її «‎закрити».

6. Захист даних

Насамперед це методи шифрування і хешування інформації, налаштування системи зберігання ключів шифрування, способи їх передачі тощо.

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

7. Відповідність та керування

Окреме завдання – це збереження даних. Тут важливо проаналізувати відповідність тим чи іншим стандартам. Наприклад, PCI DSS вимагає, щоб дані про банківські картки користувачів зберігалися в базі даних у зашифрованому вигляді. Це один із ключових критеріїв виконання комплаєнсу. AppSec перевіряє, що використані на проєкті підходи відповідають цим вимогам.

8. Інтеграція DevSecOps

Вразливі місця можуть бути не лише у проєкті, але й у конфігурації інфраструктури. Зазвичай це зона відповідальності DevOps-фахівців. Проте вони часто не мають вузької спеціалізації та знають лише базові аспекти безпеки. Тоді AppSec дивиться, як усе налаштовано з позиції DevSecOps. Подекуди переймає деякі задачі девопсів.

Наприклад, в одному з моїх проєктів AppSec-інженери тісно взаємодіяли з DevOps-ами. Розбиралися в наявних пайплайнах та інтегрували в CI-процес кастомний сканер. Обом командам допоміг попередній досвід розробки, і вони досить легко знайшли спільну мову.

9. Моніторинг та реагування на інциденти

За відстеження атак та реагування на них відповідає Social Operation Center. AppSec-інженери визначають кроки: як має реагувати команда, організація і продукт, коли щось трапилось. Усе прописують у стандартах полісі та інцидент-планах для різних варіантів атак.

Наприклад, юзер завжди логінився з Австрії, але раптово зайшов у систему з Австралії. Це вибивається зі звичного сценарію, тому потрібен план дій. Система за схемою мультифакторної авторизації зв’язується із користувачем за допомогою іншого каналу комунікації та перепитує: а це точно ти? Якщо відповіді немає чи вона негативна, запит автоматично блокується.

Саме тому норми Application Security слід впроваджувати від початку розробки. Реалізація такого інцидент-плану потребує заздалегідь передбачити технічну можливість блокування юзера.

Ми не можемо закрити очі на жоден із цих пунктів чи приділити їм замало уваги. Але будемо чесні: ресурсів завжди не вистачає, тому доводиться йти на компроміси. І це треба обговорювати з клієнтом.

Часто команди не встигають перевірити певний функціонал. Тут є сенс переглянути бізнес-стратегію та змінити фічу чи взагалі відмовитися від неї на певний час.

А ще, наприклад, сьогодні чимало продуктів будують навколо ШІ, який може робити в системі будь-що. Але це порушує базові стандарти Application Security. Зловмисники намагатимуться зламати такого «юзера» задля супердоступу. Тож слід переконати клієнта, що ризики від впровадження фічі перевищують профіт.

Краще йти на компроміс не в безпеці, а в можливостях. Якщо ж клієнт все одно залишає без уваги згадані небезпечні місця у застосунку, то варто винести їх у пріоритет для наступного релізу.

Що допомагає у виконанні завдань

Арсенал інструментів, методологій, фреймворків доволі широкий, та передусім варто...

Орієнтуватися на галузеві та державні стандарти

Наприклад, є визнані фреймворки американського інституту NIST та міжнародні стандарти ISO, яким повинні відповідати організація та ПЗ (наприклад, ISO 27001 чи ISO 15408). Ці документи описують, яким має бути безпечний IT-продукт.

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

Працювати зі сканерами – статичного аналізу коду, аналізу залежностей, динамічного аналізу (коли є готовий продукт у вигляді API)

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

Application Security не обмежується налаштуванням і запуском інструментів. Робота з тим же статичним аналізатором коду нескладна, але для AppSec недостатньо запустити інструмент і витягнути звіт. Варто досліджувати особливості продукту, щоб прогнозувати можливі атаки в тих чи інших місцях.

Часто розробники використовують характерні системи найменування змінних, на які сканер реагує як на вразливість.

Припустимо, в назві змінної є слово password, але це не пароль. У такому випадку інженер оцінює проблему та позначає її як false positive – хибну тривогу. Сканери показують все, що здається неправильним, і видають багато нерелевантної інформації.

Опрацьовувати алерти можуть і розробники, але краще довірити це AppSec-ам. Вони відфільтрують вразливості, а девелопери зосередяться на своїх завданнях.

Як впроваджувати Application Security на проєкті

Існує кілька моделей роботи Application Security. На вибір впливають особливості проєкту. Наприклад, створення SOC-команди виправдано лише в масштабних проєктах. А для роботи з продуктами у хмарі навіть AppSec-команда часто не потрібна. Адже 99,9% комплаєнсів та перволів налаштовує хмарний провайдер. Тому побудувати все зможуть і девопси, а з боку AppSec потрібна буде лише перевірка їхньої роботи.

Зазвичай AppSec-спеціалістів можуть залучати у проєкти під такі завдання:

• Аудит – коли інженер аналізує системи та організації та надає звіт, чи все відповідає нормам безпеки. Зауважу, що жоден продукт не може та не має відповідати абсолютно всім нормативам. Їх безліч, а тому під час аудиту варто орієнтуватися на бізнес-домен та особливості конкретного проєкту.
  
• Консалтинг – коли разово чи на постійній основі спеціаліст допомагає командам, де немає ролі AppSec. Консультації можуть стосуватися й окремих напрямів роботи. Наприклад, потрібно налаштувати шифрування даних. Розробники не впевнені, що використовують оптимальні алгоритми. Тоді AppSec оцінює, як побудовано механізм шифрування, і за необхідності радить щось виправити.
  
• Інтеграція в SDLC – коли Application Security включається у життєвий цикл розробки. Особисто для мене це найцікавіше і водночас найскладніше завдання. Особливо важко це зробити, якщо проєкт вже «‎біжить».
• 
  Наприклад, неможливо швидко замінити небезпечний канал комунікацій. Складно модифікувати і процеси. Тести на проникнення часто проводять безпосередньо перед релізом, і завжди щось знаходять. Задля усунення вразливостей реліз відкладається. Завдання AppSec-інженера – порекомендувати команді змістити тестування на більш ранню стадію за принципом Shift Left. Через додаткові перевірки CI-процес затягується, що сповільнює темп розробки. Тому краще інтегрувати у проєкт Application Security якомога раніше. Це збереже і час, і кошти.

Як AppSec-фахівцеві організувати свою роботу

План роботи зазвичай такий:

• Комплексний аналіз. Ця оцінка допоможе розставити пріоритети у знайдених проблемах і створити екшен-план. Неможливо охопити все й одразу. Визначте критичні недоліки. Наприклад, у Healthcare інколи використовують публічні ендпойнти, де можна отримати дані про пацієнта, просто передавши ID. Ця проблема вимагає негайного вирішення. Бувають проблеми, що витікають із самих процесів. Тоді спершу фіксимо процесуальні недоліки.
  
• Виправлення проблем. Може стосуватися як старих частин проєкту, так і нових фіч. Виправлення можуть відбуватися паралельно за обома цими напрямами. Зазвичай вказані задачі виконуються в shadow-режимі. Тобто команда розробки в принципі не знає, що робить AppSec. Тим часом фахівець аналізує код і систему, готує звіти та передає їх техлідам, а надалі перевіряє реалізацію.
  
• Постійна інтеграція AppSec. Коли нагальних проблем немає, беремось інтегрувати процеси безпеки. Це варто робити на всіх етапах життєвого циклу ПЗ. План інтеграції може бути суворим або більш гнучким, коли спирається не стільки на виправлення помилок, скільки на покращення безпеки. Жодна система не може бути на 100% захищеною. Завжди є шляхи подальших покращень.
  

Кар’єрний розвиток AppSec-інженера

Професія AppSec передбачає виконання різних завдань різної складності, а отже й варіантів розвитку у цій сфері безліч. Можна рухатись у бік Blue Team чи Red Team.

Якщо ви вмієте проводити тести на проникнення і хочете зосередитись на цьому – ось вам ще один шлях. Можна фокусуватися на окремій технології. Наприклад, на роботі з хмарними платформами або на системах на базі штучного інтелекту.

Йдеться не про зміну професії, а про відкриття для себе нової спеціалізації. В Application Security ви зможете працювати з документацією, із кодом, з DevOps-підходами.

Для початку варто базово знатися на цьому. А далі – збагачувати практичний досвід і може навіть подумати про сертифікацію за окремим напрямом. Це дасть вам змогу як Application Security інженеру вийти на новий професійний рівень.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

В умовах війни сторони використовують всі ресурси, але залишається відкритим юридичний бік цифрового протистояння. Європейська Асоціація програмної інженерії провела інтерв’ю з Максимом Курочко, керуючим партнером та адвокатом об’єднання MK Legal Service, та його колегою Артемом Остапенком, керівником ІТ/ТМТ практики, щоб дізнатися, які сервіси найбільше наражені на небезпеку атак та чи є це законним.

В першу чергу варто зазначити, що цілі та об’єкти атак в інших країнах та в мирний час відрізняються від того, що зараз відбувається в Україні.

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

За спостереженнями експертів, найчастіше об’єктами кібератак є інформаційно-комунікаційні системи операторів критичної інфраструктури, адміністраторів державних реєстрів, та баз даних, компаній які надають масові загальнодоступні послуги через Інтернет. Найпомітнішим кейсом такої атаки було падіння «Київстару» у грудні минулого року, проте атаки менших масштабів відбуваються регулярно.

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

За допомогою атак хакери не тільки намагаються паралізувати критичну інфраструктуру та блокувати діяльність ресурсів державної влади, а також здобувати персональні дані українців та використовувати їх зі злочинними намірами.

Що ж стосується питання законності таких атак, то законодавство кожної країни регулює питання хакерства окремо. Проте не існує організації, яка б контролювала порушення на міжнародному рівні, тому притягти російських хакерів до відповідальності наразі складно. Однак варто згадати, що українські айтівці атакують ворожі ресурси не менш активно, тому це протистояння продовжується на рівних умовах.

В умовах постійних атак потрібен захист. На тлі цього експерти зазначають, що можливості українських фахівців із кібербезпеки значно зросли, як і технічні можливості. MK Legal Service також докладає зусиль до цього напряму, маючи низку успішних кейсів.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Рішення: Це виявилося завданням із викликами, що вимагало від нас не лише технічних знань, але й уміння ефективно комунікувати та співпрацювати з різними командами й партнерами. Ми вибудовували весь процес із нуля та витратили понад 96 тисяч годин для запуску фінансового мобільного застосунку.

Працюючи із такими вводними, створення застосунку ми розділили на чотири рівні:

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

Розробка базових функцій, без чого не можна обійтися. Застосунок має працювати 24/7, бути надійним, безпечним і швидким. У ньому має бути зручний і зрозумілий клієнтський шлях – починаючи з онбордингу й до отримання продуктових послуг.

Синхронізація усіх «пазлів» системи. Мобільний застосунок – це лише вершина айсберга. Крім створення мобільного застосунку, паралельно ми працювали над розробленням внутрішніх інформаційних систем компанії: створенням мобільного бекенду, розробленням інтерфейсів операторів, систем бек-офісних процесів, касової системи.

Створення унікальних для ринку продуктів. Окрім звичних платіжних послуг, у застосунку реалізовано ексклюзивні для ринку продукти та переваги: 20% вигоди на послуги з доставки й післяплати, посилку у кредит, купівлю власних облігацій, переказ коштів на відділення, розрахунок за посилки та інше.

Звісно, реалізуючи це вперше на ринку, ми не могли не зіткнутися із челенджами – як внутрішніми, так і зовнішніми.

Виклик № 1: дефіцит вузькопрофільних фахівців і синхронізація процесів

До розробки першого MVP (мінімально життєздатний продукт) ми залучили до 15 працівників із департаменту ІТ. Це був перший MVP всередині компанії, створений менш ніж за 2 місяці. Його завданням було показати потенціал життєздатності.

Ми розпочали роботу, чудово розуміючи, що багато компетенцій будемо нарощувати поступово. Адже продукт не створюється одномоментно. Також у наших планах масштабувати його не тільки в Україні, а й у Європі.

З розвитком застосунку нам не вистачало вузькопрофільних спеціалістів, які мали б досвід у фінансовому секторі. Так, окрім девелоперів, до команди приєдналися методологи, аналітики, команда впровадження core-banking, фахівці з управління електронними підписами. У нас з’явилися спеціалісти, які займаються налаштуванням карткових продуктів, фахівці з криптографії та інші.

Зараз до проєкту залучено близько 60 людей: розробники, тестувальники, фахівці з бізнес-аналізу та support-продукту.

З розширенням команди та запуском безлічі паралельних процесів і систем у нас був виклик синхронізувати релізний цикл різних команд для одночасного виходу продукту. Наприклад, якщо девелопмент працював за agile-методологіями, то запуск процесів і систем відбувався за класичним waterfall. А додаючи сюди ще й різний технологічний стек, то це було завдання не з легких.

Щоб синхронізувати роботу департаменту, ми повністю перепланували технічну складову випуску релізів, програмних продуктів і тестування. Зараз графік виходу оновлень запланований на кожні 2 тижні. Зі старту бета-версії застосунку вже було реалізовано 13 оновлень для користувачів Android та 9 релізів для iOS.

Виклик № 2: співпраця із партнерами та підрядниками

Фінансовий застосунок NovaPay – це власна розробка компанії, проте у процесі його створення ми працювали з різними партнерами та підрядниками.

Коннект із фінансовими системами й онлайн онбординг із Дія ми зробили у звичному режимі, бо в цьому вже мали експертизу. Але для деяких напрямів нам знадобився час. Досить довго ми обирали партнера, який зміг надати нам якісний Liveness Detection – біометричну систему ідентифікації. Адже важливо було, щоб система могла ідентифікувати клієнта по фото зі збігом близько 90%.

Найскладнішим технічним завданням виявилося те, що весь ринок (підрядники core-banking, процесинг, liveness та інші) спрямований на роботу із банками. Враховуючи, що NovaPay – перша небанківська фінансова установа, яка створила свій мобільний застосунок із власною емісією карт, ми маємо певні нефункціональні вимоги, що відрізняють нас від банків. На старті проєкту їх розрахувати було неможливо.

Шлях із нуля до продуктиву проходили не тільки ми, а й наші партнери, створюючи релізи своїх систем спеціально для NovaPay.

Виклик № 3: безпекова складова

Коли ми отримали розширену ліцензію НБУ, то не тільки почали роботу над новими фінансовими продуктами для клієнтів. Разом із цим ми отримали регуляторні вимоги й обов’язки, які можна порівняти із великими банками. Одночасно із запуском застосунку у нас трансформувалася і система інформаційної безпеки.

Компанія вже мала сертифікати безпеки PCI DSS та ISO 27001, що призначені для оцінки внутрішніх контролів компаній стосовно безпеки. Додатково ми розробили нову стратегію інформаційної безпеки, яка спрямована на мінімізацію ризиків і водночас дає змогу не гальмувати темп змін.

Враховуючи, що NovaPay планує виходити на європейський ринок, наша система захисту даних будується таким чином, щоб відповідати вимогам безпеки як України, так і ЄС. Для забезпечення безперервної діяльності всіх сервісів та захисту даних ми використовуємо гібридну інфраструктуру. Частина сервісів розміщена на «землі», частина – у «хмарі».

Основні компоненти «мобільного банку», усі транзакції здійснюються у «хмарі». Завдяки цьому клієнти NovaPay можуть бути впевнені – їхні фінанси та дані максимально захищені. Система спроєктована таким чином, що у разі DDoS-атаки вона не призведе до простою наших сервісів і, що найголовніше, до витоку даних клієнтів.

Виклик № 4: ми не маємо права на помилку

Зараз, коли мобільний застосунок NovaPay функціонує і стабільно розвивається, найбільший челендж, який стоїть перед IT-командою, – це зрости у кілька разів. Як технічно, так і продуктово.

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

Враховуючи навантаження платіжної системи NovaPay, у нас немає права на помилку. В той час, коли найбільші українські банки із першої десятки в середньому обробляють 1,5 мільйона транзакцій за день, ми опрацьовуємо орієнтовно 3–3,5 мільйони транзакцій. Це оплати у відділеннях, онлайн і транзакції всередині мобільного застосунку NovaPay. Тож, далі буде.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Про основні підходи до тестування дизайн-макетів розповідає Олексій Дивінець, General QA в ІТ-команді NIX.

Невже це не завдання дизайнера?

Зовнішній вигляд сайту – досить суб’єктивна річ. Проте його стиль не має порушувати принципи UI-дизайну (User Interface). Йдеться не лише про інтерфейси сайтів чи застосунків, але й вигляд побутової техніки, автомобілів, інших речей та пристроїв.

Раніше діяло правило «трьох кліків»: зробити так, щоб користувач за три кліки досягнув мети. Сьогодні ж застосунки настільки розростаються, що і трьох кліків замало. Тому головне в дизайні інтерфейсів – переконатися, що шлях юзера зрозумілий йому за будь-яких умов. Це задача UI/UX-дизайнера. Та якщо такого спеціаліста немає в команді, тестувальник цілком може взяти на себе цю роль.

Для початку дізнаємося, як користувачі взаємодіють із дизайном

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

Зазвичай фахівці користуються паттернізованими схемами розробки сайтів, приділяючи увагу розміщенню елементів інтерфейсу там, де найбільше сконцентрована увага користувачів. Це пов’язано з дослідженнями UI/UX-експерта Якоба Нільсена, засновника компанії Nielsen Norman Group. Він з’ясував, як люди переглядають сторінки сайтів. Виявилося, ми не читаємо сторінки по вертикалі. Замість цього швидко «‎скануємо» їх, шукаючи необхідні ключові слова і фрази.

Згодом на основі досліджень Нільсена сформували основні типи поведінки користувачів під час переглядання сайтів: F-патерн, Z-патерн та Діаграма Гутенберга.

• F-патерн. Рух погляду в цьому випадку переміщується за осями літери F, як на ілюстрації нижче. Цей шаблон актуальний передусім для сторінок із текстовим наповненням та монотонною сіткою з блоків (наприклад, із товарів в інтернет-магазині). Але F-патерн не працює з екранами смартфонів. Тобто він стосується лише десктопних версій застосунків. Під час тестування UI варто оцінити, наскільки легко можна охопити основну інформацію на сторінці. Для цього заголовок має бути великим і влучним, відображати суть тексту. Ключову інформацію слід подавати в перших абзацах. Інше структурувати: зі списками, розбитими на невеликі абзаци, з підзаголовками.
  

• Z-патерн. Тут погляд користувача рухається по екрану за осями літери Z, від точки 1 до 2, потім 3 та 4, як показано на ілюстрації нижче. При цьому максимум уваги зосереджується на перших трьох точках. Під час тестування треба переконатися, що головні елементи розміщені саме у точках 1, 2 і 3 (плюс 4). Якщо якийсь блок випадатиме з «маршруту» погляду людини, то може залишитися непоміченим.

• Діаграма Гутенберга. Цей патерн схожий на попередній, але тут поведінка користувачів складніша: вони ніби сканують поглядом сторінку, пересуваючись із пункту до пункту, звертаючи увагу на ключові слова і фрази, які виділяються на фоні решти тексту. Зона А – головна, сюди люди дивляться найчастіше. Тож переконайтеся, що тут знаходяться логотип і назва компанії чи заголовок. Далі за пріоритетом йде зона B. Тут варто розташувати контакти, форму замовлення дзвінка та інші подібні елементи. Зона C, на відміну від 3-ї точки у Z-патерні, не варта уваги, оскільки сюди мало хто дивиться. Перевірте, що тут немає дійсно важливої інформації та кнопок. Зона D є блоком ухвалення рішення або виходу. Тут можна розміщувати, наприклад, кнопку замовлення, щоб підштовхнути юзера до покупки.

Цими прикладами патерни поведінки користувачів не обмежуються. Насправді їх безліч. Але принаймні ці можуть слугувати орієнтирами та допоможуть оцінити структуру макета.

Що тестувальник перевіряє на макеті сторінки

Розташування елементів на сторінках має відповідати принципам дизайну та досвіду користувача (UX). Тобто всі елементи повинні розташовуватися таким чином, щоб люди швидко знаходити потрібну їм інформацію та взаємодіяти із сайтом без зайвих зусиль.

Основні принципи розташування елементів на сайті:

• Ієрархія. Елементи на сторінці повинні розміщуватися відповідно до значущості. Найважливіші, скажімо, головне меню, мають бути на видноті. Не надто важливі елементи, наприклад, інформацію про користувача, можна розмістити у менш видимих місцях.
• Рівномірність. Це про зручність користування вебресурсом. Наприклад, якщо важливі кнопки розташовані з одного боку, то решта елементів відповідно повинні бути розміщені з іншого боку, що візуально створюватиме баланс.
• Простота. Простий і лаконічний дизайн не заважатиме користувачам сприймати інформацію з сайту. Це стосується таких зайвих елементів, як анімація чи великі зображення.

Оцініть, що в наявному дизайні може знижувати конверсію. Найбільш поширеними помилками вважаються:

• Відсутність адаптивності. Це чи не перший фактор, який знижує конверсію. Сайт повинен коректно відображатися і працювати на екранах різного розміру та на різних пристроях (комп’ютери, смартфони, планшети тощо), забезпечуючи користувачам зручність і задоволення від використання.
• Складна навігація. Критичне порушення принципів UI/UX. Користувачу відразу мають бути зрозумілі основні розділи сайту, меню, назва компанії, контакти. Навіть найбільш креативний дизайн не повинен конфліктувати з наочністю. Якщо користувач не розумітиме, як знайти потрібний розділ чи фільтрувати товари, то ресурс не буде перетворювати відвідувачів сайту на клієнтів.
• Перенасиченість рекламою. Нерозбірливо розміщені оголошення будь-де лише відштовхують потенційних покупців. До того ж заважають користувачам зрозуміти функціонал сайту та виконувати цільові дії (вибір товару, оформлення замовлення, коментування на сторінці відгуків тощо). Крім того, наявність великої кількості банерів, модальних вікон та popup-ів впливає на ставлення до бренду або продукту.
• Автоматичне програвання рекламних банерів. Анімаційна реклама здебільшого викликає у користувачів вкрай негативну реакцію. Максимальне роздратування – це коли аудіо раптово автоматично вмикається на сторінці. Нашою природною реакцією є спроба якнайшвидше закрити подібний елемент чи встановити блокувальник реклами у браузері. Тож переконайтеся, що на сайті, з яким ви працюєте, немає анімаційної реклами або за замовчуванням вимкнено звук.
• Слабка диференціація реклами. Банери повинні біти візуально відокремленими від основного контенту на сайті та позначеними як реклама (цього вимагають інструкції Google Ads). Інакше користувач, клікаючи на оголошення, перейде на інший ресурс. А це може знизити довіру до першого. Переконайтеся, що рекламні блоки не виглядають як елементи основної навігації на сайті (тематичні розділи, сніпети статті тощо).
• Некоректне використання каруселі. В цілому юзери позитивно ставляться до каруселі, але за умови, що все працює коректно. Часто слайди змінюються надто швидко. Користувачі не встигають натиснути на банер і вимушені гортати карусель назад. Або ж запізно клікають і переходять на іншу сторінку. Слід перевірити, чи встигаєте ви прочитати все необхідне для розуміння інформації та натиснути на рекламу. В ідеалі карусель зупиняється при наведенні на неї курсором.
• Відсутність елементів-підказок. Сучасні сайти, особливо онлайн-магазини, мають розгалужену структуру з десятками розділів, підрозділів, категорій, підкатегорій. Шлях покупця до кінцевої сторінки може бути заплутаним. Тож рекомендовано виносити популярні внутрішні розділи на вищі рівні меню. Наприклад, на сторінку «‎Побутова техніка» додати лінки на популярні пропозиції цих товарів. Це дозволить користувачеві швидко перейти до вибору.
• Неочевидне поле пошуку. Якою б логічною не була організація меню, багатьом легше набрати запит у пошуковому полі. Подекуди на сайтах не завжди просто знайти цей елемент. Пошук може загубитися серед інших блоків або мати вигляд прихованої іконки, яка збільшується до рядка лише після натискання на неї. Краще обрати для пошуку помітний розмір та розмістити на видному місці на кожній сторінці.
• Погана стилізація клікабельних елементів. Інколи юзер не розуміє, де клікати або тапати: по всій зоні картки товару, по його назві чи зображенню або ж по кнопці «‎Детальніше». Людей це часто плутає. Починаються повторні натискання, зайвий час на це і на додачу роздратування. Щоб уникнути таких проблем, клікабельні елементи варто стилізувати – зробити так, аби їхній дизайн змінювався при наведенні або натисканні курсором. Допоможуть із цим CSS чи подібні технології верстки.

Як виміряти вплив UI-дизайну на конверсію

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

• Системи аналітики. Тут головний – Google Analytics. Це один із найпотужніших інструментів аналізу поведінки відвідувачів. Він надає інформацію про те, як люди взаємодіють із сайтом, чи досягають цілей, де виникають проблеми. Втім, існують і аналоги, більш спеціалізовані інструменти, як-от SimpleReach. Він дозволяє відстежувати поведінку юзерів онлайн, вимірювати час на реєстрацію чи пошук чогось на сайті.
• Теплова карта. Цим терміном називають різновид графічного представлення даних за допомогою кольору. У випадку сайтів теплова карта показує, куди відвідувачі клікають найчастіше. Такі зони будуть червоними, інші – жовтими чи зеленими. Це допомагає зрозуміти, які елементи є важливими або такими, що викликають хибні кліки. Для створення теплової карти можна використати застосунки Plerdy або Hotjar.
• A/B-тестування. Його мета – за допомогою контрольних груп порівняти різні варіанти дизайну, функціоналу, контенту тощо. Наприклад, одна аудиторія взаємодіє зі старим дизайном (група A), інша – з новим (група B). У результаті можна побачити, яке рішення дає кращі показники конверсії та підвищує рівень задоволеності користувачів.

Якщо тестувальники все-таки беруться оцінювати дизайн-макет, то здебільшого покладаються на аналіз за чек-листами. Адже не завжди у проєктах вистачає бюджету та людських ресурсів для використання додаткових інструментів. Є можливість взяти більше? Радимо по максимуму розібратися в темі. Звісно, всіх тонкощів UI/UX не охопити. Проте як мінімум базово оцінити дизайн-макет здатен кожен QA.

Тестування дизайну допоможе покращити інтерфейс та підвищити показники досягнення цілей вашими користувачами. Будь-який бізнес схвально поставиться до такої ініціативи QA-команди.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Редакція не несе відповідальності за інформацію, викладену у блогах. Це особиста думка автора.

Резиденти Європейської Асоціації програмної інженерії (EASE) поділилися своїм досвідом мобілізації працівників і поточною ситуацією із призовом.

Яка хвиля мобілізації стала найсерйознішою

Керівний партнер та адвокат об’єднання MK Legal Service Максим Курочко розповів, що з перших днів повномасштабного вторгнення четверо юристів пішли до армії добровольцями. При цьому вони обіймали важливі для компанії посади, як-от керівники податкової, корпоративної та IT/TMT практик компанії. Оскільки станом на лютий 2022 року штат компанії становив 11 осіб, то до армії пішло майже 40% працівників.

Лютий-березень 2022 року був найтяжчим періодом. Хоча всі працівники пішли воювати добровільно, це стало серйозним ударом для бізнес-процесів. Виходом зі складного становища для компанії стало бронювання керівного складу відповідно до вимог законодавства.

Як відбувається бронювання працівників

Максим Курочко також поділився основними даними, що стосуються бронювання згідно з постановою КМУ від 27 січня 2023 року № 76.

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

Крім того, військова спеціальність не має підпадати під дефіцитні військові спеціальності. Єдиний виняток – працівник належить до керівного складу компанії. У такому випадку його можна забронювати незалежно від спеціальності.

Оскільки тема мобілізації стала надзвичайно важливою для українців, MK Legal Service надає юридичні послуги іншим IT-компаніям: допомагає з питаннями щодо бронювання, незаконних дій із боку ТЦК, визнання компаній критично важливими для економіки тощо.

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

Як компанії допомагають працівникам, що зараз на фронті

Політикою компанії стосовно мобілізованих колег також поділилася Діана Ясько, Employer Brand Specialist компанії Uptech.

Вона зазначила, що їхні працівники також відразу стали до лав ЗСУ і територіальної оборони на початку повномасштабного вторгнення, що стало гордістю для команди. Компанії вдалося уникнути збитків завдяки тому, що більшість членів команди повернулися до роботи в перший день вторгнення.

Компанія дбає про всі потреби колег-військових, забезпечуючи їх необхідним спорядженням і допомогою. Додатково надає фінансову підтримку для своїх колег, а їхні сім’ї підтримує донейтами.

Крім того, за працівниками, які воюють, закріплено можливість повернутися до роботи в будь-який момент. А ще компанія присвячує час наданню консультаційної підтримки для членів команди, щоб тримати своїх працівників у курсі правових аспектів мобілізації.

Попри те, що мобілізація працівників завдає проблем бізнесу, українські IT-компанії продовжують допомагати своїм мобілізованим працівникам і робити внесок у захист країни.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Розібратися в нюансах кросбраузерного тестування допоможе Тетяна Шанайда, Manual QA в ІТ-команді NIX.

Навіщо потрібне кросбраузерне тестування

Користувачі взаємодіють із сайтами з комп’ютерів, смартфонів, планшетів, ТВ, навіть холодильників. І на кожному пристрої є різні браузери. В результаті будь-яка комбінація браузера, девайса й ОС може не реагувати відповідно до очікувань юзера або вимог замовника.

Макет, доступність, якість і продуктивність можуть сильно відрізнятися в кожній ситуації. Більшість браузерів базуються на різних рушіях (layout engine), тому ці програми по-різному відтворюють CSS, HTML та JavaScript. І проблема може виникати не лише в різних браузерах, а й в одному, але для різних пристроїв. Це пов’язано з інтеграцією з ОС того чи іншого рушія.

Як відповідь на все це багато років тому з’явилось кросбраузерне тестування. Його мета – переконатися, що сайт чи вебзастосунок коректно працюють і відображаються на різних браузерах та пристроях із різними ОС. Кросбраузерне тестування можна проводити як окремий вид тестування, так і комбінуючи з іншими видами тестування.

Щодо проблем через відсутність кросбраузерності, то це може бути як відображення тексту не тим шрифтом, яким було задумано в одному із браузерів, не відцентрованість зображення відносно інших елементів на сторінці, так і більш негативні сценарії.

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

Інколи проблеми кросбраузерності можуть призводити до зниження продуктивності вебзастосунку. Наприклад, браузер не може відтворити потрібний сценарій JS чи HTML5 і повністю зависає.

Тестувальник не може закривати очі навіть на некритичні помилки. Будь-який дефект відображення сайту погіршуватиме користувацький досвід і, як наслідок, це може призвести до відтоку відвідувачів. Саме тому важливо проводити кросбраузерне тестування.

Що необхідно для старту кросбраузерного тестування

Вам треба серйозно підготуватися до перевірки коректності роботи сайту чи застосунку в різних браузерах. Для цього слід визначитися із трьома головними питаннями.

1. У яких браузерах тестувати

На сьогодні існують десятки браузерів і сотні їхніх версій: мобільні та десктопні, для Windows, MacOS чи Linux, для Android або iOS. Зрозуміло, що всі їх охопити немає потреби. Тому варто вибрати найбільш важливі для замовника. Для цього орієнтуйтесь на...

• Статистику популярності браузерів. Знайти її можна на різних ресурсах, але найбільш авторитетним є Statcounter. Він показує поширеність браузерів у різних регіонах світу. І там дійсно є відмінності. Наприклад, в Азії браузер Samsung Internet популярніший за Firefox, який частіше використовують у країнах ЄС.
• Вебаналітику. Якщо це наявний сайт із певною аудиторією, можна звернутися до його власної статистики щодо відвідувачів. Її можна знайти, наприклад, у звітах Google Analytics чи аналогічного сервісу. Звісно, аналітика має бути заздалегідь підключена та налаштована, щоб збирати необхідну вам інформацію.
• Індивідуальні особливості проєкту. Інколи замовники вказують цільові для їхнього сайту браузери. Також вибір може бути викликаний нюансами аудиторії. Наприклад, на сайті з продажу аксесуарів для iPhone відсоток користувачів мобільного Safari напевно буде вищий, аніж в середньому по тому ж регіону.

Крім основних варіантів, також необхідно пригадати й менш очевидні:

• Браузери на нетипових пристроях. Люди можуть переглядати сайти на різних ОС Smart TV чи Android TV, ігрових консолях на кшталт Sony PlayStation чи Nintendo Wii та навіть деяких смартгодинниках. Тож якщо ваш проєкт передбачає використання вебзастосунку на подібних пристроях хоча б мінімальною аудиторією, ці варіанти теж слід окремо перевірити.
• Попередні версії браузерів. Зазвичай тестування проводять на найбільш актуальних версіях браузерів. Однак варто виходити за межі. Наприклад, коли з’являється новий реліз браузера, не всі користувачі відразу оновлюються. Деякі юзери через технічні обмеження їхніх девайсів взагалі роками користуються застарілими браузерами. Тож варто перевіряти сайт і на більш ранніх збірках.
• Бета-версії для розробників. Вони є у кожного браузера, мають власні назви (наприклад, Chrome Canary чи Safari Technology Preview) і демонструють можливості, які згодом можуть з’явитися в загальних версіях. Завдяки цьому ви, так би мовити, зазирнете в майбутнє і спрогнозуєте, чи не виникне проблем із сайтом після оновлення браузера.

Загалом експерти радять закладати у план тестування мінімум 4-5 браузерів. Це мають бути 3-4 основних, популярних, і 1-2 рідкісних, старих чи специфічних (про всяк випадок). Але за наявності бюджету ці показники можна збільшити.

2. На чому тестувати

Комусь відповідь на це запитання може здатися очевидною, але насправді все не так просто. Існує одразу кілька варіантів, на чому перевіряють кросбраузерність:

• Реальні пристрої. Ідеальний сценарій, коли є кілька комп’ютерів, смартфонів і планшетів на різних ОС із повним набором браузерів. Це максимально надійні й наочні умови для тестів. Але мати всі комбінації неможливо, і навіть популярні варіації зустрічаються рідко. Адже це потребує відповідного бюджету у проєкті.
• Емулятори. Так називають десктопний софт, розширення для браузерів та онлайн-сервіси, які імітують поведінку різних браузерів. Вони можуть бути платними та безоплатними, мати різний набір доступних браузерів та перевірок. Емулятори оптимальні з огляду функціонала, ціни й простоти використання.
• Віртуальні машини. За допомогою спеціального ПЗ на одному комп’ютері встановлюється кілька окремих ОС зі своїм набором браузерів. Це надає трохи більше можливостей, ніж емулятори. Але віртуальні машини потребують ресурсів і знань та мають певні обмеження в тестах мобільних браузерів.
• Ферми девайсів. Це цілком реальні пристрої, до яких у вас віддалений доступ. Таке хмарне рішення є платним, проте воно надає більше можливостей, ніж емулятори, і не вимагає складного сетапу віртуальних машин. Просто заходите на сайт, обираєте ОС та браузер і запускаєте тестування. Прикладами таких ферм є LambdaTest і BrowserStack.

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

3. Як тестувати

Фінальний крок підготовки до тестів – обрати підхід до цієї роботи. Варіантів є два:

• Мануальне тестування. Тестувальники послідовно перевіряють комбінації браузерів, операційних систем та девайсів, використовуючи техніки тест дизайну (наприклад, парне тестування). Тобто на власні очі оцінюють роботу застосунку за зазначеними користувацькими флоу. Це дозволяє реально побачити можливі дефекти, з якими стикаються юзери. Також мануальний підхід допомагає при перевірці нестандартних, унікальних флоу. З іншого ж боку, таке тестування може тривати довго і нести ризик помилок із категорії людського фактора.
• Автоматизоване тестування. Для перевірок використовуються спеціальні інструменти. Вони можуть бути готовими або створеними самим QA-інженером. Вибір перших великий: від простих тулзів, які роблять лише скриншоти сторінок, до фреймворків типу Selenium, які здатні опрацювати майже будь-які перевірки. Це пришвидшує тестування і позбавляє помилок людини. Але автоматизовані тести працюють за визначеними сценаріями, що не завжди добре. А ще для написання тестів і використання платних тулзів потрібен додатковий бюджет.

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

Як проводиться кросбраузерне тестування

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

• Візуальне тестування. QA-спеціаліст має переконатися у відповідності вмісту та дизайну сторінок тому, що очікується. Тобто слід перевірити саме вигляд сторінки сайту: від відображення шрифтів і зображень до CSS-анімації й того, як виводяться елементи інтерфейсу типу кнопок меню (чи в потрібному вони місці, чи з правильним дизайном тощо). Все має бути саме таким, як на макеті. Сучасні стандарти HTML-верстки передбачають адаптивність сайтів під екран пристрою. Тому все має відображатися коректно на будь-якому за розміром та роздільною здатністю дисплеї. Але в деяких випадках може бути ще й мобільна версія сайту, тож її також необхідно оцінити візуально.
• Функціональне тестування. Цей пакет перевірок має показати: в будь-якому браузері сайт та його окремі елементи працюють саме так, як задумано. Таку задачу слід сприймати комплексно. По-перше, QA-фахівець має перевірити кожну кнопку та функцію в десктопному та сенсорному форматах управління. По-друге, слід переконатися, що не порушені інтеграції зі сторонніми сервісами. По-третє, інженер має звернути увагу на доступність сайту на кшталт альтернативного тексту для зображень чи субтитрів на відео. Адже без цього користуватися сайтом для деяких користувачів буде в принципі неможливо або як мінімум – дуже незручно.

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

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

• Проблеми скриптів. Передусім це стосується елементів на JavaScript. Це різні види анімації, відтворення дизайнерських ефектів, робота динамічних елементів інтерфейсу тощо. При збоях вони можуть порушувати дизайн сторінки та навіть викликати зависання. На деяких сайтах для схожих задач замість JS можуть використовувати технології HTML5 та CSS3. Ці рішення надійні та швидкі, але не всі браузери повною мірою підтримують їх. Тож це також слід перевірити.
• Коректність роботи інтерфейсу. Активних елементів меню може бути дуже багато. В ідеалі треба протестувати роботу всіх. Але особливу увагу варто приділити основним для юзер-флоу кнопкам, завантаженню зображень, аудіо та відео (особливо за наявності lazy loading), валідації даних у формах (логін, оформлення покупки, реєстрація, підписка тощо) та надсиланню цих форм. А ще варто перевірити роботу всіх попапів та банерів.
• Управління сайтом. Це дуже важливе питання, якому інколи не приділяють достатньої уваги. І дарма! В деяких випадках навіть скролинг може працювати некоректно чи неповноцінно (наприклад, є прокрутка по колесу мишки, але не за стрілочками на клавіатурі). Також варто перевірити способи вводу та виділення тексту, переміщення по сайту тощо. Окремо варто опрацювати управління на пристроях із сенсорним екраном, де можуть виникати певні труднощі та баги.
• Інтеграція зі сторонніми ресурсами. В різних браузерах по-різному працюють не тільки повноцінні сайти, але й окремі сервіси, які можна вбудовувати в ці сайти. Це можуть бути, наприклад, чати для спілкування користувачів зі службою підтримки, капчі для ідентифікації людей, інтерактивні мапи, платіжні сервіси, вбудовані клієнти YouTube тощо. Тож QA-спеціаліст має переконатися, що все це і виглядає адекватно, і працює нормально на будь-якій платформі.

Що ще важливо – не бійтеся спілкуватися з розробниками, які створили той чи інший елемент. Вони докладно пояснять особливості використаних технологій. Буває, що проблеми є не стільки багом, скільки специфічною поведінкою фічі. Спільно з розробниками можна оцінити критичність знайденої помилки. А іноді збій зовсім некритичний: лише в маловідомому браузері й за умов, які складно відтворити в житті.

Отже, ми розібралися, чому кросбраузерне тестування – це важливий етап в розробці вебзастосуків. Таким чином ви перевіряєте сумісність програми з різними браузерами та платформами. А разом із тим – можете підвищити якість продукту, забезпечуючи користувачам сталий інтерфейс та функціонал незалежно від обраного програмного забезпечення. Тож вкладаючи ресурси у кросбраузерне тестування, ви підтримуєте формування оптимального користувацького досвіду.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Як правильно працювати із референсами й створювати унікальний дизайн, ділиться Юлія Федотова, Lead UX/UI Designer в ІТ-команді NIX.

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

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

У виборі референсів немає жодних обмежень ані за темами, ані за різновидами продуктів.

Як на основі «чужого» зробити «своє»

Чим більше референсів оберете для власного дизайну, тим унікальнішим він буде. Ви наслідуєте елементи чужих робіт: пошукове поле, повзунки, типи іконок, кнопку виходу з акаунту, сторінку ліцензії. Якщо із двох-трьох ресурсів усе скопіювати, то плагіат рано чи пізно помітять.

А якщо спеціально не шукати референси? Це не означає, що ваша робота буде цілком унікальною. Усе нове – це добре забуте старе.

Проаналізувавши наявні дизайни, в них можна знайти схожі елементи. Це нормально. Щоб виділити ваш проєкт, не потрібно створювати чудернацькі форми кнопок чи розташовувати меню замість хедеру у футері сайту. Замість очікуваної wow-реакції, отримаєте непорозуміння від користувачів*. Ваш дизайн має вирішувати проблеми, а не створювати нові.

* Для wow-ефекту допускаються нестандартні рішення, щоб виділитися й запамʼятатися. Щоб порушувати правила, треба їх добре знати. Тоді ви свідомо йдете проти правил. Для більш утилітарних продуктів краще користуватися знайомими користувачеві патернами.

З чого почати пошук референсів

Головне правило створення дизайну – every element should make sense. Зрозумійте, яку проблему користувача вирішуєте, і шукайте відповідне візуальне рішення. Наприклад, на сайті потрібна кнопка «Замовити». Сенс такої кнопки – спонукати до покупки товару чи скористатися послугою.

Колір, форма і текст елементу мають запевнити юзера, що його дії на сайті приведуть до бажаної цілі. Тобто кнопка повинна бути інтуїтивно зрозумілою, привертати увагу та легко розпізнаватись. Інакше потенційний клієнт покине сайт.

Або інша задача: зробити таблицю з великим вмістом. Пошукайте референси, як інші впорались із цим, оцініть, чи дійсно вдало. Ви можете натрапити на чужі помилки, але вбережете власний дизайн від них. Проаналізуйте, як «розвантажити» дизайн, оберіть найбільш вдалий варіант відповідно до вимог проєкту.

За який би елемент дизайну ви не взялися (меню навігації, форма зворотного зв’язку, інтерактивні переходи) все має створюватися для чогось. Як-от для полегшення сприйняття інформації, покращення обслуговування клієнтів, швидкого пошуку тощо. Аргумент «Тому що так красиво» не є достатнім.

Ідеї для пошуку референсів

Best practices

В інтернеті є багато добірок, де круто реалізоване те чи інше рішення. Ви швидко знайдете готові варіанти та зрозумієте вектор для подальшого пошуку.

Наприклад, потрібно зробити сайт інклюзивним для людей з інвалідністю. Так і загугліть задачу. У пошуковому рядку пишіть ключові слова на кшталт best practices of web accessibility або examples of inclusive UI/UX. Англійська – мова міжнародного бізнесу, тому такий пошук надає доступ до більшої кількості ресурсів, ідей.

Подивіться, як реалізована певна функція у продуктах Google, Apple, Microsoft. Лідери ІТ-галузі задають тренди та використовують найновіші практики. Навіть якщо не знайдете у них потрібний референс, то хоча б прокачаєте надивленість. А це теж плюс у роботі дизайнера.

Ресурси для дизайнерів

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

• Behance. Одна з найвідоміших платформ, де креативники викладають свої проєкти. Тут можна обмінюватись відгуками та знаходити референси на будь-яку тематику.
• Pinterest. Онлайн-сервіс з останніми трендами у світі дизайну. Дозволяє створювати власні дошки з натхненням і ділитися своїми ідеями («пінами»).
• Awwwards. Тут змагаються дизайнери та web-розробники з усього світу. Професійне журі визначає переможців у таких номінаціях: «Сайт дня», «Сайт місяця», «Сайт року». На порталі зібрано багато цікавих робіт. Є розділи з інтерв’ю від впливових дизайнерів, а також статті з вебдизайну.
• Mobbin. Колекція застосунків, що відображає найкращі рішення в mobile-дизайні. На платформі зібрані скріншоти, які показують user journey map різних програм. Є платна версія з розширеним доступом.
• Siiimple. Ресурс для тих, хто хоче навчитися створювати мінімалістичний дизайн. Ця добірка прикладів вебдизайну для поціновувачів простоти постійно оновлюються.
• Typewolf. Онлайн-ресурс спеціалізується на типографіці. Тут зібрані сайти різноманітної тематики. За фільтрами можна швидко знайти потрібний референс.
• Landbook. На платформі зібрані вдалі приклади дизайну елементів web-сайту. Галерея постійно оновлюється. Є можливість купити готовий  шаблон та адаптувати його під свої потреби.
• Muzli. Тут ви зможете слідкувати за трендами в дизайні. Знайдете ілюстрації, логотипи, приклади web-сайтів та мобільних застосунків тощо.
• Refero. Колекція елементів інтерфейсу та UX-шаблонів, щоб покращити свої дизайнерські навички.
• App Motion. Підходить поціновувачам мікроанімації та анімаційного дизайну.
• AppShots. Бібліотека із шаблонами для iOS, Android і web-дизайну. За фільтрами можна знайти потрібну ідею.

Щойно знайшли потрібні референси, погодьте їх із розробниками. Не всі елементи можна технічно реалізувати в межах лімітів: часових, фінансових, технічних.

Так ви ще до створення дизайну розпізнаєте ймовірні труднощі, які можуть виникнути при реалізації дизайнерських елементів у коді.

Для успішної взаємодії між командами розробників та дизайнерів потрібні:

• Регулярна комунікація. Обговорюйте референси, щоб уникнути непорозумінь.
• Детальна специфікація. Тобто набір вказівок для відтворення дизайнерських елементів. На його основі розробники оцінюють можливості для реалізації.
• Готовність до змін. Навіть у тісній зв’язці з розробниками ви не убезпечите себе від правок, але мінімізуєте їх.

Ще більше користі від референсів

Збирайте мудборди. Це добірка матеріалів, яка дозволяє спланувати настрій, стиль майбутнього дизайну. Сюди входять фотографії, іконки, зображення, скріншоти, шрифти, набір кольорів. Зібрати мудборд можна в Google-документах, Figma, створити дошку в Pinterest чи Behance.

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

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

Якщо до вашої команди приєднався дизайнер-початківець, також не ігноруйте етап створення мудборду. У процесі роботи ви побачите його навички, наскільки він розуміє завдання та загалом як мислить. З часом необхідність у цьому етапі роботи може відпасти.

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

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Штучний інтелект є новим та надважливим елементом національної безпеки й економічного розвитку для будь-якої держави. Адже всі держави, як дружні, так і ворожі до нас, приділяють велику увагу розвитку і впровадженню технологій AI/ML у різних сферах, а тому Україна, враховуючи ситуацію, що склалася, не може відставати в цьому питанні.

Країни та компанії, яким вдасться інтегруватися у стрімкий потік змін, спричинених технологіями AI/ML, отримають величезну перевагу та завжди будуть попереду конкурентів. Саме тому сьогодні такий великий попит на все, що дозволяє швидко і якісно впроваджувати розробки у сфері штучного інтелекту і машинного навчання для реалізації практичних завдань.

Відповідаючи на актуальні запити ринку, компанія De Novo, провідний український провайдер хмарних сервісів та послуг ЦОД, розробила нове сімейство сервісів: ML Cloud, Tensor Cloud і Hosted Tensor Infrastructure (HTI), для задач штучного інтелекту (AI) та машинного навчання (ML).

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

Завдяки прозорому ціноутворенню нові сервіси забезпечують 100% передбачуваність витрат, а загальна вартість використання в середньому удвічі нижча, ніж у випадку з аналогічними послугами гіперскейлерів.

Усі зазначені хмарні послуги об’єднані спільною концепцією та забезпечують доступ до найпотужніших у світі Tensor Core GPU NVIDIA H100, що значно прискорюють навчання моделей машинного навчання та підвищують продуктивність команд розробників, проте суттєво відрізняються в деталях:

• ML Cloud – це розвинена та багатофункціональна платформа, яка надає ML-інженеру повноцінне робоче оточення і звичне програмне середовище.
• Tensor Cloud та HTI забезпечують потужну, надійну та керовану обчислювальну інфраструктуру на основі тензорних процесорів та контейнерних технологій у колективній або приватній хмарі.
• Нові хмарні сервіси De Novo для AI/ML створені зусиллями українських фахівців та розгорнуті в українському дата-центрі. Поява цих інноваційних послуг не лише відкриває нові можливості для ML-інженерів, але й свідчить про те, що навіть попри війну інтелектуальний бізнес в Україні продовжує розвиватися, інвестувати в розробки та приносити користь країні у вигляді як сплачених податків, так і створення нових технологічних можливостей у межах всієї країни.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Олександр Дробот, JS developer в IT-команді NIX.

«‎Чистий» код – насамперед читабельний. У ньому все логічно: від назв змінних і функцій до розташування файлів. Ця властивість дозволяє зрозуміти навіть найскладніший код, а значить і підтримувати його буде простіше.

Надалі з кодом матимуть справу один чи кілька розробників. Це може бути легасі-код, який «‎успадкує» інша команда. Або до роботи з власним кодом повернеться той же розробник. Наприклад, для інтеграції нової фічі. І до того моменту він вже міг забути, що там робив і навіщо.

«‎Чистота» коду важлива, та чи можна інколи поступитися принципам? Так!

•  Коли треба розробити швидке рішення

Інколи немає часу на оптимізацію коду: потрібен хотфікс на проді чи простий Proof of Concept. Все-таки робочий код ліпший за гарний, тож у розумних межах можна поступитися принципами.

Обговоріть у команді невідкладність задачі, щоб показати переваги та недоліки обох рішень. Порахуйте естімейти та визначте технічний борг, який залишиться після «‎швидкого» коду.

• Коли маєте справу із незрозумілим рішенням

У деяких ситуаціях написаний за всіма канонами «‎чистий» код може виглядати незрозуміло. Ніби все коректно, без полотна рядків, але технологія незнайома більшості ваших колег. Тоді не гріх буде написати розгорнутіше, щоб інше не викликало ще більше питань.

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

• Коли рішення працює повільно

В окремих проєктах спрощення може призвести до падіння перфомансу. Можна написати код на кілька рядків, де відбуватиметься обробка циклу в циклі і в циклі. Зазвичай це не проблема. Але в масштабах Big Data проєктів така кількість ітерацій шкодить ефективності рішення.

Краще написати один цикл, що покриватиме всі задачі. Спершу це виглядатиме складно, але згодом швидкість зросте у рази. Не забудьте додати коментар у коді, чому зробили саме так, щоб інший розробник не зніс ваш «‎брудний» код і не «‎поклав» усю систему.

Початківцю варто відразу привчатися писати чисто. Тоді навіть швидкі рішення ви не зможете зробити погано. Все буде більш-менш структуровано, зі зрозумілим неймінгом.

Перелічені вище випадки не дозволяють писати «‎брудно», йдеться про певні послаблення. Базові ж речі обов’язкові, щоб і за 2 роки потому ви розуміли свій код.

«‎Чистий» код – основні принципи

Лаконічному коду присвячено чимало книг. Можна відшукати й короткі огляди з базовими правилами про форматування, коментарі тощо.

Головне – пам’ятайте, що ви пишете код не для машини, а для людей. Спираючись на цей підхід, вам буде простіше «‎очищувати» код від зайвого.

Щодо більш прикладних принципів, то важливі такі з них:

1. Використовуйте зрозумілі назви

З назви функції чи класу має бути очевидно, для чого вони. Наприклад, «Знижка постійного клієнта» або «Надсилання email про замовлення». Не слід назвати просто «А» чи «Знижка». Програма не працюватиме повільніше від того, що в назві три слова. Навпаки – повна назва допоможе розробникам.

Функція може бути частиною класу, і якщо назва незрозуміла, девелоперу доведеться заходити всередину і дізнаватися, що там відбувається.

Інколи початківці пишуть занадто довгу назву, бо функція і знижку рахує, і до бази звертається, і повідомлення відправляє. Тут діє базове правило «одна функція – одна фіча».

Проблема неймінгу вказує на проблему розділення коду. Деякі новачки вказують щось одне, але це теж неправильно. Функція має робити лише те, що зазначено в назві. Наприклад, надсилати email та повідомлення в Telegram. Тому якщо назвати її «Надсилання email», нікому й на думку не спаде про зв'язок із месенджером. Тому, якщо хтось із колег видалить цю функцію, програма перестане надсилати повідомлення ще й у Telegram.

2. Скорочуйте обсяг коду

Велика кількість рядків зазвичай є там, де клас (наприклад, контролер із MVC) виконує забагато завдань. Наприклад, в одному блоці оброблюються запити, виконується перевірка та відбувається звернення до бази даних.

Краще ділити код на логічні блоки (про це поговоримо далі). Але й в окремих блоках слід подумати про скорочення кількості коду. Звісно, 100 рядків можуть працювати не гірше за 30, але читати такий масив важче.

Є рішення – напишіть вкладену функцію в функції, щоб блок займав менше місця на екрані. Зробіть стовпчиком кілька викликів функції, запишіть результат їх виклику у змінні та використовуйте їх.

Рядків стане трохи більше, але зрозумілість коду від того лише поліпшиться. Зрештою ви ж пишете не для мікроконтролерів, а створюєте прикладні програми та вебсервіси.

3. Розділяйте код на логічні блоки

Якісний код нагадує Lego: велика складна річ створена з маленьких простих «цеглинок». А код, який використовується разом, розміщуєте поруч. Тоді розробникам легко роздивитися як окремі блоки, так і весь алгоритм. Найпростіший шлях до цього – кожна частина коду виконує окрему задачу.

Блоки не мають бути надмірно пов’язані один з одним. Часто дві функції використовують одна одну, але логіка в нижньому рівні спирається на верхню. Формально це різні юніти, але їх неможливо роз’єднати чи змінити без переписування всього ланцюга. А це заважатиме масштабуванню системи.

Найкращий код можна видалити без модифікації пів системи. Такий собі side effect «чистоти» коду. Інколи розробники намагаються передбачити розвиток проєкту та ускладнюють зв’язки, але насправді це зайве. Зазвичай командам складно вгадати нові ідеї замовника чи продукт оунера. Краще писати рішення чітко, без «вангування».

4. Не дублюйте

Класичний принцип – Don’t Repeat Yourself (DRY). Початківці полюбляють перевикористовувати все, що тільки можна. Це не дуже погано, але є одне «але».

Принцип DRY говорить не стільки про рядки, скільки про бізнес-ідею, логіку. Наприклад, є функція для розрахунку 5% від числа – для знижки на товари. Перед вами може постати задача зробити нарахування 5% для збільшення ціни з доставкою. Уже хочеться використати код функції в обох випадках, та це буде помилка. Ви поєднаєте різні задачі. І якщо знадобиться змінити розмір знижки, доведеться окремо змінювати блок із розрахунком ціни з доставкою. Тому для різних задач і код має бути різним.

5. Коментуйте зміни у коді

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

Коменти необхідні в таких випадках:

• Якщо в коді є невідомі чи неочевидні нюанси, про які варто повідомити новачку в команді. Наприклад, можна написати, що «тут використано таку-то технологію, тому що є зав’язка на такий-то модуль, який неможливо змінити». Або простіше: «Не видаляй цей клас, бо одне й інше впаде».
• Як нагадування про необхідність змін у форматі To-do. Наприклад, у вас немає часу реалізувати інноваційне рішення. Тож пишете так, щоб усе працювало. Далі додаєте коментар як нагадування про зміни певної частини коду під час рефакторингу.

6. Дотримуйтеся єдиного кодстайлу

Усі на проєкті мають слідувати заздалегідь визначеному кодстайлу. Це набір правил, як ви оформлюєте код. Йдеться про вигляд, стилістику, а не про архітектуру.

Кодстайл визначає, де ставити пробіл чи додавати в кінці крапку з комою, коли починати новий рядок тощо. Для кожної мови програмування існує безліч кодстайлів.

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

7. Орієнтуйтесь на SOLID

Що на бекенді, що на фронтенді писати «‎чистий» код допомагає SOLID – принципи об'єктно-орієнтованого програмування і проєктування. Буває важко відразу їх зрозуміти, якщо пишете код з нуля. Під час переписування чужого коду ви краще зрозумієте правила SOLID та побачите їх взаємозв’язок.

Насправді SOLID – це не тільки про «‎чистоту» коду. Завдяки цим принципам код стає придатним до перевикористання і легко масштабованим.

Не забувайте і про об’єктність програмування. Думайте об’єктно: у вас є об’єкт із певним станом та зовнішніми інтерфейсами, які змінюють цей стан. Так ви бачитимете головне в коді й не будете його навантажувати зайвим.

SOLID має концепт, який працює не лише в розробці, – Single responsibility. Тобто один клас, компонент чи метод виконує одну задачу. В житті так само: виделка виконує лише свою задачу. Якщо зрозуміти це на такому рівні, то і дотримуватися цих принципів легше, і код стає читабельним.

Чи можна навчитися «‎чистоти» коду на чужих прикладах?

В цілому ви можете перейняти досвід колег, однак на більшості проєктів код не такий вже й «‎чистий». Часом якийсь блок писали з обмеженими ресурсами, а модуль – просто вставили як хотфікс і записали до техборгу, а про якийсь ще шматок коду взагалі ніхто нічого не знає, бо його 5 років тому створила інша команда, а нині всі бояться його чіпати. Тож при вивченні чужого коду розвивайте критичне мислення і міркуйте, як би ви могли спростити той чи інший елемент.

Якщо щось здається вам нечитабельним, з’ясуйте причину:

• Розпитайте керівників команди чи колег. Інколи поява неоптимального коду може бути викликана чимось, на що ви не вплинете.
• Зверніться до системи контролю версій. Дізнайтеся, як і коли код став «‎брудним», хто його писав, які таски та пул реквести передували цьому. Не бійтесь працювати з легасі! В реальності саме легасі-код заробляє гроші. Новачки часто мріють про проєкт із нуля, щоб написати все красиво і правильно. Але тоді ваш розвиток буде не таким швидким. Ви отримаєте досвід роботи з технологією, але не з «‎очищення» коду. У проєкті з історією є змога побачити й погані приклади, які ви самі ж не захочете повторювати в майбутньому.

Початківці соромляться запитувати про щось незрозуміле. Думають, це прояв некомпетентності. Але вони ж дійсно можуть чогось не знати.

Тут радимо такий лайфхак: скажіть, що у вас є ідея, але в процесі брейнстормінгу виникло кілька «‎дурних» запитань, треба в дечому пересвідчитися. І далі розпитайте колег про все, що вас цікавить. Коли матимете потрібні відповіді, подякуйте і скажіть, що передумали, бо ваша ідея, мабуть, не спрацює.

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

Програмування не має суворих правил, яким всі мають 100% слідувати. Якби так було, то девелоперів вже давно замінила б програма. Поки цього не сталося, розвивайтесь в усьому, зокрема в написанні «‎чистого» коду. Адже його читатимуть такі ж люди, як і ви.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Команда LOOQME дослідила, що говорили про штучний інтелект українські медіа та як вітчизняні компанії використовують його у роботі, і доповнила його коментарями експертів.

Частина 1. Штучний інтелект як тренд в українських масмедіа

Щоб зрозуміти, що говорили про штучний інтелект у 2023 році, ми проаналізували згадки про нього в українських ЗМІ. Важливо, що фокус був саме на тих згадках, які стосувалися безпосередньо України. Їх шукали у п’яти типах медіа: Інтернет, друковані ЗМІ, інформаційні агентства, радіо та телебачення. Інтерактивний звіт можна подивитися тут.

Де і скільки згадували штучний інтелект?

Протягом року українські ЗМІ згадували штучний інтелект 167 452​ рази. Втім, серед цих згадок тільки 66,4 тисячі згадок стосуються безпосередньо України.

Протягом року тема штучного інтелекту поступово набирала поширення. Якщо у лютому майже 4 тисячі згадок були зумовлені тим, що ChatGPT став доступним в Україні, то в листопаді й грудні понад 8 тисяч згадок щомісяця стосувалися і загально-політичних тем. З огляду на те, що більшість держав почали вирішувати правові та морально-етичні питання щодо ШІ, це не могло не відобразитися на українському інформаційному просторі.

Більш ніж половина публікацій була у виданнях рівня топ-100 та національного рівня. Загалом же у 2023 році потенційне охоплення новин про штучний інтелект в українському сегменті становило понад 148 мільйонів.

Про що писали?

Майже половину згадок про ШІ зафіксували у новинних рубриках. Водночас до 15% публікацій було у профільних рубриках і тематичних виданнях. Це свідчить про зацікавленість фахівців певних галузей у використанні штучного інтелекту саме в їхніх сферах.

Наприклад, про ШІ в рубриці «Технології» найчастіше писали видання Speka, DOU та dev.ua. У рубриці «Маркетинг» і PR – «Детектор медіа» та MMR. А про урядові джерела найчастіше згадували державні портали – сайт Кабінету Міністрів, Мінцифри та портал Дія.

До топу згадок, які стосуються штучного інтелекту, увійшли новини про технологію SPHERE LIFE: на думку ChatGPT, вона здатна лікувати ВІЛ та гепатит В і С; про львівських школярів, які вигадали, як за допомогою штучного інтелекту покращити сервіси «Нової пошти»; про перспективи України стати лідером із цифровізації державних послуг.

Контекст і тренди

Якщо говорити про контекст і середовище, в якому трапляються згадки, то найчастіші слова – це «допомога», «система», «чатбот», «генеративний» (вид ШІ). Тобто ті слова, які стосуються перш за все використання штучного інтелекту.

Цікаво, що в середовищі згадок про ШІ досить часто трапляється Clearview. Це американська компанія із розпізнавання облич, яка надає програмне забезпечення для правоохоронних та державних органів.

Крім того, Clearview допомагає українським спецслужбам, а представники техностартапу декларують зацікавленість відкрити представництво в нашій державі.

Натомість у трендах згадок ШІ переважають слова, які стосуються більш конкретних сфер. Наприклад, дуже виділяється військова тематика. Слова «військовий», «дрон», «виробництво» увійшли в топ-10 найбільш згадуваних.

З огляду на те, що штучний інтелект згадувався у контексті різних сфер та галузей, у дослідженні ми поділили всі згадки за темами та проаналізували особливості й наративи у кожній із груп.

Штучний інтелект і війна

У контексті війни в Україні ШІ згадувався 19 тисяч разів. Це найпопулярніша тематика матеріалів про штучний інтелект, адже кількість згадок значно переважає інші теми.

Найпопулярнішими матеріалами стали новини про Артилерійську коаліцію підтримки України, дрони зі штучним інтелектом, які використовуватимуть ЗСУ, та новини платформи UNITED24, зокрема про Тімоті Снайдера, який зібрав кошти на сенсори для українських військових.

Найпопулярнішими організаціями в медіа стали ЗСУ, Міністерство оборони, Міністерство цифрової трансформації та Мінцифри, а серед персоналій найчастіше згадували Михайла Федорова, володимира путіна і Джозефа Байдена.

Штучний інтелект і держава

Про ШІ у стосунку до держави ЗМІ писали 12,3 тисячі разів. Штучний інтелект у цих матеріалах згадувався поруч зі словами «act», «чатбот» та згаданим вже «Сlearview». Серед компаній та організацій, про які найбільше говорили в контексті штучного інтелекту, – Міністерство цифрової трансформації, Дія та OpenAI.

Закономірно, що в майже половині публікацій йшлося про міністра Михайла Федорова. Решта ж персоналій не набрали навіть по тисячі згадувань. Втім цікаво, що на другому місці за популярністю – Ілон Маск (873 згадки), а на третьому – Володимир Зеленський (867 згадок).

До найпопулярніших увійшли новини про перспективи України стати лідером із цифровізації державних сервісів, про виступ Володимира Зеленського на Генасамблеї ООН, про рейтинг освітніх подій України та про безоплатний курс про штучний інтелект від Google, який запускає Мінцифри.

В останній новині ШІ став інновацією року: школярі брали участь у соціологічному дослідженні щодо нього, 30 тисяч педагогів пройшли курс «Штучний інтелект в освіті», навіть Відкритий марафон з української мови цього року відбувся за допомогою штучного інтелекту.

Штучний інтелект та освіта

В освітній тематиці про штучний інтелект згадували майже 10 тисяч разів. Попри відносно невелику кількість згадок, вони мають значне потенційне охоплення – понад 56 мільйонів.

Найчастіше вживаними у публікаціях були слова «освіта», «наука», «національний» та «мова». А до найпопулярніших матеріалів увійшли новини про львівських школярів та їхні ідеї, як покращити сервіси «Нової пошти» (учні запропонували впровадити чат зі штучним інтелектом Nova AІ, який буде вирішувати питання клієнта), міжнародну зустріч у Міністерстві освіти і науки та рейтинг мистецьких вишів.

Штучний інтелект та ІТ

Хоча, здавалося б, штучний інтелект та ІТ – це суміжні тематики, але в Україні в контексті інформаційних технологій ШІ згадували лише 8,5 тисячі разів.

Оскільки ІТ-сфера сьогодні нерозривно пов’язана з військовою справою, то й згадки про штучний інтелект часто траплялися у сусідстві зі словами «дрон» та «виробництво».

Втім топ-матеріали у цій сфері не стосувалися війни. Найпопулярнішими стали новини про купівлю британським інвестором частки компанії Cosmolot і плани застосовувати ШІ, нове медіа для айтівців, анонс платформи для управлінських рішень на основі штучного інтелекту.

Штучний інтелект і ритейл

У контексті ритейлу штучний інтелект згадували всього 3,3 тисячі разів. Найчастіше він траплявся поруч зі словами «працювати», «ринок», «сайт».

У категорії ШІ в ритейлі найпопулярнішими компаніями стали Київстар, Епіцентр, АТБ, WOG, OLX. Найчастіше писали про директора департаменту платіжних систем та інноваційного розвитку НБУ Андрія Поддєрьогіна, Ілона Маска та керівника Кіберполіції Юрія Виходця.

Щодо топ-новин, то ними стали: зображення станцій київського метро під водою, створені штучним інтелектом (так, ТРЦ «Республіка» асоціюється у ШІ з «Теремками»); технології для прискорення відновлення України від японського бізнесу; роботи-помічники в мережі АТБ.

Штучний інтелект та аграрна сфера

В агросфері згадування ШІ також пов’язані з воєнною тематикою. Адже у публікаціях часто використовувалися такі слова, як «війна», «розвиток» та «супутниковий». Це пояснюється тим, що аграрії зараз повсякчас стикаються з ризиками через мінування територій, а посівні площі через війну й окупацію значно скоротилися. Тож двома найтоповішими стали новини про штучний інтелект, який допоможе розміновувати територію України, і про досвід Азербайджану у повоєнному відновленні.

Найбільше писали про компанію EOS Data Analytics, Збройні Сили України та FAO (Продовольча та сільськогосподарська організація ООН).

Цікаво, що до найбільш згадуваних персоналій увійшли дві українки, яких журнал Time вніс до рейтингу TIME 100 Next. Це міністерка економіки Юлія Свириденко й інноваторка, засновниця агростартапу Flurosat Анастасія Волкова.

Штучний інтелект і медицина

2,2 тисячі разів згадувався штучний інтелект у контексті медичної теми. Переважно медіа писали про діагностику та лікування тяжких захворювань (ВІЛ, онкологія, гепатит) за допомогою штучного інтелекту.

Цікаво, що в цій категорії медіа значну увагу приділяють дітям. Серед слів, що набирали популярності впродовж року, – «діти», «навчання», «освіта».

Штучний інтелект і контент

Тема створення контенту у прив’язці до штучного інтелекту у 2023 році була досить популярною. Про неї згадували понад 7 тисяч разів, а публікації сумарно мають більш ніж 19 мільйонів потенційного охоплення.

Серед згадуваних організацій переважали компанії та соцмережі, які експериментують із впровадженням штучного інтелекту: ChatGPT, Google, OpenAI, Facebook, YouTube, TikTok, Instagram, Twitter, LinkedIn. Найчастіше в новинах цієї теми штучний інтелект стояв поруч зі словами «генеративний», «чатбот», «робот», «згенерувати».

Кумедно, що найбільш згадуваною особою став Тарас Шевченко. Причина цьому – новина про перший україномовний чатбот «На урок», у якому можна поговорити з відомими поетами та письменниками.

Як висновок, інтерес до теми штучного інтелекту зростає. Кількість його згадувань в українських медіа – яскравий доказ цього.

Прикметно, що про ШІ говорять у контексті практично всіх сфер життя. Щоправда, в Україні на кожну з цих сфер відбиток накладає війна. Тож штучний інтелект для українців – це не тільки генератор контенту у соцмережі, але й інструмент боротьби, а у перспективі – повоєнного відновлення нашої держави.

Частина 2. Як штучний інтелект може вирішувати проблеми компаній

Як працює ШІ, що він може дати бізнесу та які ризики у його використанні, поділився Станіслав Под’ячев, співзасновник Talents on AI Foundation і BlackBox.ua.

ШІ-спільнота в Україні

У нас є два напрями роботи зі штучним інтелектом. Перший – це Talents on AI Foundation. Ця спільнота виникла, коли з’явився Chat GPT 3. Українцям не дали можливості користуватися ним через вебінтерфейс, заблокували із політичних мотивів.

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

У кінці травня ми проводили хакатон в UNIT.City, а згодом – фінал іншого хакатону разом із Представництвом ООН в Україні, UNESCO і МЗС.

Цей хакатон не зовсім звичний – він із моделями генеративного штучного інтелекту. Його мета – дослідити, які проєкти можуть бути зроблені на перетині штучного інтелекту, захисту прав людини, толерантності й рівності. Зокрема, учасники досліджували можливість використання штучного інтелекту у юриспруденції, психології тощо.

Брейншторм зі штучним інтелектом

Зараз ми розробляємо Blackbox.ua. Це платформа, на якій можна створювати діалогові ігри для підприємців, власників компаній, стартапів, учасників програм бізнес-шкіл.

Є тема, є викладач, який її досконало вивчив і може поділитися з аудиторією. А потім аудиторія, якщо їй буде цікаво, може створити кількох ШІ-помічників, які будуть знати всі нюанси викладання саме цього лектора, саме цієї теми. І вони матимуть змогу відповідати або ставити запитання, бути гідом для учасників у вирішенні їхніх кейсів.

Наприклад, уявіть: ви – CEO, за круглим столом сидять ваші колеги: директор із маркетингу, директор із продажів, директор із фінансів. У вас є певний бізнес-челендж. І тут за столом з’являються Рей Даліо, Ілон Маск, Вільям Руделіус, і вони всі працюють над тим самим кейсом, але кожен додає щось своє. І таким чином це стає симбіозом генеративного штучного інтелекту в контексті компанії чи країни.

Контекст компанії може бути різним. Для нас це зрозуміло, що я можу сприймати компанію так, ви – інакше, директор із маркетингу – ще інакше.

Але й контекст країни може бути різним. Ми ставили це запитання людям, і вони написали зовсім різні відповіді. У когось це «Війна, нам кришка», хтось написав: «Війна – це час можливостей». Виходячи з цих контекстів кожен буде давати свою характеристику кейсів, свої відповіді, свої рішення.

Кожна охоча людина може описати контекст компанії самостійно. І кожен Diamon (помічник-модель штучного інтелекту) має контекст свого власника, який той задав. Відповідно він дає поради чи варіанти розвитку подій, виходячи з цього контексту.

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

Як ризики несе ШІ?

Найбільш очевидний ризик для генеративних моделей штучного інтелекту – це ризик галюцинацій, коли людина сліпо довірятиме ШІ і сприйматиме його як істину в останній інстанції.

Інший ризик – нерозуміння нами технології, того, як саме працює штучний інтелект.

Взагалі я – оптиміст, тому якісь загрози з погляду кібербезпеки не розглядаю. Все має бути настільки відкрито і прозоро, що витік даних не нестиме шкоди. Якщо я не хочу, щоб хтось дізнався про певні речі, я просто не буду спілкуватись із ШІ про них. У використанні штучного інтелекту все одно на першому місці – людина.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

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

Вручну збирати дані складно і довго. Набагато простіше довірити це завдання скрейперу – програмі, яка автоматизує цей процес. Поки ви самотужки виписуєте один товар з онлайн-магазину, програма здатна витягти кілька сотень таких найменувань і структурувати їх у базі даних.

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

Як ще можна отримувати вебдані

• Через API – набір протоколів зв’язку, які забезпечують доступ до даних програми, операційної системи або інших сервісів переважно у форматі JSON.

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

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

• Через інструменти автоматизації – програми на кшталт Selenium. Взагалі-то вони створені не для скрейпінгу, а для тестування. Але все одно дозволяють отримувати дані, бо імітують процес взаємодії користувача із браузером.

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

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

Обираючи між вебскрейпінгом, роботою з API та інструментами автоматизації, я рекомендую врахувати такі кроки:

1. Перевірити наявність та адекватність API. Цей варіант – найпростіший. Дані вже будуть зібрані, структуровані й очищені. У цьому випадку достатньо просто взаємодіяти з набором ендпоінтів, витягувати дані та далі маніпулювати ними, як вам заманеться. А далі залишиться лише зберігати результати у базу даних чи інше сховище. Все організовано швидко і зручно.
   
2. Використовувати скрейпери. Якщо немає змоги працювати з API, запускайте вебскрейпінг. Створені для цього бібліотеки та фреймворки заточені під отримання максимуму даних за мінімум часу. Щоправда, недостатньо просто натиснути кнопку. Слід проаналізувати сайт та зробити додаткову обробку даних для їх зберігання. Це довше, ніж робота з API, але швидкість збору даних все одно доволі висока.
   
3. Вмикати інструменти автоматизації. Тільки якщо перші два підходи не спрацювали. Інструменти автоматизації не надто зручні та швидкі для подібних задач, однак виручать, якщо інші засоби не допомогли отримати необхідні дані.

Що краще: Xрath чи CSS?

Xpath і CSS-селектори – це мови, які дають змогу описати необхідні для вилучення елементи. Їх також можна називати стратегіями локатора.

CSS, або каскадні таблиці стилів, – це мова таблиць стилів для опису зовнішнього вигляду та форматування документа, написаного в HTML або XML.

Якщо CSS – це шаблони для вибору стилізованих елементів, то Xpath – це мова шляхів XML та мова запитів для вибору вузлів із XML-документа. Xpath використовує вирази шляху для навігації за елементами й атрибутами в XML-документі.

Основна перевага CSS-селекторів – зручний синтаксис. Вони добре підходять для простих задач.

Хоча мають і низку обмежень:

• При використанні селекторів неможливо шукати елементи за вкладеними умовами типу «і» й у яких ще є подвійний «або».
• Не можна звертатися до батьківських елементів та елементів, які знаходяться на одному рівні вкладеності з вашим, але до яких немає прямого доступу.
• Не вдасться шукати тег за його вмістом. Тобто за текстом чи іншим контентом.

Тому інколи застосування CSS-селекторів може бути недостатнім. Попри більш навантажений синтаксис Xpath дозволяє виконувати все, з чим є проблеми у селекторів CSS.

Однак час від часу зустрічається думка, що CSS працює швидше, ніж Xpath. Зі свого досвіду скажу так: різниця на користь CSS є, але зазвичай вона несуттєва. Це зокрема залежить від складності виразу, від того, чи використовуються для доступу до ресурсу проксі або VPN тощо. Тож вибір між Xpath і CSS – це вибір між функціоналом і зручністю.

lxml/BeautifulSoup/Scrapy

Коли ви розібралися з базовими поняттями парсингу, можна перейти до інструментів, які використовуються в Python. Це 3 основних інструменти: lxml, BeautifulSoup і Scrapy.

Перші – схожі бібліотеки, але з різними на момент їх створення підходами. lxml був зосереджений на роботі з Xpath, а BeautifulSoup – із CSS-селекторами. Остання бібліотека була створена для роботи зі зламаними HTML-документами.

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

Я б рекомендував застосовувати бібліотеки лише у двох випадках. Перший – коли обсяг парсингу невеликий. Другий – за умови, що вилучення даних не є основним пріоритетом системи. В такому випадку можна додати Python-модуль із парсером і використовувати ці дві бібліотеки.

Але якщо плануєте збирати дані з тисяч сторінок або переходити між безліччю сторінок, поєднаних кроспосиланнями, і створювати пайплайни для обробки отриманих даних, тоді краще вибрати Scrapy. Він часто використовується у великих проєктах, де треба ізолювати код скрейпера від решти системи.

Та зауважте: Scrapy має обмеження на структуру дерева проєкту, оскільки в нього свої файлова структура та конфігураційні файли.

Бібліотеки для вебскрейпінгу

Почнімо із lxml та BeautifulSoup. Щоб потренувати навички парсингу, скористуйтеся Quotes to Scrape. Тут зібрані цитати відомих людей. Цей сайт дозволяє скрейпити, використовувати переходи по сторінках, отримувати додаткову інформацію про авторів тощо. Завдяки тому, що цей сервіс створений саме для тренування вебскрейпінгу, у його сторінок нормальна структура із зазначенням повноцінних класів, ID та іншого.

Для початку слід встановити бібліотеки BeautifulSoup та lxml способом, звичним для вас: чи то використовуючи pip install, чи то використовуючи інтерфейс для менеджменту пакетів у вашій IDE.

Після цього переходимо до функціоналу бібліотек. Насамперед необхідно отримати контент сторінки. Все це виконується через звичайний request.get, у який передамо посилання на потрібний ресурс.

Далі залишається лише закинути все це в soup, щоб отримати мінімальний набір інформації. Ми створюємо новий обʼєкт BeautifulSoup, передаємо в нього response.text і вказуємо бажаний синтаксис для обробки даних зі сторінки (наприклад, формат lxml). Після цього просто відобразимо наш об’єкт звичайною командою print().

У результаті отримаємо ту ж сторінку, але у вигляді тегів.

Можна зіставити отриманий документ із самим сайтом. Для цього треба зробити Inspect Element на потрібному об’єкті вебсторінки й отримати по суті ті самі дані, але краще відформатовані.

Безпосередньо HTML-код краще ніж нічого, але цього замало. Тому треба витягти з файлу необхідну інформацію. У цьому випадку –  цитати, їхніх авторів і теги.

Наприклад, для отримання авторів варто вивчити сам сайт і зрозуміти, як на ньому описуються такі дані. Тут ця інформація зберігається за допомогою тегу small із доданим класом author.

Аналогічно, зі скріншота вище можна побачити, що для цитат використовується div із класом quote.  І залишаються теги. У них це все оформляється як div, всередині якого є посилання (тег a) із класами tags і tag відповідно.

Цю інформацію слід перенести до коду. Тобто дати BeautifulSoup команду знайти всі елементи з таким тегом або таким набором тегів із певним класом. У цьому випадку це класи text, author та tags, як зазначено вище. Тож для перевірки виведемо цитати й на цьому зупинимо програму.

Результат кращий за попередній. Наприклад, видно, що було отримано Python-список із цитатами. Але є нюанс. Це ще не цитати, а об’єкти HTML (точніше span). Тобто фактично перед нами метаінформація, хоча потрібен лише контент тегів.

Тому слід трансформувати отримані дані за допомогою вбудованих засобів Python. Для цього треба пройтися циклом по отриманих елементах цитат, авторів і тегів та витягнути кожен конкретний об’єкт.

Для тегів необхідно зробити додаткову проходку серед кожного div-елемента, що містить усі теги. А щоб отримати текст потрібного об’єкта, знадобиться атрибут text. На наступному зображені показано повну версію коду.

Запускаємо й отримуємо всі цитати в лапках, із зазначеними авторами та набором тегів для них. Остання цитата у списку: «A day without sunshine is like, you know, night».

Звіряємо із сайтом – все правильно! Тобто результат знову покращено. Але радіти зарано.

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

Як за допомогою бібліотек парсити кілька сторінок

Почну із простого завдання – пейджинг. Для цього прикладу звернемося до другої згаданої бібліотеки lxml і водночас подивимось на синтаксис XPath.

У цьому випадку трохи збільшується кількість функцій, але суть залишається простою. Тут є функція для читання, скажімо, трьох перших сторінок. HTML отримуємо через той же response.text, що і в попередньому прикладі. Різниця починається в командах: замість beautifulsoup використаємо lxml.html.fromstring.

Нам потрібна функція, яка безпосередньо парсить сторінку. У цьому випадку це буде функція use_le_xml(html). Поки пропустимо її контент, а подивимося далі. Через необхідність читання перших трьох сторінок ми робимо відповідний цикл. Всередині нього будемо знаходити посилання на наступну сторінку, переходити, обробляти та шукати наступну сторінку від нової «поточної».

Далі перейдемо безпосередньо до функції переходу на наступну сторінку, get_next_page. Спочатку заходимо на сайт і робимо Inspect Element для кнопки Next. Завдяки цьому можна побачити, що вона розміщена у простій таблиці HTML з ul-елементом та a href.

Наступний крок – використаємо команду html.find(). Її основна відмінність від findall в тому, що вона знаходить саме перший елемент, який задовольняє описані критерії тега. Але якщо ви хочете використовувати саме findall, то потрібно наприкінці дописати індекс елемента, щоб отримати лише його, а не повний список елементів.

Погляньмо уважніше на цей код. Тут клас вказується не через нотацію функції, а через вираз xpath. Якщо вираз починається не з «.», а з «//», то пошук йде по всій сторінці. В нашому ж випадку пошук виконається з певного місця, яке вказано у змінній html. Фактично це просто вказує lxml, із якого елемента дерева тегів треба починати пошук. Можна передати як всю сторінку, так і фрагмент. Наприклад, один div.

Використання подвійного слешу дає вказівку, що можна відійти від поточного елемента вглиб на кілька рівнів, а не на один. У моєму прикладі є початковий елемент nav, від якого відбувається пошук по сторінці. Всередині нього є тег ul, який зі свого боку містить тег li.

Через те, що нас не цікавлять дані додаткові теги, ми просто пропускаємо їх, коли пишемо шлях до потрібного елемента, вказуючи “//” та конкретизуємо потрібний нам тег за допомогою класу next.

У результаті отримуємо посилання на наступну сторінку. Але воно не повне – це просто /page/2/.

Така проблема періодично виникає. Тому варто використовувати метод urljoin, викликаний через стандартну бібліотеку urllib.parse.

Завдяки цьому основний URL, наявний від початку (або такий, що не треба вичитувати кожен раз заново), з’єднується з локатором на певну сторінку.

Передаємо поєднаний url далі та перевіряємо дані з другої сторінки. Результат: все пройшло добре, оскільки дані оновилися. І тепер ми маємо посилання на 3-у сторінку /page/3/.

Про всяк випадок можна зробити ще одну перевірку. Остання цитата, яку витягнув парсер на 3 сторінці, належить Бобу Марлі.

Переходимо на сайт, відкриваємо третю сторінку. Все збігається! Тобто ми змогли правильно пройтися різними сторінками та витягнути потрібний контент.

Бібліотеки BeautifulSoup та lxml – це чудові інструменти, які задовольнять мінімальні потреби скрейпінгу. Але вся додаткова робота, як-от перехід між сторінками чи очищення даних, лежатимуть на наших плечах. Якщо ж вам хочеться автоматизувати цю роботу, варто використовувати саме Scrapy.

Як працювати зі Scrapy

Процес інсталяції Scrapy стандартний. Достатньо виконати команду pip install scrapy:

У моєму випадку всі залежності вже попередньо встановлені. У вас же додавання всіх бібліотек або їх частини може потребувати часу. Після цього запустіть команду scrapy startproject testing. Вона створить мінімально потрібну структуру директорій для проєкту та початкові файли, які знадобляться на різних етапах роботи (конфіги, шаблони тощо).

Далі з’являється директорія testing, в якій є ще одна директорія testing та файл scrapy.cfg. А вже всередині другої testing знаходяться необхідні файли для автоматизації скрейпінгу й окрема директорія spiders, де будуть зберігатися скрейпери.

Я створив це все завчасно, тому у прикладі працював із готовими директоріями. Ви ж можете повторити попередній крок та обрати інше імʼя для проєкту.

Також варто взяти більш реальний та наочний приклад, ніж описаний сайт із цитатами. Чудово, що в цьому домені toscrape.com є ще один сайт – books.toscrape.com. Він емулює такий собі онлайн книжковий магазин. Однак, перед розбором самих парсерів, давайте спочатку подивимося на налаштування наших скрейперів. Усі налаштування збережені у файлі settings.py у директорії вашого проєкту.

Тут зібрані всі доступні параметри Scrapy: кількість одночасних запитів, використані проміжні застосунки, налаштування авто тролінгу тощо. Раджу після цього туторіалу відкрити офіційну документацію та більш детально ознайомитися з  налаштуваннями. А наразі зосередимося на одному параметрі з налаштувань, а саме – ROBOTSTXT_OBEY.

Майже кожен сайт, який вам захочеться розпарсити, має файл robots.txt. У ньому розміщується набір правил, які дозволяють та забороняють певні дії на сайті для скрейперів. Наприклад, це можуть бути обмеження на відвідування певних розділів і сторінок, ліміти на частоту використання скрейпера тощо. Іноді ці заборони можна обійти технічно, але ви можете отримати за це бан від сайту.

Також у цьому файлі містяться вказівки для user-agents різних пошукових роботів. Наприклад, на сайті техніки, який ми аналізуємо, цей файл має такий вигляд:

Тож перш ніж починати працювати зі скрейперами, ознайомтеся із дозволами конкретних сайтів.

Повернімося до скрейперів. Нижче зображено простий метод, який витягуватиме дані з потрібного нам сайту:

Скрейпер має ім’я, необхідне для виклику. Наступним вказано початкове посилання для парсингу і власне метод, який займається цим процесом. Всередині метода ви бачите, як спочатку ми шукаємо по всій сторінці елементи article із класом product_pod. Після цього всередині елемента шукаємо заголовок, посилання, ціну та рейтинг книги.

Зверніть увагу на теги сторінки та порівняйте їх із xpath, які використовувалися для пошуку елементів. Особливо придивіться до останніх елементів у рядках.

Залежно від обʼєкта ми можемо звертатися до атрибута text(), який передасть текст всередині тега. А можемо спробувати дещо інше – звернутися до @href для отримання посилання чи до @class (у цьому прикладі оцінка в текстовому варіанті вказана лише у значенні класу).

Окрім рядків із безпосередньо парсингом сторінки, ви можете бачити екземпляр класу BookItem. Загалом Items у Scrapy – більш зручний спосіб звернення до елементів, які ми шукаємо. Можете думати про них як про словник, що зберігатиме імʼя поля та його значення.

Для нашого скрейпера книжок я створив простий Item, що складається із чотирьох полів: заголовка, посилання, ціни й рейтингу товару.

Тепер спробуємо запустити наш перший Scraрy-проєкт. Зробити це можна за допомогою команди Scrapy crawl <crawler_name>. Наприклад:

Результат роботи виводиться в термінал і виглядатиме ось так:

Здається, щось не так... Хотілося б, аби наші Items співпадали з кількістю обʼєктів, які ми розпарсили. Також було б добре, щоб посилання були повноцінними, щоб рейтинг зберігався як нормальне число. Як покращити наші результати?

У Scrapy, окрім власне Item, ще є такий інструмент як ItemLoader. Цей механізм дозволяє автоматизувати деякі задачі з очистки й обробки отриманих даних, перш ніж вони потраплять до Item.

Розглянемо це на прикладі. Нижче ви можете побачити клас BookLoader, що складається з default_output_processor та параметрів, що мають у своєму імені назву, аналогічну певному полю з Item. Як вони працюють?

ItemLoader містить дві частини – Input та Output processors. Якщо бути більш точним, то ItemLoader містить один Input та один Output processor для кожного поля в Item. Input processor обробляє витягнуті дані відразу після їх отримання, а результат збирається та зберігається в ItemLoader.

Після збору всіх даних викликається метод ItemLoader.load_item() для заповнення та отримання заповненого об’єкта елемента. Саме тоді викликається Output processor із попередньо зібраними даними (й обробленими за допомогою Input processor). Результат роботи Output processor є кінцевим значенням, яке призначається Item.

Якщо в нас немає потреби в окремому обробнику для якогось поля, можна вказати default_input_processor та default_output_processor.

Із полями розібрались, а що ж далі? Тепер дізнаємося, що ж за Compose використано в нашому ItemLoader. Compose – це один із стандартних processors, які можна використати для полів в ItemLoader.

Серед основних варіантів згадується TakeFirst, Compose, MapCompose, Identity, SelectJmes, Join. Щоб розібрати їх, уявімо такий приклад: у нас є список вхідних значень у вигляді списку [‘name’, ‘last_name’, ‘price’].

TakeFirst – бере перший елемент зі списку результатів парсингу. Якщо використаємо його, то з нашого списку отримаємо лише перше значення – ‘name’.

Compose – процесор, який складається з композиції заданих функцій. А значить кожне вхідне значення цього процесора передається першій функції, а результат цієї функції передається наступній і так далі, поки остання функція не поверне вихідне значення цього процесора.

У Compose ми можемо передати функції з перетвореннями. Припустимо, ми робимо такий ланцюжок перетворень: Compose(lambda v: v[0], str.upper). У результаті отримаємо одне слово зі списку, написане великими літерами, – ‘NAME.

MapCompose працює схожим чином, але застосовує ланцюжок перетворень окремо для кожного елемента зі списку. Тому якщо до нього застосувати ті ж перетворення, що й до Compose, результат буде іншим. MapCompose(lambda v: v[0], str.upper) поверне нам новий список, що буде складатися із перших літер, до яких ми потім застосували метод upper, – ['N', 'L', 'P'].

Identity – найпростіший процесор. Він нічого не робить і повертає дані в такому ж вигляді, що й отримав раніше. SelectJmes використовує JMESPath для вибору даних із результатів парсингу. Нам він знадобиться, якщо ми передаємо JSON-структуру в ItemLoader.

Join – об’єднує список елементів в один рядок, використовуючи заданий роздільник. Тому в нашому випадку він поверне один рядок ‘name last_name price’ або аналогічний, але з потрібним нам роздільником.

Повернемося тепер до нашого прикладу. Ми використовуємо прості Output Processors із Compose. Але раджу вам за можливості спробувати альтернативи. У самій Compose ми передали прості методи для чистки даних:

Настав час оновити скрейпер. Новий код зображено нижче.

Пройдімося по відмінностях:

• Ми додали custom_settings. Вказуємо максимальну кількість одночасних запитів на домен, але туди ж можна виписати будь-які інші налаштування. Врахуйте, що такі налаштування працюватимуть лише для потрібного нам скрейпера.
  
• Додали цикл, який проходиться по всім елементам article, витягує дані та проводить трансформації за допомогою BookLoader. У Loader достатньо передати Item, який буде використовуватися для зберігання даних, і selector, який знадобиться для отримання даних.

Результатом запуску цього скрейпера буде вивід терміналу, схожий на наступний:

Як бачимо, картинка вже більш корисна. Маємо очищені дані, розділені на окремі сутності. Але і цей результат можна покращити. По-перше, записати дані в інший файл, щоб кожного разу не повертатись до терміналу. По-друге, ми досі працюємо лише з першою сторінкою.

Хотілося б розширити масштаби. Було б зручніше заходити всередину сторінок, щоб, наприклад, витягувати описи книжок. Давайте спробуємо це зробити.

Для початку з’ясуємо, як реалізувати перехід між сторінками та вхід до сторінок кожного обʼєкта. Для цього в Scrapy є механізм під назвою Rule. В ньому ми можемо прописати правила для переходу між сторінками та правила для сторінок, які мають бути прочитані.

З переходом між сторінками ситуація проста. Дивимося на те, як на сайті виглядає перехід між сторінками, і шукаємо наступну. Для поточного сайту перехід такий:

Щодо посилань на сторінки з детальною інформацією про книгу, то вони в нас вже є. Тепер достатньо вказати, що ми будемо робити з цими детальними описами сторінок. На скріншоті нижче можете побачити приклад використання правил.

Перше правило – для переходу між сторінками (зверніть увагу на параметр follow=true, необхідний власне для переходу). Друге правило – для роботи з посиланням на сторінку кожної книги.

Крім того, що заходимо на цю сторінку, ми ще й будемо викликати метод parse_item, який отримуватиме дані:

Що ж стосується другої частини – збереження в файл, то й тут у Scrapy є готовий інструмент – це Pipelines. Після того, як Item був зібраний, він надсилається до Item Pipeline, який обробляє його за допомогою кількох компонентів, які виконуються послідовно.

Кожен такий Pipeline – це клас Python, що реалізує прості методи. Вони отримують елемент і виконують над ним певну дію, а також вирішують, чи повинен елемент продовжувати проходити по конвеєру чи має бути видалений і більше не оброблятися.

Давайте створимо простий Pipeline, який збиратиме книги у файл, але якщо ці книги не дорожчі за 30 умовних одиниць:

На скріншоті зображено три основні методи ItemPipeline:

• open_spider – викликається, коли відкривається скрейпер;
• close_spider – те ж саме при ‎закритті скрейпера;
• process_item – власне обробник.

Щойно запустивши скрейпер, ми створюємо або перезаписуємо файл books.jl. Потім за допомогою process_item перевіряємо ціну товару, використовуючи функцію is_cheaper_than_max, або пишемо товар до файлу чи викидаємо, якщо він підходить під нашу умову. Насамкінець закінчуємо запис до файлу.

Погляньмо тепер на код нашого скрейпера цілком:

Що змінилося? Ми додали правила переходу між сторінками. Тепер у parse_item ми працюємо зі сторінкою конкретної книжки замість головної. Тож оновилися поточні конструкції xpath. На саму ж сторінку ви можете подивитися на скріншоті нижче:

Однак, де нам викликати наш пайплайн, щоб зберігати дані у файл? Для цього розкоментуємо (або додамо самостійно) словник ITEM_PIPELINES:

У ньому пропишемо шлях до класу і пріоритет виклику пайплайну (в цьому випадку – число 300). Якщо б у нас були додаткові пайплайни, то вони викликалися б у порядку від найменшого значення до найбільшого.

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

Тож вітаю, ви успішно отримали дані! У потрібній формі та з використанням необхідних фільтрів. Можу тепер лише порадити продовжувати опановувати Scrapy, вивчати нові способи роботи з ним і завжди памʼятати про етику у роботі з чужими ресурсами.

Наведені у статті приклади – лише верхівка айсберга. Я намагався показати якомога більше прикладів того, як ви можете працювати з різними інструментами скрейпінгу.

Якщо ж прагнете повноцінно опанувати скрейпінг, то у цій темі на вас чекає ще чимало відкриттів. Звернуть увагу на автоматизацію роботи пайплайнів. Подивіться на сервіси на кшталт Zyte, які дозволяють розмістити ваші скрейпери в мережі, або подумайте над додаванням бота в Telegram чи Viber.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Протягом усього процесу розробки, стикаючись із труднощами, які доводилося вирішувати самому або мозговим штурмом команди чи просто перебираючи інформацію в інтернеті, я сформував чек-ліст цих проблем та описав деякі способи їх вирішення.

Сповіщення

Неінформативні сповіщення

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

На верхній частині скріншота ми бачимо сповіщення, яке не дає достатньо інформації про подію, яка відбудеться. Ми не розуміємо добре це, чи ні.

На нижній частині ми бачимо, що усе гаразд, обробка вже була завершена і навіть можемо підставити в застосунку значення періоду, за який ця подія відбулася

Особливу увагу треба звертати на сповіщення із зовнішніх модулів, таких як, наприклад, Perl-скрипти. При виникненні помилки вони можуть повернути у викликаючий модуль, тільки код завершення роботи скрипта, без додаткових параметрів. Тут, по можливості, треба записати подію в базу, а Perl-скриптом видавати помилки у виняткових випадках, коли немає коннекту із базою.

З лівого боку скріншота ми бачимо об’явлені коди повернення у скрипті, а справа до цих кодів прив’язані сповіщення основного застосунку

Також слід мати можливість перехоплювати сповіщення/помилки, які генерує скрипт при виконанні, й записувати їх у лог системи/застосунку на клієнті.

Не вистачає сповіщень

При роботі застосунку (особливо тих процесів, які працюють у фоновому режимі) трапляються випадки, коли процеси завершуються коректно, але з логу незрозуміло, що цей процес робив (чи не робив) і чому.

У верхньому гриді ми бачимо, що процес відпрацював без помилок, але на вкладці «Крок» немає жодного запису про роботу процесу. Запис у нижній вкладці «Крок» дає нам зрозуміти, що процес нічого не робив через те, що дані вже були оброблені!

Цей момент дуже важливий для розуміння того, що відбувалося в цей час. Загалом необхідне логування. Його кількість і місця формування сповіщень треба закладати на етапі проєктування.

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

Потрібна золота середина між кількістю й інформативністю і це здебільшого залишається на розсуд і досвід розробника.

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

Специфікація

Перед початком розробки застосунку, системи, модуля чи внесення в існуючу розробку якихось змін необхідно створити документ (специфікацію), в якому описати майбутній функціонал, вимоги (особливо замовника), якісь особливості його реалізації тощо.

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

На скріншоті приводиться опис виставленого дефекту в Jira, коли неуважно читав специфікацію

Також можуть виникати непорозуміння через заплутані формулювання вимог до розробки. З цього приводу раджу намагатися переформулювати заплутані фрази, а також де це можливо розділяти на простіші й більш зрозумілі речення.

На цьому скріншоті показано переформулювання деякої частини вимоги, щоб вона була більш зрозумілою для усіх читачів, а не тільки автору наведеного тексту

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

Ще один нюанс, з яким ви можете зіткнутися під час розробки, – не все описане у специфікації можливо чи доречно реалізовувати в такому вигляді, як описано. Можна сказати, що треба уважніше й більш скрупульозно писати специфікацію, але ж не завжди є змога все врахувати заздалегідь. Частково в цьому допомагає досвід, який отримуєш при розробці інших модулів/систем.

Партиції

При розробці буває дуже зручно, коли декілька партиційованих таблиць мають єдине правило ділення на секції. Наприклад, партиції розділяються на однакові діапазони дат. Це зручно і для архівування даних, і для очистки, і для відновлення. Але можуть виникати проблеми з тестовим середовищем, коли відбувається розсинхронізація між партиціями таблиць.

Наприклад, у партицій різні діапазони дат. Тут рятують додаткові перевірки наявності й статусу партицій у системних таблицях, щоб не отримувати помилки, як, наприклад, таку:

ORA-02149: Specified partition does not exist

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

Жовтим вказаний оброблюваний діапазон дат 11.2012 і реальний діапазон даних, які в нього входять

Ручна зупинка процесу/операції

У деяких застосунках вбудована можливість зупиняти деякі операції вручну, особливо ті, що займають багато часу. Користувач може вручну припинити виконання процесу/операції в будь-який момент.

Звісно, існує загальне правило, що від моменту виставлення сигналу зупинки до моменту самої зупинки не повинно проходити більше 30 секунд (в різних організаціях можуть бути різні значення цієї константи).

Однак не завжди є можливість так швидко припинити цю операцію стандартними методами, як, наприклад, вибірка даних із бази даних складним запитом. Бажано робити скрипти вибірки даних, виконання яких займає небагато часу.

Після отримання сигналу зупинки треба прослідкувати за коректним завершенням роботи всіх модулів/скриптів, які задіяні в цьому процесі обробки даних, а не тільки в тому, де цей сигнал виявлено.

Некоректне закриття курсору при отриманні сигналу зупинки модуля

Також рекомендую зробити відповідний запис в лог. Перед цим обов’язково важливо визначитися, в якому місці (модулі/скрипті) це буде доцільним, щоб не було дублювання сповіщень, коли модулі взаємодіють між собою.

У цьому сповіщенні показано, що не той модуль обробляв сигнал зупинки обробки, тому й згенероване сповіщення не описує ситуацію, що відбулася

Відновлення обробки після збою

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

Як варіант реалізації механізм відновлення створюється на основі журналу процесів. У нього записуються оброблені дані за період або частину періоду (для партиційованих таблиць), що дає змогу, аналізуючи лог попереднього запуску, виключити оброблені дані зі списку обробки при повторному запуску процесу.

На скріншоті ми бачимо, які об’єкти та за який період оброблені. У разі збою повторний запуск процесу вилучить із черги обробки вже оброблені дані

Також сюди можна додати механізм захисту від наступних дій, які залежать від результату проходження попередньої обробки. До прикладу, не запускати чистку даних за період, архівація якого була перервана.

Це можна реалізувати на основі журналу архівів (дивитися скріншот нижче). Водночас дуже важливо налаштувати коректну роботу кожного з цих механізмів для правильної роботи всієї системи.

На скріншоті показано, що почався процес очистки. Якщо буде збій, то наступний процес враховуватиме це

Налаштування системи

Трапляється й таке, коли через неуважність забуваєш внести деякі налаштування для розробленого модуля чи вони не увійшли в оновлення системи.

Наприклад, коли виконується якийсь процес, то він видає повідомлення, яким для зручності присвоюється номер помилки. По цьому номеру можна і користувачу, і застосунку зрозуміти, якого ступеня важливості є ця помилка:

0 – це інформативне сповіщення;

1 – це попередження, що сталася некритична помилка, яка не впливає на подальшу роботу застосунку й так далі.

Якщо неправильно налаштувати цей рівень для якоїсь задачі/процесу, тоді після її завершення застосунок може неправильно оцінити результат (дивіться скріншот нижче).

Щоб цьому запобігти, краще внесені зміни записувати у записник/файл (чи в інше місце), оскільки не завжди вдається тримати у голові заміну якогось параметру на формі, який треба додати до патчу.

На скріншоті показано, що неправильно налаштований рівень помилки (на верхньому гріду підкреслено жовтим) призводить до некоректного позначення завершення процесу (в середньому гріду обведено червоним)

Пов’язані дані

Є неприємні випадки для архівації/відновлення, коли рядок таблиці посилається на інший рядок цієї ж таблиці. Ця рекурсія може мати кілька рівнів.

Доводиться зберігати додаткові дані й позначати їх як рекурсивні, а при подальшому відновленні не забувати правильно їх обробляти. Тут треба бути уважним із зовнішніми ключами.

На скріншоті показані пов’язані між собою рядки (ID виділені жовтим). У нижньому гріду показаний зв’язок по зовнішньому ключу (виділений жовтим)

Відладка модулів/скриптів

Важлива частина розробки – це закладати можливість отримати додаткову інформацію за необхідності. Можливість її вмикати/вимикати без додаткового втручання у код.

На скріншоті показаний приклад ручного логування, рядки жовтого кольору, коли треба розкоментувати позначені рядки й відкомпілювати модулі. Поганий варіант

Це дозволить отримувати потрібну для відладки інформації з користувацької системи, в якій виконується розроблений застосунок.

Як часткове рішення можна додати компонент перехоплення SQL-запитів. Наприклад, внизу вікно Debug Window, де показуються запити до БД.

Перехоплення SQL-запитів застосунку для подальшої відладки функціоналу

Ще одна важлива частина відладки – це можливість окремо тестувати модулі (процедури, функції й так далі), які входять у розробку.

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

Ця можливість закладається на етапі розробки кожного модуля/процедури/скрипта. Якщо при розробці використовуються глобальні змінні, колекції, тимчасові таблиці, тоді потрібно додавати механізм для їх заповнення тестовими даними.

На скріншоті показано, що до початку тестування основної функції архівації “f_archive” є можливість запустити процедуру “p_fill_var_and_tmp”, яка готує для неї необхідні дані

Продуктивність

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

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

Структура PIPELINED функцій в базі Oracle

Для зменшення навантаження на клієнтську машину і спрощення обробки вивантажувальних даних на клієнті з боку бази усі стовпці запитів «склеювалися» в один текстовий стовпець із заданим форматуванням для нетекстових даних.

Приклад склеювання стовпців

При цьому виникло 2 перешкоди:

• В Oracle 11 при вивантаженні ми обмежені колонкою в 4К. Тому не виключалася ситуація, коли не всі рядки склеєних колонок деяких таблиць могли поміститися в цей розмір, якщо будуть зустрічатися повністю заповнені рядки.
• У таблицях можуть знаходиться колекція або стовпець із XML-даними, які можуть мати будь-який розмір.

Для уникнення цих перешкод краще використовувати тип CLOB для вивантаження і в подальшому завантаження даних.

Всі колонки рядка таблиць приводяться до типу CLOB, а потім склеюються в одну колонку. Далі рядок за рядком відправляються клієнту.

Схематично показана передача склеєних колонок клієнтському модулю застосунку

Вивантаження кожного CLOB-рядка окремо не раціонально. Оскільки тип CLOB може вміщувати багато даних, є сенс об’єднувати рядки в один великий блок даних і надсилати його клієнту.

Для цього можна використати проміжну змінну типу CLOB, в яку рядок за рядком додаються дані, а потім вміст цієї змінної надсилається на клієнта.

Об’єднання декількох CLOB-рядків в один CLOB, який і відправляється клієнтському модулю

Щоб зменшити використання ресурсів сервера, можна обмежити розмір CLOB-змінної й вибрані дані надсилати на клієнта порціями, які в подальшому з’єднувати на клієнті в один файл.

Показано надсилання даних порціями й кожну порцію дописувати в цільовий файл

Перетворення колонок в тип CLOB із подальшим їх об’єднанням в одну колонку може призвести до зниження продуктивність всієї обробки, особливо при використанні старих версій Oracle.

Для вирішення цієї проблеми в запиті всі колонки можна перевести в текст, а колекції, XML-дані й CLOB – у тип CLOB. Усі колонки окремо додаються до CLOB-змінної, і так рядок за рядком.

Показано, що тільки колонки XML і колекції перетворюються в CLOB для подальшого об’єднання й передачі клієнтському модулю

Обробка кожної колонки в кожному рядку окремо (особливо коли колонок в таблиці дуже багато) може займати багато часу.

Рішення полягає в об’єднанні декількох колонок в одну там, де це можливо. На практиці в таблицях небагато колонок, які мають складні формати по типу колекції чи XML, тому цей спосіб добре працює.

Винятками можуть бути таблиці, які створені як додаток до основної таблиці. В них виносять поля зі складною структурою, і тоді потрібен індивідуальний підхід для обробки цих таблиць.

На скріншоті показано, як за допомогою склеювання полів простих типів даних можна зменшити подальшу обробку даних для передачі клієнтському модулю

Сподіваюся, що мій досвід стане у пригоді тим, хто працює чи працюватиме з Oracle!

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Часто вузькоспеціалізованих фахівців, які могли б забезпечити належний супровід, навіть не залучають до процесу зйомок. Тож глядачі губляться у викривленій реальності, а експерти спантеличені фальсифікаціями.

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

Саме тому ми вирішили проаналізувати чи не найпопулярніший злочин у кіно – злам системи безпеки через клавіатуру.

Як правило, він виконується у три етапи:

1. Пошук клавіатури.
2. Отримання фізичного доступу або перехоплення радіосигналу.
3. Злам системи через стороннє програмне забезпечення.

Розберемося, що не так на кожному з цих етапів.

Крок 1: Пошук клавіатури

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

Навіть якщо ніколи не були всередині, вони безпомилково знаходять правильну стіну, хоча пристрій встановлено із протилежної сторони. У теорії це може здатися простим, але на практиці розрізнити дротові та бездротові пристрої досить складно.

Щоб визначити точне місце розташування дротової клавіатури, злочинець повинен використовувати потужний мультисканер для пошуку потрібного кабелю у стіні.

Однак мультисканер не визначає, який саме кабель знайдено: дверний дзвінок, домофон чи електрична проводка. А якщо у приміщенні товсті стіни, мультисканер взагалі може виявитися безкорисним.

Якщо клавіатура бездротова, пошук прихованих кабелів не допоможе. Злочинці можуть просканувати радіосигнал, щоб визначити місце бездротового пристрою. Проте на обмін даними між пристроєм і хабом за технологією TDMA відводиться короткий проміжок часу. Решту часу їхні комунікаційні модулі неактивні.

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

Крім того, це може бути не пристрій Ajax, адже інші пристрої також використовують частоти Ajax.

Втім, щоб зловити радіосигнал, злочинці використовують код-граббер. Це спеціальний пристрій для перехоплення сигналу, що передається під час встановлення або зняття системи з-під охорони. Але зламати пристрій Ajax у такий спосіб неможливо через шифрування сигналу та пропрієтарний протокол зв’язку.

Технології захисту:

• блокове шифрування із плаваючим ключем;
• принцип TDMA.

Крок 2: Фізичний доступ

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

Як правило, клавіатури встановлюють на вході у приміщення. Зазвичай це несучі стіни з цегли, бетону або залізобетону товщиною 25 см і більше (залежно від будівельних норм і правил). Іноді товщина може доходити до 50 см, і просвердлити таку стіну безшумно за кілька секунд неможливо.

Окрім привернення уваги сусідів, існує ризик пошкодити дрилем пристрій. Лінія Fibra дротової клавіатури проходить через кабель-канал у кріпильній панелі SmartBracket.

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

Крім пошкодження пристрою, користувачі та пульт охорони (ПЦС) будуть сповіщені про спробу вторгнення.

У разі пошкодження кабелю вони отримають повідомлення про коротке замикання та розрив кільцевого під’єднання (якщо використовується топологія «кільце»). У разі обриву кабелю або пошкодження клавіатури також буде надіслано повідомлення про втрату зв’язку із хабом.

Навіть якщо злочинець спробує пошкодити систему безпеки за допомогою електричного саботажу (наприклад, електрошокера), LineProtect Fibra поглине удар. Усі пристрої між LineProtect і хабом продовжать працювати.

«LineProtect Fibra – модуль для захисту хабів і дротових пристроїв Ajax від саботажу, коли злочинець влаштовує коротке замикання, подає напругу 110/230 В~ чи використовує удари електрошокером. Модуль контролює вхідну та вихідну напругу на лінії Fibra. Якщо LineProtect виявляє аномальну напругу на лінії, він активує запобіжники й відключає живлення пристроїв, встановлених між LineProtect і хабом», – йдеться у повідомленні.

Бездротові клавіатури взагалі не мають дротів. Щобільше, всередині корпусів бездротових і навіть дротових клавіатур Ajax немає дротів.

Отже, під’єднатися до будь-якого дроту всередині корпусу пристрою абсолютно неможливо. Єдиний доступний дріт – ізольований і прихований кабель Fibra.

Деякі злочинці відривають клавіатуру від стіни та ламають її, що призводить до збою в системі безпеки. Однак клавіатура – це лише частина системи, а не її «мозок». Тому пошкодження клавіатури не має особливого сенсу з точки зору загрози безпеці системи в цілому.

Крім того, клавіатури Ajax мають тампер, який сповіщає користувачів і ПЦС у разі розкриття корпусу пристрою, зняття пристрою із кріпильної панелі або відриву його від поверхні.

Технології захисту:

• миттєві сповіщення;
• виявлення втрати зв’язку;
• тривога тампера;
• LineProtect Fibra;
• підʼєднання кільцем.

Крок 3: Злам

Припустимо, що злочинець під’єднався до клавіатури та залишився непоміченим системою. Оскільки це можливо тільки з Fibra, розгляньмо цей випадок.

Підключення до одного дроту, як це показують у фільмах чи серіалах, не має сенсу, оскільки лінія Fibra має чотири дроти: два сигнальні та два силові.

Для захисту даних Fibra використовує шифрування із плаваючим ключем. Злам і доступ до даних вимагають можливостей суперкомп’ютера й тижнів, а то й років витраченого часу. Інакше кажучи, це марна справа.

Однак навіть зашифровані дані спочатку потрібно отримати. Кожен сеанс зв’язку між хабом і пристроєм починається з автентифікації: порівнюються унікальні маркери та властивості. Якщо хоча б один параметр не пройшов перевірку, хаб ігнорує команди пристрою. Тому немає сенсу фальсифікувати або перехоплювати дані.

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

Коди всередині хаба надійно зберігаються в хешованій формі, до того ж хаб Ajax використовує операційну систему реального часу OS Malevich, що забезпечує захист від вірусів і кібератак.

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

Врешті-решт, неможливо зламати систему непоміченим. Будь-яке зняття системи з-під охорони фіксується, а користувачі та ПЦС отримують сповіщення. Ніхто не зможе видалити сповіщення зі стрічки подій хаба.

Крім того, якщо ПЦС відстежує час штатного встановлення і зняття системи з-під охорони, оператор зателефонує користувачеві, якщо система буде знята з-під охорони в незапланований час.

Технології захисту:

• зашифрований пропрієтарний протокол звʼязку;
• захист від підміни;
• автоблокування від несанкціонованого доступу.

Висновки

Зламати систему Ajax – це складне випробування. Дані захищені шифруванням, а клавіатура не зберігає коди. Хаб перевіряє кожну команду, фільтруючи спроби несанкціонованого доступу. Традиційні грубі атаки унеможливлюються завдяки функції автоблокування клавіатури.

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

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

У цій статті Роман Махник та Ігор Кочат, .NET Developers у NIX, розкриють основні особливості gRPC і пояснять, як працювати з цією технологією на прикладі gRPC-сервісу, написаного на мові C#.

Чому ІТ-проєкти відмовляються від монолітної архітектури

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

Візьмемо як приклад інтернет-магазин ігор, що складається з трьох сервісів: один надає ігри, другий показує досягнення гравця, а третій формує знижки. Кожна дія у такому магазині потребує звернення до певного сервісу. Тож цілком логічним виглядає ідея об’єднання всіх в одну систему з єдиною базою даних. Це і є мікросервісний підхід при проєктуванні застосунків.

Щодо відмови від традиційних монолітів є кілька причин:

• Масштабованість. Монолітні програми важко розширювати. Дані знаходяться на одному сервері, його модернізація недешева. Розміщення ж модуля або застосунку в цілому на іншому пристрої можливе лише при розділенні моноліту. А при використанні мікросервісної архітектури багато невеликих сервісів може бути розміщено на одній машині. При цьому ті, які мають велике навантаження, можна винести на окремі пристрої, зокрема й на хмарних платформах типу AWS Lambda та Azure Function. Там мікросервіси можна масштабувати автоматично, за необхідності, а оплата за ресурси буде залежати від фактичного часу роботи. Це вигідно і зручно. А для моноліта навіть у хмарі потрібна окрема, мінімум одна віртуальна машина із фіксованою абонплатою.
  
• Оновлення та додавання функціоналу. Монолітні програми ускладнюють процес впровадження нових фіч. Адже при модифікації навіть малозначного елемента треба зупиняти весь застосунок. А в мікросервісній архітектурі тільки змінна частина перезапускається, тоді як решта системи функціонує без переривань.
  
• Процес тестування. Всі компоненти монолітного застосунку зосереджені разом, через що потрібно запускати всю програму для проведення тестів. З мікросервісами можна окремо тестувати кожен компонент, не торкаючись інших частин системи.

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

Його можна будувати за двома методами:

• Синхронна комунікація. В цьому випадку один сервіс чекає на відповідь від іншого.
  
• Асинхронна комунікація. Один сервіс відправляє повідомлення в чергу, другий забирає його, коли готовий, і повертає відповідь.

У кожного методу є переваги та недоліки, які залежать від конкретної ситуації. Тож у статті ми зосередимося лише на синхронній комунікації. Для її реалізації найчастіше використовують REST та gRPC.

REST та gRPC: чим відрізняються

Для розуміння ключових відмінностей треба розібратися, як влаштовані обидва фреймворки.

У REST із використанням стандартної CRUD-логіки зазвичай застосовуються такі основні типи HTTP-запитів:

• GET для читання.
• POST для додавання.
• PUT та PATCH для модифікації.
• DELETE для видалення.

За схемою REST клієнт та сервер пов’язані через мережу. Коли клієнт надсилає HTTP-запит, сервер обробляє його і повертає HTTP-відповідь. І поки сервер обробляє запит, клієнт створює окремий потік та очікує.

Але HTTP-запити можна замінити на виклики віддалених процедур, тобто RPC. Схема взаємодії залишиться схожою, проте надсилання й отримання запитів і відповідей будуть трохи іншими.

RPC є методом виклику віддалених функцій або процедур, який дозволяє одній програмі викликати метод, функцію чи процедуру в іншій програмі у мережі. З цим методом клієнт та сервер спілкуються через спеціальні проксі-об’єкти, відомі як заглушки (stub).

Тобто створюється враження, що клієнт викликає процедури (методи) так, ніби вони реалізовані прямо в нього. Ці заглушки перенаправляють дані за відповідною адресою. Це спрощує програмування, адже не треба нічого робити в самому коді, описувати HTTP-заголовки, методи тощо.

Заглушки створюються автоматично, і розробнику залишається викликати потрібні функції або процедури.

Одне з найкращих застосувань цієї концепції представлено у вигляді gRPC. gRPC – це система, що реалізує традиційний RPC із кількома оптимізаціями.

На фоні інших RPC-реалізацій у цього фреймворку є низка переваг:

• Просте визначення сервісів. Це можливо завдяки .proto-файлам.
  
• HTTP/2. Це надає підтримку двосторонньої потокової передачі даних. Попри те, що HTTP/2 вже був доступний від ASP.NET Core 3 (документація, приклад), gRPC створений спеціально для того, щоб ефективно використовувати цей протокол.
  
• Трасування. Ідеальний інструмент для діагностики та покращення сервісів, який надає можливість відстежувати виклики процедур.
  
• Механізм Health check. Він потрібен для швидкої перевірки стану сервісу та його готовності обробляти запити. Це полегшує балансування навантаження.
  
• Балансування навантаження. Воно забезпечує рівномірне розподілення завдань між серверами, що спрощує масштабування. Цей процес може здійснюватися як на рівні клієнта, так і через проксі з використанням сервіс-меша.
  
• Інтеграції системи автентифікації. У ранніх версіях протоколу така можливість була відсутня, через що RPC загалом використовували лише для внутрішніх комунікацій.

Порівняно з технологією REST gRPC також демонструє низку переваг:

• Застосування Protobuf. На відміну від текстового JSON або XML, що використовується в REST і не піддається стисненню, Protobuf є бінарним форматом. Сервер визначає структуру даних, використовуючи мову опису інтерфейсу протокольного буфера (IDL) у файлі специфікації прототипу. Потім gRPC серіалізує структуру в бінарний формат, а потім десеріалізує її на будь-яку вказану мову програмування. Цей механізм робить це швидше, ніж під час використання JSON, який не стискається під час передачі. Хоча gRPC пропонує вбудовану підтримку JSON.
  
• Обробка HTTP-запитів. Для цього не потрібен постійний аналіз можливих статус-кодів і змісту даних, як це відбувається у REST. Виклик процедур максимально спрощений.
  
• Зручний опис контрактів. REST вимагає для опису інтерфейсів та документації таких додаткових інструментів, як OpenAPI або Swagger. А контракти в gRPC визначаються безпосередньо через .proto-файли.
  
• Двонапрямний потоковий зв’язок. Клієнт і сервер можуть надсилати й отримувати кілька запитів та відповідей одночасно по одному з’єднанню. REST не пропонує цієї функції. Використовуючи REST API, клієнт надсилає серверу один запит REST API, а потім сервер відправляє одну відповідь. Клієнт повинен дочекатися її, перш ніж продовжити роботу. Цей механізм є моделлю запиту-відповіді і є унарним з’єднанням даних (один-до-одного). За допомогою gRPC клієнт може надіслати один або кілька запитів API на сервер, що може призвести до однієї або кількох відповідей від сервера. З’єднання даних можуть бути унарними (один-до-одного), потоковими серверами (один-до-багатьох), потоковими даними клієнта (багато-до-одного) або двонанапрямними потоками (багато-до-багатьох). Цей механізм можливий, оскільки gRPC заснований на HTTP/2.
  
• HTTP/2. REST часто вдається до старшого HTTP/1.1.

Про останній пункт треба сказати окремо.

Переваги HTTP/2 включають:

• Бінарний формат даних, що забезпечує зменшення обсягу переданої інформації та покращує продуктивність.
• Оптимізація трафіку завдяки більш ефективному стисканню HTTP-даних, насамперед заголовків.
• Підтримка передачі даних у потоках.
• Мультиплексування, завдяки якому в HTTP/2 достатньо одного з’єднання для передачі кількох файлів. А в HTTP 1.1 для, наприклад, трьох файлів потрібно й три з’єднання.
• Пріоритезація потоків при передачі.

Налаштування з’єднання gRPC

Для створення gRPC-каналу потрібно виконати такі кроки:

1. Відкрити сокети.
2. Ініціювати з’єднання TCP між клієнтом та сервером.
3. Узгодити TLS.
4. Встановити HTTP/2-з’єднання.
5. Запустити виклик gRPC-процедури.

Можна використовувати й механізм Persistent Connection. У такому випадку достатньо встановити одне з’єднання й уникнути відразу чотирьох перших етапів.

Але з таким механізмом виникають складнощі у налаштуванні балансування навантаження. Наприклад, якщо вам потрібно кілька екземплярів сервісу, їх треба якось розподіляти.

Для цього існує два рішення:

• Балансування на рівні клієнта. Для цього клієнтська бібліотека працює з кількома інстансами та надсилає запити у певному відсотковому співвідношенні.
  
• Балансування за допомогою проксі. Якщо для хостингу серверів використовується оркестратор на кшталт Kubernetes, то він може відповідно до ситуації прибирати або додавати інстанси. З цим допоможе балансування через проксі Service Mesh: Linkerd, Istio, Consul тощо. Клієнт встановлює стабільне з’єднання з Mesh, а той відстежує появу чи зникнення екземплярів сервісу та вирішує, як розподіляти з’єднання. Тож коннект буде лише з актуальними сервісами, хоча клієнту це не важливо, оскільки він працює з одним з’єднанням.

Хтось може порівняти gRPC із фреймворком WCF. Проте перший є спеціалізованим інструментом для фактично однієї задачі, а другий – це універсальне рішення з підтримкою як RPC, так і REST чи SOAP.

Однак у WCF є вада: залежність від платформи .NET. А gRPC працюватиме з будь-яким середовищем, плюс писати його можна будь-якою мовою з тих, що підтримуються.

Щоправда, gRPC не може повноцінно інтегруватися у браузери через відсутність реалізації HTTP/2-комунікації. Це пов’язано з відсутністю контролю каналу, який можливий у .NET-застосунку. Для цього в самому Google пропонують використовувати gRPC-проксі. У такому випадку браузер відправлятиме стандартні запити HTTP 1.1 на проксі, а вже він конвертуватиме повідомлення на gRPC-коли.

Створення gRPC-застосунку

Для демонстрації принципів створення застосунків для gRPC ми розберемо простий сервіс, який зберігає визначення слів. Ми зможемо додавати слова та визначення у словник, а потім так само отримувати визначення слів.

Першим кроком треба відкрити Visual Studio, де вже є готові шаблони для розробки таких сервісів. Для цього необхідно вибрати опцію «Створити новий проєкт» та ввести «gRPC», після чого система запропонує відповідний темплейт.

У проєкті міститься .proto-файл, який визначає сервіс та інтерфейс. Сам сервіс має процедуру SayHello. Вона приймає об’єкт Hello, який описаний далі, і відправляє назад реплай, який описаний у цьому ж файлі.

Ексклюзивною особливістю для .NET є опція csharp_namespace, яка вказує місце створення класів для цього застосунку.

syntax = "proto3";

option csharp_namespace = "GrpcExample";

package greet;

// The greeting service definition.
service Greeter {
// Sends a greeting
rpc SayHello (HelloRequest) returns (HelloReply);
}

// The request message containing the user's name.
message HelloRequest {
string name = 1;
}

// The response message containing the greetings.
message HelloReply {
string message = 1;
}

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

Якщо на серверній стороні оновлюється .proto-файл, змінюючи властивості, то клієнт із не оновленим файлом пропустить нові властивості й читатиме старі як порожні.

Тепер нам потрібно замінити цей код згідно з нашою логікою:

syntax = "proto3";

option csharp_namespace = "GrpcExample";

package definition;

service Definition {
rpc AddDefinition (AddDefinitionRequest) returns (AddDefinitionResponse);
rpc GetDefinition (GetDefinitionRequest) returns (GetDefinitionResponse);
}

message AddDefinitionRequest {
  string word = 1;
  string definition = 2;
}

message AddDefinitionResponse {
  string message = 1;
  int32 dictionarySize = 2;
}

message GetDefinitionRequest {
  string word = 1;
}

Також змінимо наш сервіс:

using Grpc.Core;
using GrpcExample.Interfaces;
using GrpcExample.Repositories.Interfaces;

namespace GrpcExample.Services
{
    public class DefinitionService : Definition.DefinitionBase, IDefinitionService
    {
        private readonly ILogger<DefinitionService> _logger;
        private readonly IDefinitionRepository _definitionRepository;

        public DefinitionService(ILogger<DefinitionService> logger, IDefinitionRepository definitionRepository)
        {
            _logger = logger;
            _definitionRepository = definitionRepository;
        }

        public async override Task<AddDefinitionResponse> AddDefinition(AddDefinitionRequest request, ServerCallContext context)
        {
            var key = request.Word.Trim();

            await _definitionRepository.Create(key, request.Definition);
        	return new AddDefinitionResponse
        	{
            	Message = "Definition added successfully.",
            	DictionarySize = await _definitionRepository.Count()
        	};
        }

        public async override Task<GetDefinitionResponse> GetDefinition(GetDefinitionRequest request, ServerCallContext context)
        {
            var key = request.Word.Trim();

            var data = await _definitionRepository.Get(key);
            if (data == null)
            {
                return new GetDefinitionResponse
                {
                    Definition = string.Empty,
                    Found = false 
                };
            }

            return new GetDefinitionResponse
	{
                Definition = data, 
                Found = true 
            };
        }
    }
}

Для прикладу додамо простий in-memory репозиторій:

using GrpcExample.Repositories.Interfaces;
using System.Collections.Concurrent;

namespace GrpcExample.Repository
{
    public class DefinitionRepository : IDefinitionRepository
    {
        private readonly ConcurrentDictionary<string, string> definitions = new();

        public async Task Create(string name, string definition)
        {
            definitions.AddOrUpdate(name, x => definition, (x, y) => definition);
        }

        public async Task<string?> Get(string name)
        {
            if (definitions.TryGetValue(name, out var definition))
            {
                return definition;
            }

            return null;
        }

        public async Task<int> Count()
        {
            return definitions.Count;
        }
    }
}

Ось такий вигляд має мати наш клас Program:

using GrpcExample.Interfaces;
using GrpcExample.Repositories.Interfaces;
using GrpcExample.Repository;
using GrpcExample.Services;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddGrpc(); 	// тут ми реєструємо gRPC сервіс

builder.Services.AddSingleton<IDefinitionRepository, DefinitionRepository>();
builder.Services.AddSingleton<IDefinitionService, DefinitionService>();

var app = builder.Build();

// Configure the HTTP request pipeline.
app.MapGrpcService<DefinitionService>();
app.MapGet("/", () => "Communication with gRPC endpoints must be made through a gRPC client. To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909");

app.Run();

А тепер створимо клієнт для нашого gRPC-сервісу. Клієнтом буде виступати вебзастосунок з оригінальним іменем WebApi, який буде приймати HTTP-запити та звертається до gRPC-сервісу для виконання процедур.

Єдина відмінність у .proto-файлі – це namespace для генерації клієнтського коду. Але можна було б використовувати і спільний файл. Головне: домовитись у команді, де саме його зберігати і як зручніше додавати до проєкту.

syntax = "proto3";

option csharp_namespace = "WebApi";

package definition;

service Definition {
  rpc AddDefinition (AddDefinitionRequest) returns (AddDefinitionResponse);
  rpc GetDefinition (GetDefinitionRequest) returns (GetDefinitionResponse);
}

message AddDefinitionRequest {
  string word = 1;
  string definition = 2;
}

message AddDefinitionResponse {
  string message = 1;
  int32 dictionarySize = 2;
}

message GetDefinitionRequest {
  string word = 1;
}

message GetDefinitionResponse {
  string definition = 1;
  bool found = 2;
}

Файли Protobuf у проєкті реєструються окремо, не як стандартні файли. Для цього вказується використання певного Protobuf і роль сервісу в контакті (у такому випадку роль буде клієнтською).

Залишається тільки вказати в серверному проєкті використання такого ж .proto-файл вже із роллю сервера. Саме за допомогою такого синтаксису і є можливість винести .proto-файл в окрему від проєкту директорію.

Для простоти прикладу продовжимо з копіями цього файлу для кожного застосунку:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework> 
  </PropertyGroup>

  <ItemGroup>
    <Protobuf Include="Protos\Definition.proto" GrpcServices="Client" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="Grpc.AspNetCore" Version="2.40.0" />
    <PackageReference Include="Grpc.Net.ClientFactory" Version="2.59.0" />
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.5.0" />
  </ItemGroup>

</Project>

Для більш ефективного повторного використання з’єднання також слід ініціалізувати фабрику gRPC-клієнтів. Для цього треба застосувати AddGrpcClient та визначити конкретний сервіс, для якого потрібен клієнт. Після цього слід вказати адресу, на якій знаходиться сервіс.

public void ConfigureServices(IServiceCollection services)
{
    services.AddGrpcClient<Greeter.GreeterClient>(o =>
    {
        o.Address = new Uri("https://localhost:5001");
    });

    services.AddControllers();
    services.AddSwaggerGen(c =>
    {
        c.SwaggerDoc("v1", new OpenApiInfo { Title = "WebApi", Version = "v1" });
    });
}

Застосування створеного gRPC-клієнта доволі просте. Його можна будь-коли інтегрувати у потрібний об’єкт за допомогою Dependency Injection.

У прикладі створено 2 ендпоінти під обидва gRPC-методи: AddDefinition, GetDefinition. Це функції контролера, які приймають HTTP-запити та перенаправляють їх на обробку до сервісу gRPC.

using Microsoft.AspNetCore.Mvc;
using WebApi;

namespace WebApiClient.Controllers
{
    [ApiController]
    [Route("[controller]")]
    public class DefinitionController : ControllerBase
    {
        private readonly Definition.DefinitionClient _client;

        public DefinitionController(Definition.DefinitionClient client)
        {
            _client = client;
        }

       [HttpPost]
        public async Task<IActionResult> AddDefinition([FromBody] AddDefinitionRequest request)
        {
            var result = await _client.AddDefinitionAsync(request);
            return Ok(new { Message = result.Message, DictionarySize = result.DictionarySize });
        }

        [HttpGet]
        public async Task<IActionResult> GetDefinition([FromQuery] GetDefinitionRequest request)
        {
            var result = await _client.GetDefinitionAsync(request);
            return Ok(new { Definition = result.Definition, Found = result.Found });
        }
    }
}

Наступним кроком треба активувати gRPC-сервіс, перевірити його працездатність і запустити клієнт.

Надсилання запиту можна трохи спростити за допомогою документації Swagger. Вказуємо необхідні параметри й дивимось на відповідь. Як бачимо, визначення для нашого слова додане, і наш словник тепер має 1 запис.

У логах можемо переконатися, що запит був оброблений нашим gRPC-сервісом.

Статус-коди gRPC

Корисно також пам’ятати, що gRPC має свою систему кодів статусу. gRPC-помилки позначаються кодами, які визначені у класі Grpc.Core.StatusCode.

Вони включають такі значення:

OK (0): Успішне виконання запиту.

CANCELLED (1): Запит скасовано клієнтом.

UNKNOWN (2): Невідома помилка.

INVALID_ARGUMENT (3): Неправильні аргументи запиту.

DEADLINE_EXCEEDED (4): Час виконання запиту минув.

NOT_FOUND (5): Ресурс не знайдено.

ALREADY_EXISTS (6): Ресурс уже існує.

PERMISSION_DENIED (7): Недостатньо прав для виконання операції.

RESOURCE_EXHAUSTED (8): Вичерпано ресурси.

FAILED_PRECONDITION (9): Порушено передумову.

ABORTED (10): Операцію було перервано.

OUT_OF_RANGE (11): Значення знаходиться поза допустимим діапазоном.

UNIMPLEMENTED (12): Функціонал не реалізований.

INTERNAL (13): Внутрішня помилка сервера.

UNAVAILABLE (14): Сервер тимчасово недоступний.

DATA_LOSS (15): Втрата даних.

UNAUTHENTICATED (16): Відсутні облікові дані або недійсні.

Для їх використання достатньо «кинути» RpcException у коді gRPC-сервісу.

Наприклад, це може виглядати таким чином:

throw new RpcException(new Status(StatusCode.AlreadyExists, "The definition is already in the dictionary."));

Також є можливість створити «мапер» різних виключень (exceptions) по типу звичного для нас ExceptionHandlerMiddleware або ExceptionFilter за допомогою ExceptionInterceptor. Приклад такого коду можна знайти за цим посиланням.

Unit-тестування gRPC-сервісів

Unit-тестування для gRPC-клієнту просте, тому що ми можемо просто підмінити імплементацію сервісу по інтерфейсу. При тестуванні самого ж gRPC-сервісу єдиним нюансом буде необхідність передачі ServerCallContext до методу, що буде тестуватися.

Якщо цей об’єкт ніяк не використовується реалізацією методу сервісу (як у нашому випадку), ми можемо просто підмінити його (як, наприклад, mockContext у коді нижче). В іншому випадку можна використати TestServerCallContext для створення такого об’єкта (приклад mockContext2 є у коді нижче).

TestServerCallContext зазвичай використовується в тестах, коли вам необхідно змоделювати конкретні умови або сценарії, які можуть виникнути у реальному виклику віддаленого методу gRPC.

using Grpc.Core;
using Grpc.Core.Testing;
using GrpcExample;
using GrpcExample.Interfaces;
using GrpcExample.Repositories.Interfaces;
using GrpcExample.Services;
using Microsoft.Extensions.Logging;
using NSubstitute;
using Xunit;

namespace UnitTest
{
    public class DefinitionServiceTests
    {
        [Fact]
        public async Task AddDefinition_ReturnsSuccessMessage()
        {
            // Arrange
            var loggerMock = Substitute.For<ILogger<DefinitionService>>();
            var definitionRepositoryMock = Substitute.For<IDefinitionRepository>();

            var service = new DefinitionService(loggerMock, definitionRepositoryMock);

            var world = "TestWord";
            var definition = "TestDefinition";

            var request = new GetDefinitionRequest { Word = world };

           var mockContext = Substitute.For<ServerCallContext>();

	var mockContext2 = TestServerCallContext.Create( 
       		method:nameof(IDefinitionService.GetDefinition)
                         , host: "localhost"
                         , deadline:DateTime.Now.AddMinutes(30)
                         , requestHeaders: new Metadata()
                         , cancellationToken:CancellationToken.None
                         , peer: "10.0.0.25:5001"
                         , authContext: null
                         , contextPropagationToken: null
                         , writeHeadersFunc: (metadata) => Task.CompletedTask
                         , writeOptionsGetter: () => new WriteOptions()
                         , writeOptionsSetter: (writeOptions) => { }
                         );

            definitionRepositoryMock.Get(world)
                .Returns(definition);

            // Act
            var result = await service.GetDefinition(request, mockContext);

            // Assert
            definitionRepositoryMock.Received(1).Get(world);
            Assert.NotNull(result);
            Assert.Equal(definition, result.Definition);
            Assert.True(result.Found);
        }
    }
}

Перевірка автентичності токена авторизації

Наступна потенційна проблема – необхідність автентифікації й авторизації для юзерів.

Для автентифікації gRPC-клієнта можна використовувати різні підходи, навіть звичні для всіх JWT-токени. Для цього можна вказати значення потрібного хедера через клас Metadata, значення якого будуть передаватися у вигляді HTTP-заголовків (хедерів).

Через те, що у нас є можливість налаштувати HttpClientHandler і для клієнта, і для сервера, ми можемо реалізувати автентифікацію зокрема і через клієнтські сертифікати.

Перевірка автентичності сертифікатів клієнта

Клієнт може також надати сертифікат клієнта для автентифікації. Перевірка дійсності сертифіката відбувається на рівні TLS задовго до його потрапляння в ASP.NET Core.

Коли запит потрапляє в ASP.NET Core, пакет для роботи із сертифікатами клієнта дозволяє розглядати дані сертифікату через клас ClaimsPrincipal. Приклад цього механізму ви можете оцінити за посиланням.

Авторизація запитів gRPC

Сервіси gRPC підтримують атрибут Authorize.

[Authorize]
public class DefinitionService : Definition.DefinitionBase
{
}

Можна використовувати аргументи конструктора і властивості атрибута Authorize, щоб обмежити доступ лише користувачами, які відповідають певним політикам авторизації.

Наприклад, за наявності політики авторизації з ім’ям MyAuthorizationPolicy використовуйте наступний код. Завдяки цьому доступ до служби зможуть отримати тільки ті користувачі, які відповідають цій політиці.

До окремих методів служби також можна застосовувати атрибут Authorize із додатковими вимогами.

[Authorize]
public class DefinitionService : Definition.DefinitionBase
{
    [Authorize("Administrators")]
    public async override Task<AddDefinitionResponse> AddDefinition(AddDefinitionRequest request, ServerCallContext context)
    {
                // ...something only Administrators can do
    }
}

Працювати із gRPC досить просто. Саме тому багато проєктів використовують цей фреймворк. Однак спільнота його фанатів досі поступається за розміром ком’юніті REST API. І це не дивно, адже для відповіді кінцевим користувачам нам все ще набагато зручніше використовувати REST-підхід, аніж налаштовувати проксі, як це описано вище.

Враховуючи зростання популярності gRPC, ком’юніті буде активно розширюватися, і ця технологія має всі шанси надалі стати корисною у багатьох випадках.

Хоча розглянутий приклад був простим, у складних системах gRPC може значно підвищити продуктивність спілкування між сервісами.

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

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Ринок у всьому світі розвивається. Особливо інвестиції зростали з 2017 по 2021 рік. Так, у 2017 році обсяг інвестицій по всьому світі становив $4,4 мільярда, а у 2021 він зріс до $20,8 мільярда.

Втім, обсяг впав на 49% у 2022 році. Це було зумовлено політикою обмеження приватних освітніх компаній у Китаї, де інвестиції в EdTech до 2021 року були найбільшими у світі. Проте у всьому світі ринок продовжує розвиток.

В Україні EdTech теж активно розвивається, незважаючи на перешкоди. Ще у 2019 році частка українців із цифровими навичками на рівні нижче базового становила 53%. Проте до цього року вказаний показник знизився на 12,6%, в тому числі завдяки «Концепції розвитку цифрових компетентностей до 2025 року», прийнятій Кабміном.

Далі його розвитку сприяла пандемія коронавірусу, коли як школярі, так і спеціалісти перебували на самоізоляції. За цей час з’явилася велика кількість платформ дистанційного навчання та онлайн-курсів.

В умовах війни EdTech продовжує розвиток. Хоча такі перешкоди, як відключення світла та відсутність мережі часто переривали навчальний процес, дистанційна освіта була єдиним виходом під час обстрілів – як для учнів в Україні, так і для тих, хто перебував за кордоном. Усі ці фактори створюють потребу у прискореному зростанні технологій цифрової освіти.

Дуже багато галузей українського IT-сектору постраждали через війну. Проте для напряму EdTech вторгнення стало каталізатором розвитку. Цифрова освіта набуває більшої популярності, а український ринок зміг відмежуватися від ринку СНД і продовжує розвиток.

Онлайн-курси дозволяють як берегти ресурси компаніям, що навчають працівників, так і залучати аудиторію блогерам, які пропонують власні інфопродукти. Хоча цифрова освіта не є офіційною, це питання часу, оскільки вона має достатньо переваг перед ВНЗ і може стати основною системою освіти в майбутньому.

Галузь EdTech в Україні з початку вторгнення

Pilicam – це польська платформа для створення онлайн-курсів, яка допомагає бізнесам швидко та якісно навчати нових працівників, партнерів, а також продавати тренінги та курси. Існує проєкт близько 1,5 року. За цей час ідея еволюціонувала від білетного сервісу до теперішнього вигляду.

Ми побачили, що зараз має попит онлайн-освіта, наприклад, курси від блогерів. Але, як відомо, організація курсів від блогерів часто буває розділеною на багато різних платформ, які між собою не пов’язані.

Спеціально щоб об’єднати всі навчальні матеріали в одному місці, ми змінили напрям діяльності з білетного сервісу на конструктор курсів. Головні наші конкуренти – Academia Ocean на українському ринку, Web to Earn на польському та GetCourse на ринку СНД. Розвиваючи проєкт із нуля, маю досвід, яким хотів би поділитися.

Оскільки ми базуємося в Польщі, на нас війна не вплинула, всі труднощі з нею не були пов’язані. Але відбулися різкі зміни на українському ринку. Відразу після вторгнення значно зріс попит серед українських блогерів. За відчуттями, ринок зріс на 50-100%, купують всі можливі курси.

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

За моїми спостереженнями, польський ринок дуже схожий на український, але він відстає приблизно на 3 роки. Ті тренди, які зараз є на ринку Польщі (як блогери вибудовують продажі, як ведуть соцмережі), вже відбулися в Україні. Після початку війни українські користувачі відмежувалися від продуктів ринку СНД, тож це надало можливість для самостійного розвитку.

Головний тренд, який з’явився ще під час коронавірусу, – люди шукають роботу, пов’язану з онлайном. Багато молодих людей надає перевагу знанням, що пов’язані з Інтернетом, соцмережами, IT тощо. Такі знання легше і простіше здобути через онлайн-курс, ніж, наприклад, за 5 років навчання в університеті. Зараз набагато більша популярність в онлайн-роботи або хоча б у гібридної, ніж у повністю офлайн.

На що є запит в EdTech

Навчання нового працівника через онлайн-курс – набагато дешевше і простіше у реалізації, оскільки працівник має прийти не з повним «нулем» знань, а вже із певною базою. У цьому разі достатньо ознайомити новенького з технологіями, які використовуються саме на проєкті.

Коли працівник проходить пробний період, йому дається доступ до цього курсу й тестове завдання. Не йдеться про лише перегляд змісту. Ми також робимо невеличкий екзамен, щоб пересвідчитися, що учень все засвоїв.

Ось як це виглядає. Нещодавно я наймав front-end-розробника. Йому призначається пробний період. Коли він його проходить, йому відкривають доступ до навчання. У курсі міститься два записи розмови з тімлідом, де ми розповідаємо, як влаштований проєкт, що слід робити, які загальні правила. Після того, як він це перегляне, йому дається тест на знання матеріалу.

Особливо це актуально для таких посад, як менеджер із продажів. Їм потрібно дуже багато знань про методи, системи й технології, які використовує компанія.

Попередньому менеджеру, який навчає новеньких, може знадобитися 3-5 днів лише на пробний етап кандидата. За цей час пошукач може в будь-який момент «вигоріти» та відмовитися, а це частий випадок. При цьому теперішній менеджер відчуває демотивацію, якщо понад три кандидати вже відмовилися. Подальшим кандидатам він буде доносити інформацію «на автоматі», а значить гірше, ніж попереднім.

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

Як знаходити клієнтів

Що стосується компаній, то поки з них є тільки польська музикальна школа, вони користуються корпоративним навчанням. А якщо брати основну цільову аудиторію, то це офлайн-бізнеси, які не мають IT-відділів і для яких платформа допомагає з організацією навчання. А от з IT-компаніями співпрацювати важко, оскільки у них і так є змога зробити навчальний проєкт самостійно.

Головний фактор офлайн-бізнесів, який дає перевагу навчанню через курси, – швидша зміна працівників. Якщо раніше люди працювали десятиліттями на одній роботі, то зараз на деяких посадах працівники змінюються за 2-3 роки. У майбутньому цей час ще більше скоротиться.

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

Суть платформи – саме в обслуговуванні, маркетинг ми на себе не беремо. Можливо, ми реалізуємо маркетплейс для користувачів у майбутньому, але це можна розглядати, якщо аудиторія платформи становитиме приблизно 25-50 тисяч користувачів, з яких хоча б 15 тисяч будуть активними. Але наразі блогери самостійно просувають свої курси через соцмережі, а для нас конкурувати з Instagram немає сенсу.

Де шукати інвестиції

Найскладніше завдання – це зробити платформу прибутковою. Ми створили MVP з одним програмістом, після чого необхідно було залучати інвестиції. Це складний етап, ми знайшли партнера, який інвестував $80 тисяч. Зараз накопичуємо ресурси для нового старту, залучаємо нову аудиторію та шукаємо інвестиції.

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

Шукаємо інвесторів зазвичай у бізнес-клубах і спільнотах. Наприклад, варшавська «Магія Ранку» зараз закриває приблизно 80% наших потреб, оскільки у них найкращі спікери – і з напряму IT, і з продажів, і з блогерства. Також ми приєдналися до EASE, щоб мати більше зв’язків з IT-спільнотою.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

Всі ж пам’ятають скільки разів я суворо критикував Дію? У січні 2022 року ми з колегами навіть список основних її гріхів склали. Той список добрі люди навіть англійською переклали.

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

Але тепер вона «лягла» у той критичний момент, коли ні за що не повинна була «лягати»: «застосунок для голосування» не справився із голосуванням. Адже ні для кого вже не секрет, що таємне стратегічне призначення Дії – для «виборів у смартфоні» із заздалегідь визначеним організаторами результатом.

До вчорашнього дня суспільний договір полягав приблизно у тому, що піпл не особливо париться стосовно викриків всіляких там експертів, мовляв, «у Дії є проблеми з безпекою». Зате зручно! Можна водійське посвідчення вдома забути, класно ж. Про штраф тебе відразу повідомлять, до суду викличуть, кредит тобі оформлять. Краса ж?

Але після такого приголомшливого фіаско навряд чи репутація державного застосунку колись відновиться. Розробники чомусь досі вірять, що, загнавши кілька десятків мільйонів користувачів у Дію, вони примусять їй довіряти.

Дослідження 2023 року свідчить, що 67% респондентів вважають Дію «засобом централізованого стеження за населенням».

У мене на телефоні немає ані Дії, ані Телеграму. А також застосунків типу «Яка ти рослина» чи «Яким ти будеш через 30 років». Бо я ж експерт, бляха, із кібербезпеки. Тому мені важко зрозуміти, нахіба люди тягнуть собі у смартфони подібне г. Але якщо вже тягнете – ставитися до цього всього слід виключно як до розваги: ну прикольно, погрався та й видалив.

Всерйоз розглядати рукожопську поробку як спосіб для голосування за вище керівництво державою, як електронний кабінет призовника чи як електронне посвідчення особи не можна категорично.

І трохи зловтішних висновків. Провал голосування через Дію на фіналі нацвідбору Євробачення показово візуалізував ризики № 10 та № 19.

У кого не було Дії – не могли проголосувати. Це реалізація ризику № 11.

Завдяки повній непрозорості роботи застосунку (ризики №№ 12, 13, 15, 16, 17, 18, 19) неможливо перевірити результати голосування, можна лише сліпо вірити організаторам.

Відсутність альтернативи – це ризик № 15. І це просто дніще, додам від себе окремо.

Примусове загоняння фанатів Євробачення в Дію. Неспортивно, не по-джентльменськи, фу. І цей підлий прийомчик вже не вперше застосовується. Схожим чином «набивали» користувацьку базу при отриманні «ковідних сертифікатів», «8 тисяч компенсації для ФОПів» та «ковідної тисячі». Брудна гра.

До речі, маю стійку підозру, що більшу частину статистики «користувачів Дією» становлять люди, які змушені були її встановити, один раз скористалися й відразу, матюкнувшись, знесли. Тому що українці – це все ж таки про свободу та незалежність.

Коли до чогось примушують – це автоматично викликає підозру, невдоволення, спротив. Так, багато хто користується Дією. Так, є деякі корисні функції. Але репутація – то досить специфічна штука.

Достатньо один раз лажонути – і тебе будуть оцінювати саме по тому одному разу. А Дія лупить репутаційно у штангу приблизно у 70% випадків. Точніше – у 67%.

P.S.: Картинку взяв у Богдана Процишина. І взагалі, судячи з океану мемів на цю тему, більшість користувачів Дії ставляться до неї, м’яко кажучи, скептично. Ржуть, але продовжують користуватися. Однак це вже тема для дещо іншого дослідження.

UPD1: Насправді було не 1,5 тисячі, а 15 тисяч запитів на секунду, що принципово нічого не змінює.

UPD2: У жовтні 2023 року було зафіксовано рекордну DDoS-атаку у світі: 398 мільйонів запитів на секунду проти Google, тому не виключено, що Гороховський теж міг трохи «перебільшити». Що знову-таки нічого принципово не змінює.

UPD3: навіть 15 тисяч запитів на секунду – це дрібничка. Сам Федоров розказував два роки тому про рекордний DDoS у 2 мільйони запитів на секунду.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодної публікації!

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

Оновлення програмного забезпечення, операційної системи й антивірусів

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

До новітніх технологій швидко адаптуються не тільки розробники, а й зловмисники, які шукають шляхи використання слабкостей. Швидке оновлення – це лише один із компонентів кібербезпеки, які допомагають захистити вашу інформацію, тому потрібно приділити увагу й наступним.

Контролюйте безпеку кінцевих точок: надійні паролі для кожного облікового запису та функція віддаленого стирання

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

Як би банально це не звучало, але зазначу про важливість того, щоб пристрої завжди були під наглядом. Це теж спосіб уникнути доступу до них, цього разу фізичного.

Я вже неодноразово вказував на важливість надійних паролів, але ми в Tet і надалі спостерігаємо, як цей аспект ігнорують багато організацій.

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

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

Не ігноруйте таку корисну функцію, як менеджер паролів. Він генерує та зберігає унікальні паролі для кожного облікового запису. Так ви створите кодові «слова», які складно піддаються атакам.

Додам, що надійні паролі потрібні й для вашої домашньої мережі Wi-Fi. Також уникайте підключення до публічної мережі Wi-Fi для здійснення конфіденційних транзакцій, якщо не використовуєте VPN.

Багатофакторна автентифікація (MFA)

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

Звичайно, така автентифікація зменшує ризик доступу зловмисників: якщо один із факторів (наприклад, пароль) виявиться скомпрометованим, інші фактори допоможуть захиститися.

Шифрування, безпечне з’єднання й обережна поведінка

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

Будьте пильними: не переходьте за підозрілими посиланнями, не завантажуйте вкладення з невідомих або небажаних електронних листів, перевіряйте адресу електронної пошти відправника. Не натискайте на рекламу, що з’являється раптово, або банери на підозрілих вебсайтах.

Усе це може призвести до інфікування вашого пристрою вірусами чи іншим шкідливим ПЗ, а підозрілі посилання можуть вести на шахрайські вебсайти, створені для витягання конфіденційної інформації або введення вас в оману (фішинг).

Також уникайте завантаження захищених авторським правом матеріалів із несанкціонованих джерел, оскільки вони можуть містити шкідливе програмне забезпечення.

Крім того, регулярно створюйте резервні копії важливих даних на зовнішньому носії або у хмарному сервісі, відстежуйте свої банківські рахунки та рахунки кредитних карток на наявність підозрілих транзакцій.

Пильність щодо фішингу

Як я зазначив раніше, фішинг – це дуже розповсюджений спосіб ввести вас в оману для досягнення різних зловмисних цілей. Тому варто пам’ятати про його ознаки.

Це підозрілі електронні листи, вимоги термінових дій, нелогічні URL-адреси, неочікувані вкладення чи посилання, спроби отримати особисту інформацію, граматичні й орфографічні помилки, нестандартні запитання, неочікувані привітання, зміни в інтерфейсі вебсайту, спам.

Кібербезпека підприємств

Звичайно, всі перелічені вище аспекти стосуються і бізнесів, і кінцевих користувачів. Організаціям не слід забувати, що в них працюють люди, і вони через свою необізнаність чи необережність можуть спричинити витік даних. Тому роботодавці повинні регулярно проводити навчання із кібербезпеки для своїх працівників, щоб вони могли розпізнавати загрози та реагувати на них.

Також бізнесам і підприємствам варто розробити стратегію реагування на потенційні порушення кібербезпеки: чим швидшою буде протидія, тим меншими – втрати.

Дотримуючись цих принципів, користувачі можуть значно знизити ймовірність того, що наступною жертвою хакерів стануть саме вони.

Проте варто пам’ятати, що посилення кібербезпеки – це безперервна робота. Універсальних рішень не існує, тож кожен користувач і бізнес мають знати свої слабкі місця. Підприємствам та організаціям я раджу звернутися до відповідних IT-компаній, щоб провести професійну оцінку загроз для кібербезпеки.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодну публікацію!

Освіта та демографічні характеристики

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

Серед працевлаштованих випускників Mate academy за 2023 рік таких 60%. Фахівців із попередньою вищою технічною спеціальністю – 33%, а тих, хто на момент початку роботи не мав вищої освіти, – 7%.

Найбільшою віковою групою для опанування ІТ є 16-24 роки – 52% працевлаштованих. 39% становить група віком 25-34 роки, а 9% – 35-45 років. Розпочати карʼєру можна й у віці 46+, таких спеціалістів серед випускників 0,3%.

Дані підтверджують і те, що ІТ – це не лише «чоловіча» робота. 37% від загальної кількості працевлаштованих випускників – жінки.

Якщо ж дивитися співвідношення від кількості студентів у конкретному напрямі, то найбільше їх у сфері UI/UX Design – 80%, а найменше у Software Development – 20%. Порівну чоловіків та жінок серед тестувальників.

Шлях до першої роботи в ІТ

Пошук роботи. Якщо у першому кварталі 2023 року кількість відгуків на вакансії задля успішного працевлаштування становила 235, то середня цифра за весь рік зросла до 270. Натомість ситуація з кількістю компаній, у яких кандидат має пройти етапи співбесід до першого офферу, залишалася стабільною весь період. У середньому це від 2 до 6 компаній.

Перша зарплата. У першому кварталі минулого року середня перша заробітна плата випускників становила $663. Середній показник за рік демонструє незначне зниження – $630.

У розподілі за напрямами спостерігається така ситуація: середня зарплата Frontend-розробників становить $518, Java – $733, Python – $563, QA – $591, UI/UX Design – $635.

Формат роботи та місцезнаходження. 39% випускників працюють з офісу, а 61% – на remote. 86% із них працевлаштовані в Україні, 14% – перебувають за кордоном.

Англійська залишається конкурентною перевагою для роботи в ІТ. 53% випускників володіють мовою на рівні Intermediate, 11,1% – Upper-Intermediate, 2,8% – Advanced. Хоча й випускники із нижчими рівнями (Pre-Intermediate – 25,7%, Elementary – 7,4%) змогли працевлаштуватися.

Попри те, що ринок праці не стає простішим для junior-спеціалістів, які тільки розпочинають карʼєру в ІТ, динаміка працевлаштування у 2023 році зберігалась майже на рівних.

За перші шість місяців 2023 року роботу знайшли 558 випускників Mate academy, за друге півріччя – 631. Тримати такі показники вдавалось і завдяки відносній стабільності найму саме продуктовими компаніями.

Підписуйтеся на ProIT у Telegram, щоб не пропустити жодну публікацію!