Аналіз глобального збою сервісів
Збій 1 лютого
Усі згадки часових міток вказано за UTC+2.
Починаючи з четверга, 1 лютого 2024 року, о 8:48 ранку, сервіси curioustudios почали повільно працювати, а невдовзі після цього сталися збої, що призвели до неможливості реагувати на будь-які запити. До цих сервісів належали бот Стицька, бот Ukraine Info, бот програми бета-тестування Ukraine Info, внутрішні бази даних, шлюзи сервісів штучного інтелекту та кілька сервісів, пов'язаних з моніторингом повітряних тривог в Україні.
Всі інші сервіси та боти, такі як бот Curiousity та аналітична база даних Стицька, працювали нормально, оскільки вони були розміщені на зовнішніх серверах.
Цей інцидент тривав з 1 лютого о 8:48 ранку до 9:43 ранку, коли всі сервіси повністю повернулися до нормальної роботи. Міграція бота програми бета-тестування Ukraine Info позначила кінець інциденту.
З чого все почалося
Інцидент почався з раптового падіння мережевого трафіку, і сервер перестав передавати будь-які дані на 5 хвилин (з 8:49 до 8:54 ранку). Щойно перед падінням мережевого трафіку, сервер почав фіксувати збільшення середнього навантаження:
О 8:49 ранку, відразу перед відключенням трафіку, сервер був завантажений на 100% ЦП.
Причина
На цьому знімку екрану, в кожній категорії (відсоток ЦП, обсяг читання I/O та Пам'ять (резидентна)) показано два кольори точок: один зелений, а інший - фіолетовий.
Будь ласка, майте на увазі, що ми зараз показуємо Пам'ять (резидентну), оскільки це буде важливо в майбутньому.
Зелений колір представляє процес під назвою mysqld. Це процес для, ну, MySQL. Як ви можете побачити на знімку екрану, він був запущений саме тоді, коли почався інцидент, що вказує на те, що він міг бути однією з причин інциденту.
Фіолетовий колір представляє процес під назвою unattended-upgr. Процес unattended-upgr в Ubuntu - це функція, яка дозволяє автоматично встановлювати оновлення безпеки на системі без необхідності втручання користувача.
Цей знімок екрану в UTC.
Як ви можете побачити, процес MySQL був запущений приблизно о 8:49 ранку, але ми також можемо побачити, як це відбувається під час роботи unattended-upgr, який також був запущений всього за хвилину до цього.
Ми покладаємося на unattended-upgr для забезпечення безпеки наших систем у будь-який час. Однак, чи міг він запустити MySQL? Цілком міг.
Раніше я сказав, що ми будемо вимірювати Пам'ять (резидентну) на той момент. Резидентна версія означає, що вона показуватиме лише пам'ять, яка використовується процесом. Якщо ми подивимося на Пам'ять (віртуальну), ми побачимо фактичний обсяг оперативної пам'яті, який виділено для процесу, що також може пояснити повільність та перевищення виділення пам'яті.
Подивившись на Пам'ять (віртуальну), ми відразу бачимо, що MySQL точно перевищує виділення оперативної пам'яті нашого сервера.
Що спричинило запуск MySQL та його велике використання?
У типовому системному налаштуванні, unattended-upgrades відповідає за автоматичне встановлення оновлень безпеки, включаючи оновлення для пакетів, таких як MySQL. Процес включає перевірку наявних оновлень та їх застосування без необхідності втручання користувача. Однак, важливо зазначити, що в логах не згадується пряма участь unattended-upgrades у запуску оновлення MySQL, і ми будемо шукати додаткові докази.
Запуск MySQL міг призвести до неочікуваних взаємодій між процесом оновлення та іншими сервісами або міг призвести до збільшення вимог до ресурсів. Один з прикладів цього - наш старий код бота Ukraine Info, який почав вимагати більше ЦП, коли не отримував того, що йому потрібно, що потім призвело до перевищення виділення та недоступності сервера.
Уроки, винесені, зміни, які будуть внесені
Ось деякі речі, які ми будемо впроваджувати протягом наступних місяців або тижнів:
встановити м'які ліміти на процеси та додатки, щоб запобігти повному відключенню
завжди залишати запасні ресурси
ізолювати та докеризувати всі додатки, щоб переконатися, що інші не постраждають від локальних збоїв (що відносяться тільки до одного додатка)
впровадити більше логування та моніторингу
повністю видалити застаріле або невикористовуване програмне забезпечення
планувати та виконувати ручні оновлення час від часу
покращити нашу систему сповіщень
спробувати не більше 3 разів запустити процес, якщо не вдається це зробити, щоб тримати використання ресурсів низьким, навіть якщо щось йде дуже не так 💥
Це деякі поліпшення, які ми будемо вносити, щоб уникнути інцидентів, які ми мали в минулому, включаючи цей.
Ми вибачаємося за будь-які незручності, спричинені 1 лютого, і ми покращимо себе настільки, наскільки це можливо, щоб переконатися, що таке ніколи знову не станеться. Поки ви тут, перегляньте наші проєкти ⬇️
🚜 Stytsko
🪐 Curiousity
- Артем
