Перейти к основному содержимому

Сисадмин отрицал падения базы, пока разработчик не открыл детальный график

Разработчик заметил, что продакшен-база периодически теряет связь на одну секунду, но сисадмин утверждал, что всё в порядке. Проблему удалось подтвердить только после переключения графика в Grafana на детальный диапазон.

Утро после праздников началось с того, что у компании упал сервер — помощник админа приехал в офис почти к восьми. Разработчик, добравшись до рабочего места, получил от своего браузерного расширения уведомление об отключении базы, хотя самописный дашборд показывал все системы зелёными. Уведомление повторилось через полчаса, но сервак к тому моменту уже работал.

К девяти утра проблема стала очевидной: база на проде в среднем раз в полчаса теряла связь. Старый сисадмин, работающий в компании с самого открытия, настаивал, что ничего не падает и расширение разработчика просто не работает. Его графики в Grafana показывали ровную горизонтальную линию — но только потому, что данные были усреднены за несколько часов.

Разработчик переключил диапазон на последние пять минут и показал админу провал ровно на одну секунду. Сисадмин пробормотал, что «видимо, что-то было», и назначил разработчика ответственным за решение проблемы — раз уж тот её обнаружил. Доступ к серверу выдали, и после изучения логов выяснилось: база действительно вырубается через разные промежутки времени, но всегда на одну секунду, после чего поднимается сама.

Через пару часов разработчик оформил в самописном таск-трекере задачу на сисадмина с отчётом о возможных причинах и тремя вариантами решения со ссылками. Пока шло разбирательство, сотрудник отдела сопровождения сообщил, что у него не сохранились данные клиента — база падала пару минут назад. Сисадмин сделал вид, что не заметил этого. Позже выяснилось, что созданная задача из трекера пропала, а админ удивился вопросу о продвижениях по ней.

Почему это важно

История показывает, как усреднённые графики мониторинга скрывают короткие, но регулярные сбои, которые уже приводят к потере клиентских данных. Для бизнеса это означает, что «всё работает» со слов администратора — не аргумент: нужны детальные метрики и прозрачный трекер задач, где фиксируется ответственность. В условиях, когда доступ к инфраструктуре есть только у одного человека, а задачи бесследно исчезают, компании рискуют терять данные пользователей без возможности быстро найти виноватого и восстановить ход работ.

Источник: Habr. Материал пересказан ИИ-агентом.

Похожие статьи по теме

Почему ИИ не спасает от плохого кода: разбор Habr
Новости IT • 2 мин чтения

Почему ИИ не спасает от плохого кода: разбор Habr

Rust-разработчик Никита разбирается, почему при всех возможностях ИИ-агентов команды продолжают выпускать некачественный софт. Причина — не в инструментах, а в том, как выстроены приоритеты.

Читать статью полностью →
Как я семь раз обманул себя метриками точности ИИ-проверки ЕГЭ
Новости IT • 3 мин чтения

Как я семь раз обманул себя метриками точности ИИ-проверки ЕГЭ

Автор бота для проверки второй части ЕГЭ по обществознанию рассказал, как за полгода сменил четыре модели и нашёл семь случаев, когда его метрики показывали…

Читать статью полностью →
Разработчик четыре года вручную разбирал формат нотного редактора Score Perfect
Новости IT • 2 мин чтения

Разработчик четыре года вручную разбирал формат нотного редактора Score Perfect

Нотный редактор Score Perfect остался без поддержки после смерти единственного разработчика в 2012 году, а все партитуры в его закрытом формате SPP оказались заперты…

Читать статью полностью →