Дата публікації:
Публікація:
Є питання, яке я ставлю майже на кожній першій зустрічі з новим клієнтом. Ставлю його навмисно, навіть трохи провокаційно.
«Звідки ви дізнаєтесь, що щось пішло не так у вашому продукті?»
За кілька років я почув десятки варіацій одної й тієї ж відповіді. Іноді це звучить як «ну, у нас є дашборди», іноді — «наш DevOps моніторить сервери», іноді — просто збентежена пауза. Але найчесніша і, на жаль, найпоширеніша відповідь виглядає так: «Нам написав клієнт».
Це означає одне: на момент, коли ви дізнались про проблему, вона вже сталась. Хтось не зміг оплатити, оформити замовлення, завантажити файл, отримати результат. Хтось витратив свій час — і пішов. А ви про це дізнались із повідомлення в месенджері або з негативного відгуку.
Саме з цього місця і починається правильна розмова про моніторинг.
Слово «моніторинг» у більшості компаній асоціюється з чимось технічним і нудним. Це завдання для DevOps-інженера, набір графіків із показниками CPU і пам’яті, uptime-сповіщення о третій ночі. Щось важливе, але периферійне — з категорії «треба мати, але не треба розуміти».
Але питання не в тому, «чи працює система». Питання в тому, «чи працює бізнес-логіка так, як очікується».
Це принципово різні питання. І більшість систем моніторингу відповідають лише на перше.
Уявіть, що ви власник мережі ресторанів. У вас є термометри на всіх холодильниках, лічильники електроенергії, камери спостереження на входах. Ви знаєте, що обладнання працює.
Але це не означає, що кухар не переплутав інгредієнти. Що офіціант не забув про столик номер сім. Що касир не зробив помилку в рахунку. Що клієнт, який чекав сорок хвилин на замовлення, не пішов і не написав відгук.
Технічний моніторинг каже вам: «Холодильник працює, світло є, двері відчиняються».
Бізнес-моніторинг каже: «Клієнт сів, замовив, отримав страву за 18 хвилин, розрахувався і залишив чайові».
Одне без одного — неповна картина. Але більшість digital-компаній живуть тільки з першою частиною.
У Gart Solutions ми прийшли до простої моделі, яка допомагає нашим клієнтам побачити, де саме в них сліпа зона.
Перший рівень — інфраструктурний. Це основа. Сервери, процесори, пам’ять, мережа, uptime. Він відповідає на одне питання: система взагалі включена? Без цього рівня все інше безглуздо. Але сам по собі він не дає нічого, крім базової впевненості, що «лампочка не перегоріла».
Другий рівень — платформений. Це вже складніше. Бази даних: скільки підключень, як швидко виконуються запити, чи немає затримок. Черги повідомлень: наскільки швидко обробляються задачі, чи не накопичується бекло. Балансувальники навантаження, API-шлюзи, міжсервісна комунікація. Цей рівень відповідає на питання: «Шестерні крутяться?» Тут вже з’являється контекст — переповнена черга сигналізує, що процеси не встигають; повільна база даних пояснює зростання latency. Але навіть тут ще немає відповіді на питання, яке насправді хвилює бізнес.
Третій рівень — бізнес-логіки. Ось де починається найважливіше — і де найчастіше зяє порожнеча. Скільки транзакцій успішно завершились за останню годину? Яка частка користувачів доходить до фінального кроку в ключовому сценарії? Скільки часу займає критична операція — і чи відрізняється цей час від того, що ви обіцяли клієнту? Де саме в user flow виникають помилки?
Цей рівень не стандартизований. Для інтернет-магазину це може бути конверсія кошика в оплату. Для SaaS-продукту — час до першого «aha moment» нового користувача. Для логістичної платформи — відсоток замовлень, які перейшли з «прийнято» в «доставлено» без ручних втручань. Кожен продукт має свою бізнес-логіку — і саме тому цей рівень потрібно будувати вручну, з розумінням того, як насправді створюється цінність.
Один із наших проєктів, який ілюструє цей підхід — платформа elandfill.io, розроблена компанією ReSource International.
На перший погляд це звучить незвично: цифрова платформа для управління сміттєзвалищами. Але за цим стоїть дуже серйозна бізнес-задача. Полігони для відходів — це складні об’єкти з жорсткими регуляторними вимогами, екологічними ризиками та великими обсягами даних. Одне з ключових завдань — прогнозування викидів метану, що безпосередньо впливає і на безпеку, і на звітність перед регуляторами.
Щоб це робити, платформа збирає дані з дронів, перетворює їх на 3D-моделі полігонів і надає аналітику в реальному часі. Звучить просто — але «під капотом» це складна розподілена система з кількома взаємозалежними компонентами.
Уявіть такий сценарій: спеціаліст виїжджає на полігон, дрон виконує зйомку, і після повернення він завантажує отримані дані в систему. Файли при цьому зовсім не маленькі — від 2 до 10 гігабайт на одну зйомку.
Після завантаження запускається багатоетапний процес:
Спочатку файл приймається системою і проходить первинну валідацію. Потім — стиснення: дані оптимізуються для подальшої обробки. Далі запускається трансформація у 3D-модель — найважча частина всього процесу. Готова модель інтегрується з геопросторовими даними і відображається на мапі. І тільки після цього аналітик може працювати з результатом: оцінювати обсяги відходів, порівнювати зйомки в динаміці, прогнозувати екологічні показники.
Весь цей ланцюжок — це не «натиснути кнопку і почекати». Це послідовність залежних кроків, де збій на будь-якому етапі означає, що результату не буде взагалі. А очікування клієнта — конкретне: він завантажив файл і чекає, що за розумний час побачить готову модель.
Архітектура платформи розподілена між кількома компонентами: фронтенд, де працює користувач; бекенд-сервіси, які координують процес; черга повідомлень для асинхронних задач; сервіси обробки даних; і окремий 3D engine, який виконує найважчу частину роботи.
Останній компонент — особливий. 3D engine не працює постійно. Він запускається під конкретну задачу, споживає значні ресурси CPU і GPU, а після завершення — вимикається. Тобто система є динамічною: сервіси з’являються і зникають залежно від навантаження.
І ось тут класичний моніторинг просто не працює. Якщо сервіс зник — це нормально чи це проблема? Якщо 3D engine не відповідає — він ще обробляє задачу чи вже впав? Якщо черга порожня — це добре чи це означає, що задачі туди взагалі не потрапляють?
Без контексту бізнес-процесу будь-яка з цих ситуацій може виглядати і нормою, і катастрофою.
Ключове рішення, яке ми прийняли на старті: зміщення фокусу з моніторингу сервісів на моніторинг процесу.
Ми побудували єдину систему спостереження — частину ширшого Resource Management Framework — яка відображає не окремі компоненти, а повний життєвий цикл кожної задачі.
Центральний дашборд показує в реальному часі: статус кожного сервісу платформи, версії застосунків, час останньої активності («last seen») кожного компонента, стан кожного етапу обробки для поточних задач, час виконання кожної операції та відхилення від очікуваної норми, а також помилки та вузькі місця.
При цьому нові сервіси, які динамічно з’являються в системі, автоматично реєструються в моніторингу — без ручного налаштування. Платформа може масштабуватись, і система спостереження масштабується разом з нею.
Ми реалізували підхід, де monitoring, observability і automation працюють як єдина система.
Observability — це збір і структуризація даних по всьому ланцюжку, від UI до обробки. Не просто логи окремих сервісів, а контекстна картина: що саме відбувається з конкретною задачею прямо зараз і на якому вона кроці.
Monitoring — контроль ключових параметрів з прив’язкою до бізнес-норм. Не просто «CPU — 80%», а «обробка файлу на третьому етапі займає вже 12 хвилин при нормі 5 хвилин». Не просто «черга непорожня», а «в черзі накопичилось 15 задач, і жодна не обробляється вже 3 хвилини».
Alerting — автоматичні сповіщення при відхиленнях. Важливий нюанс: сповіщення інтегровані з Microsoft Teams, тобто команда отримує їх там, де вже працює, а не в якомусь окремому інструменті, який ніхто не відкриває. Сповіщення при цьому містять контекст: не просто «щось пішло не так», а «задача ID 4821 застрягла на етапі компресії, час очікування 8 хвилин, очікувана норма 2 хвилини».
Automation — і це, мабуть, найважливіший рівень. Система не просто сигналізує — вона діє. При сплеску навантаження автоматично запускається скрипт оптимізації. При збої сервісу — перезапуск. При перевантаженні одного вузла — маршрутизація задач на інший. Це те, що ми називаємо self-healing system: система, яка не просто фіксує проблему, а самостійно її вирішує або мінімізує вплив до того, як це помітить людина.
Результати цього підходу виявились значно глибшими, ніж просто «менше аварій».
Перше — повна прозорість процесу. Весь шлях від завантаження файлу до готової 3D-моделі видно в одному місці. Не потрібно збирати картину з п’яти різних інструментів і логів.
Друге — швидка діагностика. Коли щось іде не так, команда бачить одразу: на якому конкретно етапі виникла проблема, скільки часу вже триває відхилення, які задачі потенційно під загрозою. Час від «щось не працює» до «ось що і ось чому» скоротився з годин до хвилин.
Третє — контроль SLA. Тепер можна не просто обіцяти клієнту, що «обробка займе кілька хвилин», а чітко визначити і контролювати конкретні параметри: стиснення — до 3 хвилин, трансформація у 3D — до 15 хвилин залежно від розміру файлу. І миттєво реагувати, якщо реальність відхиляється від обіцяного.
Четверте — оптимізація витрат. Ресурсоємні компоненти — зокрема 3D engine — тепер точно відомо, коли запускаються і скільки споживають. Це дає змогу оптимізувати витрати на інфраструктуру, не жертвуючи якістю сервісу.
Завдяки цьому платформа змогла впевнено вийти на міжнародний ринок — з впровадженнями в Ісландії, Франції та Туреччині. Не тому, що стала «технічно стабільнішою» в абстрактному сенсі, а тому, що команда отримала інструмент, з яким можна впевнено брати на себе зобов’язання перед клієнтами — і виконувати їх.
Я хочу бути чесним: побудувати правильний моніторинг непросто. І не тому, що бракує інструментів — їх якраз більше, ніж достатньо. Складно з іншої причини.
Щоб моніторити бізнес-логіку, потрібно спочатку її сформулювати. Які саме процеси є критичними? Яка норма виконання для кожного з них? Що саме є «проблемою» — а що просто варіацією, яка не потребує реакції?
Це не технічні питання. Це питання розуміння продукту. І відповідати на них мають не лише інженери — а разом з ними продуктові менеджери, власники бізнесу, іноді навіть клієнти.
Саме тому ми в Gart Solutions починаємо будь-який проєкт з моніторингу не з вибору інструментів, а з workshop: разом з командою клієнта ми описуємо ключові бізнес-сценарії, визначаємо норми, домовляємось про те, що вважати відхиленням. Тільки після цього стає зрозуміло, що саме моніторити — і тоді технічна реалізація йде значно простіше.
Моніторинг — це не технічна функція. Це управлінський інструмент.
Коли він побудований правильно, він дає helicopter view: ви бачите, де процеси працюють злагоджено, де є напруга, де виникають проблеми — і бачите це до того, як вони стають відчутними для клієнта.
Це змінює і характер роботи команди. Замість «щось не працює, треба розібратись» з’являється «на третьому етапі обробки затримка зросла вдвічі за останні 20 хвилин, ось причина, ось рішення». Замість реактивного гасіння пожеж — проактивне управління якістю сервісу.
Найкращий момент для того, щоб побудувати цю систему — до першої серйозної аварії. Тому що після неї ціна питання стає зрозумілою, але час для підготовки вже втрачено.
Gart Solutions. Ми будуємо системи моніторингу, observability і автоматизації для технологічних компаній, що масштабуються.
