25 июня 2025 с 15:30 до 16:45 мск из-за массового запуска сборок в кластере с фронтенд-приложениями переполнился диск. Это вызвало приостановку работы эпсов.
⏳ Хронология
15:30 - зафиксировали рост нагрузки и заполнение диска в кластере 15:40 - нагрузка кратно выросла из-за десятков процессов npm build / start, появившихся после запуска сервисных компонентов 15:45 - 15:55 - вручную завершили лишние процессы, нагрузка начала снижаться 16:00 - фронтенд-приложения начали восстанавливаться 16:45 - запустили сервисные компоненты в штатном режиме, стабилизировали работу кластера
🛠️ Принятые меры
Чтобы избежать повторения подобных ситуаций и повысить устойчивость систем, мы:
1. Увеличим емкость кластера.
2. Пересмотрим механизм обработки очередей в сервисном агенте.
3. Ограничим число одновременных процессов для сервисных служб.
17 июня 2025 с 15:30 до 18:20 мск в S3 были зафиксированы два последовательных сбоя.
⏳ Хронология
15:30 - 15:50 - на одной из нод Ceph произошел сбой SFP-модуля. За ним последовали потеря доступа к объектам и блочным устройствам для части клиентов.
Через 20 минут проблемный линк был отключен, модуль заменен, а доступы восстановлены.
18:00 - 18:20 - при регистрации новых доменов для бакетов, Nginx начал часто перезагружаться, уперся в лимит открытых файлов, и перестал запускать воркеры. Как итог - полная недоступность S3 и сбой балансировки.
⚒️ Принятые меры
1. В первом случае заменили SFP-модуль на Ceph-ноде.
2. Во втором - повысили лимиты open files для Nginx и оптимизировали логику конфигурации доменов.
PS вчера ночью некоторые получили через нашего бота в телеге уведомление о сбое с поплывшим форматированием. Отправили по ошибке 🥲🙏
7 июня 2025 с 10:01 до 10:41 мск в одной из наших стоек в дата-центре IXcellerate Moscow South отказал автомат защиты питания во время работ на резервном вводе, из-за чего 5 нод с виртуальными серверами стали недоступны по сети.
⏳ Хронология событий
10:01 - мониторинг зафиксировал падение сетевых портов 10:02 - инженеры сообщили в NOC о недоступности серверов 10:18 - 10:23 - к устранению инцидента подключились инженеры ЦОД и представители дата-центра 10:41 - питание в стойке восстановлено, начат процесс анализа дисков и поэтапного запуска отключенных VDS
⚠️ Текущий статус
11:52 - работа всех виртуальных серверов полностью восстановлена
🔎 Причина
Выбило автомат защиты электропитания во время проведения плановых работ, которые проводил наш дата-центр. Иначе говоря, внеплановая аварийная ситуация на стороне ЦОД.
🛠️ Принятые меры
- Перераспределение питания в стойке силами дата-центра - Проверка дисков и восстановление работы всех затронутых серверов
Сегодняшний инцидент, затронувший ~1% виртуальных серверов, был связан с редкой ошибкой в автоматизированном процессе обновления libvirt. Ранее на этапах автоматических и ручных тестов проблема не воспроизводилась.
⏳ Хронология событий
1. 4 года назад была внедрена автоматизация для плановых обновлений libvirt (ежедневно 17:00–23:00 мск).
2. Вчера было проведено плановое обновление пакетов, включая libvirt.
3. Сегодня вечером сработал мониторинг на аномальные отключения серверов. Процесс обновления был экстренно остановлен, запущен процесс включения серверов. К 19:50 мск работа серверов была полностью восстановлена.
🔎 Корневая причина
Некорректный сброс флагов cgroups в процессе обновления (уникальный, ранее не встречавшийся кейс).
22 апреля 2025 г. произошел сбой в работе баз данных PostgreSQL во всех регионах. Проблема фактически началась около 14:40, была обнаружена в 15:10 и полностью устранена к 15:40. Общее время инцидента составило 1 час.
Причиной стало добавление нового расширения PostgreSQL, вызвавшее массовый перезапуск серверов из-за нестрогого порядка выполнения задач в Salt. Другие типы баз данных не пострадали.
Алерт не сработал своевременно, так как мониторинговая система интерпретировала перезапуски как часть штатного процесса обновления. Примем меры по улучшению системы мониторинга и настройке строгого порядка задач в Salt.
🛑 Функция создания и управления балансировщиками, базами данных и кластерами Kubernetes в Москве и Санкт-Петербурге временно недоступна по техническим причинам. Не переживайте, скоро включим обратно.
Начинаем работы по вводу в эксплуатацию, состоящие из 3 этапов:
1 этап. Вывод из эксплуатации текущего телекоммуникационного узла, с переключением магистралей, апстримов, пирингов и клиентской нагрузки на новый набор оборудования. Мы здесь
Планируем завершить до 10 февраля.
2 этап. Подключение серверов фильтрации: будут подключаться оптическими кроссировками в порты нашего сетевого оборудования, после чего будут настроены сенсоры и интегрирована существующая система защиты, с переносом нагрузки из кластера СПб.
Тут ждем модули, ориентируемся на поставку до 15 февраля. Плюс время на установку.
3 этап. Расширение каналов. Мы расширим трассу до дата-центра в несколько раз, позволяя предоставлять больше высокоскоростных услуг. Точные даты будут понятны после завершения первых двух этапов.
Timeweb Cloud Alerts🛑 Временно отключили работу с образами Во всех локациях, кроме Польши, будут недоступны создание и загрузка новых образов, а также удаление и скачивание уже созданных. Ориентировочно до 5 ноября. Списания за образы на этот период остановлены.
Включили создание и загрузку новых образов в Москве и Санкт-Петербурге.
Во всех локациях, кроме Польши, будут недоступны создание и загрузка новых образов, а также удаление и скачивание уже созданных. Ориентировочно до 5 ноября. Списания за образы на этот период остановлены.
