Вступ
Сайти клієнта почали регулярно виходити з ладу вранці. Проблема виглядала як черговий збій веб-сервера, але це повторювалося занадто регулярно, щоб вважати це випадковістю.
Що було не так
О 5:30 запускалося автоматичне оновлення панелі. Воно перезапускало мережеві служби та nginx. Після цього nginx запускався раніше, ніж сервер встигав отримати потрібну IP-адресу. У результаті HTTPS тимчасово не працював, а сайти виглядали неактивними.
Діагностика
- порівняно час недоступності з графіком оновлення панелі;
- перевірено журнали доступу та помилок;
- перевірено порядок запуску мережевих служб та nginx;
- перевірено відповіді доменів після ручного відновлення;
- вирішено проблему в самому WordPress/коді сайту.
Що було зроблено
- відключено автоматичне оновлення панелі в безпечному режимі;
- додано механізм автоматичного перезапуску nginx;
- перевірено доступність доменів;
- підготовлено план щодо закріплення IP-адреси або зміни параметра `listen`, щоб nginx не залежав від гонки запуску мережі.
Результат
Збої перестали здаватися чимось надприродним. Причину було виявлено на основі логів та аналізу часу, після чого сайт повернувся до нормального режиму роботи, а ризик повторення було знижено завдяки технічним виправленням.
Що слід контролювати надалі
Після таких інцидентів важливо окремо перевіряти оновлення панелі, перезапуск мережевих служб та поведінку nginx після перезавантаження системи або перезапуску служби.