Серія: «Історія Vezha тиждень за тижнем» • Випуск від 20.04.2026
У #098 ми додали в Vezha реальний парсинг access.log, RPS та error rate для раннього виявлення підозрілої активності. Після цього кроку зворотний зв’язок від команд експлуатації був дуже конкретним: «Сигнал є, тепер дайте спосіб так само швидко зібрати доказову картину інциденту, щоб не робити це руками».
Цей запит став центром випуску #099. Ми додали у web-stats 7-денний forensic PDF-звіт по error IP. Його завдання не в тому, щоб створити ще один «красивий» графік, а в тому, щоб дати команді готовий документ для дій: локалізація, ескалація, відновлення.
Контекст: де ламався процес до цього релізу
У більшості продакшн-контурів картина типова. Аномалію видно швидко: росте частка 4xx/5xx, змінюється профіль трафіку, з’являються повторювані запити до чутливих endpoint-ів. Але між «бачимо проблему» і «прийняли рішення» утворюється ручний проміжок.
Зазвичай цей проміжок виглядає так:
- черговий інженер фільтрує логи по часовому вікну;
- окремо вибирає IP-адреси з найбільшою часткою помилок;
- зводить проміжні висновки в таблицю або тікет;
- пояснює колегам, чому саме ця активність заслуговує на реакцію прямо зараз.
Найслабше місце тут очевидне: команда витрачає ресурс не на дію, а на підготовку матеріалу для дії. У пікові години це найдорожча втрата часу.
Що з’явилося у #099
Нова можливість у web-stats формує 7-денний forensic-звіт у PDF за один керований запуск. Користувач працює в одному контурі: не перемикається між кількома інструментами, не копіює дані вручну, не збирає доказову базу «з нуля».
У результаті команда отримує:
- структурований зріз по error IP за обраний період;
- динаміку активності по часу для виявлення повторюваних хвиль;
- готовий документ для SOC/безпеки, SRE та менеджера інциденту.
Ключова ідея проста: віддати людям не «сирі фрагменти», а матеріал, з яким можна одразу ухвалювати рішення.
Як побудовано процес під капотом
Ми не робили монолітний «довгий» запит, який складно контролювати і ще складніше відновлювати при збоях. Замість цього реалізували етапний pipeline із видимим прогресом у UI.
- Запуск задачі: оператор ініціює forensic-збір із web-stats.
- Сканування вікна: агент послідовно проходить часовий інтервал і готує агреговані дані.
- Поетапна передача: дані надсилаються частинами, без «важкого» одноразового вивантаження.
- Фінальна збірка: сервер зводить результат, формує підсумковий пакет і рендерить PDF.
- Експорт: готовий файл віддається в той самий робочий контур, де команда веде інцидент.
Такий підхід дає дві переваги одночасно: передбачуваність для оператора і стабільне навантаження для системи.
Що змінилося для різних ролей команди
Ми оцінювали реліз не тільки через технічну реалізацію, а через те, як ним користуються різні ролі в одному інциденті.
Для NOC/чергового: зникає потреба руками пояснювати, чому сплеск помилок не є «випадковим шумом». Є готовий документ із чіткою структурою.
Для SRE: простіше погодити зміни на периметрі, rate-limit або сценарій ізоляції, коли доказова база вже зібрана й уніфікована.
Для безпеки/SOC: швидше стартує власний процес аналізу, тому що дані надходять у придатному форматі, а не «у вигляді сирих уривків».
Для менеджера зміни: рішення ухвалюються швидше, бо всі дивляться на одну і ту саму фактологію, а не на різні версії ручних нотаток.
Анонімізований практичний кейс
На одному контурі команда побачила помірне, але стабільне зростання частки 4xx у вечірні години. Загальний RPS не виходив за очікувані межі, тож без додаткового аналізу ситуація могла виглядати як «тимчасовий шум».
Після запуску 7-денного forensic-звіту стало видно повторюваний патерн: активність концентрувалась на невеликому наборі endpoint-ів і мала хвильову форму з майже однаковими інтервалами. Це дозволило швидко узгодити кроки між командами:
- посилити правила захисту на периметрі для конкретних сценаріїв звернень;
- уточнити ліміти для окремих шаблонів запитів;
- зафіксувати інцидентний розбір у єдиному документі без ручного дублювання.
Найважливіше у цьому кейсі: команда перейшла від обговорення симптомів до дій у межах однієї зміни.
Границі безпеки й комерційної моделі
Forensic PDF по error IP доступний у Total-плані. Це усвідомлене рішення, бо саме в цьому сегменті найвищий попит на поглиблений incident-response, віддалені операції та стабільний регламент реагування.
При цьому ми не змішуємо цілі: базовий моніторинг і щоденні метрики залишаються доступними ширше, а «важкий» інцидентний шар активується там, де він справді потрібен бізнесу щодня.
Що це означає для стратегії Vezha
Цей реліз добре відображає підхід neemle до розвитку продукту. Vezha залишається малою, швидкою та захищеною платформою реального часу, побудованою на Rust, із централізованим керуванням точками моніторингу. Кожне оновлення має давати користь у production без збільшення операційної складності.
7-денний forensic-звіт якраз про це:
- менше ручної рутини у критичний момент;
- швидша передача контексту між ролями;
- чіткіші рішення на основі фактів, а не припущень.
Також важливо, що Vezha має вбудоване проксування до Prometheus, тому нові можливості природно вбудовуються в існуючі контури спостереження без потреби «переламувати» процеси команди.
Операційний ефект у цифрах процесу
Ми свідомо вимірювали не лише технічні метрики, а й поведінкові показники команди під час інцидентів. Після появи forensic PDF скоротився час до першого узгодженого рішення, зменшилась кількість ручних проміжних артефактів, а синхронізація між змінами стала передбачуванішою.
Іншими словами, продукт не просто «бачить проблему», а допомагає команді стабільно доводити інцидент до результату.
Як використовувати звіт у перші 30 хвилин інциденту
Щоб реліз давав максимум користі, ми рекомендуємо простий робочий ритуал, який команда може запускати одразу після тригера аномалії. Він не вимагає окремих інструментів і добре лягає в стандартний операційний процес.
- Зафіксуйте подію. Визначте часове вікно, коли почалося відхилення, і створіть інцидентний контекст у вашому трекері.
- Запустіть forensic PDF у web-stats. Це дає єдину фактологію для всіх учасників інциденту.
- Відокремте шум від ризику. Подивіться, які IP та шаблони звернень формують ключову частку помилок.
- Прийміть тактичне рішення. Погодьте перший набір дій: фільтрація, rate-limit, зміни на периметрі, ескалація в SOC.
- Зафіксуйте пост-дії. Після стабілізації середовища додайте в беклог структурні покращення, щоб зменшити повторюваність кейсу.
Коли цей цикл відпрацьований, команда менше імпровізує в «гарячому» режимі і швидше переходить до керованого сценарію реагування.
Типові помилки, яких допомагає уникнути #099
Під час інтерв’ю з технічними командами ми постійно бачили кілька повторюваних anti-pattern сценаріїв. Новий звіт не «виліковує» їх автоматично, але зменшує ймовірність помилки завдяки структурі даних.
- Помилка №1: реакція лише на RPS. Високий трафік сам по собі не завжди проблема. Ключовий сигнал часто в дисбалансі між обсягом і часткою помилок.
- Помилка №2: фрагментарний аналіз по одному часовому відрізку. Без 7-денного вікна легко пропустити повторювані хвилі.
- Помилка №3: рішення «на словах» без документованої фактології. Це створює хаос при передачі інциденту між змінами.
- Помилка №4: надто пізня ескалація. Якщо доказова база збирається повільно, команда втрачає вікно для дешевого і швидкого втручання.
Саме тому ми зробили акцент на PDF-форматі: він дисциплінує процес, стандартизує комунікацію і зменшує «ефект зламаного телефону» між ролями.
Де ця можливість дає найбільший ефект
З нашого досвіду, максимум користі отримують контури, де інцидентний цикл уже існує, але «буксує» на етапі підготовки даних. Найчастіше це:
- e-commerce та high-load сервіси з хвилеподібним трафіком протягом доби;
- SaaS-платформи, де частина endpoint-ів має підвищену чутливість до автоматизованих запитів;
- інфраструктури з розподіленими командами, які працюють у кількох змінах або географіях.
У таких середовищах вирішальним стає не тільки факт виявлення, а швидкість переходу до узгодженої реакції. #099 якраз закриває цю прогалину.
Практичний чеклист перед увімкненням у вашому контурі
Щоб запуск пройшов гладко, ми радимо перед демонстрацією пройти короткий readiness-чек:
- узгодити, хто в команді є owner інцидентного рішення у вечірні/нічні зміни;
- визначити стандартний канал ескалації (SOC, SRE lead, on-call менеджер);
- зафіксувати «поріг дії» для запуску forensic-процесу, щоб уникати зайвих коливань;
- домовитися, які post-incident дії обов’язково потрапляють у backlog після стабілізації.
Це займає небагато часу, але різко підвищує якість першого місяця використання функції.
Підсумок випуску #099
У цьому тижні немає гучних обіцянок. Є практичний крок, який щодня економить час і знижує хаос у критичних ситуаціях. Саме такі кроки формують зрілий продукт: коли кожен реліз полегшує роботу команди в реальному середовищі.
Якщо хочете подивитися, як цей сценарій працює у вашому контурі, залишайте запит на демо на vezha.io. Покажемо, як Vezha інтегрується в поточну інфраструктуру з нульовим CAPEX і чесним OPEX для масштабування.
Хочете перевірити Vezha на вашій інфраструктурі? Перейдіть на vezha.io та надішліть запит на демо.