Діагностика мережі: що ламається і як це знаходять
Плаваючі таймаути застосунків — найнеприємніший клас збоїв: сервіс відповідає за частки секунди, потім зависає на півхвилини, а при повторному зверненні працює штатно.
Затримки зростають у години пік, частина з'єднань обривається, але в логах застосунку чисто — розрив стався нижче, на маршруті. Інцидент закривають формулюванням «само минуло», хоча причина нікуди не поділася.
Нестабільне з'єднання рідко проявляється як повна відмова. Втрата пакетів у частки відсотка майже не видна в моніторингу, але змушує транспорт передавати дані заново: пропускна здатність падає в рази, ростуть черги, застосунок іде в повтори й таймаути.
Один сервер із пулу починає відповідати повільніше за інших, і балансувальник розмазує проблему по всьому сервісу.
Діагностика мережі будується від зовнішнього контуру до застосунку.
traceroute і mtr показують, на якій ділянці зростає затримка і де губляться пакети; iperf вимірює чисту пропускну здатність між двома точками й відділяє мережу від коду; nmap перевіряє доступність портів і правила фільтрації; tcpdump на обох кінцях з'єднання дає звірити, що пішло і що дійшло, а Wireshark розбирає один повільний сеанс по кроках.
Завдання — знайти вузьке місце на маршруті, а не підняти таймаути в конфігу й чекати наступного піку. Далі розбираємо, як це закривається на практиці: від зняття замірів до правок на боці мережі.
Вимірювані ефекти: затримки, втрати, час відновлення
Поки причину шукають за скаргами, лік іде на години.
Постійне захоплення трафіку на проблемних ділянках і трасування маршрутів переводять час локалізації інциденту з 4–6 годин у 20–30 хвилин: дані вже знято, залишається зіставити їх з моментом скарги, а не відтворювати збій заново з проханням «повторіть проблему».
Втрати пакетів і затримка відгуку перестають бути разовими замірами в момент аварії.
Безперервний замір за ключовими маршрутами з явними порогами дає сповіщення раніше за користувачів — на лінії тримається 0,1–0,5% втрат замість 2–5%, які роками списували на «поганий інтернет» і слабке обладнання абонента.
Змінюється й клас відмов. Іде категорія «шукали, не знайшли, перезавантажили»: замість неї — конкретна причина, прив'язана до ділянки й часу, і зрозумілий власник зміни.
Частка інцидентів, які закриваються всередині команди без ескалації на провайдера чи постачальника, зростає з половини до 85–90%, а повторні звернення з тієї самої причини майже зникають.
Спостережуваність інфраструктури працює і на довгій дистанції. Тривалість деградації для користувачів скорочується в рази: про звуження каналу чи зростання відгуку дізнаються з метрики, а не з дзвінків у підтримку, і встигають перемкнути маршрут до того, як це помітить бізнес.
Кожен розібраний інцидент залишає по собі правило оповіщення — наступний схожий випадок ловиться автоматично.
Формати діагностики мережі: розбір, моніторинг, регламент
Формат діагностики обирають не за терміновістю, а за тим, що потрібно на виході: причина конкретного збою, підтверджений факт доступності чи поточний стан тракту.
Разовий розбір інциденту відповідає на питання «що зламалося зараз», постійне спостереження — «коли зламається знову», регламент перевірок — «чи не деградувало непомітно».
Як обирати формат
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Разовий розбір інциденту | Деградація або обрив уже сталися, потрібна причина, а не статистика | Бачить лише момент зняття: плаваючий збій доведеться ловити повторно |
| Зняття даних з обладнання | Незрозуміло, на якій ділянці губляться пакети чи зростає затримка | Потрібен доступ на вузли й вікно робіт, глибина запису обмежена буфером |
| Моніторинг доступності | Потрібен сигнал раніше, ніж про проблему повідомить користувач | Показує факт відмови, але не причину — для розбору все одно потрібне зняття |
| Регламент перевірок | Регулярна звірка маршрутів, втрат і конфігурацій за розкладом | Ловить лише те, що проявилося в момент перевірки |
Під кожен сценарій фіксуємо метрику й поріг, за яким вмикається розбір: без порогу спостереження перетворюється на шум, а регламент — на формальність. На практиці підходи комбінують — зняття даних з обладнання дає первинну картину, далі обирають глибину.
Замовник отримує не розсип вивантажень, а схему мережі з позначеною точкою відмови й зрозумілим порядком дій.
Етапи робіт: від зняття симптомів до передачі регламенту
Діагностика мережі починається не із запуску аналізатора, а з фіксації симптомів: без хронології й розуміння, які зміни передували збою, зняття даних дає об'ємний дамп без відповіді.
Нижче — етапи діагностики, за якими ми ведемо роботу: від збору симптомів до регламенту, який залишається у вашої команди.
- Збір симптомів і хронології. Уточнюємо, що саме деградує — затримка, втрати, розриви, — на яких вузлах і в які інтервали, як відтворюється і що змінювалося перед першим проявом.
- Схема мережі та шляхів трафіку. Будуємо схему проходження трафіку: межі сегментів, балансувальники, перетворення адрес, тунелі. Так видно, де пакет може загубитися або піти в обхід очікуваного маршруту.
- Точки зняття даних. Обираємо ключові точки — на вході й виході проблемного сегмента, на самому вузлі й на сусідньому. Дампи та заміри знімаємо синхронно, з єдиною прив'язкою за часом.
- План перевірок. Гіпотези ранжуємо за ймовірністю і вартістю перевірки: спочатку відсікаємо дешеві версії, потім переходимо до навантажувальних замірів і трасування.
- Перевірка гіпотез. Зіставляємо дані з різних точок, звіряємо лічильники інтерфейсів, підтверджуємо або знімаємо версію. Кожна гіпотеза отримує однозначний висновок — «підтверджена» або «виключена».
- Фіксація результату й передача регламенту. Описуємо причину, внесену зміну конфігурації, набір контрольних перевірок і пороги, за яких варто повертатися до діагностики.
Матеріали на виході: схеми, заміри, регламенти
Діагностика закінчується не звітом, а артефактами, з якими ваша команда працює далі без нас. Нижче — мінімальний комплект: за ним можна повторити замір, пояснити поведінку сервісу й увести в контур нового інженера.
- Схема маршрутів: адресація, шлюзи, правила фільтрації, зовнішні виходи й зони, між якими трафік дозволено.
- Карти трафіку: хто з ким спілкується, за якими портами, яка частка службова, а яка — прикладна.
- Зафіксовані заміри: затримка, втрати та їхній розкид за ключовими напрямками — з датою, вузлом і способом зняття.
- Правила зняття даних: з яких вузлів, чим і в якому вікні знімати знімки трафіку, щоб порівняння були коректними.
- Каталог типових збоїв: симптом, імовірна причина, що перевірити першим.
- Порядок дій при деградації: послідовність перевірок від каналу до застосунку, з точками зупинки.
- Маршрут ескалації: до кого йти, якщо вузьке місце на боці провайдера чи зовнішнього сервісу.
- Передача знань: розбір із вашою командою і запис розбору, щоб контур залишався керованим.
Документи оформлюємо з версією й датою: схема та заміри без позначки про час перестають бути доказом уже через місяць після здачі.
Кейс: як локалізували періодичні обриви
Сервіс на кількох вузлах рвав з'єднання від трьох до п'яти разів на добу: сесії обривалися на середині операції, деградація трималася від п'яти до дванадцяти хвилин і минала сама.
Штатні системи спостереження фіксували лише сплеск затримки, а метрики застосунку не показували, де саме губляться пакети. Користувачі списували це на «нестабільний інтернет», команда — на навантаження.
Що показали заміри
Запустили безперервні заміри за всіма ділянками маршруту: mtr дав втрати в розрізі хопів, tcpdump на обох сторонах з'єднання — ретрансмісії й повтори підтверджень, розбір дампів у Wireshark — таймлайн кожного обриву.
На сусідніх сегментах було чисто, втрати виникали лише на одному проміжному вузлі й завжди збігалися в часі з піками трафіку. iperf між суміжними сегментами підтвердив, що пропускна здатність просідає втричі саме на цій ділянці.
Причина виявилася в неузгодженості режиму порту й переповненні буфера: під піком вузол мовчки відкидав пакети, не віддаючи лічильників помилок у звичні метрики.
Після приведення налаштувань порту до узгодженого режиму, заміни кабельної збірки й увімкнення контролю переповнення картина змінилася: частка повторних передач упала з 3% до 0,02%, обриви припинилися повністю.
До усунення деградація займала до 12 хвилин і повторювалася щодня, після — нуль інцидентів за квартал спостереження. У панель спостереження винесли окремі графіки повторних передач і втрат за хопами: наступне таке відхилення видно на етапі зростання, а не в момент скарг клієнтів.
Як зрозуміти, що вузьке місце — у застосунку, а не в каналі?
Розподіл відповідальності будується на двох незалежних наборах замірів: час обробки всередині застосунку і час у дорозі за ділянками передачі даних.
Якщо перший показник зростає, а другий залишається рівним, вузьке місце — у коді або в черзі до бази, і оптимізувати канал безглуздо. Зворотна картина вказує на мережу, і будь-яка правка застосунку там нічого не змінить.
Заміри на боці застосунку знімаються його ж засобами: тривалість обробки запиту за стадіями, час очікування зовнішніх викликів, частка часу в блокуючих операціях вводу-виводу, розмір віддаваних відповідей.
Ці дані не залежать від того, що відбувається між сервером і клієнтом, — тому вони й працюють як еталон при зіставленні.
Ділянки передачі даних перевіряються окремо.
Трасування маршруту показує, на якому вузлі з'являються втрати й приріст затримки; аналізатор трафіку (Wireshark або tcpdump) дає число повторних передач, переповнення вікна, розриви й повторні встановлення з'єднань; замір пропускної здатності між двома точками відповідає на питання, скільки канал реально віддає. Важливо знімати це на обох кінцях: одностороння картина бреше через асиметричну маршрутизацію.
Методика перевірки проста за ідеєю й вимагає дисципліни: заміри беруться одночасно, прив'язуються до спільного часу й зіставляються за одними й тими самими запитами. Зростання повторних передач або втрат на конкретній ділянці при незмінному часі обробки — винуватець канал.
Зростання часу обробки при чистому каналі й відсутності втрат — винуватець застосунок або суміжний сервіс, до якого він ходить.
Підсумок — не думка, а письмовий розбір з точкою відповідальності й доказами за кожною ділянкою. Спір із провайдером або власником суміжного сервісу перестає бути смаковим, а план робіт отримує пріоритети: спочатку лагодиться те, що підтверджено вимірюваннями.
Часті технічні питання щодо розбору інцидентів
Питання на старті майже завжди не про інструменти, а про ризик і відтворюваність. Плаваюча відмова, зняття на живому сервісі, чужі сегменти мережі й закритий контур виринають щоразу — нижче короткі відповіді на кожне.
Збій не відтворюється — як ви його піймаєте?
Плаваючу відмову ловлять не разовим запуском, а тривалим зняттям з кільцевим буфером: колектор тримає свіже вікно й перезаписує старе, тому після спрацювання алерту залишається картина до події.
Поруч звіряємо лічильники помилок і затримки за вузлами — відмова локалізується за спостереженнями, а не спробами вгадати момент.
Чи доведеться зупиняти сервіси на час зняття?
Ні. Захоплення йде на дзеркалюванні порту або на точці входу, не втручаючись у трафік; за потреби глибина обмежується заголовками. Заміри смуги й втрат між вузлами проводимо у вікна низького навантаження, щоб не спотворити картину.
Частина мережі нам не підконтрольна — що реально виміряти?
Зона відповідальності визначається замірами з двох кінців: зіставлення траси, втрат за хопами й розкиду затримки показує, де починається деградація.
Де доступу до обладнання немає, висновок будується за поведінкою трафіку й точками на вашому боці — цього достатньо для предметної розмови з провайдером.
Як часто повторювати заміри?
Разовий зріз відповідає на «що було», серія — на «як змінюється». Постійні метрики тримаємо на критичних маршрутах, а детальні дані знімаємо під інцидент і повторюємо після змін — так видно, чи допомогла правка.
Чи можна вести роботи в закритому контурі?
Так: зняття й розбір розгортаються на вашому боці, колектори пишуть локально, назовні йдуть лише агреговані метрики або звіт. Ідентифікатори й вміст пакетів маскуються, якщо цього вимагає політика.
Обговоримо вашу задачу й повернемося з планом перевірок
На першій розмові нам важливіше зрозуміти картину збою, ніж отримати готовий список команд. Що саме ламається: відвалюється зв'язок між сервісами, зростає затримка в частини користувачів, періодично рветься тунель або пропускна здатність не збігається з очікуваною.
Від відповідей залежить, чи знімаємо ми дампи трафіку, звіряємо втрати на маршруті чи вимірюємо швидкість між вузлами.
Щоб оцінка робіт спиралася на факти, а не на здогадки, до старту потрібні вихідні дані:
- схема мережі та перелік сегментів, між якими йде проблемний трафік;
- доступи з правами на читання конфігурацій, точки підключення до вузлів і вікна, коли можна запускати перевірки;
- опис симптомів: коли почалося, як часто повторюється, що фіксує моніторинг;
- які гіпотези вже перевірили і що змінювали в конфігураціях перед першим збоєм;
- обмеження майданчика: продуктивний контур, порядок погодження робіт, заборона на перезапуск сервісів у години навантаження;
- хто з боку замовника приймає результат і відповідає на уточнювальні питання.
Після цього повертаємося з оцінкою робіт і планом перевірок: що і в якому порядку дивимося, які гіпотези закриваємо на кожному кроці, де потрібні короткі вікна і що потрапить у звіт.
Порядок старту погоджуємо заздалегідь — збір даних іде без зупинки сервісів, а все, що потребує втручання, виносимо в окреме вікно.
Готові обговорити задачу — опишіть симптоми й обмеження, повернемося з оцінкою робіт і планом перевірок.
