IT-інженер Назар Вергун про те, чому 80% українських компаній досі недооцінюють загрозу зупинки бізнесу

Про причини цієї ситуації, помилки українських керівників і практичні кроки, які варто зробити вже зараз, ми поговорили з IT-інженером Назаром Вергуном — сертифікованим Cisco AUCCE/DUCCE-спеціалістом з понад двадцятьма реалізованими проєктами розгортання, міграції й Cisco Contact Center, зокрема рішення лінійки Enterprise (UCCE / PCCE) та систем Express (UCCX) для клієнтів фінансового, промислового, телекомунікаційного і державного секторів. Cisco-стек, з яким він працював в Україні, є світовим стандартом для корпоративних контакт-центрів Enterprise-рівня, тож інженерна школа, яку представляє Вергун, безпосередньо співвідноситься з практиками аналогічних платформ у США, Європі й на Близькому Сході. З 2020 року він продовжує роботу в міжнародній продуктовій компанії, поєднуючи український інженерний досвід із запитами глобального ринку.

— Назаре, цифра 80% виглядає майже нереалістичною. Це маркетинговий алармізм чи справжня картина?

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

— З чого зазвичай починається деградація?

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

— Тобто головна проблема — управлінська?

— Технічних проблем завжди рівно стільки, скільки управлінська команда готова визнати. Я працював над впровадженням контакт-центрів Cisco Enterprise-рівня для великих замовників у 2015-2019 роках, і серед моїх проєктів були розгортання Cisco Packaged CCE, міграція Cisco UCCE, Cisco UCCE Contact Center Migration & Upgrade, програма стрес-тестування георозподілених систем між Києвом і Дніпром. Це системи, які обслуговують мільйони запитів на рік, з вимогою до безперервності 99,9% uptime. Різниця між компанією, яка спокійно проходить пікові навантаження, і компанією, у якої система лягає під час першого ж форс-мажору, лежить у розумінні керівництва: ІТ-інфраструктура — це актив, який має амортизацію, ризики і вартість заміщення.

— Які помилки в корпоративних мережах ви зустрічали найчастіше?

— Найпоширеніша — відсутність реального резервування там, де воно позначено на схемі. Формально компанія має два дата-центри або два канали зв'язку. Приходить аудитор, дивиться конфігурацію — виявляється, що обидва канали заходять в одну комутаційну шафу і йдуть через одного провайдера. У момент, коли цей провайдер має проблему, "резерв" виходить із гри разом з основним каналом. Друга помилка — відсутність тестування процедур відновлення. Резервні копії робляться, але ніхто ніколи не намагався відновити з них дані або протестувати їх відновлення. Коли настає година Х, з'ясовується, що бекап пошкоджений, застарілий або не містить критичних даних. Третя — концентрація адміністративного доступу в одних руках. Один системний адміністратор знає всі паролі, всі архітектурні рішення, логіку, а якщо він захворіє в невдалий момент, компанія втратить керованість.

— Що таке "точка відмови" в технічному розумінні і як вона з'являється?

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

— Як незалежний аудит запобігає фінансовим втратам?

— Технічному ризику завжди дешевше запобігти, ніж усувати його. Наприклад, аудит коштує Х-суму. Простій системи на 24 години коштує від 10-Х до 100-Х залежно від сектору. Втрата даних клієнтів коштує від 50-Х до нескінченності, тому що додається репутаційна шкода, штрафи, судові позови. Незалежний аудит потрібен саме тому, що внутрішня команда, навіть найкваліфікованіша, має конфлікт інтересів.

— Чому керівники все ж таки недооцінюють технічні ризики?

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

— Що б ви порадили керівникам зробити цього тижня?

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

— Як український інженерний досвід виглядає в порівнянні з міжнародними практиками?

— Дивно, але українська Cisco-школа сформувалася в умовах, які зробили її дуже сильною за міжнародними мірками. Наші фінансові установи впроваджували лінійки Enterprise (UCCE / PCCE) поверх мереж, у яких паралельно працювали legacy-системи попередніх поколінь, часто без нормальної документації. Кожен проєкт вимагав інвентаризації, реверс-інжинірингу, узгодження з підрядниками, які вже не працювали. Це формує тип інженера, який здатен зайти в незнайому інфраструктуру Fortune 500-компанії і за перші кілька тижнів побудувати з неї робочу карту. Найкращий індикатор того, що ринок цю навичку цінує — географія працевлаштування моїх колишніх колег. Понад половина з команд, з якими я працював, зараз розвиває кар'єру за кордоном. Це практичне підтвердження того, що українські фахівці нашого профілю відповідають міжнародним стандартам.

— Ваш прогноз на 2025 рік?

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