Обновить

Падение Data Mart и 100 миллиардов записей в ОЗУ. История о том, как починить в одиночку вендорский баг

Время на прочтение6 мин
Охват и читатели10K
Всего голосов 28: ↑28 и ↓0+33
Комментарии14

Комментарии 14

МафиозО.

МафиозИ - это множественное число.

З.Ы. Спасибо за статью, очень познавательно.

А почему эта хранимка нормально работала до того дня, как все начало падать?

Судя по SQL запросу, выбирались данные за, примерно, 2.5 месяца. Видимо в какой-то момент времени записей за этот период стало сильно больше.

Наша служба и опасна и трудна
И на первый взгляд, как будто не видна
Если кто-то кое-где у нас порой
Честно жить не хочет
Значит с ними нам вести незримый бой
Так назначено судьбой для нас с тобой
Служба дни и ночи

:)

Я бы назвал это не ошибкой, а симптомом: ошибка в логе (например, нехватка памяти) — это симптом. Целью было — найти причину. В данном случае причиной был некорректный код вендора.

Инцидент произошел не в основной операционной базе, а в модуле аналитической обработки данных (Data Mart), который технически включает в себя отдельный сервер БД (на скрине с ошибкой база nice_dw ко к раз оттуда). Этот модуль выполнял фоновые ETL-процессы и, что ключевое, не был включен в перечень критически важных компонентов для мониторинга ни у заказчика, ни у сервисного партнера.

Вся архитектура мониторинга была заточена под основные базы и сервисы. Проблема же была в «слепой зоне» — фоновом процессе, который работал с архивной аналитической БД. Когда он падал, он вызывал цепную реакцию из-за повторяющейся большой нагрузки на БД.

Поэтому инженеру пришлось:
Локализовать эту «слепую зону».
Вручную мониторить процессы и логи именно этой базы данных.
Обнаружить и исправить ошибку в коде вендора.

Но вы согласны что в вашем мониторинге были слепые зоны?

Согласен. Но в данном кейсе задача мониторинга была на стороне заказчика (условия контракта). Сервисный партнёр подключается уже по факту инцидента. По итогам инцидента заказчику были переданы рекомендации по до настройке мониторинга

Детский лепет какой-то...
Пять дней искать ежечасную задачу в основной бд, хотя аналитическая система имеет отдельную бд.
Логи только на второй день начал смотреть...

И transaction log это не "место в оперативной памяти". Садитесь, два. Впрочем, видимо у вас просто нет DBA. Он мог бы съэкономить кучу времени

Спасибо за внимательность, поправил

Клепсидра крутится - заценил

Длинная цитата для контекста: теперь вас футболят техподдержкой

А в это время у заказчика уже весело. 250 супервайзеров опять пишут в свою техническую поддержку первой линии, первая линия пишет второй, а вторая говорит, мол, только отправили сервисному партнеру, ждите. Дальше обратно по цепочке предложение «обождать» возвращается

...

призывает к ответу своих подчиненных – инженеров первой и второй линии, на что специалист второй линии опять просит всех подождать. Самое время добавить сюда фото ждуна.

https://ru.wikipedia.org/wiki/Уроборос

Фонарщику Дане ночные часы честно оплатили?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Информация

Сайт
croc.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия